[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft minutes from second session
{sorry, I mistyped tislabs on Thursday when I sent this out the first time}
IETF #52 - IPsec WG meeting
Thursday December 13th
Salt Lake City
Meeting opened at 9:06am in Grand B.
1) JFK presentation from Steve Bellovin
(draft-ietf-ipsec-jfk-00.txt)
a) JFK design process presentation.
Clarification that "pre-shared key" (PSK) refers to
pre-shared SECRET key.
b) JFK details presentation from Angelos Keromytis
(clarification: one slide has both g^i/g^r and g^x/g^y. Let i=x, r=y.)
code for Java/C/Perl implementations was done. Java versions
interoperated, but not with C/Perl due to crypto library issues.
Overview of LBJ (Less Bulky-Joint) protocol.
Eric R: JFK makes a tradeoff - imperfect forward secrecy.
if you want PFS, then you have to keep state on message 1.
AK: you do not need to keep state. You do need to take a DH hit each
time, but with hardware that may be okay.
Eric: that's not PFS really.
AK: agreed.
Comparison conversation cut short.
PM: what about performance
Unknown: would IKEv1 be able to maintain code on the payload basis?
AK: the protocol itself has not mandated any particular payload
encoding.
PHK: identity protection - you can work it out from the IPs.
SB: general question, moved later.
Unknown: there is a perception that the only thing that phase 2
is good for is rekey. There is also Delete, Notify, dead-peer
detection. Amortization is benefit.
SB: goes back to requirements.
2) IKEv2 presentation - Radia Perlman
(draft-ietf-ipsec-ikev2-00.txt)
HO: the stateless cookie concern? Has anyone done an analysis of stateless
vs stateful cookies.
only a back of the envelope one.
HO: rekeying of each IKE SA should be done with PFS?
RP: you could do that, of course, but they key is that you don't
have to delete child SAs.
SB: other working groups have found that the critical bit often
encourages vendors to gratuitously set it to cause interop problems.
RP: you can always make broken implementations.
3) SIGMA: SIGN-and-MAC. Crypto rationale and proposals
presented by Sara Bitman
http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt
4) Engineering Tradeoffs in keying systems
Charlie Kaufman
There was a discussion about whether or not JFK could negotiate on
algorithms.
SB asserts that if it wasn't clear from the document that this is bug in
the document - the protocol does support it.
5) performance numbers
Eric Rescorla
6) overview of protocol requirements
Cheryl Madson
7) open mic
Jeff Forum - there should not be too much policy provisioning in IKE.
- it should only be related to the IPsec tunnel being
established.
CM: e.g. the address of the WINS server should be necessary to get a
tunnel up.
HO: move all policy stuff into a seperate protocol. (ipsp)
WD: this is the most important discussion.
Different scenarios provide different requirements. If we can ever
replace TLS, then clearly responder identity protection is not
important there. But other responders may want
MT: my observations is that the problems with IKE are protocol problems,
not cryptographic problems. The presentations this morning suggest
the opposite.
Being able to recover from reboot avalanche at concentrator boxes is
a very important thing.
Being able to amortize work across the duration of the user is important.
PHK: designing the protocol is the easy part, getting the requirements
right is the hard part.
XCASS is a serious proposal in the XML world.
May not match the IPsec requirements - identity protection may be
a meaningless requirement if the credentials are not related to identity.
PH: thanks Cheryl.
There will be a transition time when this comes out.
A requirement is co-existance with IKEv1.
SB: we think that the crypto needed attention as well as the protocol.
I had hoped to have a draft on interop for IKEv1 on the protocol
level.
K: it seems that IKEv2 and JFK have different mechanisms for negotiating
SAs. Were there different requirements among the groups?
SB: i'd rather the working group decide what the requirements are.
JFK wants to do: "I: this is what I want. R: yes/no-explanation."
IKEv2 is a good start towards this as well.
JFK wants to get rid of negotiations that are not necessary.
e.g: Let's not have 16 ways to do IP addresses
RP: all of this can be worked out.
An even simpler way is TLS - here are four suites, rather than 16 combinations.
If we can lock down one suite, then that would win, but seems too
non-flexible.
WD: counter example to website. Microsoft home employee systems are being
targetted, so they don't want to reveal that they are in fact employees.
(CB response that agrees)
unknown: response to PM, if not co-existence, then a transition document.
ER: the documents seem to all be willing to mutate.
traditional approach has been to start with Crypto and build a protocol.
Let's start the other way - do the protocol first, and then install
the crypto.
unknown: authentication requirement for asymmetric non-public key is important.
unknown: scoping is important. is the list everything? Or just a start?
do we know where IKE is not useful for?
CB: I've put the ones we have to deal with.
Often if a protocol doesn't have security, then they should use IPsec, keyed
by IKE. But this isn't always the right answer.
CK: parable of the Donkey who starved himselves because he was standing
precisely between two bails of hay.
raises issue of choice of encoding.
negotiation of parameters - IKEv1 99,000 possibilities. JFK was precise.
SB said that they could do negotiation. Raises question about whether
this will be secure.
Suggests that we should have a suite approach (we would specify suite 1
in this spec). Vanity crypto could do vendor-ID.
CB: if we did things by suites, analysis would be easier.
unknown: credential management and delivery. It is important that we carry
credentials in the protocol. We can do PSK or certificate
usage. No difference to us. On the other side, when we try to
deploy the service, we get problems.
We chose PSK because it was cheap and simple.
JI: we are no closer to getting requirements than a hour ago.
There are three sets of (meta)-requirements:
- cryptographic requirements (PK, PSK, etc..)
- operational requirements (rekeying, blackhole detection, etc..)
- policy requirements (how to negotiate things)
Barbara: this is a useful thing.
DH: the proposals were very complex because we wanted to support very
complicated underlying things.
JS: sees good work.
"parable of the WG who sat between two proposals whose AD eventually shut
it down."
considers asking for Minneapolis deadline, but sees that realistic.
AD asks for plan from chairs.
"We want to see results"
Meeting closed at 11:35.
ER = Eric Rescorla
HO = Hilerie Orman
AK = Angelos Keromytis
SB = Stephen Bellovin
PHK= Phillip Hallam-Baker
PM = Perry Metzger
SRB= Sara Bitman
CM = Cheryl Madson
WD = William Dixon
MT = Michael Thomas
PH = Paul Hoffman
K = Katherine
$Id: ipsec-meeting2-minutes.txt,v 1.1 2001/12/13 18:36:33 mcr Exp mcr $