[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SOI QUESTIONS: 4.4 - 4.7



> 4.4.A) Both JFK and IKEv2 provide SA deletion.  The functionality
> provided is roughly identical.  Does anyone care about how low-level
> implementation details of IKEv2 and JFK?

This is pretty much a Boolean feature. You can either delete SAs or you
can't. Of course, the difference is that IKEv2 deletes SAs using an already
existant control channel. Do I care about the low-level details? Of course I
do. I object to the method described in JFK due to its obvious kludginess. I
can't imagine how someone would prefer to negotiate an SA with identitical
selectors but protocol ESP_BYPASS rather than to just say "please delete the
ESP SA with SPI X".


> 4.5.A) Both JFK and IKEv2 provide SA rekeying.  The functionality
> provided is roughly identical, although JFK requires more
> cryptographic operations to do rekeying (see 2.4).  Does anyone care
> about how low-level implementation details of IKEv2 and JFK?

I care about the details of rekeying as it relates to PFS, but we covered
that with an earlier thread.

I also think we need to learn from the problems we experienced with rekeying
in IKEv1. IKEv2 mandates continuous channel mode, so that solves one big
issue. I would also like SOI to prescribe a more deterministic timeline for
SA switchover, so we can eliminate some of the problematic race conditions.
E.g.:

1:00:00 - negotiate original SAs (with local lifetime of 1 hour)
1:52:07 - new negotiation begins at jittered rekey threshhold
1:52:09 - negotiation completes and new SAs are installed (but initially
inactive)
1:52:39 - switch over to new SAs after grace window to allow for lost IKE
packets
1:53:09 - delete old SAs after grace window to allow for delayed IPsec
packets


> 4.6.A) Both JFK and IKEv2 provide authenticated error messages.  The
> functionality provided is roughly identical, although details very
> different due to the lack of a 2 phase protocol in JFK.  Does anyone
> care about how low-level implementation details of IKEv2 and JFK?

Do they? Correct me if I'm wrong, but I didn't see anything about
authenticated error messages in the JFK draft. As far as I know, "reject
info to message 1" is not authenticated. As for message 3, I searched
through the draft for quite a while and mused on the subject. You are
supposed to cache the authenticator for message 3 in order to detect
replays, and if message 3 is rejected then you are supposed to cache the
GRPINFO along with the authenticator so you can reply quickly. Presumably
you don't want to recalculate the DH key in this case, so that implies to me
that the error message is not authenticated. But I could be wrong... I'm not
sure anyone has actually thought this through before.

To me, the important distinction is the number of possible error messages in
the protocol. The messages in IKEv1 weren't perfect, but I don't see that as
justification for removing them altogether. I'd like to be able to give some
indication of the error to the peer. JFK provides no opportunity for this,
except in the case of an algorithm mismatch. In reality, the danger that we
will act as an oracle is very slight. Overall, I think the exact
specification of the error definitions still needs some work, and this is
something I hope to clarify after we finalize the general approach.


> 4.7.A) Does SOI need to provide authenticated informational messages
> after an IKE SA has been set up?  (What sort of informational messages
> might be needed?  Do they need to be protected in a different key than
> the SA key?)

I'm not totally sure why this is a different issue from 4.6.A. In the past,
we had Delete, Initial Contact, Responder Lifetime, and Replay Enabled.
There were also some proprietary IKE pings using the notify messages and the
ever-quixotic "Notify Like When Is That Ever Right", whose ultimate intent I
never did discern. I guess the Responder Lifetime notify is now obsolete,
but the others shouldn't be. Also, in an ealier thread I proposed a new
Delete Keymat notify which would allow the peers to coordinate when to
refresh the DH exponential. Informational messages are such a multifaceted
and forward-looking feature that I really wouldn't like to see them
deprecated.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.