Subject: [karp] FW: comments on proposed KMART charter

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Sat, 17 Oct 2009 13:14:25 -0700

Hey Brian,
I got these at my juniper email address from David, and I wasn't sure 
if you had seen it on the mail list. I wanted to make sure everyone 
saw it, and that his feedback could be included in any up-coming 
charter revision, if not already in the most recent one.

Gregory.

>-----Original Message-----
>From: David McGrew [mailto:[email-masked]]
>Sent: Thursday, September 24, 2009 7:48 AM
>To: Gregory Lebovitz; [email-masked]
>Subject: comments on proposed KMART charter
>
>Hi Gregory,
>
>here are some comments on the proposed charter.  I think this is a 
>good start, but in general, it needs to be more specific; it leaves 
>open the questions of charter overlap with TCPM, whether IPsec 
>solutions are in scope, what exactly the goals of the framework are, 
>and what the goals of the KMP are.  Also, I don't see any discussion 
>about the establishment of long-term keys (public or secret) used in 
>authentication, and that strikes me as a crucial omission.  It would 
>be regrettable to have the working group succeed in defining how to 
>establish session keys but then see the work go unused due to the 
>lack of router-to-router authentication.
>
>Some detailed comments inline:
>
>
> > ===== BEGIN KMART-CHARTER-00 =====
> > This working group will focus on securing routing protocols' packets-
> > on-the-wire by the use of cryptographic authentication modern
> > cryptographic algorithms to provide
> >
> > In the March of 2006 the IAB held a workshop on the topic of "Unwanted
> > Internet Traffic".  The report from that workshop is documented in RFC
> > 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for
> > "[t]ightening the security of the core routing infrastructure."
> > Four main steps were identified for improving the security of the
> > routing infrastructure.  One of those steps was "securing the routing
> > protocols' packets on the wire."
> >
> > Four basic tactics may be employed in order to secure any piece of
> > data as it is transmitted over the wire: privacy (or encryption),
> > authentication, message integrity, and non-repudiation.
>
>Those tactics are really security services; I suggest calling them 
>that.  Many people prefer the term "confidentiality" to "privacy".
>
> > The goal of this WG is message authentication and packet integrity.
> > At present, this work explicitly excludes privacy and non-repudiation.
> >
> > Routing peer authentication and message integrity will be provided
> > through the use of per-packet cryptographic message authentication.
> > Peer authentication will protect against rogue peers, imposter peers,
> > and some denial of service (DoS) attacks aimed at routers.
>
>I understand the value of authentication in this context, but I do 
>not understand how authentication can possibly protect against rogue 
>peers.  I assume that a rogue peer is a trusted device that has been 
>subverted; what good does cryptographic authentication do in such a
>case?   I suggest that "rogue peers" be taken off the list, or
>clarified, if it means something other than what it seems.
>
> >
> >
> > Many different routing protocols exist and they employ a range of
> > different transport subsystems. Therefore there is no specific one-
> > size-fits-all authentication format that will work for all routing
> > protocols. Groups of routing protocols with similar transports will be
> > able to use the same authentication mechanism. Though there will be
> > multiple specific authentication mechanisms to meet the needs of the
> > various transport subsystems, we can create a common framework by
> > which interfaces and modules may be re-used across different routing
> > protocols.
>
>The above paragraph sounds reasonable, though it is lacking
>specifics.   I suggest adding an explicit list of routing protocols
>that are of interest.
>
>Also, what is an "authentication format"?   Does that mean
>"authentication mechanism, such as AH, TCP-AO, or an application-layer
>Message Authentication Code?"   I suggest clarifying.   Perhaps use
>"mechanism", which appears in the paragraph below, for consistency.
>
> >
> >
> > Many routing protocols (or groups of protocols) already have some
> > method for accomplishing cryptographic message authentication.  In
> > most cases the existing methods are dated, vulnerable to known attack,
> > and/or employ cryptographic algorithms that have been deprecated.
> > Internet security practices have progressed in the last 10 years when
> > many of the first generation routing authentication mechanisms were
> > created.
> > It is time to review and update those mechanisms to use modern
> > security practices.
> >
> >
>
>I agree with the gist here, but I suggest adding specific references.
>
>
> > MISSON & OBJECTIVES
> >
> > Misson:
> > Deliver specifications that empower an incrementally secure routing
> > infrastructure for the Internet by delivering cryptographic
> > authentication and message integrity for packets transmitted between
> > routing protocol peers.
>
>The term empower is vague; what all does it entail?  Analysis?
>Requirements?  Specifications for new protocols or systems?  BCPs on 
>use of existing protocols?
>
> >
> > Incremental Security:
> > Routing systems are highly tuned, having been refined by years of
> > operation for interoperability, scale and efficiency. Operators will
> > not deploy something too complex, something with too large a
> > perfomance impact or which they cannot readily characterize, nor
> > something too far removed from existing operational practices. The
> > "best" authentication for a group of routing protocols may not
> > always be reasonably deployable in one step. The WG will remain
> > sensitive to this dynamic. It will be cautious of over reaching, and
> > will strive for incremental security improvements rather than
> > perfection. "More is better than none" and "crawl, walk, run" are
> > guiding principles here.
>
>Nicely put.
>
> >
> >
> > It is possible for routing protocol packets to be transmitted
> > employing all four security tactics mentioned above using existing
> > standards.  For example, one could run unicast, layer 3 or above
> > routing protocol packets through an IPsec ESP [RFC4303] or AH
> > [RFC4304??]. encapsulation. However, routing products have been fine
> > tuned over the years for the specific processing necessary for these
> > routing protocols non-encapsulated formats.  Operators are,
> > therefore, quite unwilling to explore new packet encapsulations for
> > these tried and true routing protocols. Rather, operators have a
> > strong preference for authentication options in the routing
> > protocols instead of encapsulation. As stated previously, many
> > routing protocols already have existing mechanisms for cryptogrpahic
> > authentication.Products with these mechanisms have already been
> > produced, code has already been written and deployed, and both have
> > been optimized for the existing mechanisms.  Rather than turn away
> > from these mechanisms, we want to enhance them, updating them to
> > modern and secure levels.
>
>It is good to explicitly state that enhancements to app/transport
>layer authentication protocols are in scope, but this leaves open the
>question of what else is in scope.  Are IPsec-based proposals not in
>scope?
>
> >
> >
> > Work Blocks/Phases:
> > 1) Enahance Existing Mechanisms - The first step is to enhance the
> > routing protocols' (groups') authentication mechanism, ensuring it
> > employs modern cryptographic algorithms and methods for its basic
> > operational model.
>
>Isn't this already in scope for TCPM WG?   That sounds like serious
>charter overlap to me.  TCPM is producing "The TCP Authentication
>Option" and "Cryptographic Algorithms, Use, & Implementation
>Requirments for TCP Authentication Option".   Is the intent here to
>just support the TCP-AO work?
>
>
> > Ideally the updated mechanism will protect against as many threats
> > as possible. Many of the protocols' use manual keys currently, so
> > the first phase will focus on shoring up the manual key mechanisms
> > that exist.
> >
> >
> > 2) A framework (DOI?) will be defined for common elements and their
> > use, such that implementation on systems with many routing protocols
> > can easily re-use common structures and functions. The framework
> > will account for the future use of a key management protocol (KMP)
> > that can be layered onto a protocl's manual key mechanism.
>
>
>Item (1) aims to shore up manual keying; how does the framework for
>key management in (2) differ from that?   I suggest moving key
>management out of the original goal, or otherwise clarifying.
>
>I assume that "common elements" refers to keys, identifiers,
>cryptoperiods, and suchlike.  I suggest making this explicit.
>
>There are many different goals for key management, including the
>establishment of session keys from long-term keys, and the
>distribution of long-term keys.  IKE does the former, Kerberos and
>KEYPROV do the latter, and GDOI can do both.  Are both in scope?
>
> >
> > 3) Layer in KMP - The second work phase is to define the use of an
> > existing KMP (e.g. IKE) for generating keys and security association
> > parameters for use any routing protocol (group). It is hoped that a
> > general KMP framework -- or a small number of frameworks -- can be
> > defined and leveraged for many routing protcols (groups).
>
>Why does the charter assume IKE, which is solely point-to-point?   Are
>protocols that use multicast not in scope, or have a secondary status?
>
>Are protocols for the distribution of secret long-term keys in
>scope?   For example, would the use of KEYPROV, KMIP, Kerberos, or
>GDOI to distribute keys from a central server be in scope?   It is a
>sensible thing to consider for securing interior BGP, for example.
>
>In any case, long-term authentication belongs on the charter.  If
>there is an expectation that x.509 certificates can be used to provide
>it, then some mention should be added to the charter.   Issues like
>how certificates get issued and how CAs become trusted will be very
>important in this case.
>
>I get heartburn from the "small number of frameworks" statement - if
>there really are multiple frameworks, it seems the goals of generality
>and reusability that motivate a framework will never be met.
>
>
> >
> >
> >
> > SCOPE
> >
> > The scope of this roadmap of work includes:
> >
> > o  Making use of existing routing protocol security protocols, where
> >     they exist, and enhancing or updating them as necessary for
> > modern cryptographic best practices and expanded threat protection.
> >
> > o  Specifying authentication mechanisms in routing protocols where
> > they do not currently exist.
> >
> > o  Developing a framework that will be able to layer in use of KMP
> > in order to ease deployment, lower cost of operation, and allow for
> > rapid
> >     responses to security breaches, and
> >
> > o  Specifying the automated KMP that may be
> >     combined with the bits-on-the-wire mechanisms.
> >
> >
> > o  [List of routing protocols we will work on]. These are the
> > priorities at the moment. The WG may re-charter later to take on
> > additional protocols.
> >
> >
>
>Has the list of protocols been posted somewhere else?
>
>
> > OUT OF SCOPE
> >
> > o   Protection of route message content or payload.
>
>"confidentiality" is a good word to use here.
>
> >
> > -   Route orignation authorization (ROAs). This is being addressed
> > in SIDR WG.
> > -   Route path validation.
> > o   Route message privacy.
> > o   Authentication for anything but routing protcols.
> > o   [List of routing protocols we will not work on].  The WG may re-
> > charter later to address these, once current work items are completed.
> >
> >
> >
> >
> > SPECIFIC WORK ITEMS
> >
> > o  Grouping the routing protocols with like transports/requirements
> > o  Prioritize the the work of addressing the groups
> > o  General requirements document for cryptographic authentication of
> > routing protocols. This document will start with a threat model
> > which will then drive the requirements.
> > o Framework document describing the common elements for modern
> > authentication in routing protcols. This will include a framework
> > "manual" key modes for routing protocols, but done in a way that
> > allows for the future layering-on of an automated key management
> > protocol (KMP).
> > o  Security review of existing groups of routing protocols,
> > resulting in a requirements document for each protocol group
> > detailing what is needed to modernize (or provide) authentication
> > for that protocol group
> > o  Specification document for each routing protocol updating how
> > each will employ modern authentication.
> > o  General KMP usage - specification document(s) defining a KMP and
> > its use for generating keys and security association parameters for
> > any routing protocol (group).
> > o  Specification document for the use of KMP with each routing
> > protocol.
>
>This list provides more detail, which is great, but it still leaves
>open the questions of charter overlap with TCPM, whether IPsec
>solutions are in scope, what exactly the framework is, and what the
>goals of the KMP are.   Also, there ought to be some discussion about
>the establishment of long-term keys (public or secret) used in
>authentication.
>
>best,
>
>David
>
> >
> >
> > MILESTONES (TBD)
> >
> > TBD - BoF
> > TBD - WG formed
> > TBD - separate current roadmap document (a place holder document)
> > into General Framework, General Requirements, Priorities/Work-Plan
> > documents
> > TBD - Requirements document for each protocol group
> > TBD - Specification document for each protocol
> >
> >
> > WG LOCATION & OPERATION
> >
> > By suggestion of the Routing and Security AD's, this work will be
> > housed in the Routing Area, but will have an explicit Security Area
> > advisor assigned. In addition, members of the security community
> > will be recruited to participate in the truly cross-area WG effort.
> > This sort of authentication work has proven to be very tedious and
> > experience has shown it easily overwhelms a WG's available air time
> > for other topics (i.e. this topic can DoS a routing protocol's WG).
> > Therefore the AD's suggest that authentication work on the routing
> > protos (groups) will be done in one WG just for that purpose,
> > instead of in each routing protocol's WG themselves, but with
> > committed participation from that (those) routing protocols' working
> > groups' members, and with frequent status updates being liaised
> > between this WG and the protocols WGs.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m