RE: RESEND: Thoughts on identity attacks

[Charlie_Kaufman@notesdev.ibm.com]

"Khaja E. Ahmed" <khaja.ahmed@attbi.com> wrote:
 > Please do not treat this as an assault on the product of your love and
 > labor.  Treat this as nothing more than an appeal for simplicity in any
 > successor/replacement to IKE.  IKE is clearly is a very sophisticated,
rich
 > and elaborate protocol.  It's influence and comprehensiveness is also
 > evidenced by the fact that popular successor candidates have really made
no
 > departure from IKE1s current structure or even the entirety of it's
goals.
 > I may well be the only one who wishes this but I was thinking that it
would
 > be great to have a radically simple alternative that can be an option
 > perhaps coexisting with IKE2.  Rather like the coexistence of SSL 2.0 and
 > 3.0 in implementations supporting the two.  I was hoping to see such an
 > alternative fielded as a successor.  Such an alternative would do only
the
 > minimum necessary to create an SA for ESP.
 >
 > You are quite right to point out that I may not be aware of the context
 > here.  I am not as active a participant/reader of this list as I would
like
 > to be so I don't know if it is acceptable for a candidate successor to
IKE
 > to start from a clean slate and even sacrifice backward compatibility
with
 > IKE.
 >
 > One goal that such an alternative could depart from is the goal of
affording
 > anything like Identity protection....

Creeping complexity seems almost inevitable in the evolution of protocols.
There are several causes. Designers find features that are really neat and
appear almost free, so what the heck. Usually these features turn out to
not
be free as they interact with later design changes. People propose
requirements that might be useful in some application that may or may not
materialize, and it's easier to acquiesce than to argue. And deployment
experience reveals weaknesses that need to be plugged. Rarely does anyone
propose a simplification, because it would offend the person who added the
feature and rarely would a single simplification make a protocol that much
better. It takes a reengineering from the ground up.

I believe many features in IKE are in the category of "seemed almost free"
at the time, and so are included without any demonstrated need. Identity
hiding is one. Stateless cookies is another. The ability to craft
incredibly
complex combinations of crypto algorithms and ESP/AH/IPCOMP combinations
is a third. Having a phase I and a phase II is a fourth.

There are options that I suspect no one uses but were added on speculation.
These include certificate requests. There are options that exist only
because people couldn't make decisions, like Aggressive Mode vs. Main Mode.

I wish I could say there are things added based on deployment experience,
but I don't think there are any. If we ever hope to use IPSEC to secure
shared system to shared system communications, there will be a need for
some identity information beyond what we have today, but I am loathe to
propose anything based on speculation... that's how we got here.

As one of the contributors to an IKEv2 proposal, I went into the project
with the enthusiasm you express for making radical simplifications. But
my higher priority was to get something that was clearly and
unambiguously specified, and in many cases didn't argue for a
simplification because it seemed more likely to spur debate than to quell
it. The clear feedback from the last meeting and the list is that more
simplification would be good... well, except that authentication based on
configured secret keys should probably be added back. We're trying to do
that.

I see the following as "so easy that there is no point removing it".
In aggregate they add significant complexity.

1) Identity hiding
2) Stateless cookies
3) Multiple phase IIs from a phase I
4) Piggybacked certificate requests
5) AH
6) IPcomp

I haven't dared propose removing any of them. Nor am I doing so now.
But I'm certainly not prepared to defend any of them on any grounds
other than "I think we would spend more time debating their removal
than making them work."

Your mileage may vary.

           --Charlie

This footnote confirms that either (1) this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including computer
viruses, (2) this email message was sent by a virus that appends this
footnote, or (3) (most likely) the sender of this message is trying to
raise awareness of how foolish it would be to place any confidence in
footnotes like this.