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

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 30 Mar 2004, Ralph Droms wrote:
> 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?

The requirements aren't.  The specifications are not.  DHCPv4 does not
even try to provide any security.  DHCPv6 goes at great length to do
that.  DHCPv6 Prefix Delegation specified using authentication as a
SHOULD.  It's pretty important to be able to conform to that SHOULD.

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

You cannot run other protocols (e.g., key management protocols) unless
you have IP addresses, so this is at least somewhat relevant.  Of
course, as the current authentication scheme relies on off-band
mechanisms, but if those were found to be problematic, automation
might help.  But that is rather difficult, lacking IP addresses (or at
least non-LL addresses).


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

Sounds reasonable.
 
> (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)

I'd maybe add here:

      In a typical scenario, the link between the user and the ISP is 
      point-to-point, set up using some (semi-)trusted mechanism, and 
      DHCP authentication is not deemed necessary.  In some other 
      cases, the link is shared between the users, but the customers
      are isolated from each other using special techniques such as 
      proxy ARP; in these scenarios, DHCP authentication may not be 
      required either.  However, there are a few rather rare cases 
      where the customers really share a network, and in such a 
      network DHCP authentication is required; key management, 
      however, may prove a challenge.

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

I don't think the security issues have been sufficiently addressed in
those documents.
 
> 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.

The latter part is confusing as well.  DHCPv6 is not an "Internet 
Standard" either :-).  Actually I don't even understand what you're 
trying to say.  Instead e.g.:

 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 specification of of ND-proxy 
     is still in progress, and aimed at Informational category, rather 
     than Standards Track.

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

If you have pointers about problems with other mechanisms, please
raise them.  Note that in most cases, the mechanisms are still under
development (Teredo, tunnel broker, etc.) or being studied
security-wise (6to4).  DHCPv6 is an example for which these issues 
haven't been raised yet, so this seems like a place to do so.

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

If DHCPv6 includes a feature, and DHCPv6 PD requires it's used with a
SHOULD, it should be feasible to do so.  If a feature is made
available, it should also be possible to use it in the cases where
it's relevant.
 
> > > 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.

Again, this is more complex than in some other protocols 
because automating key management is difficult -- see 
draft-bellovin-mandate-keymgmt-00.txt.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings