Subject: Re: OPEN ISSUE: Standards Track

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 22 May 2003 15:21:20 -0400

In message <[email-masked]>, "Charles E. Perkins" writes:
>
>
>As an example, I think it was a terrible mistake to delay
>Mobile IPv6 for so long pending the completion of the world's
>most sophisticated and super robost security solution (slight
>exaggeration, but ...).  I guess I don't have to describe the
>effect this can have in a world moving at what used to be
>called "Internet speed".
>

It wasn't a matter of a "sophisticated and super robost security solution";
it was a matter of one that would *ever* work outside a company.

> To put it as briefly as
>possible, the ADs demanded a key distribution mechanism
>_in addition_ to the basic authentication scheme.  This is
>in marked contrast to the situation with AH and ESP,  But
>_nobody_ claims that AH and ESP were insecure because they
>were standardized without key distribution.

You can't do AH or ESP without keys; the difference is that we had a 
story about where those keys could come from even before we had a key 
distribution mechanism.  The story was simple:  pre-arranged keys.
That only works for MobileIP if you can pre-arrange keys with every 
possible spot you'd ever roam to, which is quite at variance with the 
plans I'd heard for MobileIP.  The only path forward we heard was, in 
effect, the One True PKI; that's something that will not, can not, and 
should not exist ("should not" because it would be horribly destructive 
towards any form of Internet privacy).

>Bottom line: at this point in time, I am convinced
>that trying to use IPsec was my own worst mistake in the initial
>designs of Mobile IPv6

I won't argue that point; however, any form of cryptographic 
authentication would run into the same key distribution problem.
Very little of the issue had to do with the syntax or semantics of 
IPsec.  You were running afoul of a basic architectural issue.

Let me expand a bit more on why IPsec can work (on a small scale) 
without key distribution, and on why the models are fundamentally 
different.  If I want to talk "securely" to someone, I have to have 
some out-of-band way of knowing who they are.  Put in concrete terms, 
if Alice wants to talk to Bob, she needs to know that it's Bob she 
wants to reach and not, say, Carol.  If you don't know out-of-band the 
difference between Bob and Carol, there's no difference in whom you're 
talking to...  If you do know it's Bob, you have to have some way to 
verify that the party to whom you're talking really is Bob.  That can 
be via pre-arranged keys or by a key distribution mechanism *rooted in 
a common trust anchor*.  In other words, it's not the key distribution 
mechanism that's at issue, it's the out-of-band trust mechanism, and 
that's relatively easy for most uses of IPsec. 

With MobileIP, the mobile node and the home agent are trying to 
persuade random parts of the Internet infrastructure of assorted 
ownership and trust relationships.  But where's the trust anchor?

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 22 May 2003 13:06:54 -0700

Hello Steven,

> it was a matter of one that would *ever* work outside a company.

This isn't true.  A mobile node could roam outside a company,
and still get data from its home agent.  I'm worried about
going over technical details on the problem statement list,
so I'll stop there.

> distribution mechanism.  The story was simple:  pre-arranged keys.

Exactly.

> plans I'd heard for MobileIP.

No, you could do it with prearranged keys with the home agent
(as I hope you would agree), and prearranged keys with some
selected correspondent nodes.

>                                  The only path forward we heard was, in

The other path, which _was_ articulated, was doing prearranged
keys first, and better key distribution later.  Which is what
happened anyway, but we just couldn't publish the Proposed
Standard.

> IPsec.  You were running afoul of a basic architectural issue.

Actually, the situation was _far_ more complicated than that,
and IPsec produces serious constraints on what can be actually
run in a protocol.  Again, this is far afield from the problem
statement list material.

> different.

The scale for initial deployment with correspondent nodes would be
limited by the lack of key distribution.  That was never at issue.

> ownership and trust relationships.  But where's the trust anchor?

What a lot of people wanted was the ability to run Mobile IP with
home agents and a few correspondent nodes.  What the ADs demanded
was assurance that we could run Mobile IPv6 with an entire
IPv6-universe full of mobile nodes.  It was and is a great goal.
I think we achieved it, but it shouldn't have stood in the way
of Proposed Standard.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 May 2003 00:57:41 +0300

I will just say first that I agree with Steven's
explanation of the  reasons why AH/ESP were
inappropriate for securing binding updates to
random nodes in the Internet. For those that haven't
followed MIPv6 development I'll add that AH/ESP were
eventually replaced by an application specific security design
which deals with the specific dangers resulting from binding
updates, but does not require pre-arranged security associations
or global authentication infrastructure. Original MIPv6 didn't
actually have a security problem, IMHO; it was more of a
deployment problem. Yes, we have wasted two years but on
the other hand the amount of nodes you can run it against
has increased from one or few to the size of the Internet.
Not bad? Now all we need is for IPv6 to take off ... and
IESG to approve the documents this time. I'm trying to figure
out which one is more likely ;-)

But then back to the issues relevant for the problem
statement WG.

Raj said that earlier review from the security folks
would have helped. Perhaps, and such help is often
very useful and the IETF needs more cross-area
expertise. I'm all for it.

However, I'd like to present a slightly different opinion
about the way that security design in the IETF could work
better. Reviews may be a necesary but certainly not a
sufficient condition. The way I see it, there appears to
be a number of problems that we are facing:

- developed protocol specifications fail to take in
   account security in some manner, leading to security/
   approval/delay issues
- security mechanisms developed for various things
   don't get used in the field for various
   reasons, perhaps a key issue being once again
   deployment and configuration
- there are some hard problems that even the
   security experts are learning to deal with
- slow publication schedule for at least some of
   security features that the community would need.
- differing opinions about where we should be in
   the low "cost" vs. high security question.

So how could the IETF do better? I think a key element
for this is not (only) more frequent review from the few
security experts, but rather a better understanding
of the security issues by the other protocol designers.
Or making the security design more of an integral
part of the rest of the design for whatever we are working
on. This should include an understanding of the possible
security problems resulting from the planned feature.
Among other things, this understanding would help in choosing
security solutions that prevent the problems, and don't
do additional things that would require, for instance,
a global PKI. A number of documents by Steven,
Eric, and others exist to educate protocol designers
and we should use those documents, and write more. So:
we need more training.

As a result of better understanding of the security
issues in a feature, I suspect that we'd see less
"just authenticate everyone" approaches, and more
intelligence tied to the specific application, such
as cross-checking TLS-derived information with something
else at the application layer.

Secondly, we've talked about early architecture
design in this list. The security architecture
for protocol X would be a prime candidate for
inclusion in the architecture design section,
and should be reviewed early. Not when the bits
have been designed! No mandatory architecture
design early on, no early review possible...

Thirdly, it is really, really crucial to think about
deployment issues and how easy to use people find the
security mechanisms. All of us could use secure e-mail
but almost no one does. Why? And do the current secure
e-mail protocols deal with the real problems people are
having with e-mail? Why can't I think of more success
stories in security beyond one-sided TLS authentication,
SSH, and cellphone smart cards? IMHO we as a community
do not understand these issues well enough at the moment,
let alone have documented them somewhere. Yet this
seems a much more important issue for the world than
getting some documents approved by the IESG at t1 or t2.
Here's where I think the security area should probably
move a bit of its focus on. Less "policy" from admins,
less extra work for users, less reliance on non-existent
other stuff in the network.

My fourth point is that we need to be more honest about
the limitations of our security mechanisms, and faster
to get them updated when new algorithms come around etc.
Again some educational documents are needed for the
first part. (In some cases I suspect the educational
aspects would apply even to the folks developing the
particular mechanism...)

Finally, any problem in the process is amplified when
we try to do too large chunks of functionality in one
document. Unfortunately, this appears quite common in
today's IETF. Why? In addition to making the wrong
decision, there maybe a few other reasons behind this.
We appear not so good in incremental design. Reviewers
want to see the whole thing, to ensure that all aspects
have been taken care of. I agree with Charlie that we
shouldn't try to boil the ocean (though I may have a
different idea about the right way to split and phase
protocols). In general, the IETF tries to arrive at
a pretty perfect protocol for PS. We need security
and maybe even scalable security when a document becomes
a PS RFC, but we may not need all functions. Lets
start producing basic protocols with a series of enhancements
following them. And since someone will worry about the
"big picture" and how these pieces fit together,
we probably need again the architecture design document,
we need more detailed roadmaps than the current charters
are, and so on. And WGs need to realize that documenting
functions in separate specifications does not mean
that their pet features have been "left out".

--Jari