[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 12:53 PM 3/25/2004 +0200, Pekka Savola wrote:
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


I can walk into a WiFi hotspot today, establish a new trust relationship
that I haven't used before, and establish a secure link to the Internet
that uses a DHCP-delegated IPv4 address.  Delegating a prefix with DHCPv6
is essentially the same problem as obtaining an IPv4 address with DHCPv4.
What is the problem we need to solve with DHCPv6?

 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).


Whether or not an IP address has been obtained is irrelevant to the
problem and especially to DHCPv6 prefix delegation.

> >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.

OK, and I think that secured, non-shared links really are the norm.

As security issues are explicitly described in more detail in the
DHCPv6 and PD RFCs, I suggest the text about security be replaced with
pointers to the discussions of security in those two documents:

4.1.2 Explicit prefix delegation

   Several networks have already started using an explicit prefix
   delegation mechanism using DHCPv6 [RFC3633]. In this mechanism, the
   gateway uses a DHCP request to obtain a prefix from a DHCP server
   managed by the ISP. The DHCP server identifies the gateway, for
   example, through identification information provided by the gateway
   in the DHCP request message or by the port or circuit through which
   the DHCP request message is received.  The server can implement
   prefix delegation policies based on the identity of the requesting
   gateway.  According to the recommendations in RFCxxxx the ISP
   assigns a /48 to the customer. The gateway then automatically
   assign /64s out of this /48 to its internal links.

(Editorial notes:
 * I don't think the acronym "ISP" is defined anywhere in the document
 * There doesn't seem to be a citation of RFC 3315 anywhere in the document
 * There should be citations of RFC 2131 and RFC 2132 for DHCPv4)

   Security issues associated with DHCP and prefix delegation are
   addressed in the "Security Considerations" section of RFC 3315
   and RFC 3633, respectively.

4.1.3 Recommendation

   The ND proxy and DHCP methods appear to have different domains of
   application. ND proxy is a simple method that corresponds well to
   "informal sharing" of a link, while explicit delegation provides
   strong administrative control. The ND proxy mechanism has not yet
   been accepted as an Internet Standard and the interaction
   between neighbor discovery and ND proxy needs to be specified.

> 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...


It's also the only place in the document where specific security issues are
raised beyond the level of "Specific security issues should be studied and
addressed during the development of the specific mechanisms."


> 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.


Which is exactly the model employed in the equivalent problem of
address assignment today.  Why are the requirements for prefix
delegation stricter than for what is deployed today?

> 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...)


The common model today is to establish a separate security relationship
with different administrative domains and select the appropriate
relationship as needed.  The same strategy can be applied to prefix
delegation - if, indeed, any ISP actually deploys a network in which
customers really see each others traffic on a shared link.

> > > 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