[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on Security requirements/framework for GSE/ULE
Hi All,
Based on the comments received here is a updated text on the preliminary framework for secure ULE networks:
Any comments /suggestions welcome. Will be posting a new rev (version 1) with the framework as an appendix.
Cheers
Sunny
//framework
This section aims to define a preliminary security framework for widespread deployment of secure ULE networks.
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 overview of the ULE Security extension header format along with the ULE header and payload is shown in figure 3 below. There could be other extension headers placed before or after the ULE Security Header extension
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
Figure 3: ULE Sec Header extension Placement
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].
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
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
Sent: Thu 01/03/2007 18:38
To: ipdvb@erg.abdn.ac.uk
Subject: Re: Comments on Security requirements/framework for GSE/ULE
A few quick comments...
I think figure 3 is probably too detailed for this draft, in that there
is a separate ID that describes these fields. If that were to progress
(and evolve), and you publish this here it would create confusion.
Perhaps a more overview picture would be better... based on something
like, for example:
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
It would be worth noting that there may be other Extension headers
placed before and/or after the ULE SEC header. For example, a bridge
extension header following the security header will allow the encryption
of bridged PDUs.
I'll send NiTs to the authors,
Gorry
Hi All,
Based on the comments received here is a updated text on the preliminary framework for secure ULE networks:
Any comments /suggestions welcome. Will be posting a new rev (version 1) with the framework as an appendix.
Cheers
Sunny
//framework
This section aims to define a preliminary security framework for widespread deployment of secure ULE networks.
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 overview of the ULE Security extension header format along with the ULE header and payload is shown in figure 3 below. There could be other extension headers placed before or after the ULE Security Header extension
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
Figure 3: ULE Sec Header extension Placement
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].
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
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
Sent: Thu 01/03/2007 18:38
To: ipdvb@erg.abdn.ac.uk
Subject: Re: Comments on Security requirements/framework for GSE/ULE
A few quick comments...
I think figure 3 is probably too detailed for this draft, in that there
is a separate ID that describes these fields. If that were to progress
(and evolve), and you publish this here it would create confusion.
Perhaps a more overview picture would be better... based on something
like, for example:
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
It would be worth noting that there may be other Extension headers
placed before and/or after the ULE SEC header. For example, a bridge
extension header following the security header will allow the encryption
of bridged PDUs.
I'll send NiTs to the authors,
Gorry