idnits 2.17.1 draft-noisternig-ipdvb-sec-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 74 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2009) is 5401 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) == Missing Reference: '14' is mentioned on line 945, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '8') (Obsoleted by RFC 6407) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPDVB Working Group M. Noisternig 2 Internet Draft University of Salzburg 3 Intended status: Standards Track P. Pillai 4 Expires: January 2010 University of Bradford 5 H. Cruickshank 6 University of Surrey 7 July 13, 2009 9 Security Extension for Unidirectional Lightweight Encapsulation 10 Protocol 11 draft-noisternig-ipdvb-sec-ext-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 13, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The Unidirectional Lightweight Encapsulation (ULE) protocol provides 49 an efficient mechanism for transporting IP and other network layer 50 protocol data over MPEG-2 networks. Such networks, widely used 51 especially for providing digital TV services, often use broadcast 52 wireless transmission media, and are hence vulnerable to various 53 types of security attacks. 55 This document describes a new mandatory ULE extension to protect ULE 56 traffic using security features such as data confidentiality, data 57 integrity, data origin authentication, and prevention against replay 58 attacks. Additionally, destination addresses may be hidden from 59 unauthorized receiver devices using the identity protection feature. 61 The format of the security extension header as well as the processing 62 at receivers and transmitters are described in detail. The extension 63 aims to be lightweight and flexible such that it may be implemented 64 in low-cost, resource-scarce transceivers, and different levels of 65 security may be selected. 67 The security extension may be easily adapted to the Generic Stream 68 Encapsulation (GSE) protocol, which uses a similar extension header 69 mechanism. 71 Table of Contents 73 1. Introduction ................................................. 3 74 2. Requirements Notation ........................................ 4 75 3. Abbreviations used in this document .......................... 4 76 4. Security Services ............................................ 5 77 5. Secure ULE SNDU Format ....................................... 7 78 5.1. Type Field .............................................. 9 79 5.2. Receiver Destination Address Field ...................... 9 80 5.3. ULE-SID Field ........................................... 9 81 5.4. Encrypted Destination Address Field ..................... 9 82 5.5. SA-Dependant Data Field ................................ 10 83 5.6. Encrypted Next-Type Field .............................. 10 84 5.7. Encrypted Payload ...................................... 10 85 5.8. Message Authentication Code (MAC) Field ................ 10 86 6. Transmitter and Receiver Processing ......................... 11 87 6.1. Security Policy Database (SPD) ......................... 12 88 6.2. Security Association Database (SAD) .................... 13 89 6.3. Transmitter Processing ................................. 14 90 6.4. Receiver Processing .................................... 16 91 7. Key Management Considerations ............................... 18 92 7.1. MSEC/IPsec Key Management Protocols .................... 19 93 7.2. Existing L2 Key Management Infrastructure .............. 19 94 7.3. Other Considerations ................................... 19 95 8. Security Considerations ..................................... 19 96 9. IANA Considerations ......................................... 21 97 10. Acknowledgments ............................................ 21 98 11. References ................................................. 22 99 11.1. Normative References .................................. 22 100 11.2. Informative References ................................ 22 102 1. Introduction 104 The Unidirectional Lightweight Encapsulation (ULE) protocol [3] 105 provides an efficient mechanism for transporting IP and other network 106 layer protocol data over ISO MPEG-2 Transport Streams (TS) [1]. This 107 document describes a new ULE mandatory extension header for providing 108 link layer security for ULE. 110 In MPEG-2 transmission networks employing ULE there is a need to 111 provide link layer security, particularly where network layer and 112 transport layer security may not be present or may not be sufficient. 113 The security requirements are presented and discussed in detail in 114 [4]. The set of security services that the security extension for ULE 115 can provide includes data confidentiality, data integrity, data 116 origin authentication and rejection of replayed packets. While 117 providing suitable link encryption is mandatory, link layer data 118 integrity and data origin authentication is provided as an optional 119 security service. These are especially desirable for systems where 120 there are several ULE transmitters (e.g., satellite mesh systems). 122 The extension also supports what is called 'identity protection' in 123 this specification. This allows hiding destination addresses from 124 unauthorized receiver devices, thus enabling a form of traffic flow 125 confidentiality. 127 The method described in this document provides security for ULE SNDUs 128 at the link layer, in contrast to higher-layer mechanisms, such as 129 IPsec [7] and TLS [10]. This allows protecting any network layer 130 protocol (even with Ethernet bridging), while higher-layer security 131 may be used independently and in parallel. Link-layer signalling 132 information may be protected as well. 134 The processing specification follows the IPsec approach of defining a 135 Security Policy Database (SPD) and a Security Association Database 136 (SAD). A Security Identifier (SID), similar to the Security Parameter 137 Index (SPI) in the IPsec protocols, assists receiver devices in 138 looking up security states. The design of the databases for ULE 139 security is similar but simpler because unlike in IPsec a receiver 140 only needs the SID along with the NPA address and possibly the PID to 141 retrieve the data from these databases. 143 Key management protocols assuming similar processing functionality, 144 such as the MSEC Group Domain of Interpretation (GDOI) [8] and the 145 Group Secure Association Key Management Protocol (GSAKMP) [6], may be 146 adapted for the ULE scenario. Simple configurations are supported 147 using manual keying (i.e., pre-shared keys). 149 Security transforms such as encryption algorithms may be modelled 150 after existing MSEC and IPsec security algorithms, but will be 151 defined in separate documents in order to proceed/update them 152 independently of this specification. 154 The ULE security extension is designed for both bi-directional and 155 unidirectional links, as well as unicast and multicast settings [9]. 157 2. Requirements Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [2]. 163 3. Abbreviations used in this document 165 AES - Advanced Encryption Standard 167 DES - Data Encryption Standard 169 DVB - Digital Video Broadcasting 171 GDOI - Group Domain of Interpretation 173 GSKAMP - Group Secure Association Key Management Protocol 175 GSE - Generic Stream Encapsulation 177 IPsec - Internet Protocol Security 179 MPE - Multi-Protocol Encapsulation 181 MAC - Message Authentication Code 183 NAT - Network Address Translation 184 NCC - Network Control Centre 186 NPA - Network Point of Attachment 188 PEP - Protocol Enhancing Proxy 190 PID - Packet Identifier 192 PDU - Protocol Data Unit 194 SAD - Security Association Database 196 SID - Security Identifier 198 SHA - Standard Hash Algorithm 200 SNDU - Subnetwork Data Unit 202 SPD - Security Policy Database 204 SPI - Security Parameter Index 206 TLS - Transport Layer Security 208 ULE - Unidirectional Lightweight Encapsulation Protocol 210 VPN - Virtual Private Network 212 4. Security Services 214 MPEG-2 based networks are susceptible to several security attacks, 215 both passive and active [4]. Some of the main security services 216 (mandatory or optional) that the security extension for ULE provides: 218 o Data confidentiality (mandatory): Data confidentiality is 219 achieved by encrypting the higher layer PDU (and other ULE 220 extensions headers that may be present and require security) 221 before encapsulation in the ULE SNDU, so that only authorised 222 receivers can decrypt the transmitted information while an 223 adversary would not be able to recover the important information 224 even if it got access to the transmitted data. 226 o Receiver address hiding (optional): Hiding an SNDU's real 227 destination NPA address from an adversary is an important step in 228 providing identity protection. While one solution for this is to 229 use temporary addresses, this is susceptible to various practical 230 issues. More importantly, from a security point of view, temporary 231 addresses do not provide adequate identity protection, as a 232 passive adversary may easily link different SNDUs to the same 233 connection. Also, a procedure to allocate temporary addresses is 234 required such that they are unique in the system. Hence it is 235 proposed to encrypt the destination address. By encrypting the 236 destination address within the SNDU, an attacker is effectively 237 denied from gaining information by monitoring addresses. 239 o Data origin authentication (optional): Data origin (source) 240 authentication allows a ULE receiver to verify data as sent by a 241 legitimate ULE sender. A Message Authentication Code (MAC) using a 242 shared secret key may be used to authenticate the sender in 243 unicast settings, or to guarantee an SNDU originating from a group 244 member in secure group communication. For the latter, other source 245 authentication schemes, such as digital signatures, may be used to 246 assure source authenticity. 248 o Data integrity (optional): Data integrity provides a way for the 249 receiver of the data message to know if the data has been tampered 250 with in transit by an attacker. This is provided for by the data 251 origin authentication algorithm. A change in the message will 252 alter the authentication value, and an adversary will unlikely be 253 able to derive a correct one. 255 o Replay attacks countermeasures (optional): Methods against replay 256 attacks need to ensure that an adversary has not replayed old 257 authentic messages at a later time. A monotonically increasing 258 sequence number may be part of the SA-dependent data field of the 259 security extension header, allowing messages with old sequence 260 number values to be rejected. As with other security services, the 261 choice of using sequence numbers is dictated by policy, usually 262 effected by the key management system. 264 Note that sequence numbers resemble unkeyed connection states that 265 an adversary may track to link packets to different connections. 266 Therefore, use of sequence numbers is not mandated. One solution 267 is encrypting sequence numbers using standard Electronic Code Book 268 (ECB) mode (i.e., encrypt as one block of data). A receiver first 269 decrypts the encrypted value within the protocol to check for a 270 replay, and then may use either the encrypted value as an 271 initialization vector for the Cipher Block Chaining (CBC) mode of 272 operation, or the decoded sequence number for the Counter (CTR) 273 mode (with the internal counter incremented by one). The 274 disadvantage is a slightly higher protocol overhead compared to 275 unencoded sequence numbers. Another solution is to use connection- 276 independent timestamp values. Depending on the resolution, 277 timestamps may or may not provide perfect replay protection. The 278 drawback is a higher protocol overhead, including the need for 279 synchronized clocks. 281 5. Secure ULE SNDU Format 283 Figure 1 below shows the format of an SNDU containing the security 284 extension header. The extension header is designed as a framework for 285 a set of security transforms, enabling high flexibility in selecting 286 various security services (including common encryption algorithms 287 such as DES [11], 3DES, AES [12], etc.). Security transforms are to 288 be described in separate documents, and will be based on algorithms 289 defined for the MSEC/IPsec protocols. 291 The ULE security extension is a standard extension header as 292 described in Section 5 of RFC 4326 [3], and does not affect the ULE 293 base protocol. Furthermore, the extension is a Mandatory ULE 294 Extension header, which means that a receiver MUST process this 295 header before it processes the next extension header or the 296 encapsulated PDU, otherwise the entire SNDU should be discarded. 298 When configuring use of the security extension at encapsulation 299 devices, it is RECOMMENDED to place the extension header directly 300 after the base header. This permits full protection for all headers. 302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 303 +-+----------------------------+------------------------------+ 304 |D| Length | Type = Secure-ULE | 305 +-+----------------------------+------------------------------+ 306 | Receiver Destination NPA Address (D=0) | 307 | +------------------------------+ 308 | | ULE-SID | 309 +------------------------------+------------------------------+ 310 | Encrypted Destination NPA Address (optional) | 311 +------------------------------+------------------------------+ 312 | | 313 = SA-Dependant Data (optional) = 314 | | 315 | +------------------------------+ 316 | | Encrypted Next-PDU Type | 317 +------------------------------+------------------------------+ 318 | | 319 | | 320 = Encrypted PDU = 321 | | 322 | | 323 +------------------------------+------------------------------+ 324 | | 325 = Message Authentication Code (optional) = 326 | | 327 +-------------------------------------------------------------+ 328 | Cyclic Redundancy Check | 329 +-------------------------------------------------------------+ 330 Figure 1. General SNDU format with security extension header 332 In Figure 1, the Type field in the base header denotes that a 333 mandatory security extension header is present. The receiver 334 destination NPA address is optional (dependent on the D bit). The 335 security extension header follows the ULE base header. This header 336 contains the ULE Security Identifier (SID), an optional Encrypted 337 Destination Address, a variable-length field whose content is 338 determined by a Security Association (SA), and an encrypted Type 339 field denoting the type of the enclosed PDU (or a subsequent 340 extension header if present). The security extension header has an 341 associated trailer following the PDU data that contains an optional 342 Message Authentication Code (MAC) field. Placing the MAC in the end 343 of the SNDU is in similar spirit to the CRC, and allows computation 344 in an on-line way, i.e., an encapsulator may derive the MAC of an 345 SNDU during the process of transmitting it, and following the last 346 bit of the PDU it can simply attach the MAC. 348 The following subsections describe the fields that are part of or are 349 directly relevant to the security extension header in more detail. 350 All other fields are defined within the ULE standard [3]. 352 5.1. Type Field 354 The 16-bit Type field of the ULE base header (or some other extension 355 header) indicates a security extension header following subsequently. 357 [XXX IANA ACTION REQUIRED to allocate xxSecure-ULExx XXX] 359 This Secure-ULE Type code is to be defined in the IANA maintained 360 Next-Header Registry for ULE and has the value xxSecure-ULExx 362 [XXX END of IANA ACTION XXX] 364 5.2. Receiver Destination Address Field 366 This field, defined in the ULE standard, typically carries the 367 destination NPA address of a receiver device, or the address of a 368 multicast group. However, when the identity protection service is 369 used, this address is moved into the security extension header (see 370 section 5.4). The address field in the base header may still be 371 present, though, to reduce processing constraints for other receiver 372 devices and aid in the lookup of security states, for example by 373 containing a multicast address designating a VPN of the destination. 374 However, it MUST NOT contain the real destination NPA address that is 375 hidden within the Encrypted Destination Address Field, and it MUST 376 NOT carry any other unique identifier for the receiver device. 378 5.3. ULE-SID Field 380 A 16-bit Security Identifier (SID), similar to the SPI in IPsec, is 381 used to look up the security state for a connection. This SID 382 represents the Security Association (SA) between the ULE transmitter 383 and receiver for a particular session and indicates the keys and 384 algorithms used for encrypting the data payload and calculating the 385 MAC. The SID is used by a receiver to filter PDUs in combination with 386 the NPA address when present. 388 5.4. Encrypted Destination Address Field 390 This field is only present if the identity protection service is 391 selected. In that case, the 48-bit destination NPA address from the 392 base header is omitted, and instead appears in the security extension 393 header, where it is encrypted subsequently (along with the payload 394 data). If no other label is inserted in the base header's address 395 field (see section 5.2), the D bit is set to 1. 397 5.5. SA-Dependant Data Field 399 This variable-length optional field may contain any auxiliary 400 information that is specific to the particular SA. Typical content 401 would be sequence numbers to provide replay protection, nonces for 402 stream cipher encryption, or Initialisation Vectors (IVs) for 403 randomized security algorithms. The length of this field, of the 404 subentries, and their order is defined by the SA and mandated by 405 policy. 407 5.6. Encrypted Next-Type Field 409 This 16-bit value denotes the type of a subsequent extension header, 410 respectively the content type of the payload data [3]. It is 411 encrypted along with the payload. If another ULE extension header 412 follows, then this type field indicates the type of this extension 413 header. 415 5.7. Encrypted Payload 417 All data transmitted between ULE sender and receiver is encrypted 418 under the data confidentiality service. The coverage of this service 419 includes the Payload Data Unit (PUD), the Encrypted Next-Type Field, 420 and the Encrypted Destination NPA Address Field if present. The 421 algorithms and keys used for this purpose are determined by the SA 422 shared between the communicating points. 424 5.8. Message Authentication Code (MAC) Field 426 This field, when present, carries the tag of a Message Authentication 427 Code (MAC) to provide both data origin authentication and data 428 integrity. The default scope of the MAC algorithm is the entire SNDU 429 up to but not including the MAC and CRC fields. 431 The MAC field may also contain a digital signature or suitable output 432 of another multicast source authentication scheme if source 433 authentication under group communication is desired. 435 Reliable protection against modification of data and masquerading 436 attacks requires both sender and receiver identifiers to be 437 authenticated in addition to the payload. This is an issue for the 438 ULE protocol because it does not exhibit a source identifier field, 439 and the PID of an underlying MPEG-2 TS cell does not depict a unique 440 and reliable identifier [9]. Without authenticating the source, an 441 active attacker may re-write the PID to appear from a different 442 transmitter under the same encryption key. This problem can only 443 arise in configurations with multiple senders sharing a key. In 444 networks that do not employ PID re-numbering, the PID may be part of 445 a pseudo-header for authenticating the source. This may be configured 446 via policy. 448 6. Transmitter and Receiver Processing 450 The processing specification follows the IPsec [7] approach of 451 defining a Security Policy Database (SPD) and a Security Association 452 Database (SAD). The SPD contains an ordered list of Security Policies 453 (SPs). These policies allow simple filtering of incoming or outgoing 454 data based on address and other information, including assignment of 455 different security services and keys to different connections and 456 secure groups. The SAD refers to the set of security states, called 457 Security Associations (SAs), which are referenced on the receiver 458 side using the SID along with the address information of the received 459 SNDU. 461 In the IPsec protocols, a receiver normally uses the SPI it has 462 chosen itself for looking up SAs within its SAD. In this 463 specification the SPI is equivalent to the SID. However, under 464 automated key management, this mechanism of using the SPI does not 465 work for multicast settings, multi-sender shared SA scenarios, and 466 unidirectional links, where the SPI value has to be centrally 467 selected by a group controller. A multicast IPsec implementation 468 partially solves these issues by taking into account the source and 469 multicast destination of a packet, and following a longest-match 470 approach in determining the appropriate SA in the following way: 471 First, an SA is looked up using the triple (SPI, destination, source) 472 (1); if not successful, a search is done for (SPI, destination) (2); 473 finally, only the SPI is taken for the lookup (3). While (1) aims to 474 support source-specific multicast groups, (2) is meant for any-source 475 multicast groups. This document adapts that approach in the following 476 way, using the Packet Identifier (PID) of the underlying MPEG-2 TS 477 cell: 479 For an SNDU with a multicast address present, a longest-match search 480 on (SID, destination NPA, PID) is performed in the incoming SAD. 481 Otherwise, a longest-match search is derived using (SID, PID) in the 482 incoming SAD. This takes into account VPN-like settings with a single 483 sender, as well as unidirectional links. 485 Support for shared SAs with multiple senders requires a coordinated 486 solution for determining a unique SID value. To support shared SAs 487 permitting bi-directional communication and avoid the effort of 488 duplicating SAs, an SAD may store references to SAs, and reference 489 bi-directional SAs in both the incoming and outgoing SAD. 491 Another difference to IPsec is the treatment of directionality for 492 SPs and SAs. In a standard IPsec implementation, a match on an SP 493 affects traffic in both directions, resulting in two separate 494 unidirectional SAs being created. This document always requires 495 separate SPs to be defined for incoming and outgoing data, and in 496 turn allows SAs to be shared across several devices, supporting both 497 unidirectional links and group communication. 499 For the rest of this section, a Selector is defined as a pair of 500 destination NPA address and PID. 502 6.1. Security Policy Database (SPD) 504 An SPD contains an ordered list of SPs, similar to Access Control 505 Lists (ACLs). Each transmitter and receiver device defines one SPD 506 for outgoing data, and an independent one for incoming SNDUs. For 507 both databases, an SP must provide the following information: 509 o An SP Selector, together with an SP Selector mask. This provides a 510 simple and basic way to filter based on address information. For a 511 transmitter SP, the Selector may be extended to include additional 512 filtering information, such as higher-layer addresses, and port 513 numbers. 515 o Information about the SA(s) to be instantiated by this SP, when a 516 match is found based on filtering. This contains: 518 o A Selector mask, denoted SA Selector mask, which specifies the 519 set of SAs derived from the policy. This provides a simple way 520 to instantiate secure unicast connections, as well as shared SAs 521 for secure group communication. It is similar to the Populate- 522 From-Packet (PFP) flags in the IPsec specification, but slightly 523 more general. 525 o An optional SID value. If not defined, Group Controller and Key 526 Server (GCKS) data must be present for the SID to be selected 527 dynamically. 529 o Optional GCKS data. When a GCKS is configured, it MUST be 530 contacted by a device which cannot find an SA for a matching SP, 531 and when the SP does not define a static SID and default key 532 data in its first set of Security Parameters. 534 o An ordered list of Security Parameter sets used for 535 instantiating an SA, sorted according to preference. On creating 536 an SA, devices must default to the first entry in the list, 537 unless a key management protocol permits negotiation (e.g., for 538 unicast, bidirectional settings), and the device contacts the 539 GCKS to request another set of Security Parameters from the 540 list. 542 Each set of Security Parameters contains: 544 o The cryptographic algorithms used. 546 o The cryptographic parameters required by these algorithms (e.g., 547 sequence number length, MAC length). 549 o Optional key data for manual keying. 551 A Security Parameter set may select no security services, by which it 552 is to be interpreted requesting processing without the security 553 extension header. 555 Each SPD may be manually constructed by a device or network operator, 556 but it may also be dynamically set up via a GCKS. This document does 557 not describe how to create such databases, or how to store, manage, 558 and look up SPs within the SPD; this is regarded as implementation 559 specific detail. 561 6.2. Security Association Database (SAD) 563 A Security Association (SA) is an instantiation of an SP. It 564 describes the current state of a secure connection between two or 565 more devices. Each SA within the SAD must contain the following 566 information: 568 o The SA Selector derived from the instantiating SP. 570 o The SID defined by the SP or the GCKS. 572 o Static security parameters defined by the SP (cryptographic 573 algorithms, MAC length, Sequence Number length, etc.). 575 o Dynamic security parameters (keys, sequence number, SA lifetime, 576 etc.), initially defined by the SP or the GCKS, and updated during 577 processing. 579 o GCKS specific data defined by the SP or the GCKS, including GCKS 580 contact information. 582 As with the SPD, the description of the implementation-specific 583 details of the SAD is out of scope of this document. 585 6.3. Transmitter Processing 587 The following list describes in detail the processing steps required 588 for a ULE encapsulator implementing the unified ULE security 589 extension: 591 1. Get SP: Upon constructing an SNDU for transmission over the ULE 592 link, an encapsulator must scan its outgoing SPD for a matching 593 policy. If no such policy can be found, the SNDU data MUST be 594 discarded, and this event SHOULD be logged as an invalid 595 transmission attempt. 597 2. Get SA: Given a matching SP, an SA is searched within the outgoing 598 SAD using the SNDU's Selector information and the policy's SA 599 Selector masks, including the SP's SID value if defined. If no SA 600 could be found, it must be set up as follows: If the SP's first 601 Security Parameter set contains default key data, or defines data 602 to be sent without protection, the SA is immediately created and 603 initialized according to these settings. Otherwise, if the SP 604 defines GCKS contact information, the GCKS MUST be queried for 605 obtaining key material. During that attempt the device SHOULD 606 postpone transmission, or discard the data. Any case of failure 607 MUST result in the data being discarded, and this event SHOULD be 608 logged (e.g., as a user authentication failure in the case of 609 membership denial by the GCKS). If the SA allows passing data 610 unprotected, processing continues as usual [3]. 612 3. Check SA: The SA may have a pre-defined lifetime (e.g., maximum 613 number of encryptions, sequence number state, seconds since 614 instantiation) after which it may no longer be used. To allow for 615 a transient switch-over to a new SA, the SA must define a point 616 prior to its lifetime end at which transmitters switch to the new 617 SA. If that point is reached, a device MAY proactively request a 618 new SA from a GCKS. In general, it is the responsibility of the 619 operator or the GCKS to create new SAs, and distributing these to 620 legitimate transmitter and receiver devices in time. If no new SA 621 is available, a transmitter MAY still use the current SA during 622 its full lifetime. After that, it MUST discard the data, and this 623 event SHOULD be logged. 625 4. Construct SNDU: A protected SNDU is built as follows: 627 a. First, the ULE base header and any extension headers preceding 628 the security extension header are written. If the SA requests 629 identity protection, the destination NPA address is omitted 630 from the base header, setting the base header's D bit to 1 631 (though another label may be re-inserted, see section 5.2). The 632 last next-header-type field within the extension header chain 633 contains the type code for the security extension. 635 b. The SID value is written as the first field of the security 636 extension header. 638 c. If identity protection is used, the SNDU's destination NPA 639 address follows. It is encrypted along with the payload. 641 d. Any SA-dependent data, such as sequence numbers and 642 initialization vectors, are written subsequently. 644 e. Then, the next-header-type field, any further extension 645 headers, and the payload data are encoded as defined by the 646 SA's data confidentiality algorithm (together with the 647 encrypted destination NPA address). 649 f. For authentication and integrity protection, a MAC of length as 650 defined by the SA is appended. The MAC is computed over all the 651 data encoded so far, i.e., from the start of the SNDU to the 652 end of the payload data. 654 g. Finally, the CRC is calculated and appended, and the SNDU 655 further processed according to RFC 4326. 657 5. Update SA: After transmission of the SNDU, the SA MUST be updated 658 (e.g., the sequence number incremented by one). 660 +-----------------+ 661 | receive PDU | +-----------------+ 662 +---->|from upper layers|<-------------------| discard PDU | 663 | +-----------------+ +-----------------+ 664 | v ^ 665 | +-----------------+ not found? +-----------------+ 666 | | get SP |------------------->| log event |<-+ 667 | +-----------------+ +-----------------+ | 668 | v ^ failure? | 669 | +-----------------+ not found? +-----------------+ | 670 | +--| get SA |------------------->| create SA | | 671 | | +-----------------+ +-----------------+ | 672 | |w/o | | success? | 673 | |sec.ext. | +----------------+ | 674 | | v | | 675 | | +-----------------+ end of | | 676 | | | check SA |-----------------------------------------+ 677 | | +-----------------+ lifetime? | 678 | | | | +-----------------+ 679 | | | expected | | get new SA | 680 | | +---------------------------->| from GCKS | 681 | | | lifetime end? | +-----------------+ 682 | | v | v failure? 683 | | +-----------------+ | +-----------------+ 684 | +->| construct SNDU |<-----------+ | log event | 685 | | & transmit | +-----------------+ 686 | +-----------------+ 687 | v 688 | +-----------------+ 689 | | update SA | 690 | +-----------------+ 691 | | 692 +--------------+ 694 Figure 2. Transmitter Processing Flow Chart 696 6.4. Receiver Processing 698 For a receiver device to process SNDUs containing the security 699 extension, the following steps must be performed: 701 1. Decode SNDU (1): First, the CRC of an SNDU received is verified, 702 and the base header and extension headers preceding a security 703 extension header or the payload are evaluated. 705 2. Get SA: If a security extension header is found, a longest-match 706 search within the incoming SAD is performed as described in 707 section III. If it contains a matching SA, processing continues at 708 step 4. 710 3. Get SP: The SPD is scanned similar to step 1 in the transmitter 711 processing specification. However, the destination NPA address may 712 be hidden, and consequently the SP must define whether the address 713 must be matched or not. When the SNDU is received without a 714 security extension header but the SP does not permit data to pass 715 unprotected, the SNDU MUST be discarded immediately, and this 716 event SHOULD be logged. Likewise, if there is a security extension 717 header, but the policy allows only for unprotected data, the SNDU 718 MUST be discarded, and the event SHOULD be logged. When permitted, 719 an unprotected SNDU is processed as usual [3]. Otherwise, an SA is 720 created as described in step 2 of the transmitter processing 721 specification. 723 4. Check SA: If the SA's lifetime has expired, the SNDU MUST be 724 discarded, and this SHOULD be logged. If the extension header 725 contains an encrypted destination NPA address, it is first 726 decrypted, using the SA-dependent data, and checked for a valid 727 address for that SA. If the decoded address is not accepted by the 728 receiver device and the SA, the SNDU MUST be silently discarded. 730 5. Decode SNDU (2): This step includes verification of the MAC, 731 protection against replay attacks, and decoding of the payload. In 732 any case of failure, the SNDU MUST be discarded, and this event 733 SHOULD be logged. 735 6. Update SA: After successful reception of an SNDU, the SA MUST be 736 updated (e.g., the sequence number set to the one found within the 737 SNDU, incremented by one). 739 +-----------------+ 740 | receive SNDU | +-----------------+ 741 +---->| from MPEG layer |<----------------| discard SNDU |<----+ 742 | +-----------------+ +-----------------+ | 743 | v ^ | 744 | +-----------------+ decoding error? +-----------------+ | 745 | |decode headers up|- - - - - - - - >| log event |<-+ | 746 | | to security ext.| +------->| | | | 747 | +-----------------+ | +-----------------+ | | 748 | | | not found/ ^ | | 749 | v | not permitted? | | | 750 | +-----------------+ not found? +-----------------+ | | 751 | +--| get SA |---------------->| get SP | | | 752 | | +-----------------+ | +-----------------+ | | 753 | |w/o | | success? | | | 754 | |sec.ext. v | v | | 755 | | +-----------------+ end of | +-----------------+ | | 756 | | | check SA |--------+ | create SA |->| | 757 | | +-----------------+ lifetime? +----------------+ | | 758 | | | success? | | | 759 | | | +--------------------------------+ | | 760 | | | | | | 761 | | v v | | 762 | | +-----------------+ decoding error? | | 763 | +->| decode SNDU |--------------------------------------+ | 764 | | & pass to L3 | | 765 | | |-----------------------------------------+ 766 | +-----------------+ destination address mismatch? 767 | v 768 | +-----------------+ 769 | | update SA | 770 | +-----------------+ 771 | | 772 +--------------+ 774 Figure 3. Receiver Processing Flow Chart 776 7. Key Management Considerations 778 Small and rather static network configurations may be supported using 779 manual keying. More elaborate settings, consisting of a higher number 780 of devices, or when users need to be added or excluded more 781 frequently, require some automated key management. This may be 782 defined independently of the ULE security extension. This section 783 presents some considerations on this issue. 785 7.1. MSEC/IPsec Key Management Protocols 787 MSEC/IPsec key management protocols, such as the Group Domain of 788 Interpretation (GDOI) and the Group Secure Association Key Management 789 Protocol (GSAKMP) protocols, may be adapted for the ULE security 790 extension. This has the advantage of sharing similar functionality in 791 terms of SA lookup and database architectures. 793 The protocol may be run entirely within the ULE network, or it may be 794 performed by some other means. This is a matter of policy and an 795 architecture decision. For example, for bidirectional transfers the 796 whole key exchange procedures could be carried within the ULE 797 network, while for unidirectional links some other bidirectional 798 connection could be used. 800 7.2. Existing L2 Key Management Infrastructure 802 ULE security may re-use an already existing L2 key management 803 infrastructure, such as the DVB-RCS security system [5]. The format 804 of the ULE-Security-ID will be the same format as defined in DVB-RCS 805 security procedures. 807 7.3. Other Considerations 809 Key management protocols are traditionally assuming bidirectional 810 links. GSAKMP provides some initial support for push operation. 811 However, supporting unidirectional links within the ULE network may 812 require defining a new protocol. Such a protocol should be designed 813 flexibly to support bidirectional operation as well without a change 814 in the header structures. 816 Existing L2 unidirectional mechanism may be evaluated, such as DVB- 817 Conditional Access (CA) and ATSC-CA. 819 8. Security Considerations 821 Link-level security is commonly used in broadcast/radio links to 822 supplement end-to-end security, and may not be treated as a 823 substitute for end-to-end security. A common objective is to provide 824 the same level of privacy as terrestrial links. 826 A number of security considerations specific to the ULE security 827 extension have been outlined throughout the document. The following 828 paragraphs extend that analysis. 830 Hiding destination addresses under the identity protection service is 831 an effective mechanism against traffic flow analysis. However, there 832 are other more subtle ways for a passive adversary to deduce the real 833 destination address of an SNDU, even when precluded from decoding the 834 destination NPA address field. For example, SNDUs with increasing 835 sequence numbers may be linked to a single connection, providing a 836 hint regarding the identities of the communicating parties based on 837 packet sizes and distribution patterns. Alternatives to sequence 838 numbers were outlined in section 5. When SID values are selected at 839 random for bidirectional links using identity protection, they may 840 resemble unique temporary addresses. This may be mitigated by always 841 selecting the smallest free SID value on a receiver device, thereby 842 increasing the chance of equal SID values among several devices. 843 However, this also means increased processing requirements in the 844 filtering step for these devices. 846 Other problems arise with certain cryptographic algorithms. Stateful 847 algorithms are problematic for manually keyed configurations when 848 devices cannot retain their cryptographic states across device 849 restarts (due to power or device failures, etc.). Reuse of sequence 850 numbers for the Counter (CTR) mode renders all encryption insecure. 851 Receiver devices may be vulnerable to replay attacks if they do not 852 remember prior lower bounds for sequence numbers. If devices cannot 853 store their cryptographic state in non-volatile memory, it is advised 854 that they resort to non-stateful schemes, such as the randomized 855 Cipher Block Chaining (CBC) mode for encryption, or the use of 856 timestamps for replay protection (if replay protection is desired). 858 Many stateful schemes, such as the CTR mode of operation, require 859 nonces as part of their input. As mentioned before, nonces must never 860 be re-used under the same key. To provide this guarantee, 861 particularly under group communication where the encryption key is 862 shared among several group members, some source identifier must be 863 incorporated into the construction of the nonce. 865 Within ULE networks, the PID may be used as a source identifier, but 866 this is not reliable. A device may receive data from different MPEG-2 867 multiplexes, which both may allocate PID values independently [9]. 868 Furthermore, multiplexors within the network may transparently re- 869 number PID values. This is a problem for receivers as they require 870 the originating PID value for reconstructing nonces. 872 One solution to circumvent these issues is to assign a unique sender 873 identifier to each legitimate transmitter under the same key [14]. To 874 avoid the problem of associating an MPEG-2 TS with a sender 875 identifier, the latter is included explicitly as part of the nonce in 876 each SNDU. This means that the nonce field (e.g., sequence number) 877 may get enlarged by the size necessary to support a predefined 878 maximum number of different senders sharing a key. The other caveat 879 of this approach is the problem of generating and distributing unique 880 sender identifiers. 882 The lack of a reliable source identifier entails also a potential 883 authentication insecurity. However, this only applies for specific 884 communication scenarios, as outlined in section 5. 886 9. IANA Considerations 888 The Secure-ULE header is defined in the IANA maintained Next-Header 889 Registry for ULE and has the value xxSecure-ULExx. 891 10. Acknowledgments 893 The authors acknowledge the help and advice from Gorry Fairhurst 894 (University of Aberdeen), L. Duquerroy (Alcatel Alenia Space) 895 Stephane Coombes (ESA) and Yim Fun Hu (University of Bradford) in the 896 preparation of this document. 898 11. References 900 11.1. Normative References 902 [1] ISO/IEC DIS 13818-1, "Information technology - Generic coding 903 of moving pictures and associated audio information - Part1: 904 Systems", International Standards Organisation (ISO) 906 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 907 Levels", BCP 14, RFC 2119, March 1997. 909 [3] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 910 Lightweight Encapsulation (ULE) for Transmission of IP 911 Datagrams over an MPEG-2 Transport Streams", RFC 4326, December 912 2005. 914 11.2. Informative References 916 [4] H. Cruickshank, P. Pillai, M. Noisternig, and S. Iyengar, 917 "Security requirements for the Unidirectional Lightweight 918 Encapsulation (ULE) protocol", RFC 5458, March 2009. 920 [5] "Digital Video Broadcasting (DVB): Interaction Channel for 921 satellite distribution systems", ETSI EN 301 790 v1.4.1, 2005. 923 [6] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 924 Group Secure Association Key Management Protocol", RFC 4535, 925 June 2006. 927 [7] S. Kent and K. Seo, "Security Architecture for the Internet 928 Protocol", RFC 4301, December 2005. 930 [8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 931 Domain of Interpretation", RFC 3547, July 2003. 933 [9] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B., 934 and H. Linder, "A Framework for Transmission of IP Datagrams 935 over MPEG-2 Networks", RFC 4259, November 2005. 937 [10] http://www.ietf.org/html.charters/tls-charter.html 939 [11] National Institute of Standards and Technology, "Data 940 Encryption Standard (DES)", Federal Information Processing 941 Standard (FIPS) Publication, FIPS PUB 46-3, October 1999. 943 [12] National Institute of Standards and Technology, "Advanced 944 Encryption Standard (AES)", Federal Information Processing 945 Standard (FIPS) Publication, FIPS PUB 197, November 2001.[14] D. 946 McGrew, B. Weis, "Using Counter Modes with Encapsulating 947 Security Payload (ESP) and Authentication Header (AH) to 948 Protect Group Traffic", draft-ietf-msec-ipsec-group-counter- 949 modes-03 (work in progress), 2009. 951 Author's Addresses 953 Michael Noisternig 954 University of Salzburg 955 Jakob-Haringer-Str. 2 956 5020 Salzburg 957 Austria 958 Email: mnoist@cosy.sbg.ac.at 960 Prashant Pillai 961 Mobile and Satellite Communications Research Centre (MSCRC) 962 School of Engineering, Design and Technology 963 University of Bradford 964 Richmond Road, Bradford BD7 1DP 965 UK 966 Email: p.pillai@bradford.ac.uk 968 Haitham Cruickshank 969 Centre for Communications System Research (CCSR) 970 University of Surrey 971 Guildford, Surrey, GU2 7XH 972 UK 973 Email: h.cruickshank@surrey.ac.uk