Subject: Re: [secdir] Secdir Review of draft-stjohns-sipso-05

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 1 Oct 2008 22:12:17 -0400

On Tue, 30 Sep 2008 06:44:45 -0400
Sam Hartman <[email-masked]> wrote:

> >>>>> "Steven" == Steven M Bellovin <[email-masked]> writes:
> 
>     Steven> On Mon, 29 Sep 2008 15:20:23 -0400
>     Steven> Sam Hartman <[email-masked]> wrote:
> 
>  
>     >> Section 8 proposes that AH is the mandatory-to-implement
>     >> security mechanism for this option.  Do we still believe that
>     >> is appropriate given RFC 4301's move away from AH as a
>     >> mandatory-to-implement service?
> 
>     Steven> As discussed way back when, when we'd agreed on what
>     Steven> became 2401 et seq., the IETF preferred that security
>     Steven> labels be part of the credential, and hence implicit in
>     Steven> the security association, rather than being part of the
>     Steven> IPsec header.  Now -- here, the use of IPsec is to protect
>     Steven> the security label, rather than the data -- but does it
>     Steven> actually do that in any useful way?  If the security
>     Steven> option is really end-to-end, we don't need it, per the
>     Steven> above.  If it's hop-by-hop -- and it's using a v6
>     Steven> hop-by-hop option -- AH doesn't provide useful protection
>     Steven> unless packets are digitally signed rather than MACed.
> 
> Doesn't that sort of depend on 
> 1) who the attackers are
> 2) who the endpoints of the SA are?

I'm not sure what you mean here.  I think it's reasonable to postulate
an active or semi-active attacker on a nominally-secure link -- think
Operation Ivy Bell, or any of a number of CIA attacks on Soviet
communications systems described in a new book "Spymaster".  Such an
attack could record packets and resend them with a different security
label; in the absence of digital signatures, this could not be detected
until the receiving site, which of course will never see it -- the
destination address would be changed, too.
> 
> As far as I can tell AH would be fine for hop-by-hop SAs to protect
> packets flowing over a link that cannot be trusted to preserve
> integrity between two intermediate systems.
> 
> You could potentially have both an end-to-end SA and a hop-by-hop SA.
> That says that you trust intermediate systems less than you do the
> endpoints, but somehow you're still trusting them not to disclose
> traffic. I'd like to understand the threat model that leads to this
> better.

"Need to know" -- intermediate systems may be cleared very high, but
they have no need to see the packet contents.
> 
> However, I agree with you that the draft is broken.  It seems clearly
> like it is talking about end-to-end AH, and I agree that doesn't fit
> the model well at all without digital signatures.
> 
That's my main point.
> 
>     >>  As we know, BCP 61 requires a strong mandatory-to-implement
>     >> security mechanism for Internet protocols.  That mechanism
>     >> needs to be sufficient for use over the open Internet.  We have
>     >> been very reluctant to accept weaker security mechanisms
>     >> because some standards-track protocol is not intended for use
>     >> on the open Internet; BCP 61 says we have consensus that is not
>     >> how we do things.  I question whether AH is sufficient as a BCP
>     >> 61 mandatory-to-implement mechanism.  The entire point of this
>     >> IPV6 option is to limit disclosure of confidential and
>     >> classified information.  In order to meet that security
>     >> objective on the open Internet, some confidentiality mechanism
>     >> is required.  I strongly recommend that if this TS is published
>     >> on the standards track,ESP with confidentially be required.
> 
>     Steven> I don't agree.  The purpose of AH in this spec is to
>     Steven> protect certain information that's in the clear.  (As
>     Steven> noted, though, I don't think it does it properly.)
>     Steven> Protection of the underlying data is the business of a
>     Steven> separate layer or sublayer.
> 
> I made a number of statements and I'd like to explore our
> disagreement.  I'm assuming that we agree about what BCP 61 is trying
> to do: it's trying to require that IETF protocols have adequate
> security for the open Internet, because networks will get connected.
> I seem to recall you buy into that argument:-)

Yes...
> 
> Do you disagree with my assertion that from a overall architecture
> view, anyone who implements this mechanism needs confidentiality to
> run their packets over the open Internet?

