Internet Engineering Task Force H. Cruickshank Internet Draft S. Iyengar Document: draft-cruickshank-ipdvb-sec-01.txt University of Surrey L. Duquerroy Alcatel Alenia Space Category: Internet Draft 11 May 2006 A Secure Extension for the Unidirectional Lightweight Encapsulation (ULE) protocol Status of this Draft By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 [RFC2119]. Abstract This document proposes an extension format for the Unidirectional Lightweight Encapsulation (ULE) protocol. This work is intended as a work item of the ipdvb WG, and contributions are sought from the IETF on this topic. Expires November 2006 [page 1] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 Table of Contents 1. Introduction 1.1 Definitions used in this document 2. Link Security Protocol 2.1 Encryption of the SNDU payload 2.2 Encryption Extension Header format 3. Key Exchange Procedure 3.1 IPsec Key Management for L2 3.2 Alternative Key Management 4. Summary 5. Acknowledgments 6. Security Considerations 7. References 7.1 Normative References 7.2 Informative References 8. Authors' Addresses 9. IPR Notices 9.1 Intellectual Property Statement 9.2 Disclaimer of Validity 10. Copyright Statement 11. IANA Considerations Annexe A. Examples of use Expires November 2006 [page 2] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 1. Introduction This document describes an extension header for providing link layer security for the ULE [RFC4326] encapsulation which supports transport of IP datagrams or other network layer packets over ISO MPEG-2 Transport Streams [iso-mpeg]. In MPEG-2 transmission networks employing ULE, there is a need to provide link-layer (L2) security, particularly where network layer and transport-layer security (e.g. IPsec, TLS) may not be sufficient. The security requirements are presented in draft- cruickshank-ipdvb-sec-req-01. ULE may use and benefit from IETF key management protocols, such as the MSEC GDOI [RFC3547, RFC3547] and GSAKMP [msec-gsakmp]. This does not preclude the use of other key management methods in scenarios which benefit from this. In some current encapsulation methods, e.g. MPE [etsi-dat], encryption of the MAC address requires each Receiver to decrypt all encrypted data sent using a TS Logical Channel (PID), before it can then filter the PDUs that matches the set of MAC/NPA addresses that the Receiver wishes to receive, therefore encryption of the MPE MAC address is not permitted in such systems. This document specifies a mode in that provides optional support for using temporary Layer 2 MAC/NPA address. To support link level encryption, an encryption extension header is defined, and included in the SNDU payload. This approach is generic and decouples the encapsulation from the evolution of future security methods. The proposed approach suggests a new ULE Mandatory Extension header for a security. Encryption algorithms, key lengths, etc. will be defined making use of the standard IPsec suites [msec], as a security association id similar to the IPsec SPI [IPsec] is used. The focus is on providing suitable link encryption. However, Link layer data integrity is provided as an optional security service, especially for systems where there are several ULE transmitters (e.g. satellite meshed systems with On-Board Processing) 1.1 Definitions used in this document AES Advanced Encryption Standard [msec-gsakmp] D-bit Destination Address Omitted field [RFC4326] DVB Digital Video Broadcast GDOI Group Domain of Interpretation [RFC3547] GSKAMP Group Secure Association Key Management Protocol [msecgsakmp] IPsec Internet Protocol Security suite [ipsec, RFC2401, RFC2402, RFC2406] L2 Link Layer MPE Multi-Protocol Encapsulation [etsi-dat] NAT Network Address Translation [RFC3715] NCC Network Control Centre PEP Protocol Enhancing Proxy [RFC3135] PID Packet Identifier [iso-mpeg] PDU Protocol Data Unit (IP packey, MPLS frame, etc) Expires November 2006 [page 3] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 SHA-1 Standard Hash Algorithm 1 [msec-gsakmp] SID Security Identifier SNDU Subnetwork Data Unit [RFC4326] RFC 4082 Timed Efficient Stream Loss-Tolerant Authentication TLS Transport Layer Security [tls] TS MPEG-2 Transport Stream [RFC4259] ULE Unidirectional-Lightweight Encapsulation 2. Link Security Protocol This section describes the link security protocol for the ULE protocol. 2.1 Encryption of the SNDU payload The security suite of algorithms for data encryption and data integrity specified in IPsec/MSEC will be used for ULE security. The SNDU padding must be used in order to make the SNDU length as multiples of 8 or 16 byes depending on the type of encryption algorithm used. Another issue is key space there is a need for two databases for the correct processing on security in ULE Transmitters and Receivers: . Security Policy Database (SPD): This database contains the policies that determine the processing of all ULE inbound / outbound traffic (such as encrypting all outbound ULE traffic destined to a certain terminal). . Security Association Database (SAD): Each entry defines the parameters associated with one ULE-SID such as encryption . keys. Each ULE-SID has an entry in the SAD. The main aim of this document is to re-use existing techniques in IPsec architecture and therefore the SDP, SAD and will follow the format of these databases as defined in RFC 4301 [RFC4301]. The encryption is done on the entire PDU including the checksum. In the case of using sequence numbers the sequence number field is not included in the encryption process In order to prevent against the hijacking of the MPEG2-TS transport stream, a source authentication integrity block is appended to the above mentioned encrypted block. This integrity is applied over the whole SNDU including the header and after encryption (and if included the sequence number field too). At the receiver end if the integrity check fails the receiver can drop the packet without decrypting the packet. The choice of the integrity service is flagged as a matter of policy by the gateway and is handled by the key management system. In order to prevent replay attacks, the optional field of sequence number is added to the encrypted payload. This field is left in the open and does not need to be encrypted. It is a 32 bit value and it follows the ULE-SID field. The choice of using sequence numbers is dictated by policy and is done by the key management system. 2.2 Encryption Extension Header format Expires November 2006 [page 4] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 A ULE [RFC4326] encryption header extension is defined for use with any ULE payload. This extension header MAY directly follow the ULE base header (as illustrated in figures 1 and 2). It MAY also follow another specified extension header. The Encryption Extension is a Mandatory ULE Extension Header. This means that a Receiver MUST either process this header, before it processes the next header (or the enclosed PDU); otherwise the entire SNDU is to be discarded. The first two bytes of the encrypted data block contain a ULE Type field, defined by [RFC4326] that specifies the type/extension header that follows. This document defines one code-point for encryption headers. SNDUs that are not encrypted do NOT include this header. IANA action is required to assign a one code point from ULE Mandatory Next-Layer-Header Registry. 00YY Secure ULE A The ULE Security IDentifier (ULE-SID) is a 32 bit value. The ULE-SID can be used by a Receiver to filter PDUs in conjunction with the set of MAC/NPA addresses that it wishes to receive. ULE-SID to have a similar format to the Security Parameter Index (SPI) used in IPSEC and MSEC protocols. The extension MAY be used with PDUs that carry a NPA/MAC address (D=0) or with PDUs that omit this field (D=1). In the latter case, there is no MAC address present to a receiver of an encrypted ULE PDU. Receiver NPA/MAC address hiding is an important objective for ULE security. Using option D=1 (no MAC/NPA address) is OK as long as the ULE-SID is unique in the whole ULE network. This implies the need for a centralised key management system that generates the ULE-SID. If MAC/NPA address is used (option D=0), then the Network Control Center (NCC) is responsible for generating this temporary MAC/NPA address. The temporary MAC/NPA address should be used for all secure communications with that Receiver. In addition, the temporary MAC/NPA address will change from time to time depending on the security policy and it is not directly related to each ULE session. It can change periodically (for example after a specified period of time and/or after a specified volume of traffic has been sent to that terminal). The temporary MAC/NPA address is used in association with the ULE-SID for specific session security. It is envisaged that there will be small impact on the NCC for handling two MAC/NPA addresses for each terminal. In order to prevent replay attacks a optional 32-bit sequence number has been added to the ULE SNDU. The value of this sequence number would be set to 0 at the beginning of the session. The gateway would monotonically increment this number when it sends a packet to the receiver and the receiver would verify the correct sequence number. If an adversary tries to inject or replay old packets the sequence number would not match. This would result in discarding the packet. The optional source authentication block is necessary in Expires November 2006 [page 5] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 situations where the MPEG2-TS stream can be hijacked. This block prevents the attack and also provides data origin authentication. Light weight authentication mechanisms (e.g. RFC 4082 [RFC4082] could be used for this security service. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 | Length (2B) | Type = Secure ULE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Receiver temporary NPA Address (6B) | + +--+--+--+--+--+--+--+--+ | | ULE SID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ULE SID |Seq. Number (optional) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + Seq Number (4B) | | |--+--+--+--+--+--+--+--+ | | | Encrypted Block | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | Integrity Block (optional) | +--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+-| Figure 1: SNDU Format for the Encryption Header (D=0) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 | Length (2B) | Type = Secure ULE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ULE SID (4B) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Seq. Number (optional) (4B) | |--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | + | Encrypted Block | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + Integrity Block (optional) + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2: SNDU Format for the Encryption Header (D=1). This encryption header has a type value with one of two IANA- assigned 16-bit next-layer-header values. 3 Key Exchange Procedures This section describes the key exchange procedure, used to install and manage the keys at Receivers. There is a need to take into account the two cases described in [RFC4259], both unidirectional and bi-directional transfers. Expires November 2006 [page 6] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 The key management procedures are independent from the ULE operations. During the key exchange procedure, the ULE-SID will be defined. The exact data encryption and data integrity choices are linked to the key management systems in use. One example is the security suite 1 (defined in GSAKMP [msec-gsakmp]). This uses AES (CBC mode, Key Length: 128 bits) for data encryption and DSS-ASN1-DER for digital signature and SHA-1 as the Hash algorithm. Other suites will be added in future versions. A detailed key management system is not presented in this document, but two approaches are outlined. 3.1 IPsec Key Management for L2 Existing key management systems can be used such as the MSEC key exchange protocols, GDOI and GSAKMP [RFC3547 and msec-gsakmp]. The format of the ULE-SID will be identical to the security association as defined in GDOI or GSAKMP. The initial key exchange between the security server (which may reside with NCC) and the ULE Receiver can be transported either within the ULE network or may be performed by some other means. This is a matter of policy and an architecture decision. For example, for bi-directional transfers the whole key exchange procedures could be carried within the ULE network, while for unidirectional transfers, some other bidirectional connection should be used. 3.2 Alternative Key Management The method described here for link encryption could be used with alternative key management systems when used as a part of a system that already implements a key management infrastructure (e.g. the DVB-RCS security system [etsi-dvbrcs]). The format of the ULE-SID will be the same format as defined in DVB-RCS security procedures. 4. Summary This document proposes a security framework for a layer 2 security method designed for the Unidirectional-Lightweight Encapsulation (ULE) protocol. It proposes an extension format for the Unidirectional Lightweight Encapsulation (ULE) protocol. The key management for this protocol may be performed using IPsec methods such as the msec gsakmp and gdoi protocols or using other methods not defined in this document. Expires November 2006 [page 7] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 5. Acknowledgments The authors acknowledge the help and advice from Gorry Fairhurst (University of Aberdeen) in the preparation of this draft. 6. Security Considerations Link-level (L2) encryption of IP traffic is commonly used in broadcast/radio links to supplement End-to-End security (e.g. provided by TLS, SSH, Open PGP, S/MIME, IPsec). A common objective is to provide the same level of privacy as terrestrial links. An ISP or User may also wish to provide end-to-end security services to the end-users (based on the well known mechanisms such as IPsec). This document defines a method to provide optional link encryption. The method may also support optional link level integrity / authentication of the SNDU payload plus sequence numbers for anti-relay attacks. This is provided in a flexible way using a ULE Mandatory Extension Header. This decouples specification of the security functions from the encapsulation functions. This method also supports encryption of the NPA/MAC addresses. The encryption and integrity algorithms are similar to the ones used in IPSEC/MSEC protocols. 7. References 7.1 Normative References [iso-mpeg] ISO/IEC DIS 13818-1 "Information technology -- Generic coding of moving pictures and associated audio information: Systems", International Standards Organisation (ISO). [etsi-dat] EN 301 192, "Digital Video Broadcasting (DVB); DVB Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI). [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005. 7.2 Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [etsi-dvbrcs] "Digital Video Broadcasting (DVB) -- interaction channel for satellite distribution systems", ETSI EN 301 790 V1.4.1 (2005-04) [msec-gsakmp] H Harney (SPARTA ), et al, "GSAKMP: Group Secure Association Group Management Protocol", , IETF Work in Progress. [RFC3547] M. Baugher , et al, "GDOI: The Group Domain of Interpretation" RFC 3547. [RFC3715] B. Aboba and W Dixson, " IPsec-Network Address Translation (NAT) Compatibility Requirements" [RFC4259] Montpetit, M.-J., 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. [msec] http://www.ietf.org/html.charters/msec-charter.html [IPsec] http://www.ietf.org/html.charters/wg- dir.html#Security%20Area. RFCs 2401, 2402 and 2406 [tls] http://www.ietf.org/html.charters/tls-charter.html Expires November 2006 [page 8] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001. [RFC4301] S. Kent, et al, "Security Architecture for the Internet Protocol", RFC 4301, December 2006. [RFC4082] A. Perrig, et al, "Timed Efficient Stream Loss- Tolerant Authentication", RFC 4082, June 2005. 8.Authors' Addresses Haitham Cruickshank Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK Email: h.cruickshank@surrey.ac.uk Sunil Iyengar Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK Email: S.Iyengar@surrey.ac.uk Laurence Duquerroy Research Department/Advanced Telecom Satellite Systems Alcatel Alenia Space, Toulouse France E-Mail: Laurence.Duquerroy@space.alcatel.fr 9. IPR Notices 9.1 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention Expires November 2006 [page 9] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006 any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 9.2 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 12. IANA Considerations This document will require IANA involvement. To assign a pair of Mandatory header extension values from the ULE Registry. Annexe A. Examples of use No examples of use are provided in this revision of the I-D. Expires November 2006 [page 10]