Keying and Authentication for Routing Protocols (karp) WG
Tuesday, March 23, 2010, 9:00 - 11:30 (California A)
===========================================================
CHAIR(s): Joel Halpern
Brian Weis
AGENDA
======
- Administrivia
- Mailing list: karp@ietf.org
- Scribes (Meeting Minutes & Jabber)
Jabber log: http://www.ietf.org/jabber/logs/karp/2010-03-23.txt
- Blue Sheets
- Welcome & Document Status - Chairs
- The Threat Analysis and Requirements for Cryptographic
Authentication of Routing Protocols Transports (Gregory
Lebovitz)
- draft-ietf-karp-threats-reqs-00
- Slides
- Threat Analysis I-D Discussion
- Keying and Authentication for Routing Protocols (KARP)
Design Guidelines (Gregory Lebovitz)
- draft-ietf-karp-design-guide-00
- Slides
- Design Guidelines I-D Discussion
- Framework for Cryptographic Authentication of Routing
Protocol Packets on the Wire (Bill Atwood)
- draft-ietf-karp-framework-00
- Slides
- Framework I-D Discussion
- Roadmap Discussion
- Open Discussion
Administrivia
=============
Joel Halpern and Brian Weis called the karp working group
meeting to order. Melinda Shore agreed to be jabber scribe,
and Karen O'Donoghue took the minutes. The chairs welcomed
attendees and provided a brief update. The working group
was successfully chartered since the Hiroshima IETF. A
series of conference calls were held, and three working
group drafts have been produced from Greg's draft, draft-
lebovitz-kmart-roadmap-03. Each of the three documents will
be discussed today.
Thread Analysis and Requirements (Gregory Lebovitz)
===========================================================
Document:
http://tools.ietf.org/html/draft-ietf-karp-threats-reqs-00
Slides:
http://www.ietf.org/proceedings/10mar/slides/karp-1.pdf
Gregory Lebovitz presented the Threat Analysis and
Requirements draft. He could use a co-editor if anyone
would like to volunteer. First, Greg was interested in
whether or not the goal of the document was clear. The
random participant that he questioned answered correctly
leading to the conclusion that the goal is clear. Further
input is solicited. Paul Hoffman commented that the
document could be much shorter.
Greg presented a slide with lists of items that were
specifically in and out of scope. He asked for additional
input on what is specifically out of scope. Steve Kent
indicated that sniffing is out of scope because we aren't
encrypting the data. Karp is about protecting how we say
something and not what we say. Does this also mean that man
in the middle attacks are out of scope? There was some
concern that we were confusing services and tactics. There
is a contradiction between the left and right columns:
Delaying a message is out of scope, but it breaks
synchronization which is listed as in scope. Reordering is
in scope and timing should be as well.
There is a third category, things we need to look at on a
case-by-case basis. Sam Hartman asked to what extent is the
scope for us to define and to what extent is this defined
for us by the charter. Joel Halpern indicated that the
basic outline is defined by the working group charter, but
there is some room within that for refinement.
Another discussion point was the denial of service on the
transport subsystem. Are we trying to make this protocol
harden the transport subsystem? We need to look at making
the layers above us resilient to attack from the layers
below us. Tim Polk commented that we are very interested in
key management that may enable this for some of the routing
protocols. Some of these are threats we are trying to
protect against and some of these are things we are
enabling the routing protocol to support. It was pointed
out that we are trying to protect routing protocols
regardless of where the attackers attack. This is not a
layers problem. Greg pointed out that you can attack a
routing protocol by flooding a segment, but we can't solve
that within the scope of this effort. Further discussion on
scope was solicited on the mailing list.
Gregory moved on to specific requirements he felt needed
some community discussion.
Requirements #5 and #6 address inter-connection and intra-
connection replay protection. Is this a relevant
requirement? Replaying the can suppress failure detection.
There is one requirement, protecting against replay
attacks.
Requirement #19 addresses a large seq# space. A decision on
the last question will take care of this. Why are we trying
to add protection onto whatever level of connection is
being utilized? Sam Hartman commented that he didn't
understand why a shim or a TLV is outside the bounds of
reason. Gregory indicated that perhaps transport subsystem
is the wrong term here, but it is the third one he tried.
Requirement #14 states that the authentication mechanism
must be decoupled from the key management system. Some felt
this was a premature design decision. Others felt that it
was required in order to make incremental advances. There
was a lengthy discussion on the advantages and
disadvantages of tightly and loosely coupled key management
systems. A key desire here is to have something useable by
the operator community and able to support incremental
development and deployment. Joel Halpern directed further
discussion on this topic to the mailing list.
Requirement #17 indicates that the authentication mechanism
should not interfere with the ability to prioritize certain
protocol packets. Does the security community recognize
this and think it should be preserved. There was some
discomfort with this requirement, and it requires further
discussion.
Requirement #21 is on backwards compatibility in the
message format, transmission, and processing of routing
information carried through a mixed security environment.
This seems a bit obvious. Please looking at and respond to
the mailing list. Should Requirement #22 be combined with
#15? Also, Gregory is not confident about Requirement #25
and asked for feedback.
Gregory wrapped up the discussion on the Threat Analysis
and Requirement document by discussing next steps. These
include cleaning up known issues in the document, get
additional reviews, and start the design teams. Paul
Hoffman feels that the three documents need to be combined.
Given that the documents were just separated into three
from one, Gregory stated that we need to decide what is
wanted here and stick to it Manav Bhatia,.
Design Guidelines (Gregory Lebovitz)
====================================
Document:
http://tools.ietf.org/html/draft-ietf-karp-design-guide-00
Slides:
http://www.ietf.org/proceedings/10mar/slides/karp-2.pdf
Gregory Lebovitz presented the Design Guidelines document
for Manav Bhatia who couldn't be here. Appropriate pointers
to the requirements document need to be added. A
categorization has been defined based on communications
models (one-to-one, one-to-many, and multicast) and keying
models (peer-to-peer and group). This categorization needs
to get consensus in the very near term.
We will be using a two step process: 1) Enhance existing
protocols current authentication mechanisms; and 2)
Introduce a Key Management Protocol for operational
efficiency gains.
The question from the floor was "Why do we need a KMP?"
While I agree that key management is useful, but the list
of reasons is not relevant. Key management is for parameter
negotiation, re-establishment of new traffic keying
material, and compatibility. Paul Hoffman feels this needs
to be taken out of the document, it is factually wrong.
Some felt that replacement text is needed for all the stuff
you have in this section. Gregory feels that there is a
certain amount of operational reality that security people
need to understand, and that is addressed by some of the
items on this list. Gregory also agrees that this part
needs to be cleaned up, and he asked the security community
to work on it with him.
Slide 8 brought the topic back to categorizations. If the
categorizations look good, they will become the basis for
the design teams. It was pointed out that what works for
one-to-many would be applicable to one-to-one as well. We
want one mechanism for protocols in a group, not one for
each category.
Additional work is needed on this document to reduce the
repetition with the requirements analysis document. Section
6 on Gap Analysis may be removed completely.
In the security considerations section, it was asked
whether or not we needed algorithm agility. There was also
a comment made to be clear about the usage of the words
credential and key. It is confusing when the same word is
used as a credential of the key management protocol. It was
pointed out that there have been two related efforts
outside the IETF - IEEE 1619.3 and OASIS. Gregory asked for
pointers to be sent to the mailing list.
Framework (Bill Atwood)
=======================
Document:
http://tools.ietf.org/html/draft-ietf-karp-framework-00
Slides:
http://www.ietf.org/proceedings/10mar/slides/karp-0.pdf
Bill Atwood presented the Framework document. He discussed
the structure of the document and the material moved from
the original source document. Russ Housley commented that
he was surprised by the suggestion that you would use the
same credential for peers that are outside your network and
peers that are inside your network. He had assumed that you
wouldn't operate this way.
Eric Rescorla is concerned about the single unified
architecture in the diagrams. We have no idea how to build
key management for point-to-point protocols or for groups.
What does this buy you? Gregory asked for Eric to provide
additional information on what would be better. Eric
doesn't feel there is a straight line from the requirements
to this result. Bill Atwood reminded the group that this is
a just starting point.
Joel Halpern indicated there are two different issues that
he thinks Eric has raised: 1) the claim that there's single
key management across all routing protocols, and 2)
separation between key mgmt and security protocols. Joel
agrees that trying to define one thing for all of this
won't fly, but he disagrees that the result will be one
solution per routing protocol. Gregory is pretty convinced
that the KMP function will have at least two variants.
There was extensive discussion on the KeyStore shown in the
diagram. Eric indicated that the keystore box should be
removed from the diagram. Gregory indicated that the idea
is that there is a keystore where keys are stored outside
the routing protocol. Operators don't want to have to put
key storage mechanisms into their router for each protocol.
Tim Polk asked whether the concerns were that the functions
identified are not needed conceptually or that the
description of how it is to be instantiated is broken. Some
felt it was an implementation detail. Sam Hartman indicated
that his main concern was the assumption that they're
separate protocols rather than things that can be modularly
consumed within a protocol. He wants fully integrated key
management. Joel Halpern reminded folks that the charter
clearly states we are going to use this two-stage approach.
Additional discussion was directed to the mailing list.
Discussion on the list will also identify specific actions
for moving forward.
The meeting was adjourned at 11:30 am.