Subject: [dhcwg] Security for leasequery messages

From: Ralph Droms <[email-masked]>
Date: Tue, 06 Apr 2004 19:56:12 -0400

The following issues relate to security for leasequery messages:

Steve Bellovin:

Discuss:
(26 March 2004)
The Security Considerations section says this:

    DHCP servers SHOULD prevent exposure of location information
    (particularly the mapping of hardware address to IP address lease,
    which can be an invasion of broadband subscriber privacy) by
    employing some form of relay agent authentication between the
    DHCPLEASEQUERY client and the DHCP server.

    Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
    path to the DHCP server is secure.  Clients SHOULD use Relay Agent
    Information security as a way to achieve this goal.

What is "some form of ... authentication"?  What is "Relay Agent Information
security"?  Put another way, what is mandatory to implement?

Russ Housley:

Discuss:
   Section 7 says:
   >
   > DHCP servers SHOULD prevent exposure of location information
   > (particularly the mapping of hardware address to IP address lease,
   > which can be an invasion of broadband subscriber privacy) by
   > employing some form of relay agent authentication between the
   > DHCPLEASEQUERY client and the DHCP server.
   >
   There needs to be more discussion of the authentication requirements.
   I would prefer the specification to name a mandatory-to-implement
   mechanism, but that may be asking too much.

   Section 7 also says:
   >
   > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
   > path to the DHCP server is secure.
   >
   What security services are needed?  Integrity, authentication, access
   control, replay protection confidentiality?  The hint about Relay Agent
   Information security, with no reference, is not sufficient.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 07 Apr 2004 16:38:19 -0400

Folks,

This is clearly an issue, and there are no easy answers.
Here is one approach:

Nothing is mandatory to implement, since one approach is to
ensure that there is physical security between the access
concentrator and the DHCP server.

A better approach is to use some form of the not-yet-fully-baked
relay agent authentication.  For example:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-03.txt

but since this is still coming along, it can't be mandatory,
that's for sure.  We could wait to standardize leasequery until
something was approved for relay agent authentication, but that
will further delay something that has already undergone numerous
delays.  There are large number of similar-to-the-standard
leasequery installations, and more every day.  It would be nice
to bring them all into compliance over time, and time is
getting away from us.

One approach would be to make something mandatory once that
something exists, which is a little odd but perhaps doable.  We
might be able to say:

        "When some form of relay-agent to DHCP server
        authentication becomes a standard, its use for leasequery
        becomes mandatory."

Something to consider.

Any other ideas for handle this one?

Cheers -- Kim

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 9 Apr 2004 12:10:32 -0400

Seems like a good approach ... But will the IESG be happy with it?

Today, there's always the basic security of only allowing the requests
from specific addresses (and since it is the reply that has the
interesting information, spoofing the sender doesn't buy you that much).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kim Kinnear
Sent: Wednesday, April 07, 2004 4:38 PM
To: Ralph Droms; [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Security for leasequery messages

Folks,

Nothing is mandatory to implement, since one approach is to ensure that
there is physical security between the access concentrator and the DHCP
server.

A better approach is to use some form of the not-yet-fully-baked relay
agent authentication.  For example:

but since this is still coming along, it can't be mandatory, that's for
sure.  We could wait to standardize leasequery until something was
approved for relay agent authentication, but that will further delay
something that has already undergone numerous delays.  There are large
number of similar-to-the-standard leasequery installations, and more
every day.  It would be nice to bring them all into compliance over
time, and time is getting away from us.

One approach would be to make something mandatory once that something
exists, which is a little odd but perhaps doable.  We might be able to
say:

Something to consider.

Cheers -- Kim

At 07:56 PM 4/6/2004, Ralph Droms wrote:
>What is "some form of ... authentication"?  What is "Relay Agent 
>Information security"?  Put another way, what is mandatory to 
>implement?
>
>Russ Housley:
>
>Discuss:
>  Section 7 says:
>  >

> > path to the DHCP server is secure.  >

---

From: Josh Littlefield <[email-masked]>
Date: Fri, 09 Apr 2004 13:35:27 -0400

Is IPSec for DHCP relay to server communication any more fully baked?  Isn't 
that draft just documenting what is already possible, rather than proposing 
something new?

Wouldn't another approach be to use RFC 3118?  In this case, we aren't talking 
about relayed messages, we're talking about directed messages from a 
relay/access concentrator to the server (and back), with non-zero giaddr.  Seems 
to me there's no reason RFC 3118 couldn't secure these messages based on shared 
secret.

Bernie Volz wrote:

>> control, replay protection confidentiality?  The hint about Relay
> 
> Agent
> 

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: same               Boxborough, MA  01719-2205

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Apr 2004 20:52:52 -0700

On Apr 9, 2004, at 10:35 AM, Josh Littlefield wrote:
> Wouldn't another approach be to use RFC 3118?  In this case, we aren't 
> talking about relayed messages, we're talking about directed messages 
> from a relay/access concentrator to the server (and back), with 
> non-zero giaddr.  Seems to me there's no reason RFC 3118 couldn't 
> secure these messages based on shared secret.

That's a good point - RFC3118 is actually a credible answer to the 
problem of securing server<->concentrator communication, because in 
most cases it is not a problem to use one or only a few shared keys in 
this context, where it's completely lame to do so in the context of a 
large set of DHCP end-users.