Subject: [anonsec] persistence of leap-of-faith-learned entries.

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Thu, 10 Nov 2005 14:40:49 -0800

section 3 of your draft says:

   Implementors may provide a PAD entry attribute used to indicate that
   the given PAD entry is a template that should, when matched, cause
   new PAD and SPD entries to be created binding the matching peer's IP
   address and BTNS ID (i.e., public key) by using the PUBLICKEY ID
   selector to match on the peer's public key.  Entries created this way
   have to be persistent, for some value of "persistent," though we
   RECOMMEND that "persistent" mean "until manually removed."

much of current IPsec use involves portable systems which use
dhcp-assigned addresses.

ssh's leap-of-faith database only records the key of the server (which
usually doesn't move much); it does not record client-side keys.

your scheme might work on a node which is usually the ultimate
initiator, but is likely to cause trouble on a usually-the-responder
node.

an IKE protocol extension to (for instance) include TTL or remaining
lease lifetime might help..

						- Bill

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 10 Nov 2005 17:23:43 -0600

> initiator, but is likely to cause trouble on a usually-the-responder

The security considerations text call this out as a DoS.

> lease lifetime might help..

Yeah, personally I'd rather rip LoF out.

---

From: paul at xelerance.com (Paul Wouters)
Date: Fri, 11 Nov 2005 02:08:07 +0100 (CET)

> > usually doesn't move much); it does not record client-side keys.

can it not record the used ID as well? Then it could send a FQDN as id,
and we could store key+id.

> Yeah, personally I'd rather rip LoF out.

I'd rather keep LoF in. It's all we have in BTNS.

Paul
-- 

"Happiness is never grand"

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 10 Nov 2005 19:17:06 -0600

> I'd rather keep LoF in. It's all we have in BTNS.

It's not.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 10 Nov 2005 20:05:38 -0600

On Thu, Nov 10, 2005 at 07:17:06PM -0600, Nicolas Williams wrote:
> _______________________________________________

To clarify: there's channel bindings.

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 21 Nov 2005 10:58:18 -0500

>>>>> "Paul" == Paul Wouters <paul at xelerance.com> writes:

    Paul> On Thu, 10 Nov 2005, Nicolas Williams wrote:
    >> > ssh's leap-of-faith database only records the key of the
    >> server (which > usually doesn't move much); it does not record
    >> client-side keys.

    Paul> can it not record the used ID as well? Then it could send a
    Paul> FQDN as id, and we could store key+id.

Then what do you do?  How is it useful to kno the key and ID without
knowing which traffic should go to that ID?

--Sam

---

From: paul at xelerance.com (Paul Wouters)
Date: Mon, 21 Nov 2005 17:49:53 +0100 (CET)

> knowing which traffic should go to that ID?

If it is a host-host connection (a la Opportunistic Encryption) then it
will just encrypt that traffic which otherwise would go plaintext. This
would allow us to keep the ID and key fingerprint for subsequent connects.

If there are multiple ways of connecting, eg towards a subnet behind the
host, then I would want to allow some unknown incoming machine without
having a confirmed (hardcoded) policy anyway.

Though one middle case here is when an "OE gateway" is used, eg one IPsec
server offering anonymous IPsec connections for an entire subnet behind it.
But then the OE gateway has a specific policy loaded for that.

Opportunistic Encryption, as curently implemented in freeswan/openswan is
always bound to a policy. Authentication of a host (and using leap of faith)
is a seperate process from applying policies for OE/anonsec type connections.

Or in other words. we do ssh leap of faith without knowing whether the user
can still login to the remote server as well. authentication is a different
step from host/client verification.

Paul
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 21 Nov 2005 12:19:55 -0500

>>>>> "Paul" == Paul Wouters <paul at xelerance.com> writes:

    Paul> On Mon, 21 Nov 2005, Sam Hartman wrote: On Thu, 10 Nov 2005,
    Paul> Nicolas Williams wrote:
    >> >> server (which > usually doesn't move much); it does not
    >> record >> client-side keys.
    >> 
    >>  Then what do you do?  How is it useful to kno the key and ID
    >> without knowing which traffic should go to that ID?

    Paul> If it is a host-host connection (a la Opportunistic
    Paul> Encryption) then it will just encrypt that traffic which
    Paul> otherwise would go plaintext. This would allow us to keep
    Paul> the ID and key fingerprint for subsequent connects.

I think you're missing the whole point.  I'm going to suggest you do
the same thing I told Nico: walk through an example in sufficient
detail that you can explain when SPD entries get added and what they
contain.

I think you will find that you're missing information you need and/or
what you describe is not within 2401bis.

The nice thing about this suggestion is that if I'm wrong and what you
describe is in fact simple it is fairly easy to demonstrate.

--Sam

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Tue, 22 Nov 2005 12:29:03 +0200

> detail that you can explain when SPD entries get added and what they

Here is a short example of the scenario where the ssh-style leap of
faith would be useful:
----------------------------------------------------------------------
Environment
===========

Staticly configured router network, where each router has a fixed
IP-address, and fixed key that is used by that IP-address. The actual
routing is done dynamically by routing protocol run between the
routers. The IP-address <-> key mapping is static, and persistent,
meaning, that even if the router needs to be changed because of
hardware failure, the new router will be configured with the same
private key. This can be done in multiple ways, but all of those are
outside the scope of this example.

Few examples of those ways to provide static, persistent mapping are:
All keys and IP addresses are stored in the centralized database, and
routers fetch them from there when they boot up; Key, and the identity
(IP-number) of the router is stored on the smartcard which is attached
to the router itself. Note, that each organization usually have their
own way of doing this, meaning there is no single centralized
database, but one organization might use one database, and another
might use smartcards, and another might be using some other method.

There is no fast key rollover, and there is no changes in the key <->
IP mapping.

Each key is identified by the single IP-address used as a identity
when it is used.

We are trying to protect routing protocol running on UDP/TCP port
1234, and nothing else.

The routers are owned and adminstrated by multiple different
organizations, which do not have common adminstration, thus
pre-distributing keys or centralized CA is out of question. The number
of routers is huge, and and the number of organizations in the whole
network is also very large, but each router usually talks to only few
other routers (i.e. the ones they are directly connected to), and
routers keep talking all the time with the same routers (unless there
is real physical change in the network (i.e. new link / router added
somewhere)).

The parties each router talk to do not really change often, but the
whole network having huge number of routers will in total have lots of
changes each day (but affecting only those routers directly related to
those changes).

For example we could have 1 million routers, with 10,000 organizations
(each organization having 100 routers), each router is connected to
around 10 other routers via direct links, and there could be 1,000 new
routers added and deleted every day, i.e. affecting 10,000 routers in
the network. When new router is added to new or previously
disconnected link, it will automatically detect the other ends
ip-address and connect to it, and after that the routing protocol
automatically takes care of updating the routes (i.e. adding new
router or deleting old one does not require manual configuration
changes in the neighbor routers).

Policy
======

Initial SPD in each router could be something like:

Any IP, UDP/TCP port 1234 <-> Any IP, UDP/TCP port 1234:
	PROTECT(BTNS-LEAP-OF-FAITH, expire = 14 days)

Any IP <-> Any IP:
	BYPASS

Initial connection
==================

When the new IKE SA connection is created (either by us or by other
end), and the PROTECT has BTNS-LEAP-OF-FAITH, we create new SPD rule
with following values (2200:AF11::1 is remote ip, and 2200:AF22::2 is
local ip):

2200:AF11::1, UDP/TCP port 1234 <-> 2200:AF22::2, UDP/TCP port 1234
	PROTECT, expire time = 14 days

and new PAD rule:

IPV4_ID: 2200:AF11::1, key: <public key or certificate the other end used>,
	expire time = 14 days

Connections after initial connection
====================================

As we now have SPD rule that will expilicty match the traffic
2200:AF11::1 port 1234 <-> 2200:AF22::2 port 1234, and PAD entry which
ties 2200:AF11::1 to the given key, we will reject all connections
which cannot authenticate using the same key coming from the same IP
address. Thus after the initial connections, attackers cannot fake to
be the router.

Expiring entries
================

Each SPD and PAD rule has new information, i.e. the expire time. If no
connections comes in using that PAD/SPD rule before that expires then
the whole entry is removed from the database. Every time connection
comes in, then the expire timeout is started from the beginning. This
allows slow key roll-over, i.e. if we remove one router from the
network, its keys are forgotten from the other nodes after expire
time, and then we can add new router back to same IP with different
key.

The expire time should be taken long enough to be able to cope all
temporary failures (link going down, someone accidently cutting the
cable etc), but short enough that it can cope with the actual
operational changes (i.e. customer leaving, and his router being
disconnected, and then new customer arriving few weeks later to the
same premisis, and new router installed there).

This is something we cannot do on the secure shell as there is no
guarantee that the other ends will connect frequently enough, as
connections are depending on the users. If we are protecting automated
network, where we can be sure that in normal case we do have
connections up and running all the time, we can do this kind of
expiring.

Summary
========

This example above, does not try to be any exact protocol doing
everything, but a simple example showing where the ssh-style leap of
faith could be useful.

There are other places where it could be used, and this example is
very limited, and using strong limitations to limit the scope. This
probably could be expanded to support more scenarios, but the basic
idea of this example is to show one very limited scenario where it
could be used. 
-- 
kivinen at safenet-inc.com

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sat, 26 Nov 2005 22:04:55 -0500

>>>>> "Tero" == Tero Kivinen <kivinen at iki.fi> writes:
    Tero> Any IP, UDP/TCP port 1234 <-> Any IP, UDP/TCP port 1234:
    Tero> PROTECT(BTNS-LEAP-OF-FAITH, expire = 14 days)

  Probably the "expire=" is the key.

  Note that if some of routers come up with dynamic IPs and use FQDN IDs, it
all still works --- if the other routers would always refuse to speak UDP/TCP
port 1234 in the clear. There is no DOS by policy.
 
  All of this may or may not also have channel binding in the protocol.

  Want a real example of this?  Hosts getting disks via iSCSI from an ISP.

  Another good example of this might be protecting 6to4 traffic.

    Tero> This is something we cannot do on the secure shell as there is no
    Tero> guarantee that the other ends will connect frequently enough, as
    Tero> connections are depending on the users. If we are protecting

  Good point. 
  The expiry could be on the order of tens of hours.

  I think a key other point is that there is:
    a) BTNS
and
    b) BTNS-LEAP-OF-FAITH

  We don't have to make LoF work for all scenarios. It may not be appropriate.
Further, LoF is a *local* policy on the responder. It doesn't need to be
negotiated, or known a-priori.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [