On Mon, May 12, 2008 at 08:40:29PM -0400, Bill Sommerfeld wrote:
> A revised design document incorporating responses to the comments so
> far, plus a glossary of terms used in the document, is now available at:
>
> http://www.opensolaris.org/os/project/txipsec/Design/phase1-0.4.pdf
- I'm not sure if it's my PDF viewer or the software that you used for
generating the PDF, but there are lots of odd characters being used
that make cut-n-paste into ASCII e-mail painful (e.g., ff and ffi
ligatures). Also, searching for "SIT_SECRECY" only finds one
instance, but there's clearly at least two other instances that are
rendered with an underscore, but cut-n-paste transposes that
"underscore" into a space. Weird.
-
"
2. CIPSO+IPsec
IPsec-protected traffic and key management traffic may also
carry CIPSO labels. CIPSO labels in received packets will be
validated against the SADB. The on-the-wire CIPSO label used
for protected traffic is under the control of key management,
and may either match the internal label of the traffic, or be
assigned by key management.
"
Putting key management in control over both, implicit and explicit
labels when both are in use is good: there will be no chance that
inconsistent tn*db and ike.config will cause inconsistent labeling on
the wire.
-
"
Internally to the kernel, each dblk_t contains a cred_t *db_credp
field which may point to the credentials (including the label)
associated with the message.
"
For those of us who are not familiar with these details: what does
"may" mean here? What is done with dblk_ts whose db_credp is NULL?
What about incoming packets, how is their db_credp worked out, or if
left as NULL, how is labeling communicated upstream? Does latching
play a role here (IPsec classifies inbound packets and checks that
the label matches an established latch)?
-
"
Care must be taken with outer sensitivity labels in the event that
no confidentiality protection is requested (either by the use of
AH alone, or the use of ESP without encryption).
A future phase may provide for kernel-level constraints on the
relationship between the inner label, the outer label, and
requested security services (perhaps allowing the kernel to
require that the outer label dominate the inner label if
confidentiality is not used). Such constraints are out of scope
for this phase.
"
I can understand the plaintext and ciphertext having different
labels. But if we know that ESP with confidentiality protection is
not in use (or that no integrity protection is being provided), then
it seems to me that it should be an error for the outer sensitivity
label to not match or dominate the SA label. Why is this out of
scope?
-
"
If the inner sensitivity extension is not present, the SA will be
considered unlabelled and, for compatibility with existing behavior,
may carry traffic under multiple labels. Precisely how the label is
carried in this case is TBD, but will most likely involve a CIPSO
option protected by either AH or ESP integrity protection and perhaps
ESP confidentiality protection.
"
This strikes me as something that shouldn't be a TBD. There are
several choices: a) all the traffic for such an SA is single-label
(check tn*db to find out) and, if so, CIPSO is not needed, b)
unprotected CIPSO outside tunnel mode IPsec, c) unprotected CIPSO
outside transport mode w/ ESP-only, d) CIPSO protected by AH in in
transport mode, e) CIPSO protected by AH/ESP in tunnel mode.
Interop might dictate that (a), (b) and (c) must be supported, but
I'd think that (b) and (c) should require explicit configuration, and
that (d) or (e) should be defaults.
In any case, I don't think ike.config today gives much control over
whether an SA will be used in transport or tunnel mode, so I'm not
sure how options which are left out of scope will be added later.
Presumably the SPD and ike.config have to both be consistent with
what the administrator actually wants. So what you actually get will
depend on ipsecconf, no?
- I assume that [it goes without saying that] IP_SEC_OPT requests that
conflict with whatever option is dictated by IKE/SPD config will
fail.
- Certificate extensions for labeling are out of scope, yes? In the
future I'd imagine an ike.config directive like "wire-label
from-cert" would be the interface for configuring the use of a cert
extension for working out SA labeling.
Nico
--
