Subject: [dhcwg] Implementation of DHCPv6 authentication

From: Ralph Droms <[email-masked]>
Date: Fri, 01 Dec 2006 09:03:26 -0500

Hideshi Enokihara and the IPv6 Ready Logo team are considering the
requirements for DHCPv6 authentication in the DHCPv6 IPv6 Ready logo
program.  He's trying to determine the availability of DHCPv6
authentication, both the Delayed Authentication Protocol (RFC 3315, sec.
21.4) and the Reconfigure Key Authentication Protocol (RFC 3315, sec. 21.5).
If you have knowledge of the availability of these protocols in existing or
planned DHCPv6 implementations, please respond directly to
<[email-masked]>.  All responses will be used only for
analysis of DHCPv6 IPv6 Ready requirements and individual responses will be
kept confidential.

Thanks...

- Ralph

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

---

From: <[email-masked]>
Date: Tue, 5 Dec 2006 17:18:35 +0900

Hi all,

Now, I'm working for making conformance test specification for DHCPv6
Logo in IPv6 Ready Logo Program (www.ipv6ready.org).

Logo committee has decided to cover Reconfiugre function(message) as
DHCPv6 Logo requirements.
So, we'd like to know the availavility of DHCPv6 authentication
protocols both the Delayed Authentication Protocol and the Reconfigure
Key Authentication Protocol.
Do you have some plan to support the Delayed Authentication Protocol
and/or the Reconfigure Key Authentication Protocol for
sending/receiveing Reconfigure message?
Do you know some implementations that support DHCPv6 authenticaiton
protocols for Reconfigure message?

These informations obtained form you will be used to make the DHCPv6
Logo specification,
which Auhtentication protocol should be covered, both should be covered
or one of thme should be coverd?

I'm waiting for your full cooperation.

#Thank you very much for your help > Ralph

Best regards,

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Friday, December 01, 2006 11:03 PM
> To: dhcwg
> Cc: Enokihara, Hideshi ([email-masked])
> Subject: Implementation of DHCPv6 authentication
>

---

From: Shane Kerr <[email-masked]>
Date: Tue, 05 Dec 2006 11:46:21 +0100

Hideshi Enokihara,

> or one of thme should be coverd?

I think there are not many useful cases for DHCPv6 (and DHCP) authentication.

A typical case might be to use client authentication for a few important hosts
in a network. Here there are a few benefits, like preventing other clients from
seeing the configuration or being able to use the DHCP server to update DNS.

But, I do not think a shared-secret authentication mechanism has much general
applicability for DHCP. Authenticating the server in an environment where every
client has the server key seems futile... or is the idea to give a different
server key for each client? In any case, having to configure a client is kind of
contrary to the goals of DHCP.

FWIW, we are planning on supporting DHCP (and DHCPv6) authentication on ISC
DHCP, but it has not been a high priority.

- --
Shane

---

From: <[email-masked]>
Date: Thu, 7 Dec 2006 13:48:14 +0900

Hi Shane,

Thank you for your reply.

> FWIW, we are planning on supporting DHCP (and DHCPv6) 
> authentication on ISC DHCP, but it has not been a high priority.

Which authentication protocols are you planning to support?
Delayed Authentication protocol and/or Reconfigure Key Authentication
protocol?

Thank you for your cooperation.

Best regards,

...Hideshi

> From: Shane Kerr [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 7:46 PM
> To: Enokihara, Hideshi ([email-masked])
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] RE: Implementation of DHCPv6 authentication
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hideshi Enokihara,
> 
> > Logo specification, which Auhtentication protocol should be 
> covered, 
> > both should be covered or one of thme should be coverd?
> 
> A typical case might be to use client authentication for a 
> few important hosts in a network. Here there are a few 
> benefits, like preventing other clients from seeing the 
> configuration or being able to use the DHCP server to update DNS.
> 
> But, I do not think a shared-secret authentication mechanism 
> has much general applicability for DHCP. Authenticating the 
> server in an environment where every client has the server 
> key seems futile... or is the idea to give a different server 
> key for each client? In any case, having to configure a 
> client is kind of contrary to the goals of DHCP.
> 
> FWIW, we are planning on supporting DHCP (and DHCPv6) 
> authentication on ISC DHCP, but it has not been a high priority.
> 
> - --
> Shane
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFdU38MsfZxBO4kbQRAhe3AJ9kwOqepzOEgComrPFE3sEx0cTPagCgjlIi
> 5tPMUw4lzjhjzPFswRwlvmw=
> =IQLy
> -----END PGP SIGNATURE-----
>

---

From: Shane Kerr <[email-masked]>
Date: Thu, 07 Dec 2006 11:37:51 +0100

Hideshi,

> Delayed Authentication protocol and/or Reconfigure Key Authentication

To be clear, we don't actually have resources allocated or timelines defined for
authentication support. I believe we will support all DHCP RFCs, obviously some
sooner than others.

The ISC DHCP server won't send Reconfigure messages on the first public release
that supports DHCPv6. (Our server model makes on-the-fly configuration changes
difficult. We can check for changes in configuration on restart, but do not do
that now, and it is non-trivial to implement.)

If we have demand for authentication, then we'll probably support Delayed
Authentication before implementing Reconfigure at all.

If we have demand for Reconfigure support, then we'll probably implement
Reconfigure first. Because of the potential security issues, I think we would
likely also implement Reconfigure Key Authentication at that time.

I do *not* think there will be much demand for authentication, or Reconfigure
support, because of the reasons outlined in my previous mail. But I have been
wrong before... :)

- --
Shane