Please send me any comments on-list or off-, before we submit the
minutes into the proceedings.
Thanks,
Yaron
IPsecME minutes: IETF 77
Monday, March 22, 2010 0900-1130 - Morning Session I
Co-chairs: Yaron Sheffer, Paul Hoffman
Minute takers: Shawn Emery and Richard Graveman (but all errors
introduced by chairs).
Paul Hoffman (PH): Yaron Sheffer via webex
PH: "note well" not in IETF packet, implicit statement that you have
read the "note well"
PH: the group was initially chartered with a set of work items, going to
recharter as these have been completed
PH: agenda: IPsec HA, EAP-only , failure detection, PAKE authentication
PH: new RFCs: 5658, 5723, 5739, Traffic Visibility in editor's queue,
Heuristics in IESG review
PH: Pasi Eronen stepping down as Security AD, stepping up Sean Turner
PH: roadmap: new draft after Pasi's input. Will go to IETF LC soon
PH: aes-ctr-ikev2 will go to IETF LC soon
PH: ikev2bis will make changes and will submit to IESG review
PH: ipsec-ha and eap-mutual, active work items
The Jabber log is at
http://www.ietf.org/jabber/logs/ipsecme/2010-03-22.txt.
presentation on IPsec High Availability by Yoav Nir (YN)
_________________
[slides presented]
YN: ipsec-ha at -00. A problem statement (PS) and requirements will be
written. Mixed vendor clusters and protocols between cluster members are
out of scope.
YN: map out as many challenges as possible with multiple vendors
YN: similar to ipscha-ps-00
YN: load sharing is also applicable to ha
YN: state change data: message identifiers in IKE and replay counters in
IPsec
YN: must not miss any IKE messages
YN: peers do not require modification, but heavily uses synch channel
PH: looking for contributors
David McGrew asked about including crypto synch, e.g., for counter mode.
See draft-ietf-msec-ipsec-group-counter-modes-05.
Rodney van Meter: HA vs load sharing, two characteristics, cluster may
not have either or both
YN: what would you suggest.
Rod: definition is incorrect, you can have HA that does or does not do
load sharing.
Stephen Kent (SK): state that needs to be synched, if you don't have syn
on the receiving side you don't have replay
YN: attacker can not cause fail-over and send replay attack
SK: should separate send and receive sides to make this clear
Rod: terminology: hot stand-by or dual-active. Cluster is ha, tolerant
of failure
Terry Davis: vendor to vendor interoperability is most important.
Aviation industry has heterogeneous environment
Terry: definitions of fields are most important, not as much as
terminology
presentation eap-mutual-00 by Yaron Sheffer (YS)
______________________
[slides presented]
YS: channel binding not yet discussed in -00
Dan Harkins asked how the IKEv2 gateway obtains an identity.
YS asked how this differs for “plain old IKEv2.” DH agreed it does not.
Pasi Eronen (PE) said it works the same as in “plain old IKEv2.”
PH: way forward? YS identified items for a -01 draft.
SK asked about reliance on the AAA server to identify the security
gateway. PE referred to the Charter - this needs to be fixed in the
draft.
Presentation: secure failure detection overview by PH Hoffman
_____________________________________
[slides presented]
The problem space will be discussed before the solution. Two different
solutions drafts exist.
Gregory Lebowitz (GL) asked whether liveness checks may be sent in other
cases. Tero Kivinen (TK) explained how the lack of liveness replies can
be used together with INVALID_SPI notifications. GL added an explanation
of how counters can be used as well. PH acknowledged that these methods
may be combined. (The goal is to distinguish failures from DoS
attacks.)
The two proposals are called QCD (draft-nir-ike-qcd) and SIR
(draft-detienne-ikev2-recovery), which make different assumptions about
on-path attackers.
QCD maintains a token across reboots. SIR does not—it notes that an
on-path attacker can cause rekeying in any event. The tradeoff involves
security and resource usage tradeoffs.
TK argued for additional security against killing the SA using an old
idea of “birth certificates,” in effect, a reboot count. He offered to
be a co-author.
Fred Detienne asked about selection criteria. Would the computational
overhead prohibit using birth certificates? PH asked for discussion on
the ML.
Presentation on PAKE process by Paul Hoffman
______________________
[slides presented]
PH: will discuss the criteria, Yaron will not be talking about his
proposed solution
PH: clarity of what different criteria people have
PH: also want to know which criteria is important
PH: discuss criteria for two weeks
PH: wants CFRG to get more involved, though they don't know much about
IPR
PH: asked NIST to take a look at PAKE
Presentation on password authenticated key exchange selection criteria
by Yaron Sheffer
_______________________________________________________
[slides presented]
See draft-sheffer-ipsecme-pake-criteria-01.
Some discussion on the ML has already occurred.
Both security and IPR are considered. Many proposals and options have
been published.
Discussion:
Sean Turner (ST): asked about the scope and applicability of criteria.
He asked about PW encoding—UTF-8? YS: This should be part of every
solution, however this is a requirement, not a selection criterion.
David Black (DB): In IP Storage, generation of strong shared secrets
from human-memorable ones was an issue. Update of these values (password
management) was another issue.
Dan Harkins (DH): argued against too much focus on possibly speculative
IPR discussion. PE added that factual statements need to be made
carefully.
Stephen Kent (SK): added some clarification about patent filings. PE:
The coverage of a patent may not be clear.
SK: pointed out that linking “future scalability: elliptic curves” is a
misnomer, but cited the use of existing groups as a criterion.
Seongham Shin asked about applicability to different modes.
DB: A false consensus about IPR may be dangerous.
David McGrew: We should consider on-line as well as off-line dictionary
attacks against weak secrets. The use of passwords needs to be
minimized. YS said that using passwords was an assumption, and he
distinguished criteria from requirements. He also stated that expert
opinions would be needed to clarify IPR issues, in addition to mere
“factual statements”.
DH: People are going to do what is easy anyway. We need to make it safe
in spite of that.
SK: Shutting down after bad password guesses has DoS implications.
TK: It must be possible to implement simply, or it will not get used.
Rene Struik asked about forward security.
Unscheduled discussions
____________________
Suresh: will still would like some guidance from the working group on
the roadmap draft
Suresh: two weeks for feedback
Sheila: including requirement levels in the doc
Sheila: view it as value added, requirements in the roadmap mapping to
RFCs is helpful
PE: requirements on algorithms, we already have an RFC that does it.
Two places need to be updated for these changes.
PE: roadmap will be incomplete after a couple of years in any case, but
should not become incorrect.
PH: put a note that this roadmap will not be updated.
PE: roadmap has options, not requirements
Sheila: only recently included algorithms, adding verbiage in the draft
is fine.
Suresh: Tero originally requested.
David McGrew: documenting existing status, how do we want to update the
algorithms?
David Quigley: reworking labeled IPsec draft, looking for input from
working group
Rod: 00 draft quantum keys, still pursuing individual submission
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
