Post by Sam HartmanI 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.
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