AES Key Distribution for TRANSEC and Half Loop (S5066-EP15)

1. Model

This specification defines a file format with a list of AES keys with time validity. The model is that keys are distributed well in advance, so that a receiving system will always have the correct key for current use. Keys will always be used from sender to receiver. They may be marked for two way use, to avoid the overhead of keys being sent both ways when there is no requirement to use different keys in each direction.

The file format may be distributed by any mechanism. An email based mechanism is defined here.

2. Email Distribution

Files are sent by encrypted email, which can be S/MIME or STANAG 4406. Benefits of doing this:

• No new protocol mechanisms are needed.
• Standard encryption can be used.
• Sender validated by digital signature.
• Multicast/broadcast keys can be distributed in one message to multiple recipients.

This gives a red side key management and distribution system. Doing this red side maximizes protection. However, it does require a mechanism to install keys on black side

3. Requirements

3.1. General Requirements

The following requirements apply to both protocols:

• Keys need to be given a lifetime.
• Different AES key lengths need to be supported.

3.2. AES TRANSEC Requirements

Specific AES TRANSEC requirements:

• Each key must have an associated 4 byte Nonce.
• Each key nonce pair must be assigned a 32 bit identifier, which must be unique.
• Key lifetimes should overlap to enable smooth transition.
• Need to indicate if a key between a pair of nodes is to be used in both directions. When bi-directional keys are used, there needs to be a prior agreement as to which side generates the keys.

Where a system distributes keys to multiple nodes, the target node is implied by the distribution, which must match the target addresses in the file.

3.3. Half Loop Requirements

Specific requirements for Half Loop.

• Key lifetimes should not overlap. There should only be one key valid at a time.

4. File Format Encoding

4.1. File Format

The basic file is encoded as follows

	MSB 7	6	5	4	3	2	1	LSB 0
0	Not Used				Version=0
1 5	Source Address
6 10	Target Address
11 n	AES Records

For this version of the protocol, Version=0. 

Source Address is the STANAG 5066 Address of the node generating the AES Keys, Target Address is the STANAG 5066 Address of the node or group receiving the keys.

The rest of the file is a sequence of Records.  

4.2. General Record Structure

Records have the format:

	MSB 7	6	5	4	3	2	1	LSB 0
0	Record Type
1 n	Record Data

Record Type is an integer, that defines format of the record.

Times are encoded as Unix Time_t value with a three byte encoding to avoid the 2038 problem.

AES has the following key lengths, with an integer value assigned to each.

Value	Key Length (bits)	Key Length (bytes)
0	128	16
1	192	24
2	256	32

4.3. AES TRANSEC Record

	MSB 7	6	5	4	3	2	1	LSB 0
0	Record Type=1
1 4	Start Validity Time
5 8	End Validity Time
9	Not Used			Two way	AES Key Length
10 11	Key/Nonce Reference
12 15	Nonce
16 n	AES Key

4.4. Half Loop Record

	MSB 7	6	5	4	3	2	1	LSB 0
0	Record Type=1
1 4	Start Validity Time
5 8	End Validity Time
9	Not Used				AES Key Length
10 n	AES Key

5. Changes to STANAG 5066

This document defines a new management protocol associated with STANAG 5066. It is not really a protocol change.

6. Backwards Compatibility

There are no backwards compatibility issues.