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

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Sep 2008 15:20:23 -0400

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
standards-track for technical specifications that have an
applicability of "limited use," and I wonder if there is adequate
consensus within the IETF community that has considered this RFC 2026
recommendation to overturn that BCP recommendation.  I specifically
call this issue out for community discussion and recommend that the
IESG consider it when evaluating this document.  There is a second,
less serious process issue.  As the draft points out, we chose to move
RFC 1108 to historic; has there been adequate discussion to overrule that consensus or otherwise determine it does not apply to the current TS?  I consider this less serious because a plausible rationale is presented in the document: we believed IPsec would make these labels unnecessary but now have operational experience that is not the case.

If this document is going to be published on the standards track, I
think it needs significant revision to come in line with current
security best practice BCPs.  It's poor form for the security
community to enforce these BCPs on other areas' documents but not to
meet our own standards; see major comments below.

Major Comments: 

The security of the mechanism described in this
document depends critically on participants being trustworthy and trusted.  
I think the document would be improved significantly by a prominent definition of trustworthy that made specific reference to the Internet threat model  and explained how the threat model here differs from that model.

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?  This document does not provide a
mandatory to implement automated key management solution as required
by RFC 4107.  It seems like IKE or IKEV2 would be the best mechanism
to recommend.  If you recommend IKE, be sure to follow the guidance of
draft-bellovin-useipsec; if you require IKEV2 be sure to follow
similar guidelines.

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.

This document referrs to SIPSO-IPsec interactions in a number of
places, but never outlines processing rules for systems that implement
both IPsec and SIPSO.  Does the label go inside or outside of IPsec?
(presumably the label should be protected)

Section 1.3 discusses deployment involving systems that are not aware
of the option.  It proposes that the last intermediate system needs to
strip the label.  Why?  It's in an ignore-if-you-don't-understand
option.

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.

The document describes several times how to compare labels.  I really
hope these explanations are all consistent; as best I can tell they
are.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 29 Sep 2008 17:03:05 -0400

On Mon, 29 Sep 2008 15:20:23 -0400
Sam Hartman <[email-masked]> wrote:

> 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.  
> this TS is published on the standards track,ESP with confidentially be

I don't agree.  The purpose of AH in this spec is to protect certain
information that's in the clear.  (As noted, though, I don't
think it does it properly.)  Protection of the underlying data is the
business of a separate layer or sublayer.
> (presumably the label should be protected)
Very important -- see above.
> As far as I can tell this requirement gets in the way of tunneling

It guards against someone tampering with the outer label, causing the
packet to be misrouted perhaps.  Note 7.3.1 on TCP considerations.
(Also note that 7.3.1 disagrees with 793 on the treatment of security
labels in section 3.6 of 793.  At the least, this shoudl be noted.

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

---

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

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

    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.

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.

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.

    >>  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:-)

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?

If you agree confidentiality is needed somewhere, how do we get
interoperability if we don't mandate a confidentiality mechanism here?
    >>  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.

    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

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