On Tue, 30 Sep 2008 06:44:45 -0400
Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu> wrote:
"Steven" == Steven M Bellovin <smb(_at_)cs(_dot_)columbia(_dot_)edu>
writes:
Steven> On Mon, 29 Sep 2008 15:20:23 -0400
Steven> 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?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf