Keying and Authentication for Routing Protocols BOF (karp)
Tuesday, November 10th from 9:00-11:30 (Orchid East)
=================================================================
CHAIR(s): Joel Halpern
Brian Weis
AGENDA
======
-
Administriva
- Mailing list: karp@ietf.org
- Scribes (Meeting Minutes & Jabber)
- Blue Sheets
- Welcome & BoF Goals - Chairs
- KARP Roadmap - Gregory Lebovitz
- draft-lebovitz-kmart-roadmap-03
*
Goals/Overview
* Threat
Model
* Requirements
* Framework
- Issues with existing Cryptographic Protection Methods for
Routing Protocols - Joel Jaeggli
- draft-ietf-opsec-routing-protocols-crypto-issues-01
- The TCP Authentication Option - Joe
Touch
- draft-ietf-tcpm-tcp-auth-opt-08
- draft-ietf-tcpm-tcp-ao-crypto-01
- Database of Long-Lived Cryptographic Keys & Their Use In
Routing Authentication - Russ Housley & Tim
Polk
- draft-housley-saag-crypto-key-table-00
- draft-polk-saag-rtg-auth-keytable-00
- Survey of Existing Routing Authentication Methods - Chairs
- Charter Discussion
- Open Discussion
Administrivia, Chairs
---------------------
Slides: karp-0.pdf
The karp BOF meeting was called to order by co-chairs, Brian Weis
and Joel Jalpern, at 0900 local time (Hiroshima). Karen
O'Donoghue agreed to take the minutes. The chairs went over the
IETF Note Well provisions, agenda, and the goals and objectives
for the BOF.
KARP Roadmap, Gregory Lebovitz
------------------------------
Document: draft-lebovitz-kmart-roadmap-03
Slides: karp-5.pdf
Gregory Lebovitz provided an overview of what is trying to be
accomplished in this proposed working group. Joel Jaeggli
commented on the threat model. Gregory asked him to forward his
suggestion to the mailing list. Richard Graveman asked if the
focus was on identities. Greg responded that it would be pairwise
for protocols for which it makes sense. There is a difference
between what is technically possible and what will be policy for
a specific organization. Gregory asked Richard to send his
suggestions on policy to the list. Bob Morgan pointed out that
just delivering identity doesn't describe how to use it. That
is one of the common downfalls in these kinds of efforts. A
profile document that gives guidance on the use of this is really
necessary.
Issues with existing Cryptographic Protection Methods for
Routing Protocols, Joel Jaeggli
-----------------------------------------------------------
Document: draft-ietf-opsec-routing-protocols-crypto-issues-01
Slides: karp-1.pdf
Joel Jaeggli provided a quick overview on issues with existing
cryptographic protection methods. This draft has been floating
around in various forms since 2006 with several contributors.
No questions were asked.
The TCP Authentication Option, Joe Touch
----------------------------------------
Documents: draft-ietf-tcpm-tcp-auth-opt-08
draft-ietf-tcpm-tcp-ao-crypto-01
Slides: karp-2.pdf
Joe Touch provided a quick overview of the TCP Authentication
Option work done at USC. No questions were asked.
Database of Long-Lived Cryptographic Keys & Their Use In Routing
Authentication, Tim Polk
------------------------------------------------------------
Document: draft-housley-saag-crypto-key-table-00
draft-polk-saag-rtg-auth-keytable-00
Slides: karp-3.pdf
Tim Polk provided a description of work related to databases of
long-lived cryptographic keys. The question came up about
whether the API between the protocol that does the short-lived
crypto session and the long lived crypto keys need to be a push
or bi-directional. Tim indicated he thought it was a pull, but
there was some thought that it might need to be bi-directional.
It was pointed out that questions like this need to be sent on
the mailing list so they don't get forgotten. Also, human factors
need to be considered here. Leif Johansson pointed out that this
is how we do key management in federated key management space.
A question raised in the jabber session was "Have you thought
about the fact that when multicast is used, the "peer" is actually
a "group" of "near neighbors"?"
Survey of Existing Routing Authentication Methods, Brian Weis
--------------------------------------------------------------
Slides: karp-6.pdf
Brian Weis quickly went through a survey of existing routing
authentication approaches. Lou Berger asked why LMP (RFC 4204)
wasn't on the list. This presentation is not to include or exclude
specific approaches in the karp effort as much as to identify
existing work. Part of the effort will be to further investigate
these approaches. It is expected this list will change.
Charter Discussion, Chairs
--------------------------
Slides: karp-4.pdf
Joel Halpern reviewed the current draft charter. He pointed out
that the intent here is not to wordsmith the charter. The goal
is to ensure that we are talking about the right things. Gregory
Lebovitz asked a procedural question about the best methodology
for doing this. Do we think that we can accurately capture all
of this in the charter, or do we need to write a procedural or
information document that is perhaps not progressed to an rfc?
One approach is named advisers from the various routing protocols.
Joel Halpern indicated that this gets at a bigger question. There
is a lot of work here, and we need a lot of support in order to
accomplish. Joe Touch expressed some concern with the way the
charter is written. Are we routing people who need a security
solution, and are we going to develop a transport solution. He
doesn't think we want to do transport work here. Russ White
pointed out that this is important work that needs to get done.
Lou Berger asked what is meant by a routing protocol in the
context of this effort? LMP has the same keying issues as the
other protocols in the routing protocol and would benefit from
this work. Ross Callon asked if we should prioritize the list.
We don't want to do this now, but it will need to be done. This
prioritization will be based on criticality and willingness to
work.
Joel Halpern presented the draft milestones and asked if they
are the right types of milestones for this effort. Paul Hoffman
indicated that he doesn't see the cryptographic work we've been
talking about today in these milestones. Paul also asked if we
are going to do these in order. Joel felt they would be started
when we have enough information and people to start them. Work
will progress in parallel where possible. Gregory Lebovitz
indicated that it is not clear to him that the individual elements
of the framework have to be fully defined and specified in the
framework document. Also, we need to make sure that we don't
specify APIs for internal interfaces - they could be separate
and informational. The framework document could indicate that
it would be helpful to specify an API, but we shouldn't require
them.
Dave Ward indicated that the challenge will be finding the sweet
spot where the mechanisms will support current practice, bad or
otherwise, but can then be used to leverage into better
practices. How can you possible make AO backwards compatible with
TCP MD5? The question on whether or not this is a good idea will
be left for a working group.
There was a question about what area would this working group
be in. The current thought is that it would be in the routing
area with a named security AD.
The chairs asked for a show of hands of who will personally
actively participate or can arrange for other resources. There
were 20-30 raised hands. The chairs then asked for an indication
of who thought we should form a working group. There was a loud
hum. When asked who thought we should not form a working group,
the room was silent.
The chairs indicated that they were looking for document editor
commitments today. People should come up after the meeting to
volunteer. In particular, the overall document Gregory Lebovitz
has been working on needs to be split into several documents.
Gregory Lebovitz gave special acknowledgement to those who
formed RPSEC and did the original work. Thank you for all the
work you put in that laid the foundation for this effort.
The meeting was adjourned at 11:30 local time (Hiroshima).