Subject: Re: Security issues in zeroconf-v4-linklocal-05

From: Aidan Williams <[email-masked]>
Date: Fri, 31 May 2002 10:04:05 +1000

Jim Busse wrote:
> I've read over the drafts again, and I have a slightly different view
> regarding the securing of a Zeroconf network.  Please consider these
> comments:
> 

Thank you.

> I was always of the opinion that some pre-configuration and perhaps some
> "session" layer interaction was necessary (very contrary to the "Zero" in
> "Zeroconf").  But I think as was pointed out in some other emails, that the
> risks need to be identified, with the methods clarified in the requirements
> and protocol drafts to secure against these risks.  Where there's no
> security methods identified, then, or where it's external to the Zeroconf
> requirements or link-local drafts, will be obvious to the implementers, and
> not implied.  I think, although requirements draft 10 says "implications",
> the "implication" to my device or implementation may not be clear.  Also,
> just to say "messages...are authenticated" again is not sufficient.  I think
> we should say how they are authenticated.
> 

The nub of the issue is: which risks should we clarify.

I re-wrote the security section from the point of view that the
requirements document should highlight what are the security issues
that arise merely because you are using zeroconf protocols.  That's
why it talks about the relationship to configured protocols --
e.g. are we introducing new threats just because we are using a ZC
name resolution protocols in combination with the DNS.

I realise that the security section is currently pretty light on w.r.t
mechanism.  For a requirements document, that may not be a bad thing
since I'm not convinced that it could specify a solution that would
cover every possible zeroconf protocol.  My expectation is that each
zeroconf protocol should describe specific security threats and
countermeasures relevant to each protocol.  The requirements document
needs to describe and perhaps address the security issues that are
"zeroconf-architectural" in nature.

Would it help to provide some references to L2, L3 and L4 security
mechansisms, with perhaps brief examples on how to authenticate
messages?

> I know it's a big job, but I think it's time the IETF protocol developers
> start considering as many of the security aspects of their work as possible.
> So here I've tried to identify the security categories with hopes that
> certain protocols can be assigned to "fix" those areas, and identify the
> areas where the Zeroconf protocols do nothing.  This list may not be
> complete, but after working on firewalls and securing networks for awhile,
> maybe the list is a fair start.
> 
> Network/Device Attack Categorization
> 
> 1.      Physical
>      a. Theft
>      b. Isolation
>      c. Revision (modification)
> 2.      Logical
>      a. Denial of service
>      b. Theft of service
>      c. Modification of service
>      d. Denial of control flow
>      e. Theft of control flow
>      f. Modification of control flow
>      g. Denial of data flow
>      h. Theft of data flow
>      i. Modification of data flow
> 
> Device Security considerations
>      1. Authorization
>      2. Authentication
>      3. Accounting
> 

What aspects of these categories change when a network starts using
zeroconf protocols?

I'm reticent to include what could amount to an entire textbook of
network security information into the requirements draft.

On the other hand, I don't want to miss any gotchas.

> Since "secure" means "trustworthy, dependable, free from fear of loss",
> maybe "secret" for a Zeroconf network is not "secure".  I'm thinking that
> public disclosure may cause a Zeroconf network to be more "secure".  That
> is, in the event of an attack, or the joining of a network or device, or the
> unauthorized removal of a device, there may be some client-based (maybe
> Radius-like) AAA protocol run on every device.  Then each device would have
> the opportunity to either let the new device join, or prevent it, or perhaps
> shut itself down to protect itself.
> 

"Secret" was meant in the sense of "shared cryptographic secret", not
in the "don't tell the world that the network exists" sense.  Even
using radius, groups of devices that want to authenticate each other
must share some information that identifies them.

Steve Hanna's draft is about how to agree on a shared secret, that
could then be used to bootstrap authentication, privacy, etc (perhaps
even using protcol like radius).

regards
	aidan
____
:wq!