ietf
[Top] [All Lists]

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

2008-09-29 17:22:00
On Mon, 29 Sep 2008 15:20:23 -0400
Sam Hartman <hartmans-ietf(_at_)mit(_dot_)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
this TS is published on the standards track,ESP with confidentially be
required.

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.

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)

Very important -- see above.

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.

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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>