gmane.ietf.general

Sam Hartman | 29 Sep 21:18

Secdir Review of draft-stjohns-sipso-05


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.                                            

This draft defines an IPV6 option for labeling the sensitivity of
packets on trusted networks.  The idea is that all of the components
that handle these sensitive packets must support this option.  Each
component that handles a packet in this architecture needs to be
trusted to apply appropriate security policy and not to disclose the
packet in environments where the packet is outside of the appropriate
sensitivity range.

summary: This document is basically ready for publication as an
informational document.  However significant concerns are present if
the IESG plans to continue with its current course of publishing on
the standards track.  Fixing these concerns will require work, but is
definitely doable if there is sufficient consensus.

process concern: This document is being sponsored as a proposed
standard.  However as indicated by the last paragraph in section 1
before section 1.1 this document is a follow-on to RFC 1108, which the
IETF deprecated and moved to historic.  As that paragraph points out,
this option has been in *limited deployment* throughout the history of
the internet.  While this specification does not specifically invoke
the language of RFC 2026 regarding applicability statements, I think
that the applicability level "limited use" maps well onto the language
of section 1 of this draft.  It seems that RFC 2026 recommends against

(Continue reading)

Steven M. Bellovin | 29 Sep 23:03

Re: Secdir Review of draft-stjohns-sipso-05

On Mon, 29 Sep 2008 15:20:23 -0400
Sam Hartman <hartmans-ietf <at> mit.edu> 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? 

As discussed way back when, when we'd agreed on what became 2401 et
seq., the IETF preferred that security labels be part of the
credential, and hence implicit in the security association, rather than
being part of the IPsec header.  Now -- here, the use of IPsec is to
protect the security label, rather than the data -- but does it
actually do that in any useful way?  If the security option is really
end-to-end, we don't need it, per the above.  If it's hop-by-hop -- and
it's using a v6 hop-by-hop option -- AH doesn't provide useful
protection unless packets are digitally signed rather than MACed.  
> 
> 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

(Continue reading)

Sam Hartman | 30 Sep 12:44

Re: Secdir Review of draft-stjohns-sipso-05

>>>>> "Steven" == Steven M Bellovin <smb <at> cs.columbia.edu> writes:

    Steven> On Mon, 29 Sep 2008 15:20:23 -0400
    Steven> Sam Hartman <hartmans-ietf <at> mit.edu> 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?

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.

(Continue reading)

Steven M. Bellovin | 2 Oct 04:12

Re: Secdir Review of draft-stjohns-sipso-05

On Tue, 30 Sep 2008 06:44:45 -0400
Sam Hartman <hartmans-ietf <at> mit.edu> wrote:

> >>>>> "Steven" == Steven M Bellovin <smb <at> cs.columbia.edu> writes:
> 
>     Steven> On Mon, 29 Sep 2008 15:20:23 -0400
>     Steven> Sam Hartman <hartmans-ietf <at> mit.edu> 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?

(Continue reading)

Steven M. Bellovin | 2 Oct 15:31

Re: Secdir Review of draft-stjohns-sipso-05

On Wed, 1 Oct 2008 22:12:17 -0400
"Steven M. Bellovin" <smb <at> cs.columbia.edu> 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.
> > 
> > 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.
> 
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?

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

Joe Touch | 2 Oct 20:18

Re: Secdir Review of draft-stjohns-sipso-05


Steven M. Bellovin wrote:
> On Wed, 1 Oct 2008 22:12:17 -0400
> "Steven M. Bellovin" <smb <at> cs.columbia.edu> 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.
>>>
>>> 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.
>>
> 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?

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

(Continue reading)

Michael StJohns | 2 Oct 20:57

Re: Secdir Review of draft-stjohns-sipso-05

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.

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.

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.

(Continue reading)

Sam Hartman | 2 Oct 21:30

Re: Secdir Review of draft-stjohns-sipso-05

>>>>> "Michael" == Michael StJohns <mstjohns <at> comcast.net> 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

(Continue reading)

Michael StJohns | 2 Oct 21:49

Re: Secdir Review of draft-stjohns-sipso-05

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. 

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

Sam Hartman | 2 Oct 22:18

Re: Secdir Review of draft-stjohns-sipso-05

>>>>> "Michael" == Michael StJohns <mstjohns <at> comcast.net> writes:

    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.

David Borman | 2 Oct 21:38

Re: Secdir Review of draft-stjohns-sipso-05

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.
>
>
> 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

(Continue reading)

Sam Hartman | 2 Oct 17:49

Re: Secdir Review of draft-stjohns-sipso-05

>>>>> "Steven" == Steven M Bellovin <smb <at> cs.columbia.edu> writes:

    >> 
    >> 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?

(Continue reading)

Joe Touch | 2 Oct 20:16

Re: Secdir Review of draft-stjohns-sipso-05


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
> mandatory-to-implement service? 

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

Joe

Sam Hartman | 2 Oct 21:09

Re: Secdir Review of draft-stjohns-sipso-05

>>>>> "Joe" == Joe Touch <touch <at> ISI.EDU> 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

Joe Touch | 3 Oct 01:00

Re: Secdir Review of draft-stjohns-sipso-05


Sam Hartman wrote:
>>>>>> "Joe" == Joe Touch <touch <at> ISI.EDU> 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.

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

Nicolas Williams | 21 Oct 03:44

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

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.

(Continue reading)

Russ Housley | 21 Oct 22:16

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

Nico:

>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.

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

Russ

Michael StJohns | 21 Oct 22:57

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

At 09:44 PM 10/20/2008, Nicolas Williams wrote:
>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.

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.

Bill Sommerfeld | 22 Oct 16:21

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

On Mon, 2008-10-20 at 20:44 -0500, Nicolas Williams wrote:
> 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.

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

(Continue reading)

Return

Return to gmane.ietf.general.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane