Subject: Re: [karp] Classes of Key Management

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 13:26:12 -0400

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

I would strongly like to avoid that route.  I think it will be beyond my
capability at least (and I suspect beyond our combined capability) to
design a framework that is interoperable and that combines all three
approaches.

I agree that the approaches for key management I've seen discussed here
fall into linear combinations of the three approaches outlined.  For
those who are not already aware, there is some discussion of this.
There has been a lot of discussion of problems with in-bind at the mic
at IETF 77, and probably scattered throughout the design guide.

There's a section of the design guide that focuses on why the authors of
that document believe C should be out of scope.

So, an argument has been presented that we should limit ourselves to
out-of-band approaches.  I find myself in broad agreement with the
argument presented in the design guide about ruling C out of scope.  I
would prefer in-band approaches, although if the vendor constraints are
accurate then I think we're left with out-of-band approaches.

I disagree with Ran that no standards are required if we want to go down
the external key management approach.  In particular, we desire
interoperable key management.  So, I think we'd need to develop a
standardized netconf schema sufficient for us to perform key management.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 13:37:10 -0400

I have a question about whether it's possible to meet the requirements
for this WG using external key management.

How do you propose to handle inter-connection multicast replay detection
with external key management.

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Sep 2010 10:49:09 -0700

Hi, Sam,

> with external key management.

There are approaches that combine in-band with out-of-band. TCP-AO 
includes in-band mechanisms for key change coordination and session key 
derivation from shared endpoint keys, but relies on an external 
mechanism (protocol or manual methods) for managing the shared endpoint 
keys.

Is inter-connection multicast replay detection a similar case where an 
in-band mechanism is required, but can still use an out-of-band key 
distribution and revocation protocol/mechanism?

Joe

---

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 13:56:14 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> Hi, Sam,
    Joe> On 9/1/2010 10:37 AM, Sam Hartman wrote:
    >> I have a question about whether it's possible to meet the
    >> requirements for this WG using external key management.
    >> 
    >> How do you propose to handle inter-connection multicast replay
    >> detection with external key management.

    Joe> There are approaches that combine in-band with
    Joe> out-of-band. TCP-AO includes in-band mechanisms for key change
    Joe> coordination and session key derivation from shared endpoint
    Joe> keys, but relies on an external mechanism (protocol or manual
    Joe> methods) for managing the shared endpoint keys.

    Joe> Is inter-connection multicast replay detection a similar case
    Joe> where an in-band mechanism is required, but can still use an
    Joe> out-of-band key distribution and revocation protocol/mechanism?

I'm not aware of a solution that I would describe as external key
management that would meet this requirement.  I'm aware of solutions
that I'd describe as external+(in|out)-of-band that would meet this
requirement.