Subject: [karp] draft-*-saag-*-keytable-*: KARP key table drafts

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Oct 2010 16:34:44 -0400

Dear Russ and Tim:

At the last IETF, Tim gave a presentation on your key table drafts.  I
raised the concern that I didn't think you had thought through the
multicast implications and I was uncomfortable adopting this direction
until we understood those implications.

After that meeting, a group of us got together to discuss multicast key
management for KARP. At that meeting, Dacheng Zhang and I agreed to
write up a protocol based on the design we came up with at the meeting.
Today I submitted draft-hartman-karp-rkmp-00.txt which contains our work
to date.

Not surprisingly as part of that work, I did have to come up to speed on
how the multicast group keying interacts with interfaces between router
protocols and the key management.

I do think there are some changes we should consider making to your
drafts, but I think they are rather small, so I'd like to express my
support for adopting these drafts.  I think that these drafts serve as
part of two key roles in KARP. Together with the framework, they will
help us understand the interface between the components we're
implementing. I think we still need to make some rounds of terminology
consistency and work through the issues Eric has brought up, but I think
all three drafts play a role.  On another side, I think that together
with draft-hartman-karp-ops-model the keytable drafts can provide the
basis of our operations and management work.

Here are areas where I think some change may be required for multicast:

1) I suspect that like previous IETF multicast key management protocols
we'll want to have a key encrypting key in our multicast key
management. This will provide for re-keying of the group without
peer-to-peer authentication for existing members. I think such KEKs will
need rows in the crypto table. So, if you're using key management for
OSPF, I suspect you'll need at least one row for the key that gets fed
into OSPF and one row for the KEK.  The architecture clearly supports
this.  If we get agreement that we're going to need this we should
probably add text to that affect.

2) Replay protection is going to influence the key tables for multicast
groups. At the mic last time, there was a animated discussion between
Gregory, Eric and myself about whether we can introduce nonces into the
routing protocols and have a separation between the long-term key and
the transport integrity key.  

Today, we have some fairly significant DOS issues because of replay
issues. Nodes reuse sequence numbers and may even restart their sequence
number counter from scratch across a reboot. An attacker can capture
replayed packets from long ago and when the sequence number decreases
introduce significant problems. Also, no facilities are provided for
sequence number wrap.

Clearly, some sort of nonce exchange and fresh transport integrity keys
would be a good solution to this.

However, if we cannot make these changes to the routing protocol,
multicast automated key management will play a critical role in managing
replay risk.  If this comes to pass, I think we'll need to have some way
to expire a key from the keytable if its sequence space wraps.  Also, I
think we'll need to have a way of indicating that a key in the keytable
should be dropped if we lose the sequence state for that key. For
example if we reboot and don't store sequence state across reboot, we
should drop any keys we had stored that we had actually used.

I believe this will have some minor implications for your drafts. I
think we should go through the multicast issues in some detail within
the WG before we'll be ready to make any changes here.

However, I think the above are all minor and the architecture does seem
like it will work for multicast.

I do have a few comments on the version of
draft-housley-saag-crypto-keytables that I read before IETF 78; I don't
think these require handling before adoption, but I would like to start
discussion. If they've already been addressed, my apologies.

1) The draft implies that the ASCII file format described would be a
good mechanism for loading keys.  I think this draft will work better as
something abstract.  I'd expect keys to be loaded through a vendor CLI,
through a Netconf module, or the like.  As discussed in
draft-hartman-karp-ops-model, there are some questions about the scope
and administrative interface that are significant for the management of
keys.

2) Both these documents and the KARP clarity lacked a certain
consistency around key derivation.  I think we need to develop some
terms to separate manually preshared transport integrity keys, other
forms of transport integrity keys, preshared authentication keys, and
master keys used for key derivation steps. We should be consistent in
our terminology and make sure we're all signed onto what keys are stored
where. I think your draft was internally consistent, but at least then,
I don't think the design guide, your drafts and the framework formed a
consistent picture.

