Subject: Re: [karp] Classes of Key Management

From: "Michael Barnes" <[email-masked]>
Date: Wed, 01 Sep 2010 10:32:02 -0700

I agree with Bill. I know some protocols will require an out-of-band KMP and
there will be a desire from implementers to make use of that KMP for multiple
routing protocols akin to how they make use of BFD.

Regards,
Michael

------ Original Message ------
Received: Tue, 31 Aug 2010 01:52:27 PM PDT
From: Bill Atwood <[email-masked]>
To: [email-masked]
Subject: Re: [karp] Classes of Key Management

> 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:
> > Hi, Ran,
> >
> > On 8/31/2010 1:33 PM, RJ Atkinson wrote:
> >>
> >> On 31  Aug 2010, at 16:15 , Joe Touch wrote:
> >>> On 8/31/2010 12:18 PM, RJ Atkinson wrote:
> >>>>
> >>>> 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
> >>> ...
> >>>> 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.
> >>
> >> 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.
> >
> > AOK - that helps. The titles of the three might benefit from a bit of
> > refinement, but the context is useful.
> >
> > Joe
> > _______________________________________________
> > 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
>
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp