Subject: [lisp] #25: Map Server to ETR security has no automated key management

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 08 Dec 2009 11:04:50 -0000

#25: Map Server to ETR security has no automated key management
----------------------------------+-----------------------------------------
Reporter:  hartmans-ietf@…        |       Owner:     
    Type:  technical              |      Status:  new
Priority:  major                  |   Component:  ms 
Severity:  -                      |    Keywords:     
----------------------------------+-----------------------------------------
 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

-- 
Ticket URL: <http://tools.ietf.org/wg/lisp/trac/ticket/25>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues