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

From: Joe Touch <[email-masked]>
Date: Fri, 06 Apr 2012 13:16:08 -0700

Hi, all,

I had an extended discussion with Sam Hartman yesterday, and wanted to 
convey the results of that:

On 3/30/2012 5:58 AM, Joe Touch wrote:
> 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.

This is consistent with the phonecall I had.

When we talk about "the Gatekeeper", I keep referring to that term as I 
introduced it in the TCP-AO KMP doc. However, I don't care/mind if that 
is more generally a translator between various protocols to exchange 
key/configuration material and various protocols to secure routing 
information.

It's also fine for this new, more general Gatekeeper to have its own 
tables of key/configuration material - AFAICT, this is what is meant by 
"keytables". IMO, however, it's not necessary that the security 
protocols directly consult those keytables - IMO, it's the 
responsibility of the Gatekeeper to install/manage/maintain that 
material and convey it to the security protocols.

The TCP-AO KMP doc focuses on ways to use the Gatekeeper to integrate 
IKEv2 with new registry entries and/or message types with TCP-AO. If it 
turns out that it's preferable to modify IKEv2 to be more specific about 
a new class of exchanges focused on routing protocols, that's fine to me.

I hope that helps. I'm glad to provide continued feedback on the 
possible more general use of the Gatekeeper to integrate key management 
across multiple protocols, although I expect someone else would lead that.

Joe

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 24 Apr 2012 20:30:49 -0400

Hi Joe,
I need more clarity on the discussion you folks had, in particular on new exchanges required by IKEv2 below.

====
		When we talk about "the Gatekeeper", I keep referring to that term as I introduced it 
            in the TCP-AO KMP doc. However, I don't care/mind if that is more generally a translator 
            between various protocols to exchange key/configuration material and various protocols to 
            secure routing information.
[Uma]: Sure.

		It's also fine for this new, more general Gatekeeper to have its own tables of 
            key/configuration material - AFAICT, this is what is meant by "keytables". 

[Uma]: I see Keytables as defined in (http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/?include_text=1),
       defines 
           a. place holder for negotiated Keys and parameters (either through KMP or manually)
           b. Provides a key selection mechanism
       Configuration (relevant to both AO and KMP) to help negotiation with KMPs, SA management and key triggers are done by Gatekeeper. 
       Currently, http://datatracker.ietf.org/doc/draft-chunduri-karp-using-ikev2-with-tcp-ao/ doesn't refer key-tables as it specifies 
       even "a." as integral part of Gatekeeper and doesn't talk about "b." as it is not needed.
       So to be compliant with keytables draft, negotiated keys and associates parameters should be abstracted from the
       Gatekeeper (please se my specific comments on key tables draft). This is TBD.

	IMO, however, it's not necessary that the security protocols directly consult those keytables - IMO, it's the responsibility 
      of the Gatekeeper to install/manage/maintain that material and convey it to the security protocols.

[Uma]: Sure. 

	The TCP-AO KMP doc focuses on ways to use the Gatekeeper to integrate IKEv2 with new registry entries and/or message 
      types with TCP-AO. If it turns out that it's preferable to modify IKEv2 to be more specific about a new class of exchanges 
      focused on routing protocols, that's fine to me.

[Uma]: IKEv2 today defines IKE_SA_INIT, IKE_AUTH and CREATE_CHILD_SA exchange. I really don't see any need for defining new 
       class of exchanges TCP based routing protocol SA apart from changes in SA payload 
      (in IKE_AUTH and to re-key with CREATE_CHILD_SA). I would like to hear why Sam thinks new exchanges are required.

--
Uma C.

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Apr 2012 15:36:56 -0700

Hi, Uma,

>         Gatekeeper (please se my specific comments on key tables draft). This is TBD.

Agreed.

>        (in IKE_AUTH and to re-key with CREATE_CHILD_SA). I would like to hear why Sam thinks new exchanges are required.

FYI, when I talked about new message types I was thinking more about SA 
payload changes or extensions. I don't know why another class of 
exchanges is useful, but AFAICT that decision is independent of this 
architecture.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Apr 2012 09:39:47 -0400

After my discussion with Joe, I agree that security protocols need not
directly consult the key tables.
I think we can reflect that in the next version.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 26 Apr 2012 13:43:35 -0400

After my discussion with Joe, I agree that security protocols need not directly 
      consult the key tables. I think we can reflect that in the next version.

Thx. As I detailed in the other thread, in the similar lines, it's logical to separate the key tables for RPs 
which  use security protocols and don't use security protocols to secure the packets/PDUs. This is important as the 
properties and characteristics  of these 2 categories are vastly different.  IMO, this separation allows 
	1. to relate and refer the key tables easily by other protocol/KMP drafts and also
	2. allows other RPs which don't use sec. protocols to consult key tables to secure the PDUs.
		
--
Uma C.