[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on Security requirements/framework for GSE/ULE
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
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