Map Server to ETR security has no automated key management

[hartmans-ietf@…]

Brian Weis made a proposal to address part of #2 and to replace the
use of IPsec with a per-message MAC. That proposal was adopted and
the question of whether to use automated key management is being split
out into a separate issue.

From a 21 September 2009 message to the list from Sam Hartman acting as co-chair:

I'm very concerned about the idea of publishing a LISP spec without a
mechanism for mandatory-to-implement automated key management.

I understand you are familiar with the issues here, but I'd like to
educate the rest of the working group.

RFC 4107 describes the IETF's consensus requirements on when automated
key management is required.

First, automated key management does not mean we need to have a PKI or
even use public key operations. Generally, we would choose a protocol
that had these options available, although we might not make them
mandatory to implement.

for example we could use a key management protocol that used shared
secrets as the basis for automated key management.

Vendors whose customers requested the option might implement public
key base functionality. For example, if a service provider is keying
LISP CPE equipment at some central facility for shipment to customers,
they would likely prefer to use certificates rather than shared
secrets. We see this a lot in the cable modem space and this is the
model behind CAPWAP's security.

However we could make the shared secret variant of our key management
protocol the mandatory to implement version.

Automated key management would give us several advantages. It would
provide us replay protection and liveness detection.

Section 2.1 of RFC 4107 describes conditions under which automated key
management is required. There are some tradeoffs involved there, and
we as a community over a number of meetings decided where we'd draw
the bar.

However the wording is not as clear as it could be. I believe that

there is one case that explicitly forces us into requiring automated
key management.

The likely operational environment is one where personnel (or
device) turnover is frequent, causing frequent change of the
short-term session key.

As I understood it when I was making these sorts of decisions on
behalf of the IESG, an environment where systems exist for a long time
in different organizations is likely to be such an operational
environment. It seems likely that the map server will be in a
different organization than the ETR and that over the lifetime of some
of the keys involved we might have significant staff turnover.

Also, another requirement while it does not directly apply to us hints at a general condition that does apply:

A party will have to manage n^{2 static keys, where n may become
large.}

(I actually wonder whether that text is misworded; I'm having trouble
designing a protocol where one party has to manage n^{2 keys).}

A map server might well need to manage thousands of associations as
Dino pointed out. This argues (although perhaps not of itself
compels) automated key management.

I think there is general agreement in the security community (although
perhaps not in the routing community) that if our routing protocols
were designed today they would need automated key management. For a
variety of reasons we have not placed this requirement. One reason is
that routing protocols don't fit the requirements of our existing key
management solutions. In the case of OSPF, ISIS and other multicast
protocols, the gap is huge. In the case of some other protocols, it's
less clear how big the gap is.

However, it seems very likely to me that the map server falls within
the requirement space of a number of existing key management
protocols. These protocols have definitely been implemented in the
control planes of high-end routers as well as on low-end CPE
equipment. In several cases we have strong evidence that protocols
can meet any possible performance requirements for map servers.

So, I think that if we choose to specify and implement automated key
management we could do so. I don't think we have a good justification
to wait for KMART.

At the end of the process, the chair submitting the draft (probably me
for the core and ms specs) does a technical and process review of the
documents.

If we choose not to specify and implement automated key management, we
must justify our choice in the security considerations section.
Obviously, I'll read whatever we write, but at this moment I'm unable
to imagine text so compelling that I'd be able to recommend
publication of the specifications without automated key management.

Another question that is probably on everyone's mind: we're writing
experimental documents; do we have to do this for experimental.
Darrel, Jari and I had a great conversation on what it meant for us to
be writing experimental documents. We want to use the experimental
out when there's some reason why we don't have enough information to
specify something or why we need to do additional experiments, not
simply to get done faster or to avoid coming to consensus on a
difficult issue. I cannot imagine anything about automated key
management for LISP that would fall into this category.

Sam Hartman
LISP Co-chair

[luigi@…]

Reply sent by Vince Fuller:

• Outside of the scope of the current document and explicitly stated in section 7 (Security Considerations) as a subject for future work.

Note: ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated.

[terry.manderson@…]

The requirement for automated key management in an experimental draft has been raised with the INT and SEC ADs.

The chairs believe that this is an item for future work.

This item will be updated after a response comes from the ADs.

[jmh@…]

After discussion with the security folks, the current plan is to add material in the front (probably in the introduction) emphasizing the experimental nature of the work and noting that there are security issues which will need significant future attention in the event of a desire to take this to the standards track. That wording will need to be checked with the WG and the authors of course.