Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables

From: Joe Touch <[email-masked]>
Date: Thu, 29 Mar 2012 13:42:39 -0700

Hi, all,

Since some questions have been raised on the relationship of the TCP-AO 
KMP to this document, and I'm not in Paris, let me clarify my views below.

Joe

1) I don't see the need for this doc at all

The doc tries to describe a single view of persistent keying information 
used in different security protocols, but it's not clear why this is 
ever necessary. Is this information intended to be used for multiple or 
varying protocols? If so, why does that even make sense, given the 
varying protections such protocols afford?

2) if there is such a doc, it's meaningless unless it gives examples of 
how it can be viably interpreted in terms of existing KMPs; primary 
among these would be static keys (e.g., as currently widely used for 
TCP-MD5) and IKEv2

This includes resolving the fact that different KMPs and crypto 
protocols already store information in a variety of locations, and the 
relationship between that information and the crypto key tables database 
needs to be defined. How are they coordinated? Which takes precedence 
when they differ?

3) this doc has no relationship per se to the Gatekeeper in the KARP 
TCP-AO KMP approach

The Gatekeeper is a mechanism introduced in KARP TCP-AO KMP to enable 
the use of IKEv2 with TCP-AO without changing either protocol (the only 
mods are new codepoints and extensions as IKEv2 already supports).

It may or may not make sense to think of the ways in which IKEv2, the 
Gatekeeper, and TCP-AO manage keying material in terms of crypto-tables. 
If not, that is IMO a deficiency of this new, artificial view of the 
crypto-keytables document.

IMO there is no rationale for crypto-keytables as the single viable 
approach to KARP, and I continue to see crypto-keytables as irrelevant 
except in broad principles (e.g., as a user or network manager API).

----

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Mar 2012 11:09:35 +0300

> 1) I don't see the need for this doc at all

I disagree. All of the IKEv2 KARP documents are missing one
fundamental module, and I do think karp-crypt-tables do cover one
piece of architecture which is needed.

In following example I will be using (simplified) IPsec architecture
terms, as there we have all this defined.

In the IPsec architecture (RFC4301) we have 3 main database to store
information (ignoring the caching and decorrelation).

- SPD - Security Policy Database
- SAD - Security Association Database
- PAD - Peer Authorization Database

The PAD is the database needed by the IKEv2. It contains the IKEv2
related information like what identities to use, what kind of
authorization data to use (shared keys, private/public key pairs etc).

Currently none of the documents really describe where this database
is. It seems some documents assume that it is inside the IKEv2 module,
but in practice if we want to reuse code from IPsec IKEv2
implementations this is not true. Quite often the PAD is part of the
policymanagement module if the IPsec, and is linked together with
actual configuration and SPD and so on.

PAD is not really some kind of basic configuration that can fully be
given to the IKEv2 library when you start. You do want to give
pointers to it when you initiate new negotiation. I.e. when you
trigger new security association you most likely already know the SPD
and PAD entries associated to it, so you give them to IKEv2, but when
you are responding to the security association being created from the
other end you usually do lookups to the database when you get more
information, i.e initially you lookup what IKE SA algorithms to use
based on the IP-address, then when you know the identity of the other
end you decide what identity you are going to being using and what
kind of authorization credentials you use etc. Because of this tight
coupling with the configuration this database is not normally part of
IKEv2 library, but reside outside of it.

The SPD describes the policy we are going to be using for the traffic,
and the SAD describes the actual keying material and instantiated
policy based on the SPD.

All of those database are described in the RFC4301, which means that
as we are not using IPsec architecture we need to describe something
similar in our KARP use.

Crypto key tables draft describes what I have understood is
replacemend of the SAD. I.e. it is the database the KMP (in this case
IKEv2) fills in and which is used by the actual transport protocol
(TCP-AO instead of AH/ESP).

What we are missing in the KARP is the SPD and PAD. SPD can be quite
simple, but for PAD we need to support about the same what is
described in the section 4.4.3 of the RFC4301. This is about the
minimal information needed for IKEv2.

This PAD information quite often do come from different sources. I
would expect that each routing protocol to configure their own peers,
and peers authentication credentials, so that mean the PAD is not
coming from just single source, but we need to merge data from the
multiple sources to one consistent database used by the IKEv2.

How this is done is also missing in the architecture. I.e. how do the
routing protocols push their configuration to the PAD.

In (at least in some) IPsec implementations the databases are taken
care of the policy manager module, which takes events from the below
(trigger, rekey, expire), does policy lookup (finds associated SPD and
PAD entries), kicks the IKEv2 process forward, waits for it to finish,
gets the keys from the IKEv2, and pushes them down to SAD and to the
actual traffic encryption module. The same module also gets events
from the IKEv2, i.e when new connection comes to the IKEv2 server,
this policy manager module will then decide whether it is allowed,
which kind of configuration is used by the IKEv2 when it is replying
to the packets and when the incoming connection is done, it will again
push the keys from the IKEv2 down to SAD. There is still one more
event source, naming the configuration changes. I.e. when the
configuration is changed (for example a peer is removed from the PAD),
new configuration is pushed to this module, and it will then verify
that all currently active SAs are still allowed by the new policy and
will tear down those which are not allowed anymore.

When I was reading the draft-chunduri-karp-using-ikev2-with-tcp-ao I
assumed this gatekeeper module is almost the same than what we have in
the IPsec in the policy manager module. What bit suprised me was that
when I was talking about the draft, I found out that PAD was not
supposed to be part of gatekeeper, and I think that is mistake.

So I think the proper KARP architecture should be something like this:

                   +----------+   +----------+
                   | Routing  |   | Routing  |
                   | protocol |   | protocol |
                   +----------+   +----------+
                        |              /
                        |       ______/
                        |      /
     +-------+     +--------------+     +--------+
     | PAD   |-----| Gatekeeper   |-----| IKEv2  | 
     +-------+     +--------------+     +--------+
                       /    \   \
     +---------+      /      \   \_____________
     | Policy  |-----/        \                \
     +---------+         +----------+       +---------+
                         | Crypto   |-------| TCP-AO  |
                         | table    |       +---------+
                         +----------+

Routing protocols push configuration to gatekeeper, who stores it to
PAD and to policy database. IKEv2 talk to the Gatekeeper and fetches
that configuration data through it and creates keys, which Gatekeeper
then pushes to the crypto table. TCP-AO would then fetch the keys from
crypto table and use them. It could also be that TCP-AO talks directly
to the Gatekeeper and asks keys from there, and then gatekeeper would
be fetching them from the crypto table (SAD). 

I see crypto table more or less like conceptional database telling
what kind of format the SAD needs to have. I do not really expect it
to be real text-file on any real systems, it might be actual database
on some environments, but quite often it can be just memory database
inside the gatekeeper. The reason for crypto table is that in some
environments we might have both gatekeeper and some other policy
manager module pushing keys there (i.e. if someone later defines a way
to use some other KMP which have very different view to things than
IKEv2/Gatekeeper). Another reason might be that there might be some
other users reading the crypto table than TCP-AO, i.e. someone might
want to use some other security mechanisms to protect routing data. 
-- 
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 30 Mar 2012 06:08:34 -0400

Hi Tero,

I understood the PAD requirement for IKEv2, yes, this is not captured in the current version. As we discussed, this is bit orthogonal to the crypto key tables we are talking about here.

I will come back on this but, I want to quickly submit

"Routing protocols push configuration to gatekeeper, who stores it to PAD and to policy database. IKEv2 talk to the Gatekeeper and fetches that configuration data through it and creates keys, which Gatekeeper then pushes to the crypto table. TCP-AO would then fetch the keys from crypto table and use them. It could also be that TCP-AO talks directly to the Gatekeeper and asks keys from there, and then gatekeeper would be fetching them from the crypto table (SAD).  "

TCP-AO doesn't fetch the keys from crypto tables. Gatekeeper populates the same to AO, in the form required by AO (MKTs). So in that sense, crypto tables are not quite SADs. In IPSec you consult SAD to protect the traffic but TCP-AO don't consult an external entity like crypto-key-tables (it lkup rather MKTs). So, I didn't quite understand Section 3 of draft-ietf-karp-crypto-tables where it describes key selection to protect the eventual data (this is inside AO not outside).

-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Friday, March 30, 2012 1:10 AM
To: Joe Touch
Cc: Sam Hartman; [email-masked]
Subject: Re: [karp] Comments on draft-ietf-karp-crypto-tables

> 1) I don't see the need for this doc at all

I disagree. All of the IKEv2 KARP documents are missing one fundamental module, and I do think karp-crypt-tables do cover one piece of architecture which is needed.

In following example I will be using (simplified) IPsec architecture terms, as there we have all this defined.

In the IPsec architecture (RFC4301) we have 3 main database to store information (ignoring the caching and decorrelation).

The PAD is the database needed by the IKEv2. It contains the IKEv2 related information like what identities to use, what kind of authorization data to use (shared keys, private/public key pairs etc).

Currently none of the documents really describe where this database is. It seems some documents assume that it is inside the IKEv2 module, but in practice if we want to reuse code from IPsec IKEv2 implementations this is not true. Quite often the PAD is part of the policymanagement module if the IPsec, and is linked together with actual configuration and SPD and so on.

PAD is not really some kind of basic configuration that can fully be given to the IKEv2 library when you start. You do want to give pointers to it when you initiate new negotiation. I.e. when you trigger new security association you most likely already know the SPD and PAD entries associated to it, so you give them to IKEv2, but when you are responding to the security association being created from the other end you usually do lookups to the database when you get more information, i.e initially you lookup what IKE SA algorithms to use based on the IP-address, then when you know the identity of the other end you decide what identity you are going to being using and what kind of authorization credentials you use etc. Because of this tight coupling with the configuration this database is not normally part of
IKEv2 library, but reside outside of it.

The SPD describes the policy we are going to be using for the traffic, and the SAD describes the actual keying material and instantiated policy based on the SPD.

All of those database are described in the RFC4301, which means that as we are not using IPsec architecture we need to describe something similar in our KARP use.

Crypto key tables draft describes what I have understood is replacemend of the SAD. I.e. it is the database the KMP (in this case
IKEv2) fills in and which is used by the actual transport protocol (TCP-AO instead of AH/ESP).

What we are missing in the KARP is the SPD and PAD. SPD can be quite simple, but for PAD we need to support about the same what is described in the section 4.4.3 of the RFC4301. This is about the minimal information needed for IKEv2.

This PAD information quite often do come from different sources. I would expect that each routing protocol to configure their own peers, and peers authentication credentials, so that mean the PAD is not coming from just single source, but we need to merge data from the multiple sources to one consistent database used by the IKEv2.

How this is done is also missing in the architecture. I.e. how do the routing protocols push their configuration to the PAD.

In (at least in some) IPsec implementations the databases are taken care of the policy manager module, which takes events from the below (trigger, rekey, expire), does policy lookup (finds associated SPD and PAD entries), kicks the IKEv2 process forward, waits for it to finish, gets the keys from the IKEv2, and pushes them down to SAD and to the actual traffic encryption module. The same module also gets events from the IKEv2, i.e when new connection comes to the IKEv2 server, this policy manager module will then decide whether it is allowed, which kind of configuration is used by the IKEv2 when it is replying to the packets and when the incoming connection is done, it will again push the keys from the IKEv2 down to SAD. There is still one more event source, naming the configuration changes. I.e. when the configuration is changed (for example a peer is removed from the PAD), new configuration is pushed to this module, and it will then verify that all currently active SAs are still allowed by the new policy and will tear down those which are not allowed anymore.

When I was reading the draft-chunduri-karp-using-ikev2-with-tcp-ao I assumed this gatekeeper module is almost the same than what we have in the IPsec in the policy manager module. What bit suprised me was that when I was talking about the draft, I found out that PAD was not supposed to be part of gatekeeper, and I think that is mistake.

Routing protocols push configuration to gatekeeper, who stores it to PAD and to policy database. IKEv2 talk to the Gatekeeper and fetches that configuration data through it and creates keys, which Gatekeeper then pushes to the crypto table. TCP-AO would then fetch the keys from crypto table and use them. It could also be that TCP-AO talks directly to the Gatekeeper and asks keys from there, and then gatekeeper would be fetching them from the crypto table (SAD). 

I see crypto table more or less like conceptional database telling what kind of format the SAD needs to have. I do not really expect it to be real text-file on any real systems, it might be actual database on some environments, but quite often it can be just memory database inside the gatekeeper. The reason for crypto table is that in some environments we might have both gatekeeper and some other policy manager module pushing keys there (i.e. if someone later defines a way to use some other KMP which have very different view to things than IKEv2/Gatekeeper). Another reason might be that there might be some other users reading the crypto table than TCP-AO, i.e. someone might want to use some other security mechanisms to protect routing data. 
--
[email-masked]
_______________________________________________
karp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/karp

---

From: Joe Touch <[email-masked]>
Date: Fri, 30 Mar 2012 05:58:30 -0700

Hi, Tero,

See below. Perhaps we can resolve this by explaining the Gatekeeper as 
the coordinator of the interpretation of keying info between a variety 
of protocols, not just TCP-AO and IKEv2 -- which is fine with me.

However, we do need to make sure we explain this in a way that allows 
protocols like TCP-AO to be used without modification, since that 
shouldn't be necessary. In specific, TCP-AO gets keys inserted from the 
outside (user or KMP), and consults its own internal tables only. That 
must not change in this approach IMO.

Joe

> piece of architecture which is needed.

Cutting down to IMO the key parts of your note:

...
> - PAD - Peer Authorization Database
...
> is....
...
> given to the IKEv2 library when you start....  Because of this tight
...
> as we are not using IPsec architecture we need to describe something

IMO, we need to allow KARP solutions to describe how their keys are 
managed. I don't see the need for KARP to define this outside of a solution.

> What we are missing in the KARP is the SPD and PAD. ...

The location of the SAD, SPD, and PAD are specific to a particular 
approach, and need to be explained in a given solution.

> This PAD information quite often do come from different sources....

But it can also be in different locations based on the particular 
solution being deployed.

> I

That's an interface implementation issue, not a protocol issue.

...
> So I think the proper KARP architecture should be something like this:

The Gatekeeper in KARP TCP-AO KMP is solely an interface between TCP-AO 
and IKEv2.

TCP-AO has no interface to a "crypto-table" module. Its information is 
specific to TCP protection, and doesn't make sense to integrate (nor is 
it necessary).

If you can draw this diagram without a link from the crypto-table to 
TCP-AO, then that might work.

> crypto table and use them.

TCP-AO doesn't "fetch" anything. MKTs are installed into TCP-AO either 
directly by the user (manual keying) or by a KMP. That's why I would say 
that (according to your diagram), the Gatekeeper fetches keying 
information from the crypto tables and inserts them into TCP-AO at best.

Does that work for you?

> It could also be that TCP-AO talks directly

TCP-AO doesn't ask for keys. It has them added from the outside. There's 
no trigger in TCP-AO to ask for a key, nor should there be according to 
its architecture.

> what kind of format the SAD needs to have

That's fine, if the above interpretation works IMO...

. I do not really expect it
> want to use some other security mechanisms to protect routing data.

Again, if you say "there might be some other users reading the crypto 
table than the Gatekeeper", that's consistent with TCP-AO's design. 
TCP-AO doesn't read external tables; it defines its own internal ones.

----