3) I'd like to see if we could either get together or exchange email and
get the management discussions from draft-hartman-karp-ops-model to
align well with your drafts.  In that draft, we try and discuss where
operators would probably like to cover keys as well as how authorization
is somewhat dependent on authentication approach and some of the issues
looking at authorization. We need to make some significant updates to
draft-hartman-karp-ops-model based on review comments so it would be
best to have this discussion after the next version goes in.

Thanks for your consideration,

--Sam

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Oct 2010 10:17:39 -0400

Sam:

I hope that KARP will adopt draft-housley-saag-crypto-key-table as you
suggest.

> basis of our operations and management work.

Tim and I updated the draft-housley-saag-crypto-key-table.  I posted -04
on October 13th.  Tim and I went through a exercise to convince
ourselves that that the table would support a multicast protocol.  With
the help of Mike Shand, we tackled IS-IS.  We found that the previous
table could be made to work, but that the addition of an Interfaces
field made things easier to explain and thus probably easier to
implement in an interoperable fashion.

We also found places where we were not as clear as we could have been in
the earlier version.  Hopefully all of those places have been addressed too.

> probably add text to that affect.

I think that this can be supported with the existing table definition.
I'll need to review your document to make sure that we have the same
approach in mind.

> like it will work for multicast.

I agree that it would be desirable to expire keys based on sequence
space exhaustion.  However, we seem to have a disconnect on the
approach.  The table can contain a master key, and then using the KDF
and the KDF parameters, a new session key is derived when the sequence
space is exhausted.  The KDF parameters tell which things to include,
and in this way, we support protocols that can provide fresh nonces and
ones that cannot.

> and administrative interface that are significant for the management of

The group really needs to discuss this topic.  The point of ASCII is to
make it straight forward to handle in a CLI.  We do not go to the extent
of discussing delimiters and such, so from that point of view it is an
abstract description.  The point is that protocol designers can count on
these rows with these fields being available in the implementation.

> I don't think the design guide, your drafts and the framework formed a

I agree that terminology needs to be consistent across all of the KARP
documents.  The discussion above regarding KDF and nonces shows that we
are not there yet.

> best to have this discussion after the next version goes in.

I'd like to do get together in Beijing.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Oct 2010 10:45:58 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> I agree that it would be desirable to expire keys based on
    Russ> sequence space exhaustion.  However, we seem to have a
    Russ> disconnect on the approach.  The table can contain a master
    Russ> key, and then using the KDF and the KDF parameters, a new
    Russ> session key is derived when the sequence space is exhausted.
    Russ> The KDF parameters tell which things to include, and in this
    Russ> way, we support protocols that can provide fresh nonces and
    Russ> ones that cannot.

How would you invision this working without a nonce or the like?
You said you worked through IS-IS; I'm personally more familiar with
 OSPF but  can probably follow an IS-IS discussion.

Does IS-IS provide a nonce to use?

If not, exactly what happens when you run out of sequence space?

I'm not seeing an option better than someone in a group key management
role generates a new key and pushes it out to the group.

I don't understand how the KDF is useful unless the protocols have some
slot for KDF parameters to be expressed so the other side knows what
they are.  Also, for replay prevention, I think you need to have some
way to know that the parameters you received from the other side are
fresh.

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Oct 2010 12:03:18 -0400

> Does IS-IS provide a nonce to use?

No.

> If not, exactly what happens when you run out of sequence space?

The guidance we got on this point from Mike Shand is that the sequence
space is large enough that in practice it does not roll over.  If there
are experts that disagree, we need to hear from them.

> way to know that the parameters you received from the other side are

I understand these concerns, and Tim is doing the write-up for IS-IS.
We need to compare for OSPF.  I had to get a tutorial on IS-IS for the
work done to date.  I guess an OSPF tutorial is in my future.

Russ