Subject: [anonsec] BTNS mailing list auto-rejection from non-subscribers

From: yushunwa at ISI.EDU (Yu-Shun Wang)
Date: Fri, 05 May 2006 11:28:06 -0700

Hi,

(Not sure if Pekka's mail gets to the list yet, but his
comments were all quoted below.)

>> From: Pekka Savola <pekkas at netcore.fi>
>> Subject: BTNS prob/applic -02 review
>> Date: Wed, 3 May 2006 13:10:24 +0300 (EEST)

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

Thanks.

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

No direct answers, but I think the work on APIs (both
channel binding and the general IPsec API) will
definitely address that.

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

Joe is also working on some ICMP-related drafts, he is better
suited to address this suggestion.

>> 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 benefits section is of course addressing the benefit
of using BTNS, hence the assumption. I personally don't
think it is the goal of this doc to also address the
transition strategy, though it is imo not very complex.
BTNS uses IKE (or added a mode in IKE, not sure how to
accurately describe it), and is enabled through PAD and/or
SPD. So if the other end doesn't support it, IKE exchange
would fail. The "strategy" may boiled down to whether or
not we revert back to non-protected mode, as the original
intention is "better than nothing." So the question may
be: do we go back to nothing if the other end doesn't
do BTNS?

That said, I still don't think it is the goal of
this doc to address the transition strategy. It should
be addressed at some point once we know the details of
the mechanisms involved.

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

It uses IKE, so it adds whatever number of round-trips IKE
requires. So yes, in the environments that IKE is not
suitable due to latency issues, neither is BTNS. We will
make a note in the doc.

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

No. Nico or David specifically corrected me that channel
binding should (or must) not reveal passwords in the upper
layer authentication. So we should make that clear, but the
details will be in Nico's doc.

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

Maybe that should say BTNS will work over whatever
IPsec/NAPT that's being proposed. I really don't
see why that wouldn't work, but I've never investigated
that claim. (Maybe losing tunnel mode?)

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

I'll replace it with your text. Thanks!

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

Yes, but that doesn't mean one cannot use TLS in a symmetric
manner. :-)

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

Maybe 4301 & 4306. I'll check with Joe and David.

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

Noted.

yushun

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 8 May 2006 12:49:05 -0500

> comments were all quoted below.)

Joe forwarded it today.

> details will be in Nico's doc.

The application-layer authentication protocol is whatever it is.  If
it's something that provides attackers with password-derived material
that can be attacked offline then an MITM, though detectable[*], will
make out with something useful.

OTOH, if it's a protocol that does not have such a weakness then MITMs
can be detected and they cause little or no harm that they couldn't by
trying to be MITMs at the application layer in a world with no IPsec.

[*]  If the application-layer authentication protocol is sufficiently
     weak then MITMs may be difficult to distinguish from loss of
     connectivity or peer reboot.

E.g., Kerberos V AP exchanges would leak little other than the target's
krb5 principal name, while Kerberos V AS exchanges using PA-ENC-
TIMESTAMP pre-authentication would leak material that can then be
attacked offline.

So, yes, this needs to be called out in security considerations text,
that what an active attacker can get away with in the channel-binding
BTNS use cases depends on the application layer authentication protocol.

> that claim. (Maybe losing tunnel mode?)

BTNS is mostly orthogonal to NAT issues here because BTNS is primarily
about peer authentication in IKE and IPsec policy.

Applications using the new APIs may, by tying IDs to addresses [at the
app layer], cause problems with NAT, but this too is not specific to
BTNS (though it should be noted!).

Michael may want to comment here as well.

> Yes, but that doesn't mean one cannot use TLS in a symmetric

Er, I think the thing about "full, symmetric authentication at the
application layer" bit is wrong -- channel binding can be useful even if
the application layer authentication protocol does not provide mutual
authentication, as long as it authenticates one peer and can be bound to
IPsec channels.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 8 May 2006 18:38:56 -0500

On Mon, May 08, 2006 at 12:49:05PM -0500, Nicolas Williams wrote:
Pekka> ==> Did I understand correctly that MITM is discovered and session is
Pekka> taken down after the MITM attacker has been able to obtain passwords
Pekka> (or whatever) from higher-layer authentication?  This sounds a bit
Pekka> bleak.  It's of course better than nothing, but when designing or
Pekka> using higher-layer protocols, in the future the choice might be
Pekka> between using (say) TLS or using CBB-BTNS at lower layer -- and
Pekka> depending on whether the higher layer authentication leaks any
Pekka> secrets, NOT using BTNS might be a better choice (again, depending on
Pekka> the authentication type).
Pekka>
Pekka> In any case, the higher layer authentication information leaking (or
Pekka> lack thereof) and implications on BTNS applicability should be
Pekka> discussed explicitly.

I addressed some of this earlier, but I didn't address the part about
TLS being better than CBB-BTNS w.r.t. to application layer
authentication protocol leaks.

I'll make several points w.r.t. to that:

 - As I mentioned, there will be situations where the app-layer authen
   protocol leaks nothing much (e.g., Kerberos AP exchanges), and in
   these case the appeal of BTNS over TLS is that ESP/AH are much closer
   to the wire, and, more importantly, below RDDP, thus more processing
   can be offloaded to NICs.

 - Also, applications could do enrolment/leap-of-faith, where a peer's
   BTNS public key is learned and used to provide peer authentication
   via BTNS in subsequent exchanges.

 - When you say TLS you seem to mean "TLS with server certs."  BTNS can
   support assymetric authentication as well.  What's difficult about
   assymetric authentication is that you have to pre-exchange something
   by which the client can authenticate the server, such as CA root
   certs; of course, TLS too has cipher suites with no user or server
   authentication.  So does TLS have anything on BTNS?

But I agree that we have to carefully document security considerations
for CBB-BTNS applications.