Internet Engineering Task Force H. Cruickshank University of Surrey, UK Internet Draft P. Pillai draft-cruickshank-ipdvb-sec-02.txt University of Bradford, UK S. Iyengar University Of Surrey, UK Expires: December 2006 L. Duquerroy Alcatel Alenia Space, France Category: Internet Draft June 22, 2006 Security Extension for Unidirectional Lightweight Encapsulation Protocol draft-cruickshank-ipdvb-sec-02.txt 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/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 December 22, 2006. Abstract This document describes the extension format for Unidirectional Encapsulation Protocol (ULE) that secures the IP traffic transported using ULE to provide security features like data Cruickshank Expires December 21, 2006 [Page 1] Internet-Draft Security Extension for ULE June 2006 confidentiality, data integrity, data origin authentication and mechanisms to prevent replay attacks. 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 RFC2119 [2]. Table of Contents 1. Introduction 3 1.1. Abbreviations used in this Document 4 2. ULE Security Extension 4 2.1. Security Services 5 2.2. Secure ULE SNDU Format 6 2.2.1. Destination Address Absent (D) Field 8 2.2.2. Length Field 8 2.2.3. Type Field 8 2.2.4. Destination NPA Address Field 8 2.2.5. ULE-SID Field 8 2.2.6. Sequence Number Field 9 2.2.7. Message Authentication Code (MAC) Field 9 2.2.7.1. Type Field 9 2.2.7.2. Encrypted PDU 9 2.3. Transmitter Processing 10 2.4. Receiver Processing 10 3. Key Exchange Procedure 11 3.1. IPsec Key Management for L2 11 3.2. Alternative Key Management 12 4. Secure ULE SNDU example 12 5. Security Considerations 13 6. IANA Considerations 13 7. Acknowledgments 13 8. References 14 8.1. Normative References 14 8.2. Informative References 14 Author's Addresses 15 Intellectual Property Statement 15 Disclaimer of Validity 16 Copyright Statement 16 Cruickshank Expires December 21, 2006 [Page 2] Internet-Draft Security Extension for ULE June 2006 1. Introduction The Unidirectional Lightweight Encapsulation Protocol (ULE) [3] is used for the transportation of user traffic like IP datagrams, ethernet frames, etc. 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 sufficient. The security requirements are presented and discussed in detail in draft- cruickshank-ipdvb-sec-req-02. 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. The focus is on providing suitable link encryption. However, link layer data integrity and data origin authentication 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). On Securing the ULE SNDUs, security is provided at the link layer as opposed to other existing mechanisms like IP Security (IPsec) [7] that provides security at the network-layer or TLS [10] that provides transport layer security. Since these security services are provided at the link layer any network layer protocol like IP (even with Ethernet bridging) may be used with Secure ULE. ULE may use and benefit from IETF key management protocols, such as the MSEC GDOI [8] and GSAKMP [6]. This does not preclude the use of other key management methods in scenarios which benefit from this. The encryption algorithms, key lengths, etc. will be defined making use of the standard IPsec suites. For this purpose a security association identity similar to the IPsec SPI [7] is used. In some current encapsulation methods like MPE [4], encryption of the MAC address requires each Receiver to decrypt all encrypted data sent using a TS Logical Channel (identified by a PID), before it can then filter the PDUs that matches the set of Network Point of Attachment (NPA) addresses that the Receiver wishes to receive. Therefore encryption of the MPE NPA address is not permitted in such systems. This document specifies a method which provides support for using temporary Layer 2 NPA address. Cruickshank Expires December 21, 2006 [Page 3] Internet-Draft Security Extension for ULE June 2006 1.1. Abbreviations used in this Document AES - Advanced Encryption Standard DVB - Digital Video Broadcasting GDOI - Group Domain of Interpretation GSKAMP - Group Secure Association Key Management Protocol IPsec - Internet Protocol Security MPE - Multi-Protocol Encapsulation MAC - Message Authentication Code NAT - Network Address Translation NCC - Network Control Centre NPA - Network Point of Attachment PEP - Protocol Enhancing Proxy PID - Packet Identifier PDU - Protocol Data Unit SAD - Security Association Database SHA - Standard Hash Algorithm SNDU - SubNetwork Data Unit SPD - Security Policy Database TLS - Transport Layer Security ULE - Unidirectional Lightweight Encapsulation Protocol 2. ULE Security Extension This section describes the security services offered and the packet format of the security extension for ULE. The procedures for processing the security extension header at the transmitter and the receiver are also described. Cruickshank Expires December 21, 2006 [Page 4] Internet-Draft Security Extension for ULE June 2006 2.1. Security Services MPEG-2 based networks are susceptible to several security attacks, both passive and active. Some of the main security services (mandatory or optional) that the security extension for ULE aims to provide for IP services running on MPEG-2 based systems are: o Data Confidentiality (Mandatory): Data confidentiality is achieved by encrypting the higher layer PDU 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 hold of the transmitted data. o Receiver NPA address hiding (mandatory): This is an important objective for ULE security to prevent any passive attacks like traffic analysis. Using option D=1 (no NPA address) is OK as long as the ULE_Security_IDentifier (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 NPA address is used (option D=0) in the base ULE header, then the Network Control Centre (NCC) is responsible for generating a temporary NPA address. The temporary NPA address should be used for all secure communications with that Receiver. The ULE encapsulator should be notified of these addresses as well. In addition, the temporary 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 NPA address is used in association with the ULE- SID for specific session security. It is envisaged that there will be a small impact on the NCC for handling two NPA addresses for each terminal. o Data origin authentication (Optional): Data origin (source) authentication allows a receiver to verify that the data is sent by the claimed sender. To achieve data origin authentication, a Message Authentication Code (MAC) is generated for each message using a shared secret key and is also transmitted along with the data. The ULE receiver would also calculate the MAC for the received data using the shared key, and then compare this computed MAC value to the one sent by the sender along with the data. If the two matches, then the receiver knows that the data had to be sent from the claimed sender. Cruickshank Expires December 21, 2006 [Page 5] Internet-Draft Security Extension for ULE June 2006 o Data Integrity (Optional): Data integrity provides a way for the receiver of the data message to know if the data has been tampered in transit by an attacker. The MAC used for data authentication also provides data integrity. The receiver of the data calculates the MAC and compares it to the one transmitted by the sender. If an adversary had tampered with the message then the two MACs would not match. o Replay Attacks Countermeasures (Optional): Methods against replay attacks need to ensure that the received data is recent and that an adversary has not replayed old messages at a later time. A monotonically increasing sequence number would be used with every message and messages with old sequence number values would be rejected. The choice of using sequence numbers is dictated by policy and is done by the key management system. Another issue is key space, which means security key storage and the related key databases. There is a need for the following two databases for the correct processing on security in ULE transmitters and receivers: o 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). o Security Association Database (SAD): Each entry defines the parameters associated with one ULE-SID such as encryption keys, keys and algorithms used for calculating the MAC, presence of Sequence number and MAC. Each ULE-SID has an entry in the SAD. This document proposes to re-use existing techniques in IPsec architecture and therefore the SPD and the SAD will follow the format of these databases as defined in RFC 4301 [7]. The security suite of algorithms for data encryption and data authenticity / integrity specified in IPsec/MSEC will be used for ULE security. The design of these databases will be simpler and also the lookups because unlike in IPsec only the ULE-SID along with the NPA address is needed to retrieve the data from these databases. 2.2. Secure ULE SNDU Format The security extension aims to secure the transmission of user traffic over MPEG-2 Transport Streams. In order to address the Cruickshank Expires December 21, 2006 [Page 6] Internet-Draft Security Extension for ULE June 2006 security issues, Figure 1 shows the SNDU format with the security extension header. This security extension is a standard extension header as described in Section 5 of RFC 4326 [3] and it should not affect the ULE base protocol. This security extension header MAY directly follow the ULE base header as shown in Figure 1 or it MAY also follow another specific extension header. This security extension header is a Mandatory ULE Extension header. This means that a receiver MUST either process this header before it processes the next extension header or the encapsulated PDU, otherwise the entire SNDU should be discarded. 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 = S-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address * | | +------------------------------+ | | ULE_Security_ID | +------------------------------+------------------------------+ | ULE_Security_ID | Sequence Num.(Optional) | +------------------------------+------------------------------+ | Sequence Number (Optional) | MAC (Optional) | +------------------------------+------------------------------+ | MAC (Optional) | Type = Type of PDU | +------------------------------+------------------------------+ | | | | = Encrypted PDU = | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ Figure 1 General SNDU format with Security extension header (D=0) In Figure 1, the Type field in the base header denotes that the mandatory security extension header is present. The receiver destination NPA address is optional. After the base ULE header the security extension header is followed. This header contains the ULE-SID, the optional Sequence Number field and the optional Message Authentication Code (MAC) field. The next type field denotes the type of the enclosed PDU. The higher layer PDU is encrypted and then encapsulated in the SNDU. Cruickshank Expires December 21, 2006 [Page 7] Internet-Draft Security Extension for ULE June 2006 The format of the Destination Address Absent field (D), the Length field the Type field and the Receiver Destination NPA address field directly follow and are used in the same way as defined for standard ULE [3]. 2.2.1. Destination Address Absent (D) Field The most significant bit of the Length Field carries the value of the Destination Address Absent Field (D) which follows the same definition as in standard ULE [3]. When D is set to 0, it indicates the presence of the Destination Address Field while D set to 1 indicates that a Destination Address Field is not present. 2.2.2. Length Field A 15-bit Length field denotes the length, in bytes, of the SNDU counted from the byte following the Type field, up to and including the CRC [3]. 2.2.3. Type Field A 16-bit Type Field indicates that this is a Secure ULE SNDU [3]. [XXX IANA ACTION REQUIRED XXX] IANA action is required to assign the Type field for the security extension header. [XXX END of IANA ACTION XXX] 2.2.4. Destination NPA Address Field The SNDU Destination Address Field is optional. This field is MUST be carried when field D is set to 0 and may be omitted when D=1 [3]. 2.2.5. ULE-SID Field A 32-bit security identifier, the ULE-SID similar to the Security Parameter Index (SPI) used in IPsec has been added to uniquely identify the secure session. This ULE-SID would represent the security association between the MPEG-2 transmitter and receiver for a particular session and will indicate the keys and algorithms used for encrypting the data payload and calculating the MAC. The ULE-SID can be used by a receiver to filter PDUs along with the NPA address. Cruickshank Expires December 21, 2006 [Page 8] Internet-Draft Security Extension for ULE June 2006 2.2.6. Sequence Number Field An optional 32-bit sequence number has been added to the ULE SNDU to prevent replay attacks. 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. 2.2.7. Message Authentication Code (MAC) Field To provide both data origin authentication and data integrity, a Message Authentication Code (MAC) is used in the extension header. The MAC is calculated over the security extension header and the encrypted data payload. The receiver would calculate the MAC for the received packet and compare it with the transmitted value. The two would not match in only 2 cases, firstly either there was an error during processing or transmission over the MPEG-2 Network, or secondly the packet has not been sent from an authenticated entity. In either case, the packet should be discarded. Hence the same MAC can be used for data origin authentication and to provide data integrity for transmission/processing errors. 2.2.7.1. Type Field This second type field denotes the type of packet that is encrypted and encapsulated in the Secure ULE SNDU. 2.2.7.2. Encrypted PDU To achieve data confidentiality, the traffic between the MPEG-2 TS Transmitter (ULE Encapsulator) and Receiver needs to be encrypted. The network layer PDUs are first encrypted and then encapsulated in the Secure ULE SNDU. The security associations between the two communicating points will describe the algorithms and keys used for encryption purposes. Secure ULE does not impose the use of any specific encryption algorithm and should be able to support the commonly used algorithms like DES, 3DES etc. Cruickshank Expires December 21, 2006 [Page 9] Internet-Draft Security Extension for ULE June 2006 2.3. Transmitter Processing The following procedure is followed at the encapsulator for processing the security extension header for ULE: o Upon reception of the higher layer PDU, the SPD is first queried to check the policy to be applied to the packet. If security is needed then an SA must exist in the SAD (this is done by the key management system). The parameters are retrieved from the SAD and the PDU is first encrypted using the key and the algorithm as indicated in the SAD o The header of the base protocol (and other extension headers if present) would be added to the SNDU. o The ULE-SID for the security association between the transmitter and the receiver would be added next. o The SAD would be used to see if the sequence number has to be added. If yes, then the corresponding sequence number is added to the SNDU. o The SAD would also be checked to see if the data origin authentication and data integrity has to be provided. If yes, then the MAC has to be calculated. The MAC is calculated over the encrypted PDU, the Security header i.e. the ULE-SID and the Sequence Number (if present) and the secret key. The MAC is then added to the extension header in the SNDU. o Then the encrypted higher layer PDU is encapsulated to the SNDU. o Finally, the CRC is calculated as defined in Section 4.6 of RFC4326 [3] and added. 2.4. Receiver Processing The following procedure is followed at the receiver for processing the security extension header for ULE: o Upon reception of the Secure ULE SNDU, the receiver may first filter the received packets according to the receiver destination NPA address (if present). o The CRC is verified as defined in RFC4326 [3]. o It would then use the ULE-SID to obtain the security Cruickshank Expires December 21, 2006 [Page 10] Internet-Draft Security Extension for ULE June 2006 associations between the transmitter and receiver and retrieve the data from the SAD. With this the receiver would know if the sequence number and the MAC are present or not. This would also be used to get the algorithms and keys used for both encryption of the encapsulated PDU and for generation of the message authentication code. o It would then use the sequence number for filtering out any out of-sequence packets. o The next step would be to check the MAC to verify the authenticity and integrity of the received packet. If the calculated MAC does not match the transmitted MAC, then the packet is discarded. o Finally the encapsulated payload will be decrypted. 3. Key Exchange Procedure 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 [9], both unidirectional and bi-directional transfers. 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 [6]). 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. 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 the 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, Cruickshank Expires December 21, 2006 [Page 11] Internet-Draft Security Extension for ULE June 2006 while for unidirectional transfers, some other bidirectional connection should be used. 3.2. Alternative Key Management The method described here for link security 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 [5]). The format of the ULE-SID will be the same format as defined in DVB-RCS security procedures. 4. Secure ULE SNDU example This section shows the ULE SNDU with the security extension header when IP datagrams are secured using Secure ULE. 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 (15 bits) | Type = S-ULE | +-+----------------------------+------------------------------+ | Temporary Receiver Destination NPA Address (48 bits) | | +------------------------------+ | | ULE_Security_ID | +------------------------------+------------------------------+ | ULE_Security_ID | Sequence Num.(Optional) | +------------------------------+------------------------------+ | Sequence Number (Optional) | MAC (Optional) | +------------------------------+------------------------------+ | MAC (Optional) | Type = Type of IPv4 | +------------------------------+------------------------------+ | | = Encrypted IP Datagram = | | +-------------------------------------------------------------+ | Cyclic Redundancy Code (32 bits) | +-------------------------------------------------------------+ Figure 2 Secure ULE SNDU with D=0 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 +-+----------------------------+------------------------------+ |1| Length (15 bits) | Type = S-ULE | +-+----------------------------+------------------------------+ | ULE_Security_ID | +-------------------------------------------------------------+ | Sequence Number (Optional) | +------------------------------+------------------------------+ Cruickshank Expires December 21, 2006 [Page 12] Internet-Draft Security Extension for ULE June 2006 | Message Authentication Code (Optional) | +------------------------------+------------------------------+ | Type = IPv4 | | +------------------------------+ | | | = Encrypted IP Datagram = | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ Figure 3 Secure ULE SNDU with D=1 5. 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. 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-replay 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 addresses. The encryption and integrity algorithms are similar to the ones used in IPsec/MSEC protocols. 6. IANA Considerations IANA action is required to assign the Type field for the security extension header (Section 2.2.3). 7. Acknowledgments The authors acknowledge the help and advice from Gorry Fairhurst (University of Aberdeen), Stephane Coombes (ESA) and Yim Fun Hu (University of Bradford) in the preparation of this draft. Cruickshank Expires December 21, 2006 [Page 13] Internet-Draft Security Extension for ULE June 2006 8. References 8.1. Normative References [1] ISO/IEC DIS 13818-1, "Information technology - Generic codeing 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. 8.2. Informative References [4] "Digital Video Broadcasting (DVB): DVB Specifications for Data Broadcasting", ETSI EN 301 192 v1.3.1, 2003. [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 Protcol", IETF draft (work in progress), May 2005. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [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 Cruickshank Expires December 21, 2006 [Page 14] Internet-Draft Security Extension for ULE June 2006 Author's Addresses Haitham Cruickshank Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK Email: h.cruickshank@surrey.ac.uk Prashant Pillai Mobile and Satellite Communications Research Centre School of Engineering, Design and Technology University of Bradford Richmond Road, Bradford BD7 1DP UK Email: p.pillai@bradford.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 Space, Toulouse France E-Mail: Laurence.Duquerroy@space.alcatel.fr 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 Cruickshank Expires December 21, 2006 [Page 15] Internet-Draft Security Extension for ULE June 2006 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 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. 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. 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. Cruickshank Expires December 21, 2006 [Page 16]