Subject: Re: [IPsec] Proposed work item: Labelled IPsec

From: Scott C Moonen <[email-masked]>
Date: Wed, 2 Dec 2009 20:42:38 -0500

If this proposal is accepted, I commit to review it.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Yaron Sheffer <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
11/29/2009 12:26 PM
Subject:
[IPsec] Proposed work item: Labelled IPsec

This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec 
to be used in environments that require Mandatory Access Control. It is 
envisioned that this will be used by modern high-security operating 
systems, that go beyond the currently supported Multilevel Security (MLS).

Proposed starting point: 
http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and 
http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01.
 
Please reply to the list:
 
- If this proposal is accepted as a WG work item, are you committing to 
review multiple versions of the draft?
- Are you willing to contribute text to the draft?
- Would you like to co-author it?
 
Please also reply to the list if:
 
- You believe this is NOT a reasonable activity for the WG to spend time 
on.
 
If this is the case, please explain your position. Do not explore the fine 
technical details (which will change anyway, once the WG gets hold of the 
draft); instead explain why this is uninteresting for the WG or for the 
industry at large. Also, please mark the title clearly (e.g. "DES40-export 
in IPsec - NO!").
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2009 22:05:04 -0500

Yaron Sheffer wrote:
> This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to be used in environments that require Mandatory Access Control. It is envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS).
> 
> Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01.
>  

I have no interest in this work.
I am not convinced that this work has very broad interest.  I think that
in most cases, this work can be done with vendor extensions until it is
finished, at which point an Informational RFC could ask for IANA
assigned values, and be published.

I am unclear if this work has any mainstream value without an IPsec API.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2009 22:05:04 -0500

---

From: Joy Latten <[email-masked]>
Date: Fri, 04 Dec 2009 12:09:50 -0600

On Sun, 2009-11-29 at 19:59 -0500, Stephen Kent wrote:
> I think that there has been insufficient discussion of whether those 
> who wish to make use of IPsec to enforce mandatory access controls 
> require the facilities described by the folks who have proposed this. 
> At the WG meeting 2 weeks ago I made two observations:
> 
> 	-  possible use of CIPSO for carrying labels had not been 
> fully discussed
> 	- use of tunnel mode to protect such labels in the inner 
> header did not appear to have been considered

The drafts do mention IPSO/CIPSO. They also acknowledge that FIPS-188
describe the use of free form tags that would allow additional security
attributes. However, there is nothing protecting the data and heading,
including the security context. Nor is anything preserving or protecting
the bindings between the data and security context. Only IPSO is a
standard and it was designed to support security labels used by DoD.

Yes, I agree, tunnel mode could be used to protect the data, header,
security context and thus bindings. However, it seem useful that, if you
are going to deploy IPsec in a MAC environment, it included a mechanism
to handle labels too.  

The method described in the labeled ipsec drafts was originally designed
using ikev1. Perhaps thru further discussion this method could be
refined and improved upon for ikev2.

> I think it is incumbent on those who wish to pursue this work to 
> provide more persuasive arguments. It also seems appropriate to have 
> a discussion of whether mandatory, label-based controls are 
> sufficiently mainstream to warrant bringing them back into IPsec at 
> this time, or whether this is more of a research topic.
> 

I believe they are becoming more mainstream. For example, SELinux and
Simplified Mandatory Access Control (SMACK) in Linux Operating System
and Mandatory Integrity Control in Windows Vista. However, I am also
inclined to agree that at this time it could be argued to be more a
research topic.

regards,
Joy

---

From: Dan McDonald <[email-masked]>
Date: Fri, 4 Dec 2009 13:39:46 -0500

On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote:

<SNIP!>

> and Mandatory Integrity Control in Windows Vista.

You forgot OpenSolaris Trusted Extensions (and their brand-new IPsec
support):

	http://hub.opensolaris.org/bin/view/Project+txipsec/

The page needs an update, because the bits are now available for use.

The bigger point being missed by this thread, I think, is that it seems that
any work in multi-level security needs to deal with successful
interoperability.  If it doesn't, there's little point in documenting a
single-platform solution as part of a working group's output.

Dan

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Dec 2009 12:46:21 -0600

On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> The bigger point being missed by this thread, I think, is that it
> seems that any work in multi-level security needs to deal with
> successful interoperability.  If it doesn't, there's little point in
> documenting a single-platform solution as part of a working group's
> output.

+1.

The proposed work item is, at first glance anyways, too SELinux-
specific.

Note that SMACK encodes its labels as CIPSO labels, so a scheme that
uses CIPSO can possibly be used in SMACK and non-SMACK environments, and
possibly even be mixed.

In any case, there have been lengthy threads elsewhere (saag, IIRC)
about MAC interoperability.

Some options to consider:

 - implicit labeling
    - derived from CERTs
    - derived from IDs
    - derived from network addresses
 - negotiated labeling
    - requires a DOI negotiation of some sort
    - each node asserts one, or more, or a range of labels (SMACK, for
      example, doesn't support the notion of label ranges) and the peers
      evaluate and narrow the assertion according to policy and produce

All I see in the proposed work item is single label assertions.  That
strikes me as insufficient.

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 4 Dec 2009 22:46:02 +0200

Please remember that it is up to the WG to define the work item. The I-D is just a possible starting point, so if there's strong interest in this area, you may wish to reach consensus on a charter item - and to convince the rest of us that enough people are interested.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nicolas Williams
> Sent: Friday, December 04, 2009 20:46
> To: Dan McDonald
> Cc: [email-masked]; Joy Latten
> Subject: Re: [IPsec] Proposed work item: Labelled IPsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 4 Dec 2009 16:11:08 -0600

On Fri, Dec 04, 2009 at 10:46:02PM +0200, Yaron Sheffer wrote:
> Please remember that it is up to the WG to define the work item. The
> I-D is just a possible starting point, so if there's strong interest
> in this area, you may wish to reach consensus on a charter item - and
> to convince the rest of us that enough people are interested.

Yes, but that's not how the original message in this thread was worded:

| Please reply to the list:
|  
| - If this proposal is accepted as a WG work item, are you committing to
|   review multiple versions of the draft?
|   - Are you willing to contribute text to the draft?
|   - Would you like to co-author it?
|    
|   Please also reply to the list if:
|    
|   - You believe this is NOT a reasonable activity for the WG to spend
|     time on.

True, you might interpret "the draft" to mean "the WG draft" as opposed
to "the starting point" I-D given in that e-mail, but it wasn't
sufficiently clear.  Now that you've clarified, my answers are:

 - I am willing to review multiple versions of a WG I-D on labelled
   IPsec, and to contribute text.

 - I am not willing to co-author.

 - I do believe that labelled IPsec via IKE extensions is a reasonable
   activity for the WG.

   However, I do not believe the the proposed starting point is
   appropriate as is.  I believe that an appropriate labelled-IPsec-via-
   IKE-extensions work item should address interoperability, which means
   at a minimum that for explicit labelling in IKE we should have a DOI
   agreement sub-protocol (i.e., both peers must understand that they
   have a common DOI or that they don't).

   I'm also interested in proposals that do CERT-based implicit
   labelling, but such proposals are probably more appropriately pursued
   elsewhere (e.g., PKIX WG).

Nico
--

---

From: Joy Latten <[email-masked]>
Date: Mon, 07 Dec 2009 10:10:15 -0600

> uses CIPSO can possibly be used in SMACK and non-SMACK environments, and
Yes, I agree. 

Actually, we hoped the method we introduced was generic enough to 
accommodate both CIPSO and SMACK and any other MAC besides SELinux.
We had hoped to do this by treating the security context as an opaque
blob and introducing a DOI. 

I've actually discussed and collaborated about the "DOI" concept with
Linux's CIPSO developer, and labeled nfs' developer. SMACK developer
was included, but I do not recall if he said anything. We hoped that
this "DOI" would not only be used by labeled IPsec, but CIPSO and others
that use labels on the network. In a way, the "DOI" would help
to identify the "mapping", thus perhaps allowing  different MACs to talk
to each other. Interoperability was and is a chief concern. However, 
I am sure the drafts most definitely can be improved upon.

regards,
Joy

---

From: Joy Latten <[email-masked]>
Date: Mon, 07 Dec 2009 10:13:28 -0600

> The page needs an update, because the bits are now available for use.

My apologies. I am aware of this work.

> single-platform solution as part of a working group's output.

Yes, I agree. 
We may have missed the mark, but this was suppose to be a multi-platform
solution. Interoperability was primary concern and reason to document.

regards,
Joy

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 15:02:48 -0600

> I am sure the drafts most definitely can be improved upon.

See the long threads on related topics on the SAAG and NFSv4 lists with
subjects:

 - Common labeled security (comment on CALIPSO, labeled NFSv4)
 - Why the IETF should care about labeled?ne tworking (was:CIPSO
   implementations)
 - Secdir Review of draft-stjohns-sipso-05

I'm not sure what the best way forward is, but here are some thoughts:

 - A notification indicating what DOI(s) are supported by the sender
   might help.

   Not that I expect that any system will participate in multiple DOIs,
   but then, IIRC SMACK supports mappings of SMACK labels (which hijack
   a level in CIPSO) to non-SMACK CIPSO labels for interop, for example.
   This idea is probably not too farfetched.

 - A label type in addition to DOI.

   Not that I expect a single DOI to use multiple label types, but at
   least one can then parse the label payload according to the stated
   type rather than having to find the right type for the given DOI.

 - Text on the encodings of specific label types' labels.

   Particularly I think you need to have normative references to the
   relevant RFCs and other work for the 'core' label types.

 - Text on implicit labeling.

   Strictly speaking this is not necessary, since implicit labeling is
   a purely local matter.

 - Perhaps a notification indicating the label/label-range/set assigned
   by the sender to a given child SA.  This would be useful for
   diagnostic purposes in all cases, particularly implicit labeling
   cases, but it should be strictly optional.

   Label ranges/sets would be used only for unnarrowed SAs, obviously.
   Narrowed SAs should have a single label.

 - Similarly, a notification indicating whether the sender understood
   the DOI asserted by the peer.

 - A separate I-D for adding labeling information to certificates.

Nico
--

---

From: Paul Moore <[email-masked]>
Date: Mon, 7 Dec 2009 16:37:50 -0500

> I am sure the drafts most definitely can be improved upon.

At the SELinux Developer's Summit a few months ago there was a bit of a 
general discussion about DOIs and label representation between myself (Linux 
labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey 
Schaufler (SMACK, added to CC) as well as a few others.  As could be expected, 
there still seems to be quite a bit of confusion around the best way to 
interoperate two different labeled security mechanisms.  While I believe 
everyone agrees that tagging network security labels with a DOI is important, 
there seems to be little consensus beyond that (at least at the summit 
discussion).  Since Dave has an immediate need, he is working on a solution 
for labeled NFS which uses three values: a format token, a DOI token, a 
variable length label blob.  Arguably the format and DOI tokens could be 
combined but I understand the desire to keep things flexible at this point.  
It is my understanding that Dave plans to first support a CALIPSO-like format 
simply because it is well defined and the level/compartment-bitmap format 
seems to be easiest to internalize across the different labeled security 
mechanisms.

I've mentioned all of this before, but my main fundamental concern with the 
proposed labeled IPsec spec is that not everyone who wants labeled networking 
wants IPsec.  Look at the CALIPSO effort as an example, it was created because 
users needed a way to communicate security labels over the network but did not 
want or need IPsec (they already had security mechanisms in place and IPsec 
was seen as an unnecessary burden, especially for the smaller devices).  What 
I would really like to see is a spec providing for a general security label to 
be assigned per-packet, similar to CALIPSO but without the reliance on MLS 
(imagine the FIPS-188 freeform tag).  This way users who only need to labeling 
support are not required to go through the IPsec end node processing while 
those users who do not already have a fully trusted network can run IPsec on 
the untrusted links to secure the packet, the label and their binding.

-- 
paul moore
linux @ hp

---

From: Sean Turner <[email-masked]>
Date: Mon, 07 Dec 2009 16:40:05 -0500

Nicolas Williams wrote:
...snip...
>  - A separate I-D for adding labeling information to certificates.

Are you suggesting that you'd label a certificate?  I suspect what 
you're talking about is including what labels a user/device supports and 
the clearance attribute in the RFC 3281 update 
(http://tools.ietf.org/html/draft-ietf-pkix-3281update-05) is defined 
for just such a purpose.

spt

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Dec 2009 17:16:26 -0500

Paul,

 From your comments it seems as though an IP option would be 
preferable, as it is not IP-sec-specific, and it an be protected if 
needed, in the IPSec context, e.g., via tunneling.

Steve

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 15:51:10 -0600

> seems to be easiest to internalize across the different labeled security 

I agree that {format, DOI, blob} is a good place to start.

> the untrusted links to secure the packet, the label and their binding.

But this is not a reason to oppose labelled IPsec.  It's a reason to
want an extended IP packet labelling standard.  The two should support
much the same semantics where possible, though IPsec can provide more
functionality (e.g., derive labels from authentication elements).

Nico
--

---

From: Paul Moore <[email-masked]>
Date: Mon, 7 Dec 2009 17:26:04 -0500

> needed, in the IPSec context, e.g., via tunneling.

Exactly.  Since the option would be immutable it could also be protected with 
AH allowing for intermediate nodes to apply security policy based on the 
label.  Although I do understand AH is falling out of favor.

-- 
paul moore
linux @ hp

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 15:43:30 -0600

> (http://tools.ietf.org/html/draft-ietf-pkix-3281update-05) is defined 

Ah, I didn't know that a clearance attribute existed already.  Yes,
that's exactly what I had in mind.  (Incidentally, the I-D you mention
has a referenced to X.501-1993, but it doesn't appear in the References
sections.)

Nico
--

---

From: Paul Moore <[email-masked]>
Date: Mon, 7 Dec 2009 17:53:59 -0500

On Monday 07 December 2009 04:51:10 pm Nicolas Williams wrote:
> > I've mentioned all of this before, but my main fundamental concern with
> > the proposed labeled IPsec spec is that not everyone who wants labeled
> > networking wants IPsec.  Look at the CALIPSO effort as an example, it was
> > created because users needed a way to communicate security labels over
> > the network but did not want or need IPsec (they already had security
> > mechanisms in place and IPsec was seen as an unnecessary burden,
> > especially for the smaller devices).  What I would really like to see is
> > a spec providing for a general security label to be assigned per-packet,
> > similar to CALIPSO but without the reliance on MLS (imagine the FIPS-188
> > freeform tag).  This way users who only need to labeling support are not
> > required to go through the IPsec end node processing while those users
> > who do not already have a fully trusted network can run IPsec on the
> > untrusted links to secure the packet, the label and their binding.
> 
> want an extended IP packet labelling standard.

Why spend the time and effort to develop two specifications (not to mention 
the actual implementations) when one IP option based labeling spec could solve 
both use cases at the same time?

> The two should support much the same semantics where possible, though IPsec
> can provide more functionality (e.g., derive labels from authentication
> elements).

I'm not exactly sure how you envision this working, but for the sake of 
argument lets say that for the certificate derived security labels node A 
sends a cert to node B as part of the IKE negotiation which node B then uses 
to derive a security label for the SA matching node A's traffic (indirectly 
labeling node A's traffic as it is received).  This is an interesting scenario 
because it doesn't actually involve any security labels being transfered over 
the network, either via IKE or AH/ESP; in fact, if you implement it correctly 
you could probably achieve this today using a standard IPsec implementation on 
node A (only node B and its IPsec implementation need to be label aware).  I 
hasn't thought about this too much until just now, but I would almost consider 
this case to be a method of fallback labeling; instead of deriving the 
security label from an IP address you derive it from an authentication token.

Do you know of users who need to network peer security labels based on 
authentication tokens or are you simply posting this as an example?  Also, do 
you see the need for user auth tokens, machine auth tokens or both?

-- 
paul moore
linux @ hp

---

From: Dan McDonald <[email-masked]>
Date: Mon, 07 Dec 2009 18:20:31 -0500

> both use cases at the same time?

Because sometimes you want to put sensitive traffic on public networks,
without the overhead of tunnel mode (until we can get the world to go beyond
1500-byte datagrams, overhead IS a problem).  IPsec SAs are perfect
repositories for sensitivity information.  And you can continue to use
explicit labelling either to transit label-reading routers if you must.

> security label from an IP address you derive it from an authentication token.

You could have PAD entries that set labels.  We do that today in OpenSolaris.

Dan

---

From: Joy Latten <[email-masked]>
Date: Mon, 07 Dec 2009 17:09:51 -0600

>  - Secdir Review of draft-stjohns-sipso-05

Thanks for pointing this out. I was not aware of the threads and
am finding them very interesting and informative.

>  - A notification indicating what DOI(s) are supported by the sender
Yes. The drafts suggest that by specifying the DOI as part of the SPD
entry, that would identify the DOI to support for this traffic stream.
 
>  - A label type in addition to DOI.
Ok. I originally perceived this as part of the DOI description, but I 
could understand wanting to separate for perhaps flexibility.

>    relevant RFCs and other work for the 'core' label types.
Yes, I agree, although I am unaware of any RFCs dealing with that yet.

regards,
Joy

---

From: Paul Moore <[email-masked]>
Date: Mon, 7 Dec 2009 18:59:13 -0500

On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote:
> > Why spend the time and effort to develop two specifications (not to
> > mention the actual implementations) when one IP option based labeling
> > spec could solve both use cases at the same time?
> 
> without the overhead of tunnel mode (until we can get the world to go
>  beyond 1500-byte datagrams, overhead IS a problem).

It is worth noting that this does introduce a scalability concern in the case 
where a system communicates with another using a large number of security 
labels.  It is only made worse on systems that have "rich" security labels 
which consist of more than just MLS attributes; e.g. SELinux labels contain 
user, role, type and MLS ranges, each unique combination represents a new 
label and in the case of labeled IPsec, a new SA.  It is possible that a 
traditional, unlabeled IPsec configuration which would only use a single SA 
could potentially expand to several thousand SAs depending on the number of 
security labels in use for that particular policy.  We've already seen issues 
related to this with SELinux.

Also, on the topic of performance, labeled IPsec requires that the IPsec 
processing occur at the end node making it impossible to offload IPsec to a 
gateway.  On small or heavily loaded systems this can quickly outweigh any 
advantages gained by decreased header sizes.

>  IPsec SAs are perfect repositories for sensitivity information.

There is a subtle problem with using SAs for labeling that hasn't really been 
discussed in this forum and may not be immediate obvious.  All of the labeled 
security mechanisms I've seen generate the packet/SA's security label from the 
application which generates the network traffic (the sender).  The fact that 
IPsec SAs are not tightly bound to applications/senders, instead relying on 
the traffic selectors to match packets to the SA, can make things more 
difficult for security policy developers and security administrators.  As an 
example, compare the security policy required for both CIPSO and labeled IPsec 
traffic on a SELinux system.

>  And you can continue to use explicit labelling either to transit label-
>  reading routers if you must.

In which case you are now worse off since you have both the AH/ESP overhead as 
well as the security label overhead.
 
> > sends a cert to node B as part of the IKE negotiation which node B then
> > uses to derive a security label for the SA matching node A's traffic
> > (indirectly labeling node A's traffic as it is received).  This is an
> > interesting scenario because it doesn't actually involve any security
> > labels being transfered over the network, either via IKE or AH/ESP; in
> > fact, if you implement it correctly you could probably achieve this today
> > using a standard IPsec implementation on node A (only node B and its
> > IPsec implementation need to be label aware).  I hasn't thought about
> > this too much until just now, but I would almost consider this case to be
> > a method of fallback labeling; instead of deriving the security label
> > from an IP address you derive it from an authentication token.
> 

I apologize, but I'm not familiar with OpenSolaris's IPsec - do you use the 
pad to assign labels when none are present (the fallback case) or do you use 
it to limit the range of labels you will accept from a remote node?  Based on 
your comment I suspect it is at least the former, I just wanted to clarify.

-- 
paul moore
linux @ hp

---

From: Joy Latten <[email-masked]>
Date: Mon, 07 Dec 2009 18:22:43 -0600

On Mon, 2009-12-07 at 16:37 -0500, Paul Moore wrote:
> was seen as an unnecessary burden, especially for the smaller devices). 

Yes, I have seen threads debating whether IPv6 should continue to
mandate IPsec for the reasons you have stated. 

>  What 
Yes, I agree that not everyone wants to use IPsec and thus CIPSO would
be a better option for them. 

Perhaps I am incorrect, but it seem possible that as MAC becomes more
mainstream, the desire to communicate beyond the trusted
network/environment will grow. Thus the need to use IPsec to protect the
bindings. It just seem advantageous to me then that IPsec include a
mechanism. 

Either way, as MAC goes more mainstream, I do think a standard solution
addressing interoperability is needed.

regards,
Joy

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 18:41:21 -0600

> related to this with SELinux.

For any discrete packet flow (say, a TCP connection), it makes no sense
to have more than one label or clearance range.  Thus at worst you end
up with a narrowed SA pair (or two, during re-keys) per-flow.

For protocols like NFS you'd have to do labelling in the protocol.
I.e., for NFS you'd let IP/IPsec determine the labels/clearances of the
client and server, and then the client and server would deal with
labelling of files and user processes'/threads' actions.

IOW, the number of SAs will be bounded by the number of concurrent,
discrete packet flows, not by the number of labels.

> advantages gained by decreased header sizes.

I don't see why you believe this.

> traffic on a SELinux system.

See RFC5660.  See also the charter of the BTNS WG (though it's likely to
be concluded before completing IPsec API work).

Nico
--

---

From: Sean Turner <[email-masked]>
Date: Mon, 07 Dec 2009 20:16:55 -0500

> has a referenced to X.501-1993, but it doesn't appear in the References

It's in AUTH48 and the RFC editors caught that.

spt

---

From: Joy Latten <[email-masked]>
Date: Mon, 07 Dec 2009 19:05:44 -0600

> discrete packet flows, not by the number of labels.

I could be misunderstanding what you are saying, but I agree with Paul
here. When using a MAC that employs labels using other security
attributes in addition to the MLS attributes, there can be more
than one SA-pair per flow. 

For example, SELinux uses user:role:type:mls-attributes. There can be a
large number of "types" defined by MAC system for the type attribute.
So, although mls-attributes may be the same for two different TCP
connections, if the "type" is different, then that implies 2 different
labels, one for each of the TCP connections. 
Thus an SA-pair is needed for each of the two TCP connections
on the flow.

regards,
Joy

---

From: Paul Moore <[email-masked]>
Date: Mon, 7 Dec 2009 22:51:00 -0500

On Monday 07 December 2009 07:41:21 pm Nicolas Williams wrote:
> > It is worth noting that this does introduce a scalability concern in the
> > case where a system communicates with another using a large number of
> > security labels.  It is only made worse on systems that have "rich"
> > security labels which consist of more than just MLS attributes; e.g.
> > SELinux labels contain user, role, type and MLS ranges, each unique
> > combination represents a new label and in the case of labeled IPsec, a
> > new SA.  It is possible that a traditional, unlabeled IPsec configuration
> > which would only use a single SA could potentially expand to several
> > thousand SAs depending on the number of security labels in use for that
> > particular policy.  We've already seen issues related to this with
> > SELinux.
> 

I agree that it only makes sense to assign a single label to a discrete packet 
flow, no argument there.  If you re-read what I wrote I wasn't talking about 
an individual connection/flow between two nodes but rather the general case of 
IPsec protected communications between two nodes.  The point I'm trying to 
make is that labeled IPsec adds the flow's security label to the SA's traffic 
selector which has the potential to increase the number of SAs on the system 
by making the SAs more selective. 

For example, it is possible to configure a SPD such that all communication 
between two nodes is protected with a single SA; if labeled IPsec is used, the 
number of SAs in use would grow to equal the number security labels used in 
communications between the two nodes.  If the two systems only communicate 
with label "Coke" then only a single SA is needed.  However, if the two 
systems have two or more communication channels using with at least one 
channel using "Coke" and another using "Pepsi" then two SAs will need to be 
created to convey the two unique security labels.

You can easily see how this example can be applied with finer grained SPDs as 
well.

> > processing occur at the end node making it impossible to offload IPsec to
> > a gateway.  On small or heavily loaded systems this can quickly outweigh
> > any advantages gained by decreased header sizes.
> 

What don't you understand, that labeled IPsec requires IPsec processing to 
occur at the end node or that requiring IPsec on small devices can incur more 
of a performance penalty than a separate labeling protocol?  Perhaps I'm wrong 
about one of those statements, if I am I would appreciate help in 
understanding why.

> > There is a subtle problem with using SAs for labeling that hasn't really
> > been discussed in this forum and may not be immediate obvious.  All of
> > the labeled security mechanisms I've seen generate the packet/SA's
> > security label from the application which generates the network traffic
> > (the sender).  The fact that IPsec SAs are not tightly bound to
> > applications/senders, instead relying on the traffic selectors to match
> > packets to the SA, can make things more difficult for security policy
> > developers and security administrators.  As an example, compare the
> > security policy required for both CIPSO and labeled IPsec traffic on a
> > SELinux system.
> 

I just quickly skimmed RFC5660 and the BTNS charter so please correct me if I 
am misunderstanding things, but I don't see either the IPsec connection 
latching or BTNS charter having much impact on MAC security policies.  
Granted, the IPsec connection latching seems like an excellent idea but I'm 
fairly certain that systems which implement MAC using labeled security will 
still need to have MAC security policy in place to control (and provide the 
desired level of assurance) how IPsec SA based labeling is applied to network 
traffic; at least for implementations going through some form of security 
certification (I'm thinking Common Criteria).  IPsec latching may make this 
easier but I don't see how it would remove the requirement on MAC control over 
the process or change the MAC security policy, the basics of the SA based 
labeling remain the same.

-- 
paul moore
linux @ hp

---

From: Dan McDonald <[email-masked]>
Date: Tue, 8 Dec 2009 09:35:48 -0500

On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> pad to assign labels when none are present (the fallback case) or do you
> use it to limit the range of labels you will accept from a remote node?
> Based on your comment I suspect it is at least the former, I just wanted to
> clarify.

Both.  IKE will reject a peer that proposes a label outside the scope of a
PAD entry's preferences.

Dan

---

From: Casey Schaufler <[email-masked]>
Date: Mon, 07 Dec 2009 20:26:01 -0800

Paul Moore wrote:
> wants IPsec.

I concur with Paul. IPsec is an expensive mechanism that requires an
extensive support infrastructure. Yes, it's general. But if all you
want is to pass MAC information about local processes as happens on
embedded systems IPsec is a bad choice.

This is an old discussion. Back in the late 1980's the choices were
CIPSO and DNSIX. I don't think that anyone who was involved with
the B1/CMW systems of that bygone era would argue that DNSIX was
worth the costs.

I really dislike unnecessary complexity and I believe that security
is probably the last place that complexity should be tolerated.
I understand the arguments for DNSIX/IPsec and just can't buy
the cost/value proposition.

>   Look at the CALIPSO effort as an example, it was created because

---

From: Paul Moore <[email-masked]>
Date: Tue, 8 Dec 2009 09:37:33 -0500

On Monday 07 December 2009 11:59:51 pm Steven Bellovin wrote:
> On Dec 7, 2009, at 5:26 PM, Paul Moore wrote:
> > Exactly.  Since the option would be immutable it could also be protected
> > with AH allowing for intermediate nodes to apply security policy based on
> > the label.
> 
> Not really, because the the intermediate nodes probably don't have the key
>  necessary to verify the label.

Yes, my mistake.  While the security label would be visible to intermediate 
nodes they would have no way to verify the integrity of the label.

-- 
paul moore
linux @ hp

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 7 Dec 2009 23:59:51 -0500

On Dec 7, 2009, at 5:26 PM, Paul Moore wrote:

> label.

Not really, because the the intermediate nodes probably don't have the key necessary to verify the label.

> Although I do understand AH is falling out of favor.

I certainly hope so...

		--Steve Bellovin, http://www.cs.columbia.edu/~smb