DHCP auth in unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt]

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 24 Mar 2004, Ralph Droms wrote:
> > > The statement "To be useful in such environment in practice, the practical
> > > details of managing the DHCP authentication need to be analyzed." needs to
> > > be explained.  How is the authentication specified in RFC3315 and
> > > recommended for DHCPv6 PD in RFC3396 not adequate?
> >
> >(Operational) key management seems problematic, even though DHCP
> >provides support for that.
> 
> How is operational key management for the authentication mechanism described
> in RFC3315 more problematic than for other mechanisms that use shared keys?

Those protocols are not often used 1) between administrative domains 
[where key management is arguably simpler] and 2) before getting IP 
addresses in the first place (that is, if you don't have an address 
yet, you cannot run mechanisms which help in making the key sharing 
simpler).

> >Maybe reword:
> >
> >    The basic use of DHCP is insecure. This may be a problem if the link
> >    between gateway and ISP is shared by multiple subscribers. DHCP
> >    specification includes authentication options, but does not describe
> >    the task of managing the keys, and how the information would be
> >    shared between the customer and the ISP.  To be useful in such
> >    environment in practice, the practical details of managing the DHCP
> >    authentication need to be analyzed.
> >
> >to:
> >
> >    DHCP is insecure unless authentication is used. This may be a
> >    particular problem if the link between gateway and ISP is shared by
> >    multiple subscribers. DHCP specification includes authentication
> >    options, but the operational procedures for managing the keys and
> >    methods for sharing the required information between the customer
> >    and the ISP are unclear.  To be secure in such environment in
> >    practice, the practical details of managing the DHCP authentication
> >    need to be analyzed.
> >
> >Perhaps that is a bit more fair statement of the issue(s) involved.
> 
> No, I honestly don't think it's any more fair.  Most service providers
> provide complete isolation of customer traffic through filtering even if the
> link appears to be shared among multiple customers.  

But then it no longer is a shared link, and the above does not apply.

But you raise a good point: I think we should spell out the obvious,
that rather than trying to operate with *really* shared links, the
operators should strongly consider mechanisms (any pointers?) which
achieve the isolation, making the issues more complex.

> If customers do truly
> share a link, there are *many* other attacks available and pointing out DHCP
> as a specific problem is only telling part of the story.

Yep, but that's the only story being covered in that section of the 
document...

> Finally, I still
> haven't heard an explanation of the requirement that "the practical details
> of managing the DHCP authentication need to be analyzed."  DHCP can use a
> password provided by the service provider to the customer.  What additional
> analysis do we need to perform?

If they provide a password, that's fine.  As long as it's clear how 
they provide it, and how it would end up being configured in the 
router. (Trivial if the ISP ships the box to the user, possibly 
non-trivial otherwise.)

I think the shared key model also requires that the key stays as it 
forever (providing for better brute-force attacks against it), unless 
you do re-keying or the like somehow.  But that would probably be 
equally problematic.

> The issue of DHCPv6 security is adequately addressed in RFC3315 and need
> not be rehashed here.  Anyone who reads RFC3315 (btw, the reference
> [DNSDHCPV6] is never cited anywhere in the body of the document) will
> see the security analysis for DHCPv6.

The security analysis in there is restricted to the scenario which 
may not be directly applicable here:

   This protocol is focused on solving the intradomain problem where the
   out-of-band exchange of a shared key is feasible.

This is inter-domain, and whether sharing keys is feasible is an open 
question. (In some cases, with some constraints, it certainly seems to 
be possible, but...)

> > > What are the security implications of ND proxy?
> >
> >Roughly equal or slightly worse, but then again, it would probably not
> >be applicable in this specific ("multiple subscribers in one big LAN")
> >environment in any case.
> 
> So ND proxy doesn't represent a security problem and requires no
> authentication because its scaling properties preclude its use in what you
> consider to be a typical deployment scenario? 

Yep.

> Whatever the situation,
> the security issues for ND proxy should be mentioned as well as those
> for DHCPv6.

Agreed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings