Subject: [karp] Relationship between RPs and Key management

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2010 16:25:42 -0500

Several design teams have been tasked with getting starting documents 
put together for this working group.  (We hope that the WG status will 
become final next week.)

In the course of those discussions, issues arise.
In this, and some other messages over the next several days I am going 
to try to paraphrase an issue, so as to get input and discussion from 
the WG as a whole.  Apologies if I mangle the issue in translation.

The issue for this mail is the relationship between routing protocols 
and key management / generation / storage.

One of the long term goals of this working group is to enable automated 
key management, automated smooth rekeying, and clean key storage and 
handling.  One aspect of this is taht for many of the protocols there is 
likely to be a notion of a master key, and key generation.
The quesiton is how aware of this the routing protocols should be.  One 
can imagine several choices.  In the extremes:
1) The coordinated generation of new keys is negotiated and managed by 
the routing protocol itself
2) The routing protocol is completely oblivious to how keys get 
generated, and just managed a smooth transition from one key to another, 
completely unaware of any key generation mechanism.

This is related to the point, which I think is non-controversial, that 
to the degree we describe a key store, that key store should be agnostic 
to the mechanisms use to generate keys (up to and including manual 
provisioning.)

Rotten tomatoes are now invited.
(Even better would be useful comments.)
Joel

---

From: Bill Atwood <[email-masked]>
Date: Thu, 11 Feb 2010 16:54:49 -0500

My answer has to be, "all of the below".  To illustrate:

PIM-SM:
In our work on implementing link-local security for PIM-SM (based on
draft-ietf-pim-sm-linklocal, now in the RFC Editor queue), it has become
clear that PIM-SM has no need to know anything about IPsec, or Keys, or
Security Associations.  The two implementations that we have done (using
a software router on a Linux box, and using some hardware routers) have
been implemented by entering IPsec commands.  We have not had to touch
the routing code at all.  As a result, it is _possible_ for secure
PIM-SM to function with no knowledge of security issues such as key
generation.

OSPFv3:
In OSPFv3, certain virtual interfaces are created.  In RFC 4552
(link-local security for OSPF v3), the Security Associations
corresponding to these interfaces have to be established dynamically by
the routing protocol.  While this does not imply that OSPFv3 needs to
know anything about the keys themselves (or how they are _generated_),
it does imply that the creation of an SA, and the resulting keys,
certainly needs to be _triggered_ by the routing protocol.  While this
is not "coordinated generation of new keys", it is equally not "complete
oblivion" either.

  Bill

Joel M. Halpern wrote:
> One of the long term goals of this working group is to enable
> automated key management, automated smooth rekeying, and clean key
> storage and handling.  One aspect of this is taht for many of the
> protocols there is likely to be a notion of a master key, and key
> generation.
> The quesiton is how aware of this the routing protocols should be. 
> One can imagine several choices.  In the extremes:
> generated, and just managed a smooth transition from one key to
> another, completely unaware of any key generation mechanism.
>
> to the degree we describe a key store, that key store should be
> agnostic to the mechanisms use to generate keys (up to and including
> manual provisioning.)
>
> _______________________________________________
> 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

---

From: "Thomas Hardjono" <[email-masked]>
Date: Thu, 11 Feb 2010 17:07:44 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joel
> M. Halpern
> Sent: Thursday, February 11, 2010 4:26 PM
> To: [email-masked]
> Subject: [karp] Relationship between RPs and Key management
> 

Hi Joel,

I guess your question generally could be re-casted as asking whether
management traffic should be in-band or out-of-band (OOB).
My understanding is today manageability platforms
primarily favor in the OOB way where the management console
uses a separate IP traffic (eg. TCP, HTTP) to the device/router.

In option (1) above, my understanding is that routers
have to do one thing fast (and its processors must not
be burdened with key gen, etc).

One related question is how automated is "automated".
If a key expires (about to expire) on a device/router,
does it (a) flag the IT admin and wait, (b) does it simply
generate a replacement key and update the key server,
(c) does it notify the key server who then generates a new key
and updates the device/router, etc. etc.

/thomas/
hardjono[at]mit.edu

---

From: Bill Atwood <[email-masked]>
Date: Thu, 11 Feb 2010 17:31:46 -0500

Inline, marked with <bill>.

> be burdened with key gen, etc).

<bill>  I believe that this is very important---all of the AAA work
seems to live under this design requirement.

> and updates the device/router, etc. etc.

<bill> There are some excellent opportunities for race conditions (and
deadlocks!) if we do not get this right.  Precise responsibilities will
have to be spelled out carefully.

  Bill

> hardjono[at]mit.edu

- --