Implementation of DHCPv6 authentication

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:rdromscisco.com] 
> Sent: Friday, December 01, 2006 11:03 PM
> To: dhcwg
> Cc: Enokihara, Hideshi (Hideshi.Enokiharajp.yokogawa.com)
> Subject: Implementation of DHCPv6 authentication
> 
> 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
> <Hideshi.Enokiharajp.yokogawa.com>.  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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hideshi Enokihara,

Hideshi.Enokiharajp.yokogawa.com wrote:
> 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 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFFdU38MsfZxBO4kbQRAhe3AJ9kwOqepzOEgComrPFE3sEx0cTPagCg
jlIi
5tPMUw4lzjhjzPFswRwlvmw=
=IQLy
-----END PGP SIGNATURE-----

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

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

> -----Original Message-----
> From: Shane Kerr [mailto:Shane_Kerrisc.org] 
> Sent: Tuesday, December 05, 2006 7:46 PM
> To: Enokihara, Hideshi (Hideshi.Enokiharajp.yokogawa.com)
> Cc: rdromscisco.com; dhcwgietf.org
> Subject: Re: [dhcwg] RE: Implementation of DHCPv6
authentication
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hideshi Enokihara,
> 
> Hideshi.Enokiharajp.yokogawa.com wrote:
> > 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 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

> 
>
iD8DBQFFdU38MsfZxBO4kbQRAhe3AJ9kwOqepzOEgComrPFE3sEx0cTPagCg
jlIi
> 5tPMUw4lzjhjzPFswRwlvmw=
> =IQLy
> -----END PGP SIGNATURE-----
> 

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hideshi,

Hideshi.Enokiharajp.yokogawa.com wrote:
> 
>> 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?

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFFd+7/MsfZxBO4kbQRAqlXAKC6fVGNR5SyYV2J4Qo7WkVaCNNWZwCf
RuqC
euHWZGxQEh8+UMxMYStLoJc=
=SH6w
-----END PGP SIGNATURE-----

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg