Subject: [karp] OASIS Key Management

From: Vishwas Manral <[email-masked]>
Date: Tue, 23 Mar 2010 17:01:01 -0700

Hi,

I guess in the KARP meeting there was a reference to the OASIS Key
management. I found the following link regarding the same:

http://www.oasis-open.org/committees/documents.php?wg_abbrev=ekmi

Thanks,
Vishwas

---

From: Sean Turner <[email-masked]>
Date: Tue, 23 Mar 2010 19:34:07 -0700

There is also the Key Management Interoperability Protocol (KMIP) TC:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip

spt

Vishwas Manral wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 25 Mar 2010 13:34:39 -0700

Sean/Vishwas/others -

Rather than just a simple pointer, could someone provide a little
description of these KMPs respectively? And for each, why you think they
should be considered for the KARP KMP? It's applicability to the various
routing protocols (families/categories) that are in our charter and in the
design-guide document? I.e. could someone try to champion and argue for why
a protocol ought to be considered?

I think this will help the WG quite a bit,
Gregory

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: "Thomas Hardjono" <[email-masked]>
Date: Thu, 25 Mar 2010 21:10:45 -0400

Gregory,

It would be useful for KARP WG to consider the scenario where key management
messages/transactions are Out-Of-Band (OOB) and separated from routing
messages. It simplifies the picture quite a bit.

That is, for each routing domain/area there could be one (or more) key
server that speaks 1-to-1 unicast with each router and performs the
necessary KM lifecycle (eg. back-up key, replace key, nuke key, revoke cert,
install CA cert (TAMP), migrate key, shutdown router, etc etc). All of this
done in the background without affecting any routing-specific
updates/messages.

There should be one (1) OOB key management protocol only, regardless of the
type of router and routing protocol. An OSPF box, a PIM box, a RIP box,
could all speak OOB unicast to the Key Server. Nothing to do with the
routing protocol.

The IEEE1619.3 folks used the notion of a crypto module (KeyStore?) inside
the storage device. I believe its reasonable and realistic to see crypto
modules inside routers in the future. This is also what the TAMP protocol
assumes exists within the target device. (Really, if a $50K box cannot even
afford to include a $20 tamper-resistant hardware then the routing vendors
are really not doing their best for their customers).

(PS. Is the KARP KeyStore assumed to be a crypto module?)

Furthermore, there needs to be a manageability interface defined that allows
the Network Admin (human) to remotely configure both the Key Server and
routers (from the net console) according to the security policy define for
the org.

/thomas/

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gregory Lebovitz
Sent: Thursday, March 25, 2010 4:35 PM
To: Sean Turner
Cc: [email-masked]
Subject: Re: [karp] OASIS Key Management

Sean/Vishwas/others -

Gregory

spt

Vishwas Manral wrote:

Hi,

Thanks,
Vishwas

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks