RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Bernie Volz (volz)
How about we address issue 1 by expanding the DHCID RR type code. We
have 16-bits and we're just using 4 values presently. There's plenty of
room for future expansion *SHOULD* someone come along and demand a new
algorithm in the future. I can't see why this would EVER occur since
this really isn't about strong cryptographic protection (we're just
trying to make it non-trivial to find a client's identity by not storing
it in clear text).

In the -10 draft, Section 3.3 is:

3.3.  The DHCID RR Type Codes

   The DHCID RR Type Code specifies what data from the DHCP client's
   request was used as input into the hash function.  The type codes are
   defined in a registry maintained by IANA, as specified in Section 7.
   The initial list of assigned values for the type code is:

   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
   0x0001 = The data portion from a DHCPv4 client's Client Identifier
      option [9].
   0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
      client's Client Identifier option [10] or the DUID field from a
      DHCPv4 client's Client Identifier option [12]).

   0x0003 - 0xfffe = Available to be assigned by IANA.

   0xffff = RESERVED

---

Replace with:

3.3.  The DHCID RR Type Codes

   The DHCID RR Type Code specifies what data from the DHCP client's
   request was used as input into the hash function and the hash
   function used.  The type codes are defined in a registry maintained
   by IANA, as specified in Section 7. The initial list of assigned
   values for the type code is:

   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7] and
      MD5 hash.
   0x0001 = The data portion from a DHCPv4 client's Client Identifier
      option [9] and MD5 hash.
   0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
      client's Client Identifier option [10] or the DUID field from a
      DHCPv4 client's Client Identifier option [12]) and MD5 hash.

   0x0003 - 0xfffe = Available to be assigned by IANA.

   0xffff = RESERVED

---

Note: I used MD5 since that is what the drafts presently specify.

This does mean that using the existing update mechanisms as described in
the conflict resolution draft will only work if all servers (and clients
doing updates) use the same hash algorithm as specified today.

But I don't see that being an issue as again, I suspect we'll never
change the algorithm. And, if we do, we can revise the update procedure
when the draft specifying the new DHCID RR types / algorithm is written.

I think this provide Sam his desired ability to rev the algorithm
without having to use a new DHCID RR type. And, it avoids complicating
the current update producure unnecessarily.

- Bernie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Sam Hartman
> Sent: Tuesday, November 29, 2005 2:48 PM
> To: Mark Stapp (mjs)
> Cc: [hidden email]; [hidden email]; [hidden email];
> Steven M. Bellovin; [hidden email]; Pekka Savola; Ted Lemon
> Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'Resolution of FQDN Conflicts among DHCP Clients' to
> Proposed Standard]
>
> >>>>> "Mark" == Mark Stapp <[hidden email]> writes:
>
>
>     Mark> would such a clarification be "enough" to resolve your
>     Mark> DISCUSS, Sam Hartman? that is, if it were clearer that we're
>     Mark> only aiming for more difficult than not difficult at all -
>     Mark> would that be sufficiently clear guidance to admins about
>     Mark> what they should expect from this mechanism?
>
> So, as I described in my response to  Russ, I'm asking for
> three things:
>
> 1) algorithm agility
>
> 2) Remove the paragraph explaining why md5 is OK or provide a
>    theoretical model under which we can reason about how good a hash
>    is at keeping stuff private.
>
> 3) Use sha-1 or sha-256 instead of md5.
>
>
> I feel very strongly about point 1.  Unfortunately I think this is the
> point the working group most objects to.  I understand the concerns
> about the complexity of the update process.  However I also know that
> security primitives are things that you need to replace from time to
> time.  If you were using md5 because it had a relatively even
> distribution of outputs you could probably convince me that you don't
> need a way to update it.  However even if weakly you're using md5 for
> its cryptographic properties.  Those can change over time so you need
> a mechanism to react to those changes.
>
>
> I suspect we can all agree that we need to either reword claims about
> security of cryptographic primitives so they are clearly true or
> remove those claims.  So I don't think that we're going to have much
> of an issue with point 2.
>
> I think there is room for discussion on point 3.  I think sha-1 or
> sha-256 would be a better choice.  I think that there is an argument
> that md5 is not so bad that it cannot be used.  If the working group
> ends up responding that it would really like to use md5, I can go to
> the security community and see what people think there.
>
> --Sam
>
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Jeffrey Hutzelman


On Thursday, December 01, 2005 08:48:10 AM -0500 "Bernie Volz (volz)"
<[hidden email]> wrote:

> How about we address issue 1 by expanding the DHCID RR type code. We
> have 16-bits and we're just using 4 values presently. There's plenty of
> room for future expansion *SHOULD* someone come along and demand a new
> algorithm in the future. I can't see why this would EVER occur since
> this really isn't about strong cryptographic protection (we're just
> trying to make it non-trivial to find a client's identity by not storing
> it in clear text).

I think that's a good start; in fact, I was going to propose something very
similar.  This solves half the problem; particularly, it makes it possible
to indicate that some other hash is in use.  It does bind the hash to the
type, rather than allowing them to be specified orthogonally, but I don't
think that's a major problem.  If it ever becomes an issue, there should be
no problem defining a type where the next 16 bits indicate a subtype and
the 16 bits after that indicate a hash.

However, it doesn't solve the other half of the problem, which is present
even without considering changing hash algorithms.  The problem is that for
any given fqdn and DHCP client, there are multiple possible DHCID RR's; in
particular, one for each type.  In order the update mechanism to work
without requiring either an advance query or multiple update attempts, all
possible updaters must agree in advance on the type in use.  This lack of
negotiation seems problematic to me, even in the absence of multiple hash
algorithms.

-- Jeffrey T. Hutzelman (N3NHS) <[hidden email]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

RE: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Bernie Volz (volz)
In reply to this post by Bernie Volz (volz)
If you're going to have multiple DHCP servers, such as failover pairs,
doing the DNS updates, you need to have those servers agree on how they
will identify the clients. This is not JUST for DNS updates. Failover
partners need to use the same identifiers for clients.

So, this is really not an issue.

The rules are pretty clearly described in the RFC:

For DHCPv4:
1. Use the DUID if the client identifier option is provided by the
client and it is a DUID and the server supports it. This is a new RFC
that is in the RFC-editor queue so no clients and servers yet support
this.
2. Otherwise, use the client identifier option if provided by the
client,
3. Otherwise, use htype and chaddr.

For DHCPv6:
1. Use the DUID of the client.

There really is no mystery here.

- Bernie

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[hidden email]]
> Sent: Sunday, December 04, 2005 11:43 PM
> To: Bernie Volz (volz); Sam Hartman; Mark Stapp (mjs)
> Cc: [hidden email]; [hidden email]; Pekka Savola;
> Ted Lemon; [hidden email]; [hidden email]; Steven M. Bellovin;
> Jeffrey Hutzelman
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call:'Resolution of FQDN Conflicts among DHCP Clients' to
> Proposed Standard]
>
>
>
> On Thursday, December 01, 2005 08:48:10 AM -0500 "Bernie Volz (volz)"
> <[hidden email]> wrote:
>
> > How about we address issue 1 by expanding the DHCID RR type code. We
> > have 16-bits and we're just using 4 values presently.
> There's plenty of
> > room for future expansion *SHOULD* someone come along and
> demand a new
> > algorithm in the future. I can't see why this would EVER occur since
> > this really isn't about strong cryptographic protection (we're just
> > trying to make it non-trivial to find a client's identity
> by not storing
> > it in clear text).
>
> I think that's a good start; in fact, I was going to propose
> something very
> similar.  This solves half the problem; particularly, it
> makes it possible
> to indicate that some other hash is in use.  It does bind the
> hash to the
> type, rather than allowing them to be specified orthogonally,
> but I don't
> think that's a major problem.  If it ever becomes an issue,
> there should be
> no problem defining a type where the next 16 bits indicate a
> subtype and
> the 16 bits after that indicate a hash.
>
> However, it doesn't solve the other half of the problem,
> which is present
> even without considering changing hash algorithms.  The
> problem is that for
> any given fqdn and DHCP client, there are multiple possible
> DHCID RR's; in
> particular, one for each type.  In order the update mechanism to work
> without requiring either an advance query or multiple update
> attempts, all
> possible updaters must agree in advance on the type in use.  
> This lack of
> negotiation seems problematic to me, even in the absence of
> multiple hash
> algorithms.
>
> -- Jeffrey T. Hutzelman (N3NHS) <[hidden email]>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Ted Lemon-2
In reply to this post by Jeffrey Hutzelman
On Sunday 04 December 2005 21:42, Jeffrey Hutzelman wrote:
> In order the update mechanism to work
> without requiring either an advance query or multiple update attempts, all
> possible updaters must agree in advance on the type in use.  This lack of
> negotiation seems problematic to me, even in the absence of multiple hash
> algorithms.

