In message <[EMAIL PROTECTED]>, Erik Nordm
ark writes:
>
>Steve,
>
>I think this is a very good writeup, but it's missing
>the security considerations section :-)/2
>
>Thinking for 5 minutes about intermediaries vs. not and security
>it isn't obvious to me that one is better than the other.
>A few points:
> - A solution with an intermediary requires on the order of N + M trust
> relationships for N clients and M services. A solution without requires
> N * M. Are there fundamental differences in how to do key management in
> the two cases?
Yes and no, and a lot depends on the trust relationships between seeker
S, intermediary I, and target T. And whether or not N*M is a
significant issue depends on the relative values of N and M, and the
frequency of contact.
The latter is easier to see. If a member of set S has comparatively
infrequent contact with a member of T, and N ~= M, there isn't a
serious problem with the number of security associations -- there won't
be many at any one time, so it won't be much of a load. And trust
isn't much of an issue, either -- if S is trying to talk to T and T
isn't trustworthy, it doesn't matter much if T is lying about the
needed info or in the actual service response. In other words, if we
can manage direct responses, we're in much better shape.
If N>>M, then setting up many security associations is a considerable
burden on T. (This is one of the many reasons one can't use
transmission security instead of DNSSEC.)
With an intermediary, the question of how much S trusts I is crucial.
If S trusts I implicitly, the situation is relatively simple. If there
can be more than one intermediary -- i.e., the situation in today's DNS
-- S has no idea whether or not it can trust the chain, and hence
doesn't know if the response comes from the real T (or the info server
for T). This is the major reason that DNSSEC works by protecting
objects instead of transmission -- the records are digitally signed by the
ultimate source, thus rendering the trustworthiness of the transmission
chain irrelevant.
In other words, we can't really make any security statements until we
can define our terms better.
> - An intermediary would imply putting all the security eggs in one basket.
Yes, though that's not always bad: "The fool says ``Don't put all of your
eggs in one basket,'' but the wise man says ``put all your eggs in one basket
and watch that basket!''" (Puddin'head Wilson's Calendar)
>
>I think it is important to think about this some more. While the devices
>in a single home can rely on physical security combined with firewalls
>I think the fact that folks are talking about DNS discovery as
>reaching from the home networks into the ISP means that we need to
>take security a bit more seriously in this space.
The crucial question for security is how a node decides what other
nodes to trust. My light switch might decide to trust everyone, on the
assumption that no one else has access to the house wiring. I don't
think I want my burglar alarm to make the same assumption, since those
wires do appear outside my house, both at the service entrance and at
the nice, convenient outlets on my porch. (I would note that the U.S.
National Electrical Code (adopted by most, though not all,
municipalities) *requires* a few outdoor outlets.) In other words, you
have to pick your threat model, too.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
