Subject: [karp] Fwd: RE: [kmart] Draft Charter for KMART BoF

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Wed, 04 Nov 2009 10:27:56 -0800

Thomas,
Thanks for the review.  I just re-read this and realized that Brian 
Weis was not on the "To:", though he may have picked it up via the 
kmart (now defunct, replaced by KARP) list. Brian is updating the 
charter going forward, as part of the role of chairing the BoF. I 
just want to make sure Brian saw it when he did his charter re-write. 
Can you confirm that, Brian?

Comments below...

>From: "Thomas Hardjono" <[email-masked]>
>To: "'Gregory M. Lebovitz'" <[email-masked]>,
>         <[email-masked]>,
>         "'Adrian Farrel'" <[email-masked]>
>References: <[email-masked]>
>In-Reply-To: <[email-masked]>
>Subject: RE: [kmart] Draft Charter for KMART BoF
>Date: Tue, 8 Sep 2009 16:39:20 -0400
>
>Hi Gregory,
>
>Comments in-line below.
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Gregory M. Lebovitz
> > Sent: Friday, September 04, 2009 2:09 PM
> > To: [email-masked]; Adrian Farrel
> > Subject: [kmart] Draft Charter for KMART BoF
> >
> > Team,
> > Below is -00 for the KMART charter. Pls review and send
> > debate/comment/edit to list.
> >
> > At this point I'd like to step out of the editor role for the
> > charter. The AD's are looking for BoF chairs, and a charter editor.
> > Pls let them know if you are interested. I will continue actively as
> > a participant, document editor/author and Liaison to IABs Secure
> > Routing work item.
> >
> > Gregory.
> >
> > ===== 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
>
>I think KMART is a good idea, though some clarifications are still needed
>for the Charter:
>
>- Packets-on-the-wire: some readers may not be aware of the exact meaning
>for this term (e.g. versus a point to point secure-channel, ala SSL/TLS).
>Thus, some clarifications may be needed (e.g. use of keyed hash on a per
>packet basis).

makes sense.

>- Intra/Inter domain: does this KMART address only intra-domain (intra-AS)
>routing protocols, or also inter-domain protocols.

both. In fact, the work has really started with TCP for BGP, with 
mostly EBGP in mind (but it works the same for IBGP). There seems to 
be a lot of demand for PIM-SM too, since it is often crossing domain 
boundaries these days. There is less demand for interior-gateway 
protocols at present, i.e. OSPF and IS-IS.

-- snip --

> >
> > 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.
>
>TH:  Calling out some examples may be a good idea in this paragraph to
>clarify.
>For example, explain that some intra-domain routing protocols (eg. RIP2,
>OSPF, etc)
>may still be using hash algorithms that are deemed "weak".

agreed. Can't recall if that is covered in the most recent charter 
update or not. Brian?

>I would even go so far as adding "Algorithm Agility" as a goal or
>requirement of the framework/architectures and solutions coming out of
>KMART.

I agree. It's in the roadmap document as a very clear requirement, 
under the requirements section.

> > 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.
>
>TH: Did you mean "specifications" only, or does it include also a
>"framework" document (as is alluded further below).

Both. Good catch. The Framework is a key starting point, esp if we 
want to get to KMPs for these things.

-- snip --

> > 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. 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.
>
>TH: Perhaps the term "mechanisms" also need some clarification. Does it
>mean cryptographic algorithms, 2-party key establishment protocols,
>group key establishment protocols etc. etc.

It refers to what's needed in a RoutingProtocol in order to provide 
the basic requirements (see Requirements section of 
draft-lebovitz-kmart-roadmap). In TCP-AO's case for BGP, this meant 
adding a KeyID for key/algo agility w/o killing the connection, 
adding the connection specific info into the hash function for replay 
protection, and specification of new algos. In step 1 it is NOT 
2-party key establishment or group key establishment, that is 
expilictly part of step 2 (below). First step:  clean up the Routing 
PRotocol for manual key usage. Second Step: add in Key negotiations, 
and to it in a re-usable way.

> > 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.
>
>TH: The term "DOI" could also to be confusing (ever since ISAKMP
>was supplanted by IKE). It also narrows down the vocabulary (and thus
>available solutions) to IPsec and IKE.

Probably right. I meant DOI in the generic sense, not in the IKE 
specific sense.

>Also, the term "Key Management Protocol" when used within the IETF
>typically means a 2-party key establishment/agreement protocol
>(ala IKE and SSL).

That's what I intended.

>Within the broader standards world of IEEE1619.3
>and the OASIS KMIP working group, the phrase means a proper lifecycle
>for managing keys following that defined by NIST 800-56 and 800-57.

I'm not as familiar w/ that work. Could you point us, the WG-to-be, 
to the documents OASIS that you find germaine? We can take a look at 
IEEE1619.3 and the NIST specs. Thanks for the pointers. Would you 
recommend that we bring those in and make RFCs out of them?

>I think KMART could make a *huge* contribution to the IT Management
>industry (which includes IP network management) by providing
>an API (specific to cryptographic keys management) that allow
>instrumentation systems to provide a unified management experience
>to the IT Admin.

Me too. It would be HUGELY HELPFUL.

> > 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).
>
>TH: Again, I would serious look at existing protocols (outside the IETF)

assuming you mean the IEEE and OASIS references you gave above?

>which has already been deployed for managing cryptographic keys.
>The problem of lifecycle management of crypto keys at routers is not
>much different than that in storage controllers (really).

Agreed. Good point.

Thx again for the review,
GRegory.

>cheers,
>
>/thomas/
>
>
>
>
>
> >
> >
> > 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.
> >
> >
> > OUT OF SCOPE
> >
> > o   Protection of route message content or payload.
> >    -   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.
> >
> >
> > 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
> >
> > _______________________________________________
> > kmart mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/kmart

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