Subject: [anonsec] btns ps/as

From: paul at xelerance.com (Paul Wouters)
Date: Sun, 16 Oct 2005 17:31:58 +0200 (CEST)

On Fri, 14 Oct 2005, Love H?rnquist ?strand wrote:

> You had comments on the old (00) version of the BTNS problem statement,
> applicability statement that it contained too much focus on the TCP reset 
> problem.
>
> Now that Joe, David and Yu-Shun have released a new version of the document,
> care to see if you still have that problem (or some other issue) with the 
> document ?

> http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-applic-01.txt

In that respect it seems much better now. They have used a much more neutral
approach that makes BTNS look like a generic solution instead of a "protect
the SYN flag for BGP" solution.

That does not make me a fan of BTNS though. I find several key questions
unanswered:

- Why isn't this a fundamental part of IKEv2?
- How does BTNS work through NAT?
- How does one end "know" the other end supports BTNS? How does a peer
   advertise BTNS capability?
- How does 'upgrading' a BTNS with credentials work without the MITM being
   a problem *and* without compromising the first few packets of the
   connection (eg the part where I type my password).
- How does BTNS protect in peer to peer (eg mobile phone data exchanges)
   environment?

These questions were asked a long time ago, and I believe OE, in
combination with DNSSEC, is the way to go. This allows even for
authentication of two bluetooth devices without a current internet
connection. Image my device uses an OE connection to to talk to your
device. Both are DNSSEC capable, and have stored the keys neccessary
from the root (".") down to their own signed key. We both exchange our
identities (verified by our out of bound conversation, eg I tell you
"my phone is paul.gsm.xelerance.com"), and then my phone sends yours
the key for "paul.gsm.xelerance.com", which you do not trust, so I send
the key for "gsm.xelerance.com", which you don't trust, until I send
you the .com key that signed xelerance.com and your phono goes "aha,
that key I have and trust, therefor your path is DNSSEC verified",
I am indeed talking to "paul.gsm.xelerance.com".

What also concerns me is the BTNS "advertisement". You don't want to
try and setup an IPsec connection (I assume using some modified IKE like
protocol exchanging keys/DHgroups, therefor probably a TCP connection)
for every host you're going to connect to. And even if you do, are you
going to cache those capabilties of the hosts in case I get back to that
host 3 minutes later? Again, this has been thought through before. Use
the DNS(SEC). You get free caching, a free path of trust, and you don't
send "weird" packets to hosts that don't support this BTNS.

BTNS implies there is no way to do a secure out of bound verification
of identity without manual interference. I believe DNSSEC has made that
assumption obsolete. Therefor, I do no really believe in the future of
BTNS. Mind you, I'm not saying OE is the Holy Grail either, since a huge
problem unsolved by OE at this point is clients behind NAT. But I see
no clear method of how BTNS is securely handing that case either.

And not only OE has decided to go that way. Look at the SSHFP DNS record,
which provides a similar advertising through DNS concept to OE. BTNS as
a concept of "not rely on any out of bound communication, and perhaps
upgrade the connection later when credentials are found" is in my opinion
not a good concept. The "upgrading connections" will lead to all the
identical problems from before we had BTNS, except now my connection
'feels' protected by BTNS, while in fact, until the upgrade happens,
I'm trivially vulnerable to the laptop next to me playing man in the
middle. Either my connection is vulnerable before (failing) to upgrade,
but working, in which case I just typed in my password credentials
anyway, and the attacker already has the most important data he oculd
capture from my session, or the BTNS connection is stalled until the
'upgreade with credentials' happens, in which case BTNS hasn't added
anything over OE/SSHFP like protection that already exists.

Paul Wouters
Xelerance Corp.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Oct 2005 15:53:45 -0500

> - Why isn't this a fundamental part of IKEv2?

It is part of the handling of IKE, but has no on-the-wire changes to
IKE (v1 or v2).

> - How does BTNS work through NAT?

BTNS has to do with identities and how they are established and so has
no impact on NAT-T.

>   advertise BTNS capability?

One does not need to know/advertise peer/local support for BTNS.

Consider three peer combinations involving BTNS:

 - BTNS-capable initiator/BTNS-capable responder
 - BTNS-capable initiator/BTNS-incapable responder
 - BTNS-incapable initiator/BTNS-capable responder

SAs cannot be established in the last two situations unless the
BTNS-capable node has non-ephemeral, authenticated credentials (e.g.,
preshared certs, certs signed by some CA that the other node trusts).
BTNS is not what prevents SA establishment in such cases, credentials,
or, rather, lack thereof do.

Of course, in the first scenario SAs can be established.  Note that in
that case either peer may have authenticated credentials, or not.  And
note that BTNS-capable nodes can be configured to require authentication
of peers for some traffic, according to policy.

>   connection (eg the part where I type my password).

What do you mean by 'upgrading'?

Anyways, BTNS does suffer from MITM attacks.  This is by design, but we
provide both, mitigations and use cases where the MITM attacks are
detected without compromise of sensitive traffic.

One mitigation is leap-of-faith PAD entry creation, where a peer's
public key and IP address are noted in a PAD entry after initial SA
establishment.  I'm not fond of this, but some folks are and so it is
there.

Channel bindings of network authentication at the application layer to
IPsec channels provides for MITM detection.  Here the main value of BTNS
is to provide a way to use IPsec with protocols such as NFS/RPCSEC_GSS
without having to distribute an IPsec authentication infrastructure (a
PKI).

> - How does BTNS protect in peer to peer (eg mobile phone data exchanges)

Again, it does not protect against MITM attacks.  Also, because mobile
peers may change IP addresses it may be possible to hijack TCP
connections if AH is used but not ESP.  Connection-latching should
protect against this, but it's not yet discussed in any I-D, IIRC.

> combination with DNSSEC, is the way to go.

BTNS is NOT an alternative to OE.

> send "weird" packets to hosts that don't support this BTNS.

The intention is that policy will drive the use of BTNS for some
traffic, and that would not be optional -- failure to establish an SA
(with authenticated peers or anonymous peers, either way) means bits
don't move.  Attempting BTNS, then falling back on clear IP may be
feasible, but, as you suggest problematic also.

> of identity without manual interference.

It does not.  It accepts that in some cases this is true, and that in
some other cases the infrastructure exists for, say, Kerberos V, but is
not usable in IPsec or would take longer to make available in IPsec than
it would to make BTNS + channel bindings available.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Oct 2005 16:00:50 -0500

Also, BTW, most, if not all of your concerns came up at the BTNS BoFs.
And yet we reached consensus that the BTNS WG should be chartered
because for some scenarios BTNS seemed useful and even desirable.  BTNS
is NOT intended to be an alternative to useful methods of distributing
keys for IPsec or of enrolling nodes in IPsec authentication
infrastructures (nor, IMO, is there much risk that BTNS would become a
de facto alternative to those).

Cheers,

Nico
--

---

From: paul at xelerance.com (Paul Wouters)
Date: Mon, 17 Oct 2005 23:44:47 +0200 (CEST)

> BTNS has to do with identities and how they are established and so has

But if you later want to "upgrade" this connection, you need to know there
is no MITM. How do you know?

> of peers for some traffic, according to policy.

this does not answer the question I asked. You assume you both ends know
the BTNS capability of the other end and then tell me "either it can work or
not". I undestand both ends need to support BTNS for this to work. If I
support BTNS, and I am about to connect to your webserver, how do I know
your webserver supports BTNS? Or do I blindly try? That was my question (and
part of my point of showing if you use DNS for this, you might as well put
a KEY there and skip BTNS for OE).

> What do you mean by 'upgrading'?

upgrade from a non-priviledged, non-authenticate, BTNS connection to a
X509 roadwarrior to the company VPN. I assume BTNS needs to live with
other IPsec methods (ones that do have extra credentials).

> detected without compromise of sensitive traffic.

Can you explain how the MITM detection works? I thought there was no way
around this unless there is a third party verification? I also don't really
see how you can "mitigate" something that is just vulnerable. BTNS offers
protection against passive attacks, but AFAIK it had no change against an
active attack.

> establishment.  I'm not fond of this, but some folks are and so it is

I'll sound like a broken record, but I agree with you here. Either the
IP is static, in which case the owner controls the DNS for the reverse,
and you might as well put the key in the DNS as trusted third party to
begin with, or the IP is pretty dynamic, which means there is really
nothing to remember for a future leap of faith.

> without having to distribute an IPsec authentication infrastructure (a

So this uses the authentication of other protocols? I don't think I'm
qualified to judge on what that means in practise on multi-user machines.
I'm just not familiar with those, and always assumed IPsec connections
were between host-identities.

> BTNS is NOT an alternative to OE.

So where *does* BTNS see a valid deployment? I find its scope rather
limited because of its severe limitations, which I know were per design
goal. It cannot protect my phone exchanging data. It cannot protect my
laptop in my business meeting in the hotel lobby. My company VPN requires
more credentials. It doesn't protect remote sites I haven't done a leap
of faith with from home before?

> feasible, but, as you suggest problematic also.

Can you be less abstract and more concrete? What is "dictated by policy"?
For anonymous security like BTNS to work, I had assumed it worked
opportune, eg for each new IP connection. Are you know saying it needs
a preconfigured arangement (not for keys or shared secrets, but for 'policy'?)

> it would to make BTNS + channel bindings available.

Where there is kerberos, you can roll out OE. It's already available.

I fail to see the niche market where BTNS is useful. Sorry.

Paul
-- 

"Happiness is never grand"

 	--- Mustapha Mond, World Controller (Brave New World)

---

From: paul at xelerance.com (Paul Wouters)
Date: Mon, 17 Oct 2005 23:51:47 +0200 (CEST)

> de facto alternative to those).

What concerns me is how BTNS is presented to the enduser. those should
not be confused to believe that they are more secure then they truly are.

In another project I'm involved with, OTR (ww.cypherpunks.ca/otr/), a
library and plugin to add privacy to instant messaging, we run exactly
into these issues too. key exchange, leap of faith or phone call your
fingerprint, secure. So we deploy three states, "insecure", "unverified"
(meaning private but not authenticated) and "verfied". Most users cannot
grasp three states. They want a lock saying "open" and "closed".

For those types of users BTNS will add "IPsec security", and they'll
still be MITM'ed at Starbucks.

Paul
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Oct 2005 17:11:02 -0500

> is no MITM. How do you know?

First, the ability to "upgrade" is not a requirement.

Second, if you later acquire credentials that can be used for
"upgrading" then you use channel bindings (perhaps out of band): i.e.,
the two nodes mutually authenticate with the new credentials, with said
authentication bound to the previous BTNS public keys.

> not". I undestand both ends need to support BTNS for this to work.

Not so.  You can mix BTNS and non-BTNS IPsec as long as the BTNS-capable
peer can authenticate itself to the other.  Note that the BTNS-capable
peer can treat the other as though it were an unauthenticated
BTNS-capable peer.

>                                                                    If I

You do what your policy tells you to; if it works, great, if it doesn't,
you'll be sad.  How is this different from IPsec?

> other IPsec methods (ones that do have extra credentials).

Your assumption is, in fact, a requirement, but "upgrading" isn't.

> protection against passive attacks, but AFAIK it had no change against an

Google "channel bindings."

To summarize: given a secure channel (see below) and its channel
bindings (a handle for the channel that is cryptographically bound to
its key exchange), then you can use Kerberos V and/or other security
mechanisms at higher layers over that channel and use such mechanisms to
securely show that the channel bindings for the underlying channel are
the same for both end-points -- if indeed the channel bindings are seen
to be the same on both end-points then there is no MITM in that channel.
The security of this depends on how the channel and its bindings are
constructed as well as on the security mechanisms used at the
application layer and on the construction of the channel binding
operation.

An IPsec channel can be defined.  Some IPsec implementation support
something some of us call "connection latching" where connect()/listen()
operations cause policy to be dynamically created that binds the
connection's traffic selectors to the IDs (or public keys, say) of the
peers of the initial SA used to send/receive the first packet for the
connection.

> nothing to remember for a future leap of faith.

Joe will probably tell you how in some cases you have static addresses
but don't want/care for DNS or other infrastructure.

> qualified to judge on what that means in practise on multi-user machines.

It means that local security matters, of course.

> were between host-identities.

I don't think that will always be a safe assumption, but certainly
multi-user systems exist :)

> of faith with from home before?

Does the applicability statement not make this clear?

> a preconfigured arangement (not for keys or shared secrets, but for 

In some deployments, yes.

For example, given connection latching (see above) you can limit MITM
attacks on BTNS to the initiation of each connection.  So you might have
a policy that says that you want to always use BTNS for selected
traffic, like BGP, or OSPF, or SMTP, and which in your environment you
expect to succeed.  For mobile devices BTNS is probably not very useful
without channel bindings.

> Where there is kerberos, you can roll out OE. It's already available.

So, long-term we all want BTNS to go away.  Hopefully all the
technologies that would obviate it get deployed before BTNS ever gets
deployed.  BTNS appears to be a fairly simple feature to specify,
implement and deploy in some environments -- that is its appeal.

> I fail to see the niche market where BTNS is useful. Sorry.

The list archive has plenty of meta-discussion of BTNS.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Oct 2005 17:17:57 -0500

> grasp three states. They want a lock saying "open" and "closed".

BTNS-capable nodes should not display such status at all (unless channel
binding is used, in which case the status is "secure" or "not secure").

Nico
--

---

From: paul at xelerance.com (Paul Wouters)
Date: Tue, 18 Oct 2005 00:33:32 +0200 (CEST)

By the way,

Thanks for your patient explanations. I do appreciate it.

I can now see the channel binding of BTNS being useful, but
to me that's not "real" BTNS, because you *do* use a third
party for authentication (a kerberos infrastructure).
Running IPsec on all hosts within an organisation using
BTNS would be great.

My mindset is more aimed at protecting 'the internet at large'
though :)

Paul

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 17 Oct 2005 17:49:45 -0500

> party for authentication (a kerberos infrastructure).

BTNS in a channel binding scenario is merely a way to avoid having to
either deploy an IPsec authentication infrastructure or deploy KINK or
any other KE or IKE extension that re-uses credentials for an already-
deployed non-PKI authentication infrastructure.

Here BTNS is a means to an end, and not the only means to that end.  The
end is this: leave all session crypto to ESP/AH.

Note also that authentication at application layers cannot be avoided
entirely even if IPsec allows the use of user credentials for each
connection (with connection latching) on multi-user systems.  Consider a
protocol like NFS that can multiplex multiple users on one connection;
here the configuration with the smallest state footprint is a single
connection per-{client, server}, a single SA pair per-{client, server}
and a single GSS-API security context, thrown away as soon as channel
binding succeeds, for user authentication per-{user, client, server}.
Without channel binding to IPsec you can either have lots of live GSS
security contexts per-connection, lots of one-user connections, or
looser channel binding (i.e., make sure that the server's IPsec and GSS
identities "match").  Note too that NFS really wants RDDP, and RDDP
needs to have all application data layered above it be in cleartext
relative to RDDP -- clearly this conflicts with RPCSEC_GSS.  Thus the
desire to push session crypto down to IPsec in the context of an
application that already has authentication at theapplication-layer.

So, perhaps we'll end up with a policy where BTNS is only ever used for
NFS -- port 2049.  I'd be happy with that.

> Running IPsec on all hosts within an organisation using

Particularly for a small organization.

> My mindset is more aimed at protecting 'the internet at large'

Some IETF technologies are only/mostly deployed in intranet
environments.  Yes, we should (and do) design with the larger Internet
in mind, but it is not our only focus (think sub-IP).  Not that I'm
saying that BTNS is not appropriate for use in the Internet at large --
in a channel binding context it may be useful in large networks for
*some* applications, and perhaps Joe will explain how it can be useful
in large networks in other scenarios.

Nico
--

---

From: lha at it.su.se (Love Hörnquist Åstrand)
Date: Tue, 18 Oct 2005 12:33:21 +0200

> in large networks in other scenarios.

I would like to point out that Nico belongs to one of the three groups
that drives BTNS, namely the channel binding group.

The other two groups are "Protections against off-path attacks" and
"SSH-like leap of faith".

The off-path attack protection seems simple enough because it simply  
doesn't
care about MITM attacks. But I feel that the SSH-like leap of faith  
group
needs to explain how to handle identity handing to avoid MITM, changing
addresses, etc.

Love

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.postel.org/pipermail/anonsec/attachments/20051018/600bfdf6/PGP.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 19 Oct 2005 18:05:36 -0700

>>> My mindset is more aimed at protecting 'the internet at large'
...
> care about MITM attacks. But I feel that the SSH-like leap of faith  group

Leap-of-faith avoids MITM for asymmetric cases; I'm not sure about the
symmetric ones.

I'm not as sure that MITM is a deal-breaker, though. MITM still requires
the middleman to participate fully in the connection as a proxy; many
attackers don't want to do that much work (i.e., BTNS then raises the
bar of attacks to MITM only, not quick single-packet spoofing).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20051019/b0b32e7f/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 19 Oct 2005 17:44:21 -0700

Paul Wouters wrote:
Nico handled most of these
...
> combination with DNSSEC, is the way to go.

OE doesn't avoid the need for a key hierarchy; it just moves it to the
DNS. This is already addressed in the draft.

> This allows even for

This won't work if you're disconnected from the DNS, or if for some
reason there is NO place in the DNS that you do trust.

...
> assumption obsolete. 

DNSSEC just moves the manual part; somebody still must setup the DNSSEC
keys.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20051019/e0c20881/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 19 Oct 2005 18:01:24 -0700

Nicolas Williams wrote:
...
> in large networks in other scenarios.

One point of BTNS is missed in this discussion: it helps protect the
transport layer even when the OTHER end has a key that YOUR end can't
verify by a third party.

Consider an agent in the field. She loses her laptop, and buys a new one
at Sears. She wants to get a message back to headquarters, but can't go
to get a new key.

Headquarters, however, HAS a key that is signed and that she can verify.
She uses conventional IPsec to verify that key, but HQ can't - and they
want messages to come to them securely.

How do they know it's not a 'man in the middle'? They don't. The message
could come from anyone. But WHOMEVER it comes from MUST be communicating
directly with HQ -if they want to- (i.e., if THEY verify the CA of HQ's
key).

How do they know the message was valid? She used some passphrase.
However, she did NOT want to send it in the clear.

BTNS - even without channel bindings - allows that, using asymmetric
BTNS in this case.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20051019/87c0eba4/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 19 Oct 2005 17:52:49 -0700

> but don't want/care for DNS or other infrastructure.

I *might as well put the key in the DNS*. If I *had* a key to put there.
And the owner of the DNS *lets* me. And the DNS is DNSSEC, and that
owner's records are signed one level up, as are the next, as are the next.

There's a chain there that ends with "and we both agree to a trusted
third party" - the CA somewhere that both ends believe in. There's no
reason that chain must exist, and it's CERTAINLY not under any local
control.

> So, long-term we all want BTNS to go away.

Not me, and not some military types that would like to be able to secure
connections and THEN use a separate mecahanism to authenticate; this
makes the outer key even harder (if not impossible) to correlate to an
individual user.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20051019/a5e05ba7/signature.bin