G.Hn : Security Considerations

ITU - Telecommunication Standardization Sector Temporary Document FF-031

STUDY GROUP 15 Original: English

Ft. Lauderdale, Florida 5-8 November 2007

Question: 4/15

SOURCE1: CopperGate Communications

TITLE: G.hn: Security considerations ______

ABSTRACT

This contribution outlines some security considerations and guidelines for G.hn networks. The derived requirements could then be used in order to allow efficient operation maintaining performance and ensuring high level of security.

1. Introduction Existing security schemes were specifically designed to meet the security requirements of a particular network. This fact must be emphasized since adopting an existing scheme without first understanding the requirements might lead to a solution which provides security but prevents QoS, overloads traffic and reduces significantly performance. This contribution outlines some security considerations and guidelines for G.hn networks as were described in [5]. The considerations could then be used in order to allow efficient operation maintaining performance and ensuring high level of security.

2. Discussions The security properties of a system are derived by three main functions, encryption, authentication procedures and the key management protocols. Network performance is usually affected by the last two, Authentication and key management procedures. Authentication and the key exchange protocols should be well designed in order to guarantee high level of security while maintaining high efficiency (keeping the necessary overhead to be minimal).

In the context of G.hn, security might be achieved but if protocols are not well suited, QoS remains a wishful goal.

3. Design Considerations 3.1. Authentication and encryption of a domain and its nodes Authentication of a node is performed during registration procedure. At this stage the node is not exposed to the security secrets delivered over the network. Also it doesn’t run any service so there is no need for large buffering mechanism. As was explained in [5], after a node has been authenticated the validation of its flows is not relevant. This status remains as long as it is part of an active domain. The importance of this simple concept is that all nodes that are part of a domain are considered authenticated and confidentiality of all traffic within border of the domain is maintained!

1 Contact: Reuven Franco Tel: +972-3-644 4488 x 235 CopperGate Communications E-mail: [email protected] It is proposed to agree that:

3.28.3 Should authentication be done per a domain? (nodes are authenticated when they join the domain)?

3.2. Message Authentication Codes (MACs) MACs (Message Authentication Codes) provide data authentication and integrity. A MAC is a cryptographic checksum on the data that is used to provide assurance that the data has not changed and that the MAC was computed by the expected entity.

Authentication should be done in a domain level (authentication of nodes when they register to a domain). Once a node is authenticated (joined a domain) there is no need to authenticate its transmissions or at least not every transmission. In this way, an overhead of at least 10bytes- 16bytes might be saved per each transmission. According to the specification of CCM (CBC-MAC) [2], “CCM generation-encryption expands the size of the payload by the size of the MAC.”

Following the above it is proposed to agree on the following item:

3.28.3 Should authentication be done per a domain? (nodes are authenticated when they join the domain)?

CCM mode which was proposed to be specified in G.hn incorporates both CBC and CTR modes [3]. Therefore it is proposed that CBC mode of operation as specified in NIST special publication 800-38A [3] shall be used for confidentiality.

3.3. Initialization Vectors An Initialization Vector (IV) is used in most of the encryption schemes as the first step during encryption process. The IV can be the outcome of a known process yet be unpredictable. We think that G.hn should focus on methods where the IV is not part of the traffic but derived in an unpredictable way as opposed to schemes where the IV is delivered per each encryption process (resulting by additional overhead). The cryptography world provides efficient means to overcome this problem. Of course the rules for calculating and producing IVs should be specified. NIST recommendations even allow setting of IV to zero in certain cases and provide recommendations of how to obtain IV based in already delivered data or headers without increasing overhead We would like to propose to agree on the following item to reduce overheads: 3.31 Should the security scheme not deliver the encryption Initialization Vector (IV) over the media?

3.4. Communication between different domains The G.hn draft text currently states “Nodes connected to different domains communicate via inter- domain bridges (e.g. L2 or L3 bridging)”. It was also agreed that the G.hn Recommendation shall support inter-domain bridges (see item 3.21 in the issues list). We believe that this working text should be upgraded by agreement which states:  That Nodes connected to different domains communicate via inter-domain bridges (e.g. L2 or L3 bridging)”.

The motivation behind the proposal is to allow secured communication between nodes that belong to different domains. Each domain holds its own set of keys. These keys shouldn’t be used outside 2 of a domain (above the A1 interface). Any secured communication between domains requires that these domains be mutually authenticated. It requires additional set of keys and protocols to be used above the A1 interface. Active bridges hold security and authentication protocols allowing such secured paths. 3.5. Cryptoperiod and key association A cryptoperiod is the time span during which a specific key remain in effect. Cryptoperiods are affected by the following partial list:  The strength of the cryptographic mechanisms  operating environment (e.g., secure limited access facility, open office environment, in- home)  The volume of information flow and the number of transactions  The key update or key derivation process  The number of nodes sharing a common key  The threat model to the information

Every application requires a different level of security if at all and a different cryptoperiod. Two examples are emails and IPTV. The first shouldn’t be bounded by the cryptoperiod since the key that is used might not be relevant at the time the recipient will access its mail. As for the IPTV, usually the application is running simultaneously in both sides where keys may be changed (no need to exchange keys) according to a predefined cryptographic algorithm.

The association of applications and key exchange schemes is not possible at this stage since the G.hn is not restricted to certain applications and we can’t foresee what the future would be. Accordingly, applications should be responsible to provide the necessary amount of security above a secured domain as done today by most of the applications that require security.

Based n the above we propose 3.33 Should security and key management associated with applications be performed above the A1 interface as part of the application layer or above and therefore out of the scope of G.hn? 3.6. Key sharing and operation modes Three different operation modes (PM, CM and UM) were defined (and more might be proposed). The domain should be capable to switch between operation modes while maintaining performance and QoS. All traffic is scheduled and coordinated by the domain master so there should be no problem in doing so. A limiting factor might be if different mechanisms and different protocols are tailored and specified per mode of operation. If this is the case, the transition between modes of operation will be unpredictable due to massive keys distribution, overloading traffic, and unpredictable latencies. Even the security level might be changed. Saying that it is proposed: 3.34 Should security means not degrade performance and QoS during transitions between operating modes?

4. References [1] RJ-U12R1: G.hn: Updated Issues List, Red Bank, New Jersey – 8-12 October 2007.. [2] Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality - NIST special publication 800-38C. [3] Recommendation for Block Cipher Modes of Operation – NIST special publication 800-38A. [4] RJ-R12: G.hn Draft text – version 1.1”, Red Bank, New Jersey – 8-12 October 2007. [5] RJ-038: “G.hn: Requirements for Security”, Red Bank, New Jersey – 8-12 October 2007.

5. Summary The purpose of this paper is to outline a list of security design considerations, goals and requirements to allow maintaining performance and ensuring high level of security.

It is proposed to agree on the following items:

new That CBC mode of operation as specified in NIST special publication 800-38A [3] shall be used for confidentiality. 3.28.3 Should authentication be done per a domain? (nodes are authenticated when they join the domain)? 3.29 Should nodes connected to different domains communicate with each other via inter-domain bridges (e.g., L2 or L3 bridging)? 3.31 Should the security scheme not deliver the encryption Initialization Vector (IV) over the media? 3.33 Should security and key management associated with applications be performed above the A1 interface as part of the application layer or above and therefore out of the scope of G.hn? 3.34 Should security means not degrade performance and QoS during transitions between operating modes?