RE: SOI QUESTIONS: 2.1 - 2.3

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

Ted,

What will be the procedure for deciding on this stuff? Will the moderated
discussions be followed by a straw poll? What will happen if we can't
acheive consensus on an issue?


> 2.1.)  Does SOI need to provide identity protection

This is an issue where the idea that the requirements should dictate the
protocol goes out the window. What we should do is determined by what we can
do. I think it's a given that we want some form of PFS for the protocol so
identity protection comes "for free."

Protection against passive attacks should be the priority. We should protect
one side against active attacks simply because we can (without screwing up
the protocol). I feel there are equal arguments for protecting either side.
Since the initiator can conceivably request which identity he wants to talk
to (at the cost of repudiation, I guess), I would tend to protect the
initiator (but I don't really care). If people want to do a fancy thing
where you can negotiate which side gets more protection, that should be a
MAY.


> 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward
> secrecy" by trading off performance versus the level of PFS provided.
> The funcitonality provided is roughly identical.  Does anyone care
> about the details of how IKEv2 versus JFK provides this functionality?
> Should we just flip a coin?

I have posted many ideas on how to improve PFS in IKE, but no one really
seems interested so I won't do it again. I like the PFS interval approach
better than having a Boolean. It is silly to do PFS always (esp. in a
2-phase system), but possibly undesirable to bind it to phase 1 rekeying.

I don't particularly like the way the PFS interval is integral to the design
of JFK. In IKEv2, it is at least just a modular feature. On the other hand,
the method in IKEv2 is still inefficient on the wire (and in memory usage)
because you have to cache the peer's last key. I don't much like the
trial-and-error option for PFS mismatch either. The IKEv2 technique allows a
tuneable optimization for either time or memory, but I can't help thinking
that an acknowledged notify message would give you both.


> 2.3.A.)  Does SOI need to natively support "legacy authentication
> systems"?

Of course let's not forget that legacy authentication is a pejorative term.
For an obsolete technology, it's strange how I still use it almost every
day. I, for one, don't believe that token cards are going away any time
soon. Public key-based smartcards will see some use, but the downside is
that you have to physically connect them to the computer. I'm not about to
type in a 1024 bit signature by hand.

It would be nice for the token authentication to be done directly within
SOI, but that's not possible with Radius because the KMP doesn't have access
to the password. However, this is not an insurmountable limitation (you
don't absolutely have to use Radius). I'd like to leave this possibility
open.


> 2.3.B.)  Does SOI need to natively support some kind of "shared
> secret" scheme?  (Or just certificates-only?)

I think that once we abandon the fancy key derivation mess from IKEv1, the
authentication method just becomes another plug-and-playable crypto
algorithm. As has been noted many times before, the only thing that made
shared secrets complicated in IKEv1 was the crufty "choose any two of {main
mode, preshared key, mobile client}" problem.

By definition, plug-and-play authentication doesn't complicate the base
protocol. There is no downside, unless you happen to have a political
agenda. It allows a password (or "legacy authentication") in one direction
with RSA sigs in the other. With one extra payload (ID_KEY_ID), we could do
SRP. It even allows no authentication (or "anonymous authentication" as
Michael calls it).

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.