Subject: [anonsec] forwarded from Pekka Savola

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 08 May 2006 10:03:36 -0700

Forwarded on behalf of Pekka Savola:
- -------------------------------------------

Hi,

(Not subscribed, hopefully this gets through..)

I had a flight, so I ended reading a couple of drafts in the interest of
providing early out-of-WG review.

The doc was mostly in OK shape, though it wasn't clear whether the
scenarios were the ones thought about by BTNS proponents rather than
having been proposed by folks actually designing applications..

substantial
- -----------

   BTNS reduces vulnerability after associations have been established
   to attacks from parties not participating in the association. This
   helps protect systems from low-effort attacks on sessions or
   connections involving higher levels of resources.

==>the doc mostly discusses TCP RST attacks, maybe it should discuss
ICMP attacks a bit too as those are in most cases much easier to launch
than TCP-RST attacks.  It is not clear to me whether IPsec includes
sufficient mandatory-to-implement, enabled-by-default protections to this.

4.6. Benefits

   BTNS raises the level of effort for many types of network or
   transport layer attacks. Casual, simple packet attacks need to be
   augmented to full associations and connection establishment for SAB,
   so that an attacker must perform as much work as regular host. SAB
   thus raises the effort for a DDOS attack to that of emulating a flash
   crowd. For open services, there may be no way to distinguish such a
   DDOS attack from a legitimate flash crowd anyway.

==> AFAICS, this text is too simplistic.  It seems to assume that
non-BTNS mode of connecting to the service is not supported, i.e., BTNS
is deployed and enabled everywhere.  What is the transition strategy to
using BTNS?

   The use of BTNS means that more traffic will require cryptographic
   operations. Receivers will observe increased processing load in
   decrypting and/or verifying incoming traffic as a result. Although
   this may itself present a substantial impediment to deployment, it is
   a challenge to all cryptographically protected communication systems.
   The use of crypto increases the load on those receiving protected
   traffic; this document does not address the impact BTNS has on such
   load.

==> you don't seem to discuss the fact that the set-up of BTNS requires
significant number of round-trips, which may or may not be an issue for
ome kinds of applications, especially for links with high latency.

   A man-in-the-middle attack on IPsec with CBB is discovered later than
   if IKE authentication were used.  A man in the middle cannot subvert
   IKE authentication, and hence an attempt to attack it via use of two
   separate security associations will cause an IKE authentication
   failure.  With CBB, the BTNS-IKE step will succeed because it is
   unauthenticated, and the security association will be set up.  The
   man in the middle will not be discovered until the higher layer
   authentication fail after more resources have been invested in this
   session.  Nonetheless, this is an improvement over the alternative of
   minimizing the configuration of IPsec by using a group pre-shared
   key, which provides no defense against man-in-the-middle attacks
   among the nodes sharing the key.

==> Did I understand correctly that MITM is discovered and session is
taken down after the MITM attacker has been able to obtain passwords (or
whatever) from higher-layer authentication?  This sounds a bit bleak.
It's of course better than nothing, but when designing or using
higher-layer protocols, in the future the choice might be between using
(say) TLS or using CBB-BTNS at lower layer -- and depending on whether
the higher layer authentication leaks any secrets, NOT using BTNS might
be a better choice (again, depending on the authentication type).

In any case, the higher layer authentication information leaking (or
lack thereof) and implications on BTNS applicability should be discussed
explicitly.

6.1. Issues Not Addressed
   BTNS does not consider the impact of NAT or NAPT on the capabilities
   it intends to provide, except as are already addressed by the current
   Internet network security suite.

==> IMHO, BTNS *must* consider NAT or NAPT implications.  Folks want
this protocol to be useful across NATs.

   PKI4IPsec is an IETF WG focused on providing an automatic
   infrastructure for the configuration of Internet security services,
   e.g., to assist in deploying signed certificates and CA information
   [7].

==> I reviewed pki4ipsec's profile doc, and according to doc author,
this would be a mischaracterization of their target audience.  The
intended recipient of that spec, at least, was pki4ipsec implementors,
not protocol users, deployers or application level users.  Maybe reword
(this isn't optimal but couldn't think of anything better):

   PKI4IPsec is an IETF WG focused on specifying a profile for pki4ipsec
   implementers on ways to bind PKI information to IPsec [7].

semi-editorial
- --------------

   For higher layer protocols with full, symmetric authentication at the
   application layer, e.g., TLS, pre-shared keys, etc., S-CBB allows
   those protocols to use those credentials and exchanges to bind to
   BTNS-IPsec, protecting the transport and network layer protocols in
   addition to the application data.

==> umm.. in most cases (e.g., web or IMAP access), the use of TLS
rarely implies symmetric authentication, but rather that's obtained only
when the clients also use certificates (not that often).  Or maybe you
include password or similar rather weak form of authentication under
"symmetric" as well...

9.1. Normative References

   (none)

==> as per definitions of
http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt

there should probably be some normative references.

   [14]  Richardson, M., "Opportunistic Encryption using The Internet
         Key Exchange (IKE)," (expired, was work in progress),
         draft-richardson-ipsec-opportunistic-17, Jan. 2005.

==> this is now RFC 4322.

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 08 May 2006 10:26:31 -0700

Some comments:

Most of the feedback below will be addressed in an upcoming revision,
with exceptions as noted below. Feedback from the group is solicited on
those.

Joe

> Forwarded on behalf of Pekka Savola:
...
> -----------

We should be more specific about protecting the packets of the transport
protocol; ICMP issues should be addressed a bit, but are likely out of
scope even for IPsec.

> this protocol to be useful across NATs.

The interaction between IPsec and NAT/NAPT is already discussed in other
documents. As others have stated, though, NAT is exactly the kind of
attack that IPsec was designed to detect.

>    implementers on ways to bind PKI information to IPsec [7].

That's self-referential, which is unfortunate for a definition. What are
pki4ipsec implementers trying to do? isn't "bind PKI information to
IPsec" similar enough to the explanation offered? (if not, a rewording
of that explanation would be more useful, esp one that could avoid using
pki4ipsec and/or PKI in the definition).

> http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative-references.txt

That's an IESG statement; the current RFC-Editor procedures are in
2222bis. Sec 2.7 of that indicates:

      Within an RFC, references to other documents fall into two general
      categories: "normative" and "informative".  Normative references
      specify documents that must be read to understand or implement the
      technology in the new RFC, or whose technology must be present for
      the technology in the new RFC to work.  ...

even the IESG statement states:
	Note 3: The normative/informative distinction is relevant in
	any document that amounts to a technical specification, even
	if its intended status is Experimental or Informational.

This isn't a tech specification; that's the reason all references are
informative.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 8 May 2006 18:02:35 -0400

>protocol; ICMP issues should be addressed a bit, but are likely out of

RFC 4301 discusses dealing with ICMP traffic in a fair amount of detail.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 08 May 2006 15:36:08 -0700

> RFC 4301 discusses dealing with ICMP traffic in a fair amount of detail.

Yes; that would be the thing to cite and/or summarize.

In general, it seems like 4301:

	- indicates when to send (or not send) ICMPs
		which is not as relevant to this discussion

	- indicates that it is important to ignore incoming ICMPs
	(or at least some types thereof) if security is paramount
	(e.g., in Sec. 6)

The latter seems more relevant; I was hinting above more that IPsec
doesn't try to authenticate ICMPs from routers, so use of IPsec doesn't
itself provide protection from ICMP attacks.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 8 May 2006 17:57:54 -0500

> itself provide protection from ICMP attacks.

Really?  If you could negotiate an SA pair between two nodes you would
accept unprotected port unreachable messages?  I don't think I would.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 08 May 2006 16:56:44 -0700

> accept unprotected port unreachable messages?  I don't think I would.

ICMPs from the destination are one thing; ICMPs from the middle of the
network are different. IPsec doesn't say how to protect those, only that
those probably need to be dropped.

Joe

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 9 May 2006 08:46:01 +0300 (EEST)

> those probably need to be dropped.

In other words, there is no mandatory-to-implement, enabled-by-default 
IPsec protection which would not break legitimate uses such as 
traceroute, ICMP soft-errors for TCP failover adjustment, etc.

There was actually a debate between me and Stephen about this on RPSEC 
list this January [*].  I acknowledge the IPsec spec gives a couple of 
mostly un- or under-specified knobs for the administrators to play 
with when setting IPsec policies, but no good mechanism which wouldn't 
throw out the baby with the bathwater.

[*] if interested, you may take a look at the thread around:
http://www1.ietf.org/mail-archive/web/rpsec/current/msg01562.html

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 09 May 2006 10:06:40 -0700

> traceroute, ICMP soft-errors for TCP failover adjustment, etc.

IPsec protects communication between two endpoints. It doesn't protect
messages received from any arbitrary router in a network. Yes, since
these systems depend on such messages, they would break - but, FWIW,
they are often filtered for other reasons as well.

> mostly un- or under-specified knobs for the administrators to play with
> when setting IPsec policies, but no good mechanism which wouldn't throw
> out the baby with the bathwater.

If you want to configure an entire network's routers with keys and have
them sign their ICMPs, this would work fine. The issue is one of
deployment, not capability. This isn't - as I noted before - an IPsec
issue, IMO.

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 12 May 2006 18:21:33 -0400

>..

You're right that one would not expect an end system to have SAs with 
routers along the path. Thus the details provided about how to deal 
with ICMP traffic emitted over or received via such SAs are not so 
relevant. However, we do provide explicit advice about screening 
unauthenticated ICMPs to avoid some types of attacks, e.g., to not 
allow a PMTU to be set below some defined threshold.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 12 May 2006 15:59:08 -0700

Stephen Kent wrote:
> routers along the path. Thus the details provided about how to deal with 
> ICMP traffic emitted over or received via such SAs are not so relevant. 
> However, we do provide explicit advice about screening unauthenticated 
> ICMPs to avoid some types of attacks, e.g., to not allow a PMTU to be 
> set below some defined threshold.
> 
> Steve

Yes - Fernando and I reviewed that issue; he's updating his ICMP attacks 
doc to discuss this, and I'm cite 4301 as well as his doc in this regard 
in the update.

Joe