IPDVB Working Group M. Noisternig Internet Draft University of Salzburg Intended status: Standards Track P. Pillai Expires: January 2010 University of Bradford H. Cruickshank University of Surrey July 13, 2009 Security Extension for Unidirectional Lightweight Encapsulation Protocol draft-noisternig-ipdvb-sec-ext-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 13, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Noisternig et al. Expires January 13, 2010 [Page 1] Internet-Draft Security Extension for ULE July 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The Unidirectional Lightweight Encapsulation (ULE) protocol provides an efficient mechanism for transporting IP and other network layer protocol data over MPEG-2 networks. Such networks, widely used especially for providing digital TV services, often use broadcast wireless transmission media, and are hence vulnerable to various types of security attacks. This document describes a new mandatory ULE extension to protect ULE traffic using security features such as data confidentiality, data integrity, data origin authentication, and prevention against replay attacks. Additionally, destination addresses may be hidden from unauthorized receiver devices using the identity protection feature. The format of the security extension header as well as the processing at receivers and transmitters are described in detail. The extension aims to be lightweight and flexible such that it may be implemented in low-cost, resource-scarce transceivers, and different levels of security may be selected. The security extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses a similar extension header mechanism. Table of Contents 1. Introduction ................................................. 3 2. Requirements Notation ........................................ 4 3. Abbreviations used in this document .......................... 4 4. Security Services ............................................ 5 5. Secure ULE SNDU Format ....................................... 7 5.1. Type Field .............................................. 9 5.2. Receiver Destination Address Field ...................... 9 5.3. ULE-SID Field ........................................... 9 5.4. Encrypted Destination Address Field ..................... 9 5.5. SA-Dependant Data Field ................................ 10 5.6. Encrypted Next-Type Field .............................. 10 5.7. Encrypted Payload ...................................... 10 5.8. Message Authentication Code (MAC) Field ................ 10 6. Transmitter and Receiver Processing ......................... 11 6.1. Security Policy Database (SPD) ......................... 12 6.2. Security Association Database (SAD) .................... 13 6.3. Transmitter Processing ................................. 14 Noisternig et al. Expires January 13, 2010 [Page 2] Internet-Draft Security Extension for ULE July 2009 6.4. Receiver Processing .................................... 16 7. Key Management Considerations ............................... 18 7.1. MSEC/IPsec Key Management Protocols .................... 19 7.2. Existing L2 Key Management Infrastructure .............. 19 7.3. Other Considerations ................................... 19 8. Security Considerations ..................................... 19 9. IANA Considerations ......................................... 21 10. Acknowledgments ............................................ 21 11. References ................................................. 22 11.1. Normative References .................................. 22 11.2. Informative References ................................ 22 1. Introduction The Unidirectional Lightweight Encapsulation (ULE) protocol [3] provides an efficient mechanism for transporting IP and other network layer protocol data over ISO MPEG-2 Transport Streams (TS) [1]. This document describes a new ULE mandatory extension header for providing link layer security for ULE. In MPEG-2 transmission networks employing ULE there is a need to provide link layer security, particularly where network layer and transport layer security may not be present or may not be sufficient. The security requirements are presented and discussed in detail in [4]. The set of security services that the security extension for ULE can provide includes data confidentiality, data integrity, data origin authentication and rejection of replayed packets. While providing suitable link encryption is mandatory, link layer data integrity and data origin authentication is provided as an optional security service. These are especially desirable for systems where there are several ULE transmitters (e.g., satellite mesh systems). The extension also supports what is called 'identity protection' in this specification. This allows hiding destination addresses from unauthorized receiver devices, thus enabling a form of traffic flow confidentiality. The method described in this document provides security for ULE SNDUs at the link layer, in contrast to higher-layer mechanisms, such as IPsec [7] and TLS [10]. This allows protecting any network layer protocol (even with Ethernet bridging), while higher-layer security may be used independently and in parallel. Link-layer signalling information may be protected as well. The processing specification follows the IPsec approach of defining a Security Policy Database (SPD) and a Security Association Database (SAD). A Security Identifier (SID), similar to the Security Parameter Noisternig et al. Expires January 13, 2010 [Page 3] Internet-Draft Security Extension for ULE July 2009 Index (SPI) in the IPsec protocols, assists receiver devices in looking up security states. The design of the databases for ULE security is similar but simpler because unlike in IPsec a receiver only needs the SID along with the NPA address and possibly the PID to retrieve the data from these databases. Key management protocols assuming similar processing functionality, such as the MSEC Group Domain of Interpretation (GDOI) [8] and the Group Secure Association Key Management Protocol (GSAKMP) [6], may be adapted for the ULE scenario. Simple configurations are supported using manual keying (i.e., pre-shared keys). Security transforms such as encryption algorithms may be modelled after existing MSEC and IPsec security algorithms, but will be defined in separate documents in order to proceed/update them independently of this specification. The ULE security extension is designed for both bi-directional and unidirectional links, as well as unicast and multicast settings [9]. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. 3. Abbreviations used in this document AES - Advanced Encryption Standard DES - Data Encryption Standard DVB - Digital Video Broadcasting GDOI - Group Domain of Interpretation GSKAMP - Group Secure Association Key Management Protocol GSE - Generic Stream Encapsulation IPsec - Internet Protocol Security MPE - Multi-Protocol Encapsulation MAC - Message Authentication Code NAT - Network Address Translation Noisternig et al. Expires January 13, 2010 [Page 4] Internet-Draft Security Extension for ULE July 2009 NCC - Network Control Centre NPA - Network Point of Attachment PEP - Protocol Enhancing Proxy PID - Packet Identifier PDU - Protocol Data Unit SAD - Security Association Database SID - Security Identifier SHA - Standard Hash Algorithm SNDU - Subnetwork Data Unit SPD - Security Policy Database SPI - Security Parameter Index TLS - Transport Layer Security ULE - Unidirectional Lightweight Encapsulation Protocol VPN - Virtual Private Network 4. Security Services MPEG-2 based networks are susceptible to several security attacks, both passive and active [4]. Some of the main security services (mandatory or optional) that the security extension for ULE provides: o Data confidentiality (mandatory): Data confidentiality is achieved by encrypting the higher layer PDU (and other ULE extensions headers that may be present and require security) before encapsulation in the ULE SNDU, so that only authorised receivers can decrypt the transmitted information while an adversary would not be able to recover the important information even if it got access to the transmitted data. Noisternig et al. Expires January 13, 2010 [Page 5] Internet-Draft Security Extension for ULE July 2009 o Receiver address hiding (optional): Hiding an SNDU's real destination NPA address from an adversary is an important step in providing identity protection. While one solution for this is to use temporary addresses, this is susceptible to various practical issues. More importantly, from a security point of view, temporary addresses do not provide adequate identity protection, as a passive adversary may easily link different SNDUs to the same connection. Also, a procedure to allocate temporary addresses is required such that they are unique in the system. Hence it is proposed to encrypt the destination address. By encrypting the destination address within the SNDU, an attacker is effectively denied from gaining information by monitoring addresses. o Data origin authentication (optional): Data origin (source) authentication allows a ULE receiver to verify data as sent by a legitimate ULE sender. A Message Authentication Code (MAC) using a shared secret key may be used to authenticate the sender in unicast settings, or to guarantee an SNDU originating from a group member in secure group communication. For the latter, other source authentication schemes, such as digital signatures, may be used to assure source authenticity. o Data integrity (optional): Data integrity provides a way for the receiver of the data message to know if the data has been tampered with in transit by an attacker. This is provided for by the data origin authentication algorithm. A change in the message will alter the authentication value, and an adversary will unlikely be able to derive a correct one. Noisternig et al. Expires January 13, 2010 [Page 6] Internet-Draft Security Extension for ULE July 2009 o Replay attacks countermeasures (optional): Methods against replay attacks need to ensure that an adversary has not replayed old authentic messages at a later time. A monotonically increasing sequence number may be part of the SA-dependent data field of the security extension header, allowing messages with old sequence number values to be rejected. As with other security services, the choice of using sequence numbers is dictated by policy, usually effected by the key management system. Note that sequence numbers resemble unkeyed connection states that an adversary may track to link packets to different connections. Therefore, use of sequence numbers is not mandated. One solution is encrypting sequence numbers using standard Electronic Code Book (ECB) mode (i.e., encrypt as one block of data). A receiver first decrypts the encrypted value within the protocol to check for a replay, and then may use either the encrypted value as an initialization vector for the Cipher Block Chaining (CBC) mode of operation, or the decoded sequence number for the Counter (CTR) mode (with the internal counter incremented by one). The disadvantage is a slightly higher protocol overhead compared to unencoded sequence numbers. Another solution is to use connection- independent timestamp values. Depending on the resolution, timestamps may or may not provide perfect replay protection. The drawback is a higher protocol overhead, including the need for synchronized clocks. 5. Secure ULE SNDU Format Figure 1 below shows the format of an SNDU containing the security extension header. The extension header is designed as a framework for a set of security transforms, enabling high flexibility in selecting various security services (including common encryption algorithms such as DES [11], 3DES, AES [12], etc.). Security transforms are to be described in separate documents, and will be based on algorithms defined for the MSEC/IPsec protocols. The ULE security extension is a standard extension header as described in Section 5 of RFC 4326 [3], and does not affect the ULE base protocol. Furthermore, the extension is a Mandatory ULE Extension header, which means that a receiver MUST process this header before it processes the next extension header or the encapsulated PDU, otherwise the entire SNDU should be discarded. When configuring use of the security extension at encapsulation devices, it is RECOMMENDED to place the extension header directly after the base header. This permits full protection for all headers. Noisternig et al. Expires January 13, 2010 [Page 7] Internet-Draft Security Extension for ULE July 2009 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 +-+----------------------------+------------------------------+ |D| Length | Type = Secure-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address (D=0) | | +------------------------------+ | | ULE-SID | +------------------------------+------------------------------+ | Encrypted Destination NPA Address (optional) | +------------------------------+------------------------------+ | | = SA-Dependant Data (optional) = | | | +------------------------------+ | | Encrypted Next-PDU Type | +------------------------------+------------------------------+ | | | | = Encrypted PDU = | | | | +------------------------------+------------------------------+ | | = Message Authentication Code (optional) = | | +-------------------------------------------------------------+ | Cyclic Redundancy Check | +-------------------------------------------------------------+ Figure 1. General SNDU format with security extension header In Figure 1, the Type field in the base header denotes that a mandatory security extension header is present. The receiver destination NPA address is optional (dependent on the D bit). The security extension header follows the ULE base header. This header contains the ULE Security Identifier (SID), an optional Encrypted Destination Address, a variable-length field whose content is determined by a Security Association (SA), and an encrypted Type field denoting the type of the enclosed PDU (or a subsequent extension header if present). The security extension header has an associated trailer following the PDU data that contains an optional Message Authentication Code (MAC) field. Placing the MAC in the end of the SNDU is in similar spirit to the CRC, and allows computation in an on-line way, i.e., an encapsulator may derive the MAC of an SNDU during the process of transmitting it, and following the last bit of the PDU it can simply attach the MAC. Noisternig et al. Expires January 13, 2010 [Page 8] Internet-Draft Security Extension for ULE July 2009 The following subsections describe the fields that are part of or are directly relevant to the security extension header in more detail. All other fields are defined within the ULE standard [3]. 5.1. Type Field The 16-bit Type field of the ULE base header (or some other extension header) indicates a security extension header following subsequently. [XXX IANA ACTION REQUIRED to allocate xxSecure-ULExx XXX] This Secure-ULE Type code is to be defined in the IANA maintained Next-Header Registry for ULE and has the value xxSecure-ULExx [XXX END of IANA ACTION XXX] 5.2. Receiver Destination Address Field This field, defined in the ULE standard, typically carries the destination NPA address of a receiver device, or the address of a multicast group. However, when the identity protection service is used, this address is moved into the security extension header (see section 5.4). The address field in the base header may still be present, though, to reduce processing constraints for other receiver devices and aid in the lookup of security states, for example by containing a multicast address designating a VPN of the destination. However, it MUST NOT contain the real destination NPA address that is hidden within the Encrypted Destination Address Field, and it MUST NOT carry any other unique identifier for the receiver device. 5.3. ULE-SID Field A 16-bit Security Identifier (SID), similar to the SPI in IPsec, is used to look up the security state for a connection. This SID represents the Security Association (SA) between the ULE transmitter and receiver for a particular session and indicates the keys and algorithms used for encrypting the data payload and calculating the MAC. The SID is used by a receiver to filter PDUs in combination with the NPA address when present. 5.4. Encrypted Destination Address Field This field is only present if the identity protection service is selected. In that case, the 48-bit destination NPA address from the base header is omitted, and instead appears in the security extension header, where it is encrypted subsequently (along with the payload Noisternig et al. Expires January 13, 2010 [Page 9] Internet-Draft Security Extension for ULE July 2009 data). If no other label is inserted in the base header's address field (see section 5.2), the D bit is set to 1. 5.5. SA-Dependant Data Field This variable-length optional field may contain any auxiliary information that is specific to the particular SA. Typical content would be sequence numbers to provide replay protection, nonces for stream cipher encryption, or Initialisation Vectors (IVs) for randomized security algorithms. The length of this field, of the subentries, and their order is defined by the SA and mandated by policy. 5.6. Encrypted Next-Type Field This 16-bit value denotes the type of a subsequent extension header, respectively the content type of the payload data [3]. It is encrypted along with the payload. If another ULE extension header follows, then this type field indicates the type of this extension header. 5.7. Encrypted Payload All data transmitted between ULE sender and receiver is encrypted under the data confidentiality service. The coverage of this service includes the Payload Data Unit (PUD), the Encrypted Next-Type Field, and the Encrypted Destination NPA Address Field if present. The algorithms and keys used for this purpose are determined by the SA shared between the communicating points. 5.8. Message Authentication Code (MAC) Field This field, when present, carries the tag of a Message Authentication Code (MAC) to provide both data origin authentication and data integrity. The default scope of the MAC algorithm is the entire SNDU up to but not including the MAC and CRC fields. The MAC field may also contain a digital signature or suitable output of another multicast source authentication scheme if source authentication under group communication is desired. Reliable protection against modification of data and masquerading attacks requires both sender and receiver identifiers to be authenticated in addition to the payload. This is an issue for the ULE protocol because it does not exhibit a source identifier field, and the PID of an underlying MPEG-2 TS cell does not depict a unique and reliable identifier [9]. Without authenticating the source, an Noisternig et al. Expires January 13, 2010 [Page 10] Internet-Draft Security Extension for ULE July 2009 active attacker may re-write the PID to appear from a different transmitter under the same encryption key. This problem can only arise in configurations with multiple senders sharing a key. In networks that do not employ PID re-numbering, the PID may be part of a pseudo-header for authenticating the source. This may be configured via policy. 6. Transmitter and Receiver Processing The processing specification follows the IPsec [7] approach of defining a Security Policy Database (SPD) and a Security Association Database (SAD). The SPD contains an ordered list of Security Policies (SPs). These policies allow simple filtering of incoming or outgoing data based on address and other information, including assignment of different security services and keys to different connections and secure groups. The SAD refers to the set of security states, called Security Associations (SAs), which are referenced on the receiver side using the SID along with the address information of the received SNDU. In the IPsec protocols, a receiver normally uses the SPI it has chosen itself for looking up SAs within its SAD. In this specification the SPI is equivalent to the SID. However, under automated key management, this mechanism of using the SPI does not work for multicast settings, multi-sender shared SA scenarios, and unidirectional links, where the SPI value has to be centrally selected by a group controller. A multicast IPsec implementation partially solves these issues by taking into account the source and multicast destination of a packet, and following a longest-match approach in determining the appropriate SA in the following way: First, an SA is looked up using the triple (SPI, destination, source) (1); if not successful, a search is done for (SPI, destination) (2); finally, only the SPI is taken for the lookup (3). While (1) aims to support source-specific multicast groups, (2) is meant for any-source multicast groups. This document adapts that approach in the following way, using the Packet Identifier (PID) of the underlying MPEG-2 TS cell: For an SNDU with a multicast address present, a longest-match search on (SID, destination NPA, PID) is performed in the incoming SAD. Otherwise, a longest-match search is derived using (SID, PID) in the incoming SAD. This takes into account VPN-like settings with a single sender, as well as unidirectional links. Support for shared SAs with multiple senders requires a coordinated solution for determining a unique SID value. To support shared SAs permitting bi-directional communication and avoid the effort of Noisternig et al. Expires January 13, 2010 [Page 11] Internet-Draft Security Extension for ULE July 2009 duplicating SAs, an SAD may store references to SAs, and reference bi-directional SAs in both the incoming and outgoing SAD. Another difference to IPsec is the treatment of directionality for SPs and SAs. In a standard IPsec implementation, a match on an SP affects traffic in both directions, resulting in two separate unidirectional SAs being created. This document always requires separate SPs to be defined for incoming and outgoing data, and in turn allows SAs to be shared across several devices, supporting both unidirectional links and group communication. For the rest of this section, a Selector is defined as a pair of destination NPA address and PID. 6.1. Security Policy Database (SPD) An SPD contains an ordered list of SPs, similar to Access Control Lists (ACLs). Each transmitter and receiver device defines one SPD for outgoing data, and an independent one for incoming SNDUs. For both databases, an SP must provide the following information: o An SP Selector, together with an SP Selector mask. This provides a simple and basic way to filter based on address information. For a transmitter SP, the Selector may be extended to include additional filtering information, such as higher-layer addresses, and port numbers. o Information about the SA(s) to be instantiated by this SP, when a match is found based on filtering. This contains: o A Selector mask, denoted SA Selector mask, which specifies the set of SAs derived from the policy. This provides a simple way to instantiate secure unicast connections, as well as shared SAs for secure group communication. It is similar to the Populate- From-Packet (PFP) flags in the IPsec specification, but slightly more general. o An optional SID value. If not defined, Group Controller and Key Server (GCKS) data must be present for the SID to be selected dynamically. o Optional GCKS data. When a GCKS is configured, it MUST be contacted by a device which cannot find an SA for a matching SP, and when the SP does not define a static SID and default key data in its first set of Security Parameters. o An ordered list of Security Parameter sets used for Noisternig et al. Expires January 13, 2010 [Page 12] Internet-Draft Security Extension for ULE July 2009 instantiating an SA, sorted according to preference. On creating an SA, devices must default to the first entry in the list, unless a key management protocol permits negotiation (e.g., for unicast, bidirectional settings), and the device contacts the GCKS to request another set of Security Parameters from the list. Each set of Security Parameters contains: o The cryptographic algorithms used. o The cryptographic parameters required by these algorithms (e.g., sequence number length, MAC length). o Optional key data for manual keying. A Security Parameter set may select no security services, by which it is to be interpreted requesting processing without the security extension header. Each SPD may be manually constructed by a device or network operator, but it may also be dynamically set up via a GCKS. This document does not describe how to create such databases, or how to store, manage, and look up SPs within the SPD; this is regarded as implementation specific detail. 6.2. Security Association Database (SAD) A Security Association (SA) is an instantiation of an SP. It describes the current state of a secure connection between two or more devices. Each SA within the SAD must contain the following information: o The SA Selector derived from the instantiating SP. o The SID defined by the SP or the GCKS. o Static security parameters defined by the SP (cryptographic algorithms, MAC length, Sequence Number length, etc.). o Dynamic security parameters (keys, sequence number, SA lifetime, etc.), initially defined by the SP or the GCKS, and updated during processing. o GCKS specific data defined by the SP or the GCKS, including GCKS contact information. Noisternig et al. Expires January 13, 2010 [Page 13] Internet-Draft Security Extension for ULE July 2009 As with the SPD, the description of the implementation-specific details of the SAD is out of scope of this document. 6.3. Transmitter Processing The following list describes in detail the processing steps required for a ULE encapsulator implementing the unified ULE security extension: 1. Get SP: Upon constructing an SNDU for transmission over the ULE link, an encapsulator must scan its outgoing SPD for a matching policy. If no such policy can be found, the SNDU data MUST be discarded, and this event SHOULD be logged as an invalid transmission attempt. 2. Get SA: Given a matching SP, an SA is searched within the outgoing SAD using the SNDU's Selector information and the policy's SA Selector masks, including the SP's SID value if defined. If no SA could be found, it must be set up as follows: If the SP's first Security Parameter set contains default key data, or defines data to be sent without protection, the SA is immediately created and initialized according to these settings. Otherwise, if the SP defines GCKS contact information, the GCKS MUST be queried for obtaining key material. During that attempt the device SHOULD postpone transmission, or discard the data. Any case of failure MUST result in the data being discarded, and this event SHOULD be logged (e.g., as a user authentication failure in the case of membership denial by the GCKS). If the SA allows passing data unprotected, processing continues as usual [3]. 3. Check SA: The SA may have a pre-defined lifetime (e.g., maximum number of encryptions, sequence number state, seconds since instantiation) after which it may no longer be used. To allow for a transient switch-over to a new SA, the SA must define a point prior to its lifetime end at which transmitters switch to the new SA. If that point is reached, a device MAY proactively request a new SA from a GCKS. In general, it is the responsibility of the operator or the GCKS to create new SAs, and distributing these to legitimate transmitter and receiver devices in time. If no new SA is available, a transmitter MAY still use the current SA during its full lifetime. After that, it MUST discard the data, and this event SHOULD be logged. 4. Construct SNDU: A protected SNDU is built as follows: a. First, the ULE base header and any extension headers preceding the security extension header are written. If the SA requests Noisternig et al. Expires January 13, 2010 [Page 14] Internet-Draft Security Extension for ULE July 2009 identity protection, the destination NPA address is omitted from the base header, setting the base header's D bit to 1 (though another label may be re-inserted, see section 5.2). The last next-header-type field within the extension header chain contains the type code for the security extension. b. The SID value is written as the first field of the security extension header. c. If identity protection is used, the SNDU's destination NPA address follows. It is encrypted along with the payload. d. Any SA-dependent data, such as sequence numbers and initialization vectors, are written subsequently. e. Then, the next-header-type field, any further extension headers, and the payload data are encoded as defined by the SA's data confidentiality algorithm (together with the encrypted destination NPA address). f. For authentication and integrity protection, a MAC of length as defined by the SA is appended. The MAC is computed over all the data encoded so far, i.e., from the start of the SNDU to the end of the payload data. g. Finally, the CRC is calculated and appended, and the SNDU further processed according to RFC 4326. 5. Update SA: After transmission of the SNDU, the SA MUST be updated (e.g., the sequence number incremented by one). Noisternig et al. Expires January 13, 2010 [Page 15] Internet-Draft Security Extension for ULE July 2009 +-----------------+ | receive PDU | +-----------------+ +---->|from upper layers|<-------------------| discard PDU | | +-----------------+ +-----------------+ | v ^ | +-----------------+ not found? +-----------------+ | | get SP |------------------->| log event |<-+ | +-----------------+ +-----------------+ | | v ^ failure? | | +-----------------+ not found? +-----------------+ | | +--| get SA |------------------->| create SA | | | | +-----------------+ +-----------------+ | | |w/o | | success? | | |sec.ext. | +----------------+ | | | v | | | | +-----------------+ end of | | | | | check SA |-----------------------------------------+ | | +-----------------+ lifetime? | | | | | +-----------------+ | | | expected | | get new SA | | | +---------------------------->| from GCKS | | | | lifetime end? | +-----------------+ | | v | v failure? | | +-----------------+ | +-----------------+ | +->| construct SNDU |<-----------+ | log event | | | & transmit | +-----------------+ | +-----------------+ | v | +-----------------+ | | update SA | | +-----------------+ | | +--------------+ Figure 2. Transmitter Processing Flow Chart 6.4. Receiver Processing For a receiver device to process SNDUs containing the security extension, the following steps must be performed: 1. Decode SNDU (1): First, the CRC of an SNDU received is verified, and the base header and extension headers preceding a security extension header or the payload are evaluated. 2. Get SA: If a security extension header is found, a longest-match search within the incoming SAD is performed as described in Noisternig et al. Expires January 13, 2010 [Page 16] Internet-Draft Security Extension for ULE July 2009 section III. If it contains a matching SA, processing continues at step 4. 3. Get SP: The SPD is scanned similar to step 1 in the transmitter processing specification. However, the destination NPA address may be hidden, and consequently the SP must define whether the address must be matched or not. When the SNDU is received without a security extension header but the SP does not permit data to pass unprotected, the SNDU MUST be discarded immediately, and this event SHOULD be logged. Likewise, if there is a security extension header, but the policy allows only for unprotected data, the SNDU MUST be discarded, and the event SHOULD be logged. When permitted, an unprotected SNDU is processed as usual [3]. Otherwise, an SA is created as described in step 2 of the transmitter processing specification. 4. Check SA: If the SA's lifetime has expired, the SNDU MUST be discarded, and this SHOULD be logged. If the extension header contains an encrypted destination NPA address, it is first decrypted, using the SA-dependent data, and checked for a valid address for that SA. If the decoded address is not accepted by the receiver device and the SA, the SNDU MUST be silently discarded. 5. Decode SNDU (2): This step includes verification of the MAC, protection against replay attacks, and decoding of the payload. In any case of failure, the SNDU MUST be discarded, and this event SHOULD be logged. 6. Update SA: After successful reception of an SNDU, the SA MUST be updated (e.g., the sequence number set to the one found within the SNDU, incremented by one). Noisternig et al. Expires January 13, 2010 [Page 17] Internet-Draft Security Extension for ULE July 2009 +-----------------+ | receive SNDU | +-----------------+ +---->| from MPEG layer |<----------------| discard SNDU |<----+ | +-----------------+ +-----------------+ | | v ^ | | +-----------------+ decoding error? +-----------------+ | | |decode headers up|- - - - - - - - >| log event |<-+ | | | to security ext.| +------->| | | | | +-----------------+ | +-----------------+ | | | | | not found/ ^ | | | v | not permitted? | | | | +-----------------+ not found? +-----------------+ | | | +--| get SA |---------------->| get SP | | | | | +-----------------+ | +-----------------+ | | | |w/o | | success? | | | | |sec.ext. v | v | | | | +-----------------+ end of | +-----------------+ | | | | | check SA |--------+ | create SA |->| | | | +-----------------+ lifetime? +----------------+ | | | | | success? | | | | | | +--------------------------------+ | | | | | | | | | | v v | | | | +-----------------+ decoding error? | | | +->| decode SNDU |--------------------------------------+ | | | & pass to L3 | | | | |-----------------------------------------+ | +-----------------+ destination address mismatch? | v | +-----------------+ | | update SA | | +-----------------+ | | +--------------+ Figure 3. Receiver Processing Flow Chart 7. Key Management Considerations Small and rather static network configurations may be supported using manual keying. More elaborate settings, consisting of a higher number of devices, or when users need to be added or excluded more frequently, require some automated key management. This may be defined independently of the ULE security extension. This section presents some considerations on this issue. Noisternig et al. Expires January 13, 2010 [Page 18] Internet-Draft Security Extension for ULE July 2009 7.1. MSEC/IPsec Key Management Protocols MSEC/IPsec key management protocols, such as the Group Domain of Interpretation (GDOI) and the Group Secure Association Key Management Protocol (GSAKMP) protocols, may be adapted for the ULE security extension. This has the advantage of sharing similar functionality in terms of SA lookup and database architectures. The protocol may be run entirely within the ULE network, or it may be performed by some other means. This is a matter of policy and an architecture decision. For example, for bidirectional transfers the whole key exchange procedures could be carried within the ULE network, while for unidirectional links some other bidirectional connection could be used. 7.2. Existing L2 Key Management Infrastructure ULE security may re-use an already existing L2 key management infrastructure, such as the DVB-RCS security system [5]. The format of the ULE-Security-ID will be the same format as defined in DVB-RCS security procedures. 7.3. Other Considerations Key management protocols are traditionally assuming bidirectional links. GSAKMP provides some initial support for push operation. However, supporting unidirectional links within the ULE network may require defining a new protocol. Such a protocol should be designed flexibly to support bidirectional operation as well without a change in the header structures. Existing L2 unidirectional mechanism may be evaluated, such as DVB- Conditional Access (CA) and ATSC-CA. 8. Security Considerations Link-level security is commonly used in broadcast/radio links to supplement end-to-end security, and may not be treated as a substitute for end-to-end security. A common objective is to provide the same level of privacy as terrestrial links. A number of security considerations specific to the ULE security extension have been outlined throughout the document. The following paragraphs extend that analysis. Hiding destination addresses under the identity protection service is an effective mechanism against traffic flow analysis. However, there Noisternig et al. Expires January 13, 2010 [Page 19] Internet-Draft Security Extension for ULE July 2009 are other more subtle ways for a passive adversary to deduce the real destination address of an SNDU, even when precluded from decoding the destination NPA address field. For example, SNDUs with increasing sequence numbers may be linked to a single connection, providing a hint regarding the identities of the communicating parties based on packet sizes and distribution patterns. Alternatives to sequence numbers were outlined in section 5. When SID values are selected at random for bidirectional links using identity protection, they may resemble unique temporary addresses. This may be mitigated by always selecting the smallest free SID value on a receiver device, thereby increasing the chance of equal SID values among several devices. However, this also means increased processing requirements in the filtering step for these devices. Other problems arise with certain cryptographic algorithms. Stateful algorithms are problematic for manually keyed configurations when devices cannot retain their cryptographic states across device restarts (due to power or device failures, etc.). Reuse of sequence numbers for the Counter (CTR) mode renders all encryption insecure. Receiver devices may be vulnerable to replay attacks if they do not remember prior lower bounds for sequence numbers. If devices cannot store their cryptographic state in non-volatile memory, it is advised that they resort to non-stateful schemes, such as the randomized Cipher Block Chaining (CBC) mode for encryption, or the use of timestamps for replay protection (if replay protection is desired). Many stateful schemes, such as the CTR mode of operation, require nonces as part of their input. As mentioned before, nonces must never be re-used under the same key. To provide this guarantee, particularly under group communication where the encryption key is shared among several group members, some source identifier must be incorporated into the construction of the nonce. Within ULE networks, the PID may be used as a source identifier, but this is not reliable. A device may receive data from different MPEG-2 multiplexes, which both may allocate PID values independently [9]. Furthermore, multiplexors within the network may transparently re- number PID values. This is a problem for receivers as they require the originating PID value for reconstructing nonces. One solution to circumvent these issues is to assign a unique sender identifier to each legitimate transmitter under the same key [14]. To avoid the problem of associating an MPEG-2 TS with a sender identifier, the latter is included explicitly as part of the nonce in each SNDU. This means that the nonce field (e.g., sequence number) may get enlarged by the size necessary to support a predefined maximum number of different senders sharing a key. The other caveat Noisternig et al. Expires January 13, 2010 [Page 20] Internet-Draft Security Extension for ULE July 2009 of this approach is the problem of generating and distributing unique sender identifiers. The lack of a reliable source identifier entails also a potential authentication insecurity. However, this only applies for specific communication scenarios, as outlined in section 5. 9. IANA Considerations The Secure-ULE header is defined in the IANA maintained Next-Header Registry for ULE and has the value xxSecure-ULExx. 10. Acknowledgments The authors acknowledge the help and advice from Gorry Fairhurst (University of Aberdeen), L. Duquerroy (Alcatel Alenia Space) Stephane Coombes (ESA) and Yim Fun Hu (University of Bradford) in the preparation of this document. Noisternig et al. Expires January 13, 2010 [Page 21] Internet-Draft Security Extension for ULE July 2009 11. References 11.1. Normative References [1] ISO/IEC DIS 13818-1, "Information technology - Generic coding of moving pictures and associated audio information - Part1: Systems", International Standards Organisation (ISO) [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Streams", RFC 4326, December 2005. 11.2. Informative References [4] H. Cruickshank, P. Pillai, M. Noisternig, and S. Iyengar, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", RFC 5458, March 2009. [5] "Digital Video Broadcasting (DVB): Interaction Channel for satellite distribution systems", ETSI EN 301 790 v1.4.1, 2005. [6] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [7] S. Kent and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [9] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005. [10] http://www.ietf.org/html.charters/tls-charter.html [11] National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standard (FIPS) Publication, FIPS PUB 46-3, October 1999. [12] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Noisternig et al. Expires January 13, 2010 [Page 22] Internet-Draft Security Extension for ULE July 2009 Standard (FIPS) Publication, FIPS PUB 197, November 2001.[14] D. McGrew, B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", draft-ietf-msec-ipsec-group-counter- modes-03 (work in progress), 2009. Author's Addresses Michael Noisternig University of Salzburg Jakob-Haringer-Str. 2 5020 Salzburg Austria Email: mnoist@cosy.sbg.ac.at Prashant Pillai Mobile and Satellite Communications Research Centre (MSCRC) School of Engineering, Design and Technology University of Bradford Richmond Road, Bradford BD7 1DP UK Email: p.pillai@bradford.ac.uk Haitham Cruickshank Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK Email: h.cruickshank@surrey.ac.uk Noisternig et al. Expires January 13, 2010 [Page 23]