Subject: [karp] Classes of Key Management

From: RJ Atkinson <[email-masked]>
Date: Tue, 31 Aug 2010 15:18:34 -0400

It seems to me that the range of possible approaches that this
WG might consider fall roughly into 3 classes, which I outline
below.

A) Out-of-band Key Management Protocol
	Create a new key management protocol or reuse an existing
	key management protocol (e.g. ISAKMP/IKE, Kerberos, GKMP) 
	by writing a "profile" on how to use that to manage keys
	for some application (e.g. RIPv2 Authentication). 

B) In-band Key Management extension to existing Protocol(s)
	Extend existing application protocols (e.g. RIPv2,
	IS-IS) to incorporate some key management mechanism
	inside the protocol itself.

C) Externalised Key Management
	In this model, which I think might be most practical
	for some large organisations, the organisation maintains
	a "Configuration Database" that includes various non-security
	configuration items for its routers and uses automated
	tools to 'push' updated configuration information out
	to the device(s) being managed and also automated tools
	to identify/repair any configuration errors.  NetConf
	is a candidate standards-track way to push and monitor
	such device configurations.  I'm told that a number of
	ISPs have proprietary/in-house tools for this.  I'm also
	told that Juniper's JunOScript is commonly used for this
	(at least for devices that support that mechanism).

The WG could take a single approach for all protocols within
scope, or might take different approaches for different protocols.

(I'll post some separate comments in a different note,
with a different Subject: line to try to keep threads
distinct.)

Yours,

Ran Atkinson

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Aug 2010 13:15:56 -0700

Hi, Ran,

> A) Out-of-band Key Management Protocol
...
> B) In-band Key Management extension to existing Protocol(s)
...
> C) Externalised Key Management

I'm not clear on the difference between A and C. A uses key management 
protocols developed by the security community. C uses key management 
based on general-purpose protocols, developed largely by the operational 
community. Otherwise, they're both out-of-band, both involve protocols, 
and both are automated.

What is the goal of distinguishing between the two? (i.e., if we agreed 
on that, perhaps there would be a better way of describing the difference)

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 31 Aug 2010 16:33:08 -0400

On 31  Aug 2010, at 16:15 , Joe Touch wrote:
> I'm not clear on the difference between A and C. A uses key management protocols developed by the security community. C uses key management based on general-purpose protocols, developed largely by the operational community. Otherwise, they're both out-of-band, both involve protocols, and both are automated.

There are multiple differences.  

* A will mean this WG has to do work defining either a new KM
  protocol or (one or more) profiles for existing KM protocols.

* C might not involve any work for this WG, as it simply involves
  reuse of existing configuration management technologies/practices.
  One could imagine the WG drafting an Informational RFC with some
  recommendations on how to deploy/operate NetConf to configure the
  routers, of course.

* A involves protocols designed primarily to do key management.
  C does not.  C involves protocols designed to do generic
  configuration management (e.g. NetConf).  For example,
  NetConf does not itself have any security mechanism.
  It can be deployed over SSH, which I believe is the IETF
  recommendation, but NetConf could be deployed without SSH.

* C might involve configuration management over a completely
  isolated network (often called an "out-of-band network"
  in the ISP community) from the network that the routers
  are providing services to.  Such a network often will have
  a total air gap between it and the network that the managed
  devices are providing services to.  Such configuration management
  might not involve any protocol, but instead might use some
  other form of computer automation (e.g. SQL->Tcl/Expect->serial
  console port of device to manage).

> What is the goal of distinguishing between the two? (i.e., if we agreed on that, perhaps there would be a better way of describing the difference)

(If you have some better terminology, that's OK, 
but *please* lets not wedge just over terminology. :-)

The fundamental is that the 3 categories have very different impacts 
on the work to be undertaken (or not undertaken) by the KARP WG.

Yours,

Ran

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Aug 2010 13:42:22 -0700

Hi, Ran,

> on the work to be undertaken (or not undertaken) by the KARP WG.

AOK - that helps. The titles of the three might benefit from a bit of 
refinement, but the context is useful.

Joe

---

From: Bill Atwood <[email-masked]>
Date: Tue, 31 Aug 2010 16:51:52 -0400

What I read from this is that the framework document needs to encompass
all three approaches, since:
1) I know that some protocols will need some form of protocol-centered
control (even if the key transport is not totally in-band)
2) I suspect that some operators will prefer integration of their key
management with their existing configuration management processes

  Bill

On 8/31/2010 4:42 PM, Joe Touch wrote:
>>> I'm not clear on the difference between A and C. A uses key
>>> management protocols developed by the security community. C uses key
>>> management based on general-purpose protocols, developed largely by
>>> the operational community. Otherwise, they're both out-of-band, both
>>> involve protocols, and both are automated.
>>
>>> What is the goal of distinguishing between the two? (i.e., if we
>>> agreed on that, perhaps there would be a better way of describing
>>> the difference)
>>
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8