Subject: RE: Comments on Security requirements/framework for GSE/ULE

From: <[email-masked]>
Date: Thu, 1 Mar 2007 17:58:28 -0000

Hi All,
As the ULE security requirements draft is accepted a working group item, we (authors) wanted to increase the scope of the work by defining a framework for secure ULE networks. We wanted to show how the security requirements are satisfied and how the various building blocks interact to have a secure ULE architecture. 
Before we decide to submit a revised ID (version 1) showing this framework (appendix), we decided to post our ideas on the IPDVB ,ailing list for comments and suggestions. Please find below the framework for secure ULE networks and the building blocks as well as the way they interact. 
We are open to suggestions and comments from you and will be more than happy to include all of those in our next revision.
 
Cheers
Sunil 

//framework
 
This section aims to define a preliminary security framework for 
       ULE. It discusses the different blocks and their interfaces to 
       define a secure ULE architecture. The objective of this section 
       is to serve as a framework for related protocol development in 
       order to develop the full set of specifications required for 
       widespread deployment of secure ULE networks. 
        
    12.1. Building Blocks 
       This ULE Security framework defines the following building blocks 
       as shown in the figure 2 below: 
       1. The Key Management Block 
       2. The ULE Extension Header Block 
       3. The ULE Databases Block 

                                                +------+----------+              +---------------- 
                                | Key Management  |/------------\| Key Management | 
                                |     Block       |\------------/|     Block      | 
                                |  Group Member   |              |  Group Server  | 
                                +------+----------+              +---------------- 
                                       | |                                     
                                       | |  
                                       | | 
                                       | | 
                                       | | 
                                       \ / 
                                +------+----------+      
                                +      ULE        |      
                                |   SAD / SPD     |       
                                | Interface Block | 
                                +------+-+--------+     
                                       / \ 
                                       | | 
                                       | |                                    
                                       | | 
                                       | | 
                                       | | 
                                       | | 
                                +------+-+--------+                            
                                |   ULE Security  |                            
                                | Extension Header| 
                                |     Block       |                            
                                +-----------------+                       
        
                   Figure 2 : Secure ULE framework Building Blocks 

1) Key Management Block 
       In order to provide security at the ULE level using extension 
       headers, a key management framework is required. This key 
       management framework is responsible for user authentication, 
       access control, and Security Association negotiation (which 
       include the negotiations of the security algorithms to be used 
       and the generation of the different session keys as well as 
       policy material). This Key management framework can be either 
       automated or manual. Hence Key management client entity will be 
       present in all ULE receivers as well as ULE sources. In some 
       cases the ULE source could also be the Key Server Entity. Key 
       management protocols like GSAKMP may be used or manual insertion 
       of keying material can also be deployed.  
        
  2.             ULE Extension header Block 
       A new security extension header for the ULE protocol is required 
       to provide the security features of data confidentiality, data 
       integrity, data authentication and mechanisms to prevent replay 
       attacks. Security keying material will be used for the different 
       security algorithms (for encryption/decryption, MAC generation, 
       etc.), which are used to meet the security requirements, 
       described in detail in Section 4 of this draft. 
       This block will use the keying material and policy information 
       from the ULE security database block on the ULE payload to 
       generate the secure ULE extension Header or to decipher the 
       secure ULE extension header to get the ULE payload. An example of 
       the ULE Security extension header format is shown in the figure 
       below and is explained in [ID-SE]. 
              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 *             |  
              |                              +------------------------------+  
              |                              |      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 3 : General SNDU format with Security extension header (D=0)[ID-SE] 
        
  3.    ULE Databases Block 
       There needs to be two databases i.e. similar to the IPSec 
       databases.  
       o ULE-SAD: ULE Secure Association Database contains all the 
          Security Associations that are currently established with 
          different ULE peers. 
       o ULE-SPD: ULE Secure Policy Database contains the policies as 
          defined by the system manager. Those policies describe the 
          security services that must be enforced 
       The design of these two databases will be based on IPSec 
       databases as defined in RFC4301 [RFC4301].  
 
    12.2. Interface definition 
       Two new interfaces have to be defined between the three blocks as 
       shown in figure 2 above. These interfaces are: 
       o Key management <-> ULE Security databases  
       o ULE Security databases <-> ULE interfaces 
       While the first interface is used by the Key Management Block to 
       insert keys, security associations and policies into the ULE 
       Database Block, the second interface is used by the ULE Extension 
       Header Block to get the keys and policy material for the ULE 
       Payloads. 
 
       1.  Key management <-> ULE Security databases 
       This interface is between the Key Management client block (GM 
       client) and the ULE Security Database block. The Key management 
       client will communicate with the GCKS and then get the relevant 
       security information (keys, cipher mode, security service, 
       ULE_Security_ID and other relevant keying material as well as 
       policy) and insert this data into the ULE Security database 
       block. The ULE Security database block holds the records of all 
       security associations currently used as well as information for 
       security policy control. The Key management could be either 
       automated (GSAKMP) or manually inserted using this interface. The 
       following three interface functions are defined: 
       Insert_record_database (char * Database, char * record, char *  Unique_ID); 
       Update_record_database (char * Database, char * record, char *  Unique_ID); 
       Delete_record_database (char * Database, char * Unique_ID); 
        
       2.  ULE Security databases <-> ULE interfaces 
       This interface is between the ULE Security Database and the ULE 
       Engine. For Outbound Traffic, firstly the ULE Engine using the 
       Destination Address and the ULE_Security_ID searches the ULE 
       Security Database for the relevant security record. It then uses 
       the record data to create the ULE security extension header 
       [ref]. For inbound traffic, the ULE engine on receiving the ULE 
       packet will first get the record from the Security Database using 
       the Destination Address and the ULE_Security_ID. It then uses 
       this information to decrypt the ULE extension header.  
       In both cases only one interface is needed: 
       . Get_record_database (char * Database, char * record, char *   Unique_ID); 
 
//end of framework