[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: >IPv4 Security & MLS
Reply to: RE>>IPv4 Security & MLS
>
> So it seems that any security labels would be logically part
> of the data "inside" an encrypting security protocol, and thus
> not a direct concern of the security protocol itself.
>
>Yes and no. In an environment where labels exist, the key management
>protocol has to generate keys for each label and host pair, and the
>host encryption software has to know that there is a key per label
>and destination or source.
No. You do not always need a key per label. This is not a requirement it
is one mechanism that we could consider.
An SAID (per NLSP, TLSP, and IEEE 802.10) provides the information required
to select the algorithm and key to decrypt a packet. This information may
include an implicit label. When implicit labels are used between the same
host pairs some threats may require a key per labels. Other mechanisms
could be used besides multiple keys per host pair to ensure the integrity of
the label information.
The requirements we are discussing seems to be:
* support the binding of a security label to the IPSEC protected packets
* provide integrity protection for the security labels bound to the
protected packets
Optional features we are discussing:
* provide a mechanism to efficiently carry labeling information
Mechanisms to bind the security label to the IPSP packet include:
- explicitly in protected header as a variable length field (CIPSO,
IPSO)
- implicitly bound to the packet, the label is determined when a
Security Association (SA) is created
- carried in the protected header in a compressed form, label mapping to
the reduced
representation must usually be established when the SA is created
Hopefully when the secretary posts the minutes from the March meeting (hint,
hint) we can try to focus on the requirements and issues we identified in
Ohio.
Also, sorry for responding backwards on this discussion thread, but I tend
to treat by mail as a FILO queue.
Paul