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

[Russ Housley <[e-mail]>]

Sam:

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

> 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.

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.

> 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.

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.

> 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 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.

> 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.

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.

> 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.

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.

> 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.

I'd like to do get together in Beijing.

Russ