The whole point of this protocol is that the rendezvous point is the DNS.   So
if you make the algorithm for computing the DHCID variable based on a
configuration setting on the DHCP server, then you have to accept  that two
DHCP servers that are configured to use different hash algorithms will not
interoperate.   This is not currently the case with the different DHCID
types, because the algorithm used depends on what the client sends, and we
can safely assume that the client will always send the same thing; if it does
not, then according to RFC2131/2132, it is not the same client.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Jeffrey Hutzelman
In reply to this post by Bernie Volz (volz)


On Sunday, December 04, 2005 11:58:25 PM -0500 "Bernie Volz (volz)"
<[hidden email]> wrote:

> If you're going to have multiple DHCP servers, such as failover pairs,
> doing the DNS updates, you need to have those servers agree on how they
> will identify the clients. This is not JUST for DNS updates. Failover
> partners need to use the same identifiers for clients.

The document I read identifies several possible situations in which DHCID
records are used to coordinate between updaters which are not DHCP failover
partners.  It discusses a scenario in which multiple clients may attempt to
issue updates for the same name (and, presumably, in which more than one
client is authorized to issue such an update; otherwise, there would be no
problem), and one in which a client moves between subnets served by
different DHCP servers, both of which are authorized issue updates for the
client's FQDN.

You can plausibly argue that the two DHCP servers in the second scenario,
while not failover partners, are nonetheless part of the same
administrative domain and require coordination.  Such an argument seems a
little weak to me, but if that were the only issue, I could live with it.

I suppose you can also argue that two clients configured to use the same
name will (by design) not produce the same DHCID RR's even if they use the
same type, and therefore there's not a problem if they use different types.
That I'll definitely buy.

However, what about a scenario where both a client and the DHCP server on
its home network are authorized to do the updates.  When the client is at
home, it lets the server do the update.  When it is off-site at an IETF
meeting, the IETF DHCP server has no authorization to update the client's
fqdn, so the client must do so itself.  Now, if the client and its home
DHCP server disagree on which type to use, then the update may fail.


> The rules are pretty clearly described in the RFC:
>
> For DHCPv4:
> 1. Use the DUID if the client identifier option is provided by the
> client and it is a DUID and the server supports it. This is a new RFC
> that is in the RFC-editor queue so no clients and servers yet support
> this.
> 2. Otherwise, use the client identifier option if provided by the
> client,
> 3. Otherwise, use htype and chaddr.

The rules are clear, but require that all possible updaters have the same
view of the world.  Consider the client I described above, which identifies
itself with a DUID.  So, as far as the client knows, it should follow rule
1 and use the DUID to form a DHCID record.  Unfortunately, the client's
home DHCP server doesn't support DUID's, so it skips rule 1 and follows
rule 2, using the client identifier.

It gets worse when you start adding new types after DHCID support is widely
deployed.  In fact, you arguably have that problem already, since a client
supporting this option doesn't know whether its home server even supports
the DHCID RR, as opposed to using the TXT record method.


If you think my example involving both a client and a server is contrived,
consider a client which always does its own updates.  When such a client is
updated, it may begin supporting new DHCID record types.  It may begin
supporting DUID's, or even be required to switch from non-DUID client
identifiers to DUID's because it now supports IPv6.  In each of these
cases, the client will fail to perform an update because its new DHCID
value is different from the old one.  You can require the client to give up
its lease and remove the record prior to shutting down, but such a
requirement is fragile because a client may shut down unexpectedly, with no
chance to send a DDNS update first.



In short, as long as the only authorized updaters are a set of carefully
coordinated DHCP servers which never receive configuration changes or
software upgrades, everything works.  Once you introduce clients (which by
their nature are unpredictable) or support for new DHCID types, the
negotiation problem becomes an issue.  It's possible to work around by
performing an extra query to determine what DHCID type is in use, but you
seem to want to avoid that.


-- Jeff

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf