Subject: Re: [karp] [kmart] Automated Key Management for Router Updates

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Tue, 27 Oct 2009 18:21:42 -0700

Bill,
Did you want to present this at the KARP BOF in Hiroshima? It is 
definitely related work in progress. Have you published this as an 
I-D yet? Better speak up now, as the agenda is solidifying quickly.

Gregory.

At 08:00 PM 7/23/2009, Bill Atwood wrote:
>Dear all,
>
>I have written a paper that outlines the requirements for the
>distributed key management part of the "kmart" roadmap, and proposes a
>distributed Key Server solution.  It has been accepted for
>publication/presentation at Emerging 2009 in Malta, October 11--16.
>
>A preprint of the paper can be accessed via
>http://users.encs.concordia.ca/~bill/papers/emerging2009-akm.html
>
>I welcome comments from any participant in the kmart mailing list (or
>anyone else!).
>
>   Bill Atwood
>
>--
>
>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
>_______________________________________________
>kmart mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kmart

---

From: William Atwood <[email-masked]>
Date: Tue, 27 Oct 2009 21:35:39 -0400

Gregory,

Yes, I would love to present it, but unfortunately I will not be at  
Hiroshima.  It's not in an Internet Draft yet, either.  Hopefully,  
someone will at least read the paper, and give me comments.  I will  
send Brian and Joel some notes on draft-ietf-pim-sm-linklocal and the  
AKM framework paper, which they can use at their discretion.

   Bill

Quoting "Gregory M. Lebovitz" <[email-masked]>:

> definitely related work in progress. Have you published this as an I-D
> yet? Better speak up now, as the agenda is solidifying quickly.
>
> Gregory.
>

-- 
Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
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://www.cse.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: "Thomas Hardjono" <[email-masked]>
Date: Wed, 28 Oct 2009 11:00:52 -0400

Bill, folks,

I read through the paper -- interesting use of GDOI. 

I'm kind of thinking that the KARP problem has multiple faces/phases
(similar if not identical to the NIST 800-57 lifecycle):

(a) Initialization phase, where all the entities (routers) somehow obtains
the relevant keying material.

(b) Operational phases, where the routers use or exercise the keys.

(c) Maintenance phase, where security maintenance is performed (eg. backup
of keys, migration to new router, re-initialization, etc. etc).

(d) Decommissioning phase, where routers are taken off the network in a
graceful (and secure) way, and their keys logged elsewhere (for legal
purposes) and then nuked.

Many IT folks in medium to large Enterprises dislike having to install and
operate yet another management console (for another part or aspect of their
network and IT). So it would a good design goal for the KARP WG to allow the
resulting KARP protocol to be "integrate-able" to existing network
management consoles (read products) that implement device-management
protocols (eg. WS-Man, DMTF DASH/MASH, etc etc).  Some of these existing
protocols could be used for one or more of the phases above.

For key management specifically, perhaps the KARP WG could look at re-using
the Oasis KMIP work (Key Management Interoperability Protocol). Something
like a router-specific profile could be created. The KMIT spec already
support a number of key formats (packing format), as well as transport
methods.

Thoughts?

cheers,

/thomas/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> William Atwood
> Sent: Tuesday, October 27, 2009 9:36 PM
> To: Gregory M. Lebovitz
> Cc: [email-masked]
> Subject: Re: [karp] [kmart] Automated Key Management for Router Updates
> 
> Gregory,
> 
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

---

From: Brian Weis <[email-masked]>
Date: Wed, 28 Oct 2009 11:03:39 -0700

Hi Thomas,

> purposes) and then nuked.

That's a good overview of life cycle key management, and it might be a  
good topic for the OPSEC WG.

> support a number of key formats (packing format), as well as transport

Thanks for pointing out this work. A KARP WG (should it be formed)  
could consider the KMIP key when it begins work on automated key  
management. However, specifying the use of (or changes to) protocols  
developed outside of the IETF might be an issue. I'd welcome further  
thoughts on this once a WG is formed and thinking about automated key  
management.

Thanks,
Brian

>>> I-D
>>>> distributed key management part of the "kmart" roadmap, and  
>>>> proposes
>> a

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Thomas Hardjono" <[email-masked]>
Date: Thu, 29 Oct 2009 16:13:36 -0400

Hi Brian,

Comments inline.

> From: Brian Weis [mailto:[email-masked]]
> Sent: Wednesday, October 28, 2009 2:04 PM
> To: Thomas Hardjono
> Cc: 'William Atwood'; 'Gregory M. Lebovitz'; [email-masked]

Hi Brian,

I believe the IETF already has a Liaison agreement with Oasis. The IP rules
of both orgs are very similar.

The IEEE 1619.3 folks plan to produce a *profile* of KMIP specifically for
storage devices (e.g. storage controllers that have crypto). A "profile" in
Oasis language means a narrow-down and selection of various available
options. So the 1619.3 folks would be working in their own world and doing
their own approving of the resulting profile.

KARP could also adopt the same approach, preventing re-invention and
allowing interoperability of devices. Thus, if an Enterprise has a key
back-up service/server, it could received backup-blobs from storage devices,
routers, app servers and even clients (ie. agnostic to source of keys).

I think a number of vendors already have products that have some degree of
compatibility with KMIP. So its not just a spec, but actual product.

Just a thought.

cheers,

/thomas/