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

From: Jarrett Lu <[email-masked]>
Date: Tue, 08 Dec 2009 15:31:17 -0800

>
> Joy Latten wrote:
> On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote:
>   
>> On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote:
>>   
>>>> 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.
>>>>       
>>> 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.
>>>     
>> 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
>>   
>
> Thanks for pointing this out. I was not aware of the threads and
> am finding them very interesting and informative.
>   

Without rehashing the statements made in above discussion threads, it's 
probably helpful to have a realistic interoperability expectation for 
labeled systems. Defining label formats and security mechanisms in 
various networking protocols is important. Consistent label 
interpretation and label policy enforcement are also key to labeled 
communication. Note the latter is mostly handled outside the protocols 
in this discussion. So in reality, only systems that implement same 
Mandatory Access Control (MAC) security models are likely to be able to 
inter-operate. A possible example is OpenSolaris FMAC and SELinux.

The term "DOI" has been used in traditional MLS system for about two 
decades. In the MLS world, when systems use same DOI, it means they 
agree to the same label definition and MAC policy, and the systems are 
most likely under same administrative control (Note which policy is 
agreed upon is handled outside of a networking protocol). The label 
format is determined, i.e. it's CIPSO. In the current "Labeled IPsec" 
proposal, DOI is a Security Label Format Selector. I really think you 
ought to use a different name, calling it what it is and not be confused 
with MLS DOI. And use ISAMKP DOI when appropriate to avoid confusion.

>   
>> 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.
>>
>>   
> 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.
>  
>   
>>    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.
>>
>>   
> Ok. I originally perceived this as part of the DOI description, but I 
> could understand wanting to separate for perhaps flexibility.
>   

David Quigley and I had some offline conversation about this, as he has 
the same need for labeled NFSv4 work. The current thinking is to have a 
separate draft describing the need to set up an IANA registry and its 
content. Each entry consists at least the following fields:
LABEL TYPE: A number to indicate label type, e.g.  CIPSO, CALIPSO, 
SELinux security contex strings, etc.
SUB FIELD: Used to aid label handling, e.g. SELinux could use it for 
policy version numbers; CIPSO could use it for tag type;
LABEL FORMAT: pointers to reference docs on how labels should be parsed.

Both Labeled IPsec and labeled NFSv4 (and any future label protocol 
extensions) can refer to this document.

>   
>>    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.
>>
>>   
> Yes, I agree, although I am unaware of any RFCs dealing with that yet.
>   

There are more references for MLS labels (FIPS 188, CALIPSO draft, etc.) 
as they have a longer history. BTW, I don't think the label format 
specification has to be IETF RFCs.

- Jarrett

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 08 Dec 2009 22:53:18 -0800

Casey Schaufler wrote:
> Jarrett Lu wrote:
>   
>> Without rehashing the statements made in above discussion threads,
>> it's probably helpful to have a realistic interoperability expectation
>> for labeled systems. Defining label formats and security mechanisms in
>> various networking protocols is important.
>>     
>
> This reflects the traditional viewpoint and is a major obstacle to
> progress in the modern world. The modern reality is that two SELinux
> systems installed with the same software from the same distribution
> at the same time with configuration parameters that you might think
> would be insignificant may well have policies with differences that
> can not be reconciled in a network protocol.
>
> But it's worse than that. Static label formats (e.g. Bell & LaPadula)
> are often cited as the downfall of the 1990's MLS systems. In the
> rest of the OS the notion has been discarded. None of the current LSMs
> use a structured label format, unless you want to argue that the
> SELinux label format is structured, in which case you're likely to
> hear that it is structured for flexibility. Networking is the final
> hold-out for the archaic notion that labels should be inherently
> meaningful.
>
>   
>> Consistent label interpretation and label policy enforcement are also
>> key to labeled communication.
>>     
>
> This has never ever been true, not even once. You need look no
> further than the level "Secret", which means something very different
> in the US Department of Defense and in the Department of Energy.
> The only case where a serious attempt was made was IPSO, which
> had a classified mapping of DoD categories in the label.
>   

Although your statements sound a lot different, I think we are actually 
in agreement for the most part, i.e. having a labeled networking 
protocol alone is insufficient for MAC system interoperability. For 
example, it's pointless if two systems can't agree on what "Secret" means.

>   
>> Note the latter is mostly handled outside the protocols in this
>> discussion. So in reality, only systems that implement same Mandatory
>> Access Control (MAC) security models are likely to be able to
> This is also a common misconception. In truth, two SELinux systems are
> no more likely to interact properly than a Trusted Solaris system and
> one running UNICOS/MLS.
>   

The bottom line is that the MAC systems should enforce the same policy 
in order for " interoperability" to make sense. How to ensure policy 
consistency across communicating systems is beyond Labeled IPsec, and is 
probably a burden on the system/network administrators. This comes back 
to my earlier point of having a realistic expectation of MAC system 
interoperability.

>> format is determined, i.e. it's CIPSO. 
>>     
>
> Actually, the TSIG definition only requires that the two be able
> to work out their differences. They are not required to speak the
> same dialect.
>   

True. They need not be identical but must be consistent.

>   
>> In the current "Labeled IPsec" proposal, DOI is a Security Label
>> Format Selector. I really think you ought to use a different name,
>> calling it what it is and not be confused with MLS DOI. And use ISAMKP
>> DOI when appropriate to avoid confusion.
>>     
>
> Sure.
>
>   
>> David Quigley and I had some offline conversation about this, as he
>> has the same need for labeled NFSv4 work. The current thinking is to
>> have a separate draft describing the need to set up an IANA registry
>> and its content. Each entry consists at least the following fields:
> Two systems, no matter how similar, will never be able to translate
> formatted labels reliably. It only takes trivial changes to an SELinux
> system for my_dog_has_no_nose_t to mean completely different things
> on the two machines.
>   

I don't think this is the problem we are trying to solve here. I believe 
we are trying to solve the problem of getting packet labels across the 
network with confidentiality and integrity protection. The security 
administrators need to make sure your dog_has_no_nose_t is same as my 
dog_has_nose_t on two systems.

- Jarrett

---

From: Casey Schaufler <[email-masked]>
Date: Tue, 08 Dec 2009 19:57:03 -0800

Sure.

I stick by my claim that the right and only rational scheme is for
each system to explicitly map the labels it understands from another
system to local values, and vis versa. Any label without a mapping
must be discarded unused. If you are brave and foolish you can say
that the mapping is unity.

> There are more references for MLS labels (FIPS 188, CALIPSO draft,
> etc.) as they have a longer history. BTW, I don't think the label
> format specification has to be IETF RFCs.

Yeah, that would be bad.

---

From: "David P. Quigley" <[email-masked]>
Date: Wed, 09 Dec 2009 10:21:30 -0500

On Tue, 2009-12-08 at 19:57 -0800, Casey Schaufler wrote:
[snip]
> same

I think that this is a reasonable statement.

[snip]

> that the mapping is unity.

I'm pretty sure this is what has been proposed from the beginning. I
don't know where in our conversations at least that I've given you a
different opinion.

> > format specification has to be IETF RFCs.

I spoke with the people at IANA and I believe that we're going to go
with a hybrid approach for the registry. It is going to be open standard
meaning that the document that describes the format must be freely
available and there will also be an expert review requirement.

Dave

---

From: Casey Schaufler <[email-masked]>
Date: Wed, 09 Dec 2009 08:21:59 -0800

Jarrett Lu wrote:
> Although your statements sound a lot different, I think we are
> actually in agreement for the most part, i.e. having a labeled
> networking protocol alone is insufficient for MAC system
> interoperability. For example, it's pointless if two systems can't
> agree on what "Secret" means.

The subtle distinction begin that they don't need to agree what Secret
means, but they must each know what to do with a Secret presented to
them by the other.

> in order for " interoperability" to make sense.

Nope. I disagree. Two wildly divergent policies can interoperate. I have
seen it done. It is not pleasant to gaze upon, and there is lots of
human overhead to set it up, but it does happen because in the real world
it must.

> How to ensure policy consistency across communicating systems is
> beyond Labeled IPsec, and is probably a burden on the system/network
> administrators. This comes back to my earlier point of having a
> realistic expectation of MAC system interoperability.

Yes, with this I can agree.

> I don't think this is the problem we are trying to solve here. I
> believe we are trying to solve the problem of getting packet labels
> across the network with confidentiality and integrity protection.

But once people start down that path they always start trying to dictate
what the on-wire labels are going to contain. And that is what needs to
get nipped in the bud.

> The security administrators need to make sure your dog_has_no_nose_t
> is same as my dog_has_nose_t on two systems.

Can't be done reliably.

---

From: Paul Moore <[email-masked]>
Date: Wed, 9 Dec 2009 12:31:21 -0500

> don't know where in our conversations at least that I've given you a

I agree with Casey and David.  I think the only way we stand any chance of 
success is to develop a on-the-wire format that can be easily internalized by 
a variety of implementations.  For example, I know CIPSO is far from the 
darling child of labeled networking, but due in large part to it's simple, MLS 
(level/compartment) format it is possible to interoperate between fairly 
different security models.  I've personally used CIPSO to communicate between 
Trusted Solaris (that is traditional TSOL not FMAC) and SELinux as well as 
SELinux and Smack (interesting because Smack does not have inherent MLS 
specifics like TSOL and SELinux); I have not tried to interoperate between 
Smack and Trusted Solaris but I see no reason why it would fail.  I will be 
the first to admit that these were simple test cases and there was definitely 
configuration on both required to reach this point, but it is possible.

I hope to be able to do the same with CALIPSO when I finish the Linux 
implementation (only about 50% at present).

It is partly because of this experience that I'm not entirely convinced a 
label format token is needed along with the DOI token and label blob.  I 
currently believe that the best solution would be one that only specified the 
DOI and the label, in whatever representation seems "the best" given what we 
currently know.  Specify in great detail what the on-the-wire format should 
look like and let the individual implementations worry about translating from 
their native format to the wire format.  I suspect this will provide the 
highest level of interoperability and as a result, adoption.

-- 
paul moore
linux @ hp

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 09 Dec 2009 11:14:31 -0800

> human overhead to set it up, but it does happen because in the real world

OK. The point I try to get across is that enforcing coherent label 
policies is another critical piece in MAC interoperability, and that 
piece is outside the scope of a labeled networking protocol.

> what the on-wire labels are going to contain. And that is what needs to

Right. Sometimes the bits matter :-) . I think we are still discussing 
how many ways a labeled opaque blob can be parsed. For example, if 
on-wire representation of a label is always CIPSO/CALIPSO, it's simpler 
as there is already a defined IP option number and no Label Format 
Selector is needed. This means label transformation overhead for non-MLS 
systems.

>> is same as my dog_has_nose_t on two systems.

Maybe true. But that's clearly out of scope of a labeled networking 
protocol. At end of the day, people who deploys this technology need to 
bear the responsibility for obtaining the right level of assurance that 
the systems are going to behave correctly.

- Jarrett

---

From: Paul Moore <[email-masked]>
Date: Wed, 9 Dec 2009 14:28:25 -0500

On Wednesday 09 December 2009 02:06:04 pm David P. Quigley wrote:
> On Wed, 2009-12-09 at 12:31 -0500, Paul Moore wrote:
> > > > > The term "DOI" has been used in traditional MLS system for about
> > > > > two decades. In the MLS world, when systems use same DOI, it means
> > > > > they agree to the same label definition and MAC policy, and the
> > > > > systems are most likely under same administrative control (Note
> > > > > which policy is agreed upon is handled outside of a networking
> > > > > protocol). The label format is determined, i.e. it's CIPSO.
> > > >
> > > > > has the same need for labeled NFSv4 work. The current thinking is
> > > > > to have a separate draft describing the need to set up an IANA
> > > > > registry and its content. Each entry consists at least the
> > > > > following fields: LABEL TYPE: A number to indicate label type, e.g.
> > > > >  CIPSO, CALIPSO, SELinux security contex strings, etc.
> > > > > SUB FIELD: Used to aid label handling, e.g. SELinux could use it
> > > > > for policy version numbers; CIPSO could use it for tag type;
> > > > formatted labels reliably. It only takes trivial changes to an
> > > > SELinux system for my_dog_has_no_nose_t to mean completely different
> > > > things on the two machines.
> > > >
> > I agree with Casey and David.  I think the only way we stand any chance
> > of success is to develop a on-the-wire format that can be easily
> > internalized by a variety of implementations.  For example, I know CIPSO
> > is far from the darling child of labeled networking, but due in large
> > part to it's simple, MLS (level/compartment) format it is possible to
> > interoperate between fairly different security models.  I've personally
> > used CIPSO to communicate between Trusted Solaris (that is traditional
> > TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting
> > because Smack does not have inherent MLS specifics like TSOL and
> > SELinux); I have not tried to interoperate between Smack and Trusted
> > Solaris but I see no reason why it would fail.  I will be the first to
> > admit that these were simple test cases and there was definitely
> > currently believe that the best solution would be one that only specified
> > the DOI and the label, in whatever representation seems "the best" given
> > what we currently know.  Specify in great detail what the on-the-wire
> > format should look like and let the individual implementations worry
> > about translating from their native format to the wire format.  I suspect
> > this will provide the highest level of interoperability and as a result,
> > adoption.
> 
> I don't think its realistic to develop a single on the wire format for
> labels.

Well, I've seen it work so I know it is possible, I guess it all comes down to 
what we decide "realistic" really means.

> I'm pretty sure this has been tried in the past and has failed.

I've actually seen very little discussion about why single format labeling 
protocols have failed (or rather was it the systems that failed, causing the 
protocols to fail as a result) and unfortunately I wasn't involved in that 
space at the time so I have no personal history.  I think a good first step to 
arriving at a new protocol is to understand what went wrong in the past and 
why it went wrong.

It is important to note I'm talking about adoption, implementation and 
interoperability; I'm not talking about what went wrong between the IETF and 
TSIG (although based on what I've learned I suspect there is some overlap 
here).

> I also think its not very reasonable to have the DOI incorporate both
> the format of the label and the policy authority/identifier.

I think this is secondary to the single vs multiple wire format question.  If 
you only have a single wire format then a label format token is a bit silly, 
however, if you want to support multiple label formats then you might as well 
include some sort of format specifier.

-- 
paul moore
linux @ hp

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 09 Dec 2009 11:31:16 -0800

> highest level of interoperability and as a result, adoption.

This sounds as too ambitious to me. Even if this can be done for all 
known label formats in use today, how would we know it will map well for 
some new labels in future?

- Jarrett

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Dec 2009 11:41:54 -0800

It is very clear that there is no common understanding among the participants on this thread. I propose that we cut this off for now until we can figure out what to do with the proposed work item.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Moore <[email-masked]>
Date: Wed, 9 Dec 2009 14:48:49 -0500

On Wednesday 09 December 2009 02:31:16 pm Jarrett Lu wrote:
> This sounds as too ambitious to me. Even if this can be done for all known
> label formats in use today, how would we know it will map well for some new
> labels in future?

We don't, well not unless your crystal ball works a lot better than mine :)

I'm concerned that if we devote too much effort into making the protocol 
completely future-proof we will end up sacrificing capability with the 
implementations we have today (or can envision).  Beyond the interoperability 
concerns over multiple label formats, one of my main concerns is that a 
protocol with multiple formats is almost surely going to be rejected/ignored 
by the intermediate hop vendors as it is too difficult to put in an ASIC.  One 
of the lessons I learned during the CALIPSO review process was that one of the 
reasons CIPSO failed was due to the different label formats, aka CIPSO "tag 
types", which made it difficult for intermediate node vendors to parse and 
apply security policy quickly.

Nothing last forever, especially when technology is concerned, there is always 
another revision (and another ... and another).  I understand that we need to 
design the protocol to be flexible but in this case I think we need to 
approach flexibility with some restraint.

-- 
paul moore
linux @ hp

---

From: "David P. Quigley" <[email-masked]>
Date: Wed, 09 Dec 2009 14:47:00 -0500

> approach flexibility with some restraint.

I spoke with Ran at the IETF in San Francisco and he told me that router
vendors will definitely not approve of having to do string comparisons
to apply security policy.  This means the only label formats that you're
going to be able to get the intermediate hop vendors to approve of are
strictly things like CALIPSO. They want to be able to do a quick integer
and bitmask comparison. Having to parse a string and pass it to a policy
decisions engine doesn't seem to be acceptable. 

Dave

---

From: Jarrett Lu <[email-masked]>
Date: Wed, 09 Dec 2009 12:29:03 -0800

Paul Moore wrote:
> implementations we have today (or can envision).  

Actually I was advocating the opposite of "devoting too much 
future-proof effort". How about not going that route at all? The Label 
Format Selector idea is quite extensible. For any new label in future, 
you need to publish a Label Format Spec, get an INAN registry, add new 
parsing capability in the system, and you are done. There is little to 
change in the protocol itself.

> Beyond the interoperability 

I could be wrong here. I thought the opaque blob is passed as pay load 
in IKE exchange, not as IP option in the header.

- Jarrett

---

From: "David P. Quigley" <[email-masked]>
Date: Wed, 09 Dec 2009 14:06:04 -0500

I don't think its realistic to develop a single on the wire format for
labels. I'm pretty sure this has been tried in the past and has failed.
I also think its not very reasonable to have the DOI incorporate both
the format of the label and the policy authority/identifier.

Dave

---

From: Casey Schaufler <[email-masked]>
Date: Wed, 09 Dec 2009 13:42:52 -0800

David P. Quigley wrote:
> to apply security policy.

The "router vendors" have always been the excuse for not getting IETF
approval for security attribute protocols. They were the opponents to
CIPSO the first time around, as Paul mentioned. This is ridiculous, since
it is pretty well known that the OS that the "router vendors" all use is
... wait for it ... Linux!

>   This means the only label formats that you're
> and bitmask comparison.

Sure, and I want the Moon on a stick. There is absolutely no reason
why the "router vendors" can't figure out how to deal with blobs. Paul
has given them ample examples of what needs doing.

>  Having to parse a string and pass it to a policy

But they parse data and pass it to engines all the time anyway.
It may well be the case that they don't see any market for it, but
that is hardly a technical argument.

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 10 Dec 2009 11:57:08 -0800

> in IKE exchange, not as IP option in the header.

There are multiple places where labels could appear on a packet by
packet basis:

a) explicitly in each packet outside encryption
b) explicitly in each packet inside encryption
c) implicitly (as an attribute of the security association)

any router forwarding the packet which doesn't have the encryption key
should not be able to tell the difference between (b) and (c).

In all three cases, labels could also be part of the key management
protocol; in case (c) that's the only place they appear in a wire
protocol.

when I implemented the labeled IPsec now in solaris development builds,
I found that (c) was the simplest piece of the implementation -- there's
no per-packet on-the-wire protocol change.

I think labeled IPsec is a large enough problem space that it could keep
an entire working group busy.

					- Bill

---

From: Steven Bellovin <[email-masked]>
Date: Thu, 10 Dec 2009 19:01:36 -0500

> no per-packet on-the-wire protocol change.

Yes.  In fact, if I recall correctly, the WG explicitly agreed many years ago, back when we adopted the IPsec v2 standards, that this was our preferred approach.  I also don't understand why why labels in the cleartext portion do any more good than putting it in the SA, since routers can't verify it without a lot of trouble.

Having a security label between the host and and IPsec gateways is another matter -- that would be interesting indeed.
> an entire working group busy.

Right -- and to what end?

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