Yes.
> 
> If you agree confidentiality is needed somewhere, how do we get
> interoperability if we don't mandate a confidentiality mechanism here?

It's a different layer.  The security label doesn't require
confidentiality; it does require integrity.

>     >>  The document requires that if there is a label inside and
>     >> outside an AH header, that these labels must be the same.  Why
>     >> is this a valid use of a 2119 MUST?  What security or
>     >> interoperability problem results if for example the outer label
>     >> dominates the inner label?  As far as I can tell this
>     >> requirement gets in the way of tunneling arbitrary IP traffic.
> 
>     Steven> It guards against someone tampering with the outer label,
>     Steven> causing the packet to be misrouted perhaps.  
> I guess I'm having a hard time seeing why you would have both labels
> if they serve the same purpose.  However I think I was misreading the
> text.  I thought the text was intended to apply to IP within IP--for
> example an inner label in a ip-in-ip tunnel.  If the text is only
> intended to apply to two copies of the option at the same IP layer,
> then I agree they need to be the same, although I'd also like an
> explanation of why you ever do that.
> 
The model is you send a packet over some secure internal networks.
It reaches a site boundary, where it's encapsulated -- say, via IPsec.
The security label should be preserved.  Why?  I always get nervous
when there are two fields describing the same data; it's too easy to
sneak something past if a filter checks one but the end system relies
on the other.  In this case, it might be the receiving TCP which uses
the inner label, but the routers that use the outer label.  

