[karp] Fwd: RE: [kmart] Draft Charter for KMART BoF
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[karp] Fwd: RE: [kmart] Draft Charter for KMART BoF
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" <ietf at hardjono.net>
To: "'Gregory M. Lebovitz'" <gregory.ietf at gmail.com>,
<kmart at ietf.org>,
"'Adrian Farrel'" <adrian at olddog.co.uk>
References: <4aa1886e.171bf30a.5017.4fb0 at mx.google.com>
In-Reply-To: <4aa1886e.171bf30a.5017.4fb0 at mx.google.com>
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: kmart-bounces at ietf.org [mailto:kmart-bounces at ietf.org] On Behalf
> Of Gregory M. Lebovitz
> Sent: Friday, September 04, 2009 2:09 PM
> To: kmart at ietf.org; 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
> kmart at ietf.org
> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
