[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
It will see either an Authentication Header:
+--------+--------+---------+---------+
|Nxt Plod| Length | Reserved |
+--------+--------+---------+---------+
| Security Association ID | (32 bits)
+--------+--------+---------+---------+
| Auth data (variable length) |
| |
| | (variable size, random binary data)
+--------+--------+---------+---------+
or a Security Header:
+--------+--------+---------+---------+
| Security Association ID | (32 bits)
+--------+--------+---------+---------+
| Secure data (variable length) |
| |
| | (variable size, random binary data)
+--------+--------+---------+---------+
I make the following observations:
1) The Auth data length is limited to the range 0 - 255
2) The Security payload *MUST* be the last and *ONLY* Security Payload in
the packet since there is no cleartext Next Payload field.
3) If the "Authentication" Header were to have its length field extended to
16 or 24 bits this would allow a larger amount of variable binary data
which could be used for Authentication, Security or both.
Further, more than one Secure Payload could be carried in a packet if
required and it need not be last payload.
The interpretation of the variable length binary data is be controlled
by the SAID. The receiver uses the SAID as an index or key into an
array of records which contain information which enable the received data
to be interpreted. The records would indicate:
The security mechanisms to be used (DES, MD5 etc)
The data required by those mechanisms (keys etc)
How the mechanisms are to be applied to the data (order of mechanism
application, range of data to be processed, location of
Algorithm-dependent init stuff etc)
How the security processed data is to be interpreted after processing
(Authentication, protected data packet e.g.:
Security Processed Data:
+--------+--------+---------+---------+
|Next Hdr| Length | Reserved | (8/8/16 bits; per usual IPv6 practice)
+--------+--------+---------+---------+
| TCP/UDP payload or header indicated |
+ | (variable size)
| by Next Hdr value above |
+--------+--------+---------+---------+
| Algorithm-dependent trailing stuff | (variable size, would put padding
+--------+--------+---------+---------+ for block-mode algorithms here, etc)
Thus the SAID can be used by the receiver to differentiate between
Authentication and other uses of the data. In some cases several uses may
be optimised such as the case when pairwise unique secret keys are used for
encryption. This may give both Authentication and Confidentiality in one
go.
The records at the receiver (and sender) corresponding to the SAIDs must be
complete for the security functionality to work. The information may be
placed in a number of different ways:
o Pre-defined in a RFC standard and compiled in,
o Loaded locally (floppy disk, smart card? etc)
o Set up in some on-line management exchange (ICMP-like or DNS lookup).
The DNS will most likely contain certificates with Public keys in,
so the format could also contain the associated SAID for initial
contact.
Some allocation of the SAID space for local/global allocation as propossed
in IEEE 802.10 seems to be sensible to allow for multicast.
Antony Martin
Defence Research Agency
Malvern
UK