Of course, thinking more, an encrypted packet can often have a
different label, though for traffic analysis protection one still might
want an outer label that selected, say, paths that used link
encryptors.  I think the conclusion is your point: the document needs
to be clearer on this point.
> 
>     Steven> Note 7.3.1 on
>     Steven> TCP considerations.  (Also note that 7.3.1 disagrees with
>     Steven> 793 on the treatment of security labels in section 3.6 of
>     Steven> 793.  At the least, this shoudl be noted.
> 
> I had completely missed this.  I'll call out the section to the
> transport ADs
> 
I should have added: I think the new document is in fact more correct
than 793 -- the 793 scheme would permit various forms of high-bandwidth
covert channels to be set up.  This is an issue that was not nearly
that well understood when 793 was written.  That said, it is a change
to TCP, and needs to be treated as such.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 2 Oct 2008 09:31:29 -0400

On Wed, 1 Oct 2008 22:12:17 -0400
"Steven M. Bellovin" <[email-masked]> wrote:

> >     Steven> Note 7.3.1 on
> >     Steven> TCP considerations.  (Also note that 7.3.1 disagrees
> >     Steven> with 793 on the treatment of security labels in section
> >     Steven> 3.6 of 793.  At the least, this shoudl be noted.
> > 
> than 793 -- the 793 scheme would permit various forms of
> high-bandwidth covert channels to be set up.  This is an issue that
> was not nearly that well understood when 793 was written.  That said,
> it is a change to TCP, and needs to be treated as such.
> 
Thinking further -- I suspect that the right thing to do here is for
someone to write a short, simple draft amending 793 -- it's handling of
the security option is simply wrong, independent of this draft.  I
wonder -- what TCPs actually implement even 793?  NetBSD doesn't; I
strongly suspect that no BSDs do.  Does Solaris?  Linux?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Oct 2008 11:49:06 -0400

>> 
    >> You could potentially have both an end-to-end SA and a
    >> hop-by-hop SA.  That says that you trust intermediate systems
    >> less than you do the endpoints, but somehow you're still
    >> trusting them not to disclose traffic. I'd like to understand
    >> the threat model that leads to this better.

    Steven> "Need to know" -- intermediate systems may be cleared very
    Steven> high, but they have no need to see the packet contents.

If we were talking about ESP, I think this would apply.  I don't see
how it applies to integrity protection without confidentiality though.
    >>  Do you disagree with my assertion that from a overall
    >> architecture view, anyone who implements this mechanism needs
    >> confidentiality to run their packets over the open Internet?

    Steven> Yes.

OK, I'm not seeing this.  Can you give me an example of a system that
would use this mechanism over the open internet but not need
confidentiality at some layer?
The draft asserts that you would need confidentiality protection to run this over the Internet and as best I can tell, the draft authors are correct.

    >>  If you agree confidentiality is needed somewhere, how do we
    >> get interoperability if we don't mandate a confidentiality
    >> mechanism here?

    Steven> It's a different layer.  The security label doesn't
    Steven> require confidentiality; it does require integrity.

That's true.  However, I'm claiming that to be useful, confidentiality
needs to be provided at some layer.  If we have two implementations of
this spec, one of which uses confidentiality mechanism a and one of
which uses confidentiality mechanism b, even though they both
implement the mandatory-to-implement security mechanism for this spec,
they cannot interoperate in a secure manner.  Traditionally, we've
fixed that sort of interoperability problem by requiring a specific
mechanism at the other layer be mandatory to implement.

I don't think the argument that something happens at another layer has
been a sufficient reason to avoid interoperability.
At least while I was on the IESG, we tended to address this problem by requiring a specific other layer be a mandatory-to-implement layer.

Now, if you are saying that there are situations where confidentiality is not needed in the system as a whole, then I'd like to understand those systems.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Oct 2008 15:09:32 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> I was wondering about that; it seems inconsistent to have
    Joe> this document require something that is optional in RFC 4301.

I suspect you realize this, but some people following the discussion
may not.  It's critical to this mechanism that intermediate systems be
able to read the sensitivity level.  You can either do hop-by-hop SAs
using either ESP-null or AH, or end-to-end SAs using AH or ESP/null
plus one of the fixes so you can determine that a packet is ESP-null
rather than ESP-encrypted.  Note that if you are talking about
end-to-end SAs you need to either explain why the intermediate systems
don't need to be able to confirm the integrity of the label, or you
need to address Steve Bellovin's concerns.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Oct 2008 15:30:27 -0400

>>>>> "Michael" == Michael StJohns <[email-masked]> writes:

    Michael> Hi Joe - A quick disclaimer - although I was complicit in
    Michael> allowing this draft to be resurrected from 1992, I have
    Michael> had very little to do with it on this cycle.

    Michael> At 02:18 PM 10/2/2008, Joe Touch wrote:

    >> First, I don't agree with this document's recommendation in
    >> section 7.3.1.
    >> 
    >> TCP's current definition of a connection is:
    >> 
    >> local IP address remote IP address local port remote port
    >> protocol (e.g., TCP)
    >> 
    >> I don't agree that treating each sensitivity level as a
    >> separate virtual network (Sec 3 of this ID) is the appropriate
    >> analogy. If that were the case, we'd need to redefine every
    >> Internet protocol to understand the pair [address, sensitivity
    >> level] as an identifier, and that is not realistic. Further, if
    >> we did need to do such an extension, there are other equally
    >> (or arguably more) worthy candidates, notably VPN-ID.
    Michael> A single level process at TOP SECRET does a passive open
    Michael> of the port (call it 666) and waits for connections.  A
    Michael> second single level process at SECRET also attempts to do
    Michael> a passive open to the same port - but gets blocked
    Michael> because the port resource is being held by the TOP SECRET
    Michael> process.  The SECRET process now has one bit of
    Michael> information about the TOP SECRET part of the host.  By
    Michael> grabbing and releasing port resources, the TS process can
    Michael> signal data to processes at lower security levels.

You're proposing a huge complexity increase for the TCP stack in order
to get this covert channel protection.  Now, I do understand the value
of covert channel avoidance in these environments.  However, I wonder
what other ways have been explored.  In particular, this draft focuses
on V6.  It's easy to create a new address on a V6 link.  Have people
looked at separating each virtual network interface onto its own
address?  I think you'd still need label options so that intermediate
systems could enforce mandatory access control, but this might allow
you to escape doing so much damage to the TCP implementation.

If using multiple addresses doesn't work, what other mechanisms have
people looked at?

Are there other ways to decrease the bandwith of the covert channel to
an acceptable level?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Oct 2008 16:18:36 -0400

Michael> At 03:30 PM 10/2/2008, Sam Hartman wrote:
    >> You're proposing a huge complexity increase for the TCP stack
    >> in order to get this covert channel protection.

    Michael> Hi Sam -

    Michael> The guys at Honeywell who did the fix for Multics back in
    Michael> '87 took about 2 days to do the fix.  The complexity was
    Michael> pretty much limited to a single module and a few internal
    Michael> structures which described the TCP context. Basically
    Michael> tagging the TCP connection structure with the security
    Michael> level of the process and changing the matching logic
    Michael> already in place to do the right thing with respect to
    Michael> security.

I consider that a huge change to what is a fairly public interface.
>From an implementation standpoint I expect you will find that is more
work on a modern TCP implementation as well.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 2 Oct 2008 21:06:59 -0400

On Thu, 02 Oct 2008 17:48:07 -0700
Joe Touch <[email-masked]> wrote:

> 
> The point I'm making is that there seems like there should be a way to
> prevent the covert channel without mucking up TCP's definition of what
> an endpoint is.

I think this belongs elsewhere than either the secdir list or the main
IETF list, but I think you're wrong -- there doesn't have to be a way.
Certainly, I don't think your suggestion of filtering SYNs will do it.

MLS security is a very different creature than regular security.  We've
seen very little of MLS in the IETF (and for that matter, it's not used
all that much even in the DoD world), but there's a lot of literature
on the subject.  The questions for the IETF are (a) is this TCP issue
worth doing at all in the IETF, given the limited market, and (b) if it
is, how is it best done?

I don't think a WG is needed -- the subject is too narrow -- but I do
think we need one or more I-Ds, and probably a mls-tcp mailing list.
Clearly, any resulting document will have to pass muster by TSV as well
as SEC; probably, that means TCPM and SAAG.  It might pay for someone
to write an assumptions and threat model I-D first -- to give just one
example of what might be discussed in it, should we assume that the OS
has any role at all?  Given how few operating systems are even
MLS-capable these days (let alone evaluated for that purpose), perhaps
all of the MLS processing will be done (in the real world) on outboard
NICs or IPsec boxes.  What is the scope, then, of host MLS processing?

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 2 Oct 2008 21:40:54 -0400

On Thu, 02 Oct 2008 18:11:07 -0700
Joe Touch <[email-masked]> wrote:

> Steven M. Bellovin wrote:
> >> The point I'm making is that there seems like there should be a
> >> way to prevent the covert channel without mucking up TCP's
> >> definition of what an endpoint is.
> > 
> > I think this belongs elsewhere than either the secdir list or the
> > main IETF list, 
> 
> Agreed; I propose to take this over to TSVWG. It's more general than
> just TCP...
> 
Don't forget to include SAAG...

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 17:48:07 -0700

Michael StJohns wrote:
> At 07:01 PM 10/2/2008, Joe Touch wrote:

>> ...
>>> The fix was to virtualize TCP so that there was a complete set of TCP
>>> ports per distinct security domain.
>> I agree that this fixes your problem, but what it does is create a new
>> naming dimension to the entire Internet, and I don't think that this is
>> feasible.
> 
> Naming?  Not really.  Addressing maybe - but that's - as I said before
> - pretty local to only those hosts that implement MLS.

In TCP, endpoint names are composed of the 4-tuple (localIP, remoteIP,
localPort, remotePort). You'd first need to extend that to include MLS
as part of the endpoint name.

I'm not sure how this works with IPsec, since transport mode wants to
filter on ports, and you now can have only one transport mode
association for all MLS levels for a given port.

For ICMP to work, you need to care about intermediate devices sending
back enough of the IP and TCP header - including the MLS option - to
demux the info back to the correct TCP. Since TCP connections are
currently defined by the 4-tuple, you also need to extend ICMP
processing to send the ICMP payload to the right TCP connection.

This means, at least, extending IPsec, TCP (UDP, SCTP, RTP, ...), and
ICMP processing on the end host to support your extending notion of an
endpoint name.

>> Perhaps you'd prefer to black-hole the SYNs at the wrong security level,
>> which would still modify 793, but would not create the naming dimension
>> problem that concerns me...
> 
> Define "wrong security level" - both the attacker and victim are operating
> at their own security levels, its just the resource interactions that lead
> to the covert channel.

"wrong security level" means that when segment with a SYN set arrives to
a TCB set for a given level, the segment's level must match that of the
TCB. That's as defined in 793.

> Which SYN's - (need an exact filter definition here please) would you
> black hole, and how would that solve anything?

I'm focusing on the behavior of TCP on the wire (and explained the SYN
issue above); there is also the issue of port binding, which is different.

The port issue is really an OS problem. IMO, a process at level A that
wants to bind to port X might silently return a "sure, you're bound"
response if the port is bound to a different process at a different
level. The OS should accept the connection only for a specific process,
though - i.e., the first one to bind to the port, or the highest one to
bind to the port.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 16:01:01 -0700

Hi, Mike (et al.),

Michael StJohns wrote:
> Hi Joe -
...
> At 02:18 PM 10/2/2008, Joe Touch wrote:
> 
>> First, I don't agree with this document's recommendation in section 7.3.1.
>>
>>        local IP address
>>        remote IP address
>>        local port
>>        remote port
>> I don't agree that treating each sensitivity level as a separate virtual
>> network (Sec 3 of this ID) is the appropriate analogy. If that were the
>> case, we'd need to redefine every Internet protocol to understand the
>> pair [address, sensitivity level] as an identifier, and that is not
>> realistic. Further, if we did need to do such an extension, there are
>> other equally (or arguably more) worthy candidates, notably VPN-ID.
> 
> The issue isn't so much the network, but how the host views it and
> deals with resources that might otherwise be in multiple sensitivity
> domains.
> 
> Consider a multi-level host that runs at both SECRET and TOP SECRET.
> Consider that it wants to run some protocol to send and receive data
> from other hosts, some multi level, some single level SECRET and some
> single level TOP SECRET.
> 
> A single level process at TOP SECRET does a passive open of the port
> (call it 666) and waits for connections.
> A second single level process at SECRET also attempts to do a passive
> open to the same port - but gets blocked because the port resource is
> being held by the TOP SECRET process. The SECRET process now has one bit
> of information about the TOP SECRET part of the host. By grabbing and
> releasing port resources, the TS process can signal data to processes at
> lower security levels.

Understood. However, the lower security process can't know whether it's
the TS process doing this or some other reason (port blocked, e.g.); all
it knows is that it can't connect at the level it wants on
the port it wants.

...

>> I.e., I don't think this needs to update 793 - it needs to redefine the
>> Internet architecture in places like 1122, 1123, and 1812, and flow down
>> through all protocols they impact to make this sort of change, and I
>> don't see a reason to do so solely for this issue.
>>
>> Overall, I see no reason why 793's current rules aren't sufficient to
>> emulate the desirable separation of sensitivity levels without extending
>> this to true virtualization. I.e., the current rule (in 793, sec 3.6,
>> paraphrased):
>>
>>        - match the levels proposed by both ends of the connection
>>        where there is a mismatch, terminate the connection
>>
>> I.e., I don't see how to extend TCP to support concurrent connections
>> with matching connection identifiers on different sensitivity levels
>> without rearchitecting the entire Internet. AFAICT, it's sufficient to
>> allow each TCP connection to have exactly one sensitivity level, as is
>> already currently required.
> 
> Not quite the point.  If you have a single level process reserving a
> TCP port, then the port has sensitivity level of the process. If you
> have a multi-level process reserving a port then the port can have
> one, some or all of the sensitivity levels of the process. Each
> instantiation of a connection does have one and only one sensitivity
> level.

I understand that this wasn't your point (or goal), but I'm claiming
it's the effect of your goal - and that it's untenable.

> The changes don't have to happen on the entire internet, just those
> hosts and routers that are CIPSO aware AND multi-level. If the host is
> CIPSO aware (or for that matter IPSO aware), but not multi-level, it's
> just looking for the specific label and doesn't have to deal with the
> multiple virtual network cruft.

The changes need to happen for all RFCs that are affected by naming -
you're adding a dimension to naming by expecting different TCP
connections to occur where the only difference is security level. At
that point, the same has to happen for ICMP (so PMTUD works for each TCP
separately), which means you modify 1122. The same has to happen for
user apps, which now need to be able to connect to different sockets for
the same socket-pair - which modifies 1123. The same happens for 1812,
... That's the problem. Naming dimension extensions creep into the
architecture.

Joe

>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL
>> AicAn1kLwAQdQ087x9H32tbdVK26t1Hq
>> =8u6k
>> -----END PGP SIGNATURE-----
>> Ietf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: David Borman <[email-masked]>
Date: Thu, 2 Oct 2008 14:38:30 -0500

I totally agree with Mike.  If you've never dealt with a multi-level  
security (MLS) system, let's just say they are non-trivial, and this  
issue with TCP ports is only one part of the overall system.  Just the  
act of labeling the IP packets effectively creates multiple virtual  
networks, and the place where they clash is in the MLS host.  As Mike  
said, those that aren't MLS aware don't have to do anything  
different.  But explicitly calling this out for MLS hosts, as this  
draft does, seems to me to be perfectly reasonable.

			-David Borman

On Oct 2, 2008, at 1:57 PM, Michael StJohns wrote:

> Hi Joe -
>
> A quick disclaimer - although I was complicit in allowing this draft  
> to be resurrected from 1992, I have had very little to do with it on  
> this cycle.
>
>
> Consider a multi-level host that runs at both SECRET and TOP  
> SECRET.  Consider that it wants to run some protocol to send and  
> receive data from other hosts, some multi level, some single level  
> SECRET and some single level TOP SECRET.
>
> A second single level process at SECRET also attempts to do a  
> passive open to the same port - but gets blocked because the port  
> resource is being held by the TOP SECRET process.  The SECRET  
> process now has one bit of information about the TOP SECRET part of  
> the host.  By grabbing and releasing port resources, the TS process  
> can signal data to processes at lower security levels.
>
> In 1987 I used a rough analog of the old 1822 protocol using TCP  
> ports to build a fairly fast covert channel between two processes at  
> different security levels on the same host.
>
> The fix was to virtualize TCP so that there was a complete set of  
> TCP ports per distinct security domain.
>
> You could try doing this by writing the processes as multi-level,  
> but that means you can't use off the shelf code for things like a  
> mail server that only wants to handle mail of a specific security  
> level.
>
> Mostly, this only applies to protocols just above IP which have  
> distinguishable host resources. In other words, TCP, UDP and their  
> ilk.
>
>
>
> TCP port, then the port has sensitivity level of the process.  If  
> you have a multi-level process reserving a port then the port can  
> have one, some or all of the sensitivity levels of the process.   
> Each instantiation of a connection does have one and only one  
> sensitivity level.
>
> hosts and routers that are CIPSO aware AND multi-level.  If the host  
> is CIPSO aware (or for that matter IPSO aware), but not multi-level,  
> it's just looking for the specific label and doesn't have to deal  
> with the multiple virtual network cruft.
>
>
>> Joe
>>

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 11:16:56 -0700

Hi, Sam,

Sam Hartman wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.                                            
> 
...
> Section 8 proposes that AH is the mandatory-to-implement security
> mechanism for this option.  Do we still believe that is
> appropriate given RFC 4301's move away from AH as a

I was wondering about that; it seems inconsistent to have this document
require something that is optional in RFC 4301.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 18:11:07 -0700

Steven M. Bellovin wrote:
> IETF list, 

Joe

---

From: Michael StJohns <[email-masked]>
Date: Thu, 02 Oct 2008 16:23:15 -0400

Sorry - for both of these - the date was '83, not '87.... Mike

At 03:49 PM 10/2/2008, Michael StJohns wrote:
>At 03:30 PM 10/2/2008, Sam Hartman wrote:
>>to get this covert channel protection. 
>
>Hi Sam -
>
>The guys at Honeywell who did the fix for Multics back in '87 took about 2 days to do the fix.  The complexity was pretty much limited to a single module and a few internal structures which described the TCP context. Basically tagging the TCP connection structure with the security level of the process and changing the matching logic already in place to do the right thing with respect to security.  
>
>Note that this treatment of multiple networks only has to happen on hosts which are multi-level.  And the multi-level stuff is already a bit of cruft and complexity.  This just gets thrown in to the other stuff you have to do to have a secure multi-level system.
>
>For your suggestions with multiple addresses... its possible, but all you're doing is moving the complexity from implementation (where you do it once and test the hell out of it) to administration (where you have to do it for each system and hope you get it right).  I know what I'd choose... :-) 
>
>Mike

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 11:18:17 -0700

local IP address
	remote IP address
	local port
	remote port
	protocol (e.g., TCP)

Joe

---

From: Michael StJohns <[email-masked]>
Date: Thu, 02 Oct 2008 14:57:18 -0400

Hi Joe -

A quick disclaimer - although I was complicit in allowing this draft to be resurrected from 1992, I have had very little to do with it on this cycle.

>other equally (or arguably more) worthy candidates, notably VPN-ID.

The issue isn't so much the network, but how the host views it and deals with resources that might otherwise be in multiple sensitivity domains.

Consider a multi-level host that runs at both SECRET and TOP SECRET.  Consider that it wants to run some protocol to send and receive data from other hosts, some multi level, some single level SECRET and some single level TOP SECRET.

A single level process at TOP SECRET does a passive open of the port (call it 666) and waits for connections.
A second single level process at SECRET also attempts to do a passive open to the same port - but gets blocked because the port resource is being held by the TOP SECRET process.  The SECRET process now has one bit of information about the TOP SECRET part of the host.  By grabbing and releasing port resources, the TS process can signal data to processes at lower security levels.

In 1987 I used a rough analog of the old 1822 protocol using TCP ports to build a fairly fast covert channel between two processes at different security levels on the same host.

The fix was to virtualize TCP so that there was a complete set of TCP ports per distinct security domain.

You could try doing this by writing the processes as multi-level, but that means you can't use off the shelf code for things like a mail server that only wants to handle mail of a specific security level.  

Mostly, this only applies to protocols just above IP which have distinguishable host resources. In other words, TCP, UDP and their ilk.  

>already currently required.

Not quite the point.  If you have a single level process reserving a TCP port, then the port has sensitivity level of the process.  If you have a multi-level process reserving a port then the port can have one, some or all of the sensitivity levels of the process.  Each instantiation of a connection does have one and only one sensitivity level.

The changes don't have to happen on the entire internet, just those hosts and routers that are CIPSO aware AND multi-level.  If the host is CIPSO aware (or for that matter IPSO aware), but not multi-level, it's just looking for the specific label and doesn't have to deal with the multiple virtual network cruft.

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 16:00:38 -0700

Hi, Sam,

Thanks for pointing that out. The issue, AFAICT, is how to achieve the
required transparency while relying on (as much as possible) only
protocols that are MUSTs, rather than MAYs.

Perhaps that's less of an issue for this system, but I would hate to
have it depend on IPsec devices that implemented a MAY.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Oct 2008 10:00:55 +0300

> Agreed; I propose to take this over to TSVWG. It's more general than

I agree that the intersection of TSVWG and SAAG will probably more or  
less capture the correct set of folks, let's move the discussion there.

I'll send another followup to only those lists, please use that thread  
as a starting point for the discussion.

Thanks,
Lars

---

From: Michael StJohns <[email-masked]>
Date: Thu, 02 Oct 2008 15:49:38 -0400

Hi Sam -

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Oct 2008 20:44:56 -0500

On thing that sticks out from the Introduction is this:

|      However, some applications (e.g. distributed file systems),
|   most often those not designed for use with Compartmented Mode
|   Workstations or other Multi-Level Secure (MLS) computers,
|   multiplex different transactions at different sensitivity levels
|   and/or with different privileges over a single IP communications
|   session (e.g. with the User Datagram Protocol).

So far so good, and certainly true.  But then:

|                                                    In order to
|   maintain data Sensitivity Labeling for such applications, in
|   order to be able to implement routing and Mandatory Access
|   Control decisions in routers and guards on a per-IP-packet basis,
|   and for other reasons, there is a need to have a mechanism for
|   explicitly labeling the sensitivity information for each IPv6
|   packet.

So if I understand correctly then this document would have an
implementation of, say, NFSv4[0] over TCP[1] send TCP packets for the
same TCP connection with different labels, *and* ensure that each packet
contains parts of no more than one (exactly one) NFSv4 RPC.

Surely that would have an enormous impact on transport protocol
implementations!

And all so that middle boxes can make labelled routing decisions at
100Gbps wire speed.  And these are not simple labels either.

And the middle boxes have to trust the end nodes to get the labelling
right.

Call me a skeptic.  I don't see this flying.

In any case, wouldn't it be easier to just use IPsec with labelled SAs
(with no outer packet labelling) and let the middle boxes be label
agnostic?  The end nodes still have to be trusted to get the labelling
right, but this way you free the middle boxes to do what they're good at
(routing) and use crypto to provide integrity and confidentiality
protection over any public networks.

And if you really must have outer packet labelling for middle boxes to
inspect, why not modify NFSv4 clients to use a TCP connection per-local
{user, label}?  That'd certainly be a lot less troublesome than to
modify TCP to keep track of labels in a PCB's buffers/arrange to send
each sub-buffer in a separate packet or train of packets!

The changes proposed in this I-D are non-trivial, but there are clearly
far simpler alternatives.

Nico

[0] "e.g. distributed file systems"?  NFSv4 qualifies.

[1] "multiplex different transactions... over a single IP communications
    session (e.g. with the User Datagram Protocol)"?  NFSv4 qualifies,
    though the mandatory-to- implement transport for NFSv4 is TCP, not
    UDP.
-- 
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Oct 2008 16:16:14 -0400

>contains parts of no more than one (exactly one) NFSv4 RPC.

I am aware of several multi-level secure implementations; none of 
them of make any attempt to do anything like this.

Russ

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Oct 2008 15:21:41 -0500

> them of make any attempt to do anything like this.

Bill Sommerfeld points out that I have read much too much into the
paragraph that I quoted.  I should only have read that a solution is
desired, and that the solution could well be not to multiplex traffic
for multiple users on a single session.

Nico

---

From: Michael StJohns <[email-masked]>
Date: Tue, 21 Oct 2008 16:57:12 -0400

>contains parts of no more than one (exactly one) NFSv4 RPC.

Classified documents have this thing called paragraph marking.  Each paragraph within a document is marked with the highest level of data within the paragraph.  A page is marked with the highest level of data in any paragraph on that page.  The overall document is marked with and protected at the highest level of data within the document.

For your example, what would probably happen is that the NFS processes on both sides would create a connection at the highest level of data they expect to exchange.  The NFS processes would be responsible for the labeling and segregation of data exchanged over that connection.  E.g. the IP packets would ALL be labeled at the high level, even if some of them carried data at a level below.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Oct 2008 16:04:45 -0500

On Tue, Oct 21, 2008 at 04:57:12PM -0400, Michael StJohns wrote:
> Classified documents have this thing called paragraph marking.  Each
> paragraph within a document is marked with the highest level of data
> within the paragraph.  A page is marked with the highest level of data
> in any paragraph on that page.  The overall document is marked with
> and protected at the highest level of data within the document.
> 
> For your example, what would probably happen is that the NFS processes
> on both sides would create a connection at the highest level of data
> they expect to exchange.  The NFS processes would be responsible for
> the labeling and segregation of data exchanged over that connection.
> E.g. the IP packets would ALL be labeled at the high level, even if
> some of them carried data at a level below.

Thanks for the clarification.

Nico

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 21 Oct 2008 17:47:00 -0400

On Tue, 21 Oct 2008 16:57:12 -0400
Michael StJohns <[email-masked]> wrote:

...
 
> within the paragraph.  A page is marked with the highest level of
> data in any paragraph on that page.  The overall document is marked
> with and protected at the highest level of data within the document.

Those who want the gory details should see
http://www.fas.org/sgp/isoo/marking.pdf

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 22 Oct 2008 10:21:14 -0400

On Mon, 2008-10-20 at 20:44 -0500, Nicolas Williams wrote:
> But then:

You do not understand correctly.

See section 6.2.1 of that document, which reads in part:

   NOTE WELL:
        A connection-oriented transport-layer protocol session
     (e.g. TCP session, SCTP session) MUST have the same DOI and
     same Sensitivity Label for the life of that connection.  The
     DOI is selected at connection initiation and MUST NOT change
     during the session.

						- Bill