Subject: [dhcwg] [DHCPv6] Delayed Authentication Protocol v.s. Reconfigure Key Authentication Protocol

From: <[email-masked]>
Date: Fri, 13 Oct 2006 19:55:25 +0900

Hi all,

Before, I asked some questions regarding Reconfigure Key Authentication
Protocol in RFC3315.
And I got the knowledge that Reconfigure Key Authenctication Protocol
cannot provide protection 
for malicious Reconfigure message.
#Please refer attached e-mail.

But, RFC3315 says,
----------------
21.5. Reconfigure Key Authentication Protocol

   The Reconfigure key authentication protocol provides protection
   against misconfiguration of a client caused by a Reconfigure message
   sent by a malicious DHCP server. 
(snip)
----------------
I think that this description is incorrect.
We realize that this protocol cannot provide protection for malicious
DHCPv6 Server.
And I also think that we should not encourage to use this Protocol as
Authentication Method,
because of the weakness.
It is better to use Delayed Authentication Protocol as Authentication
Method rather than 
Reconfigure Key Authenctication Protocol.

Are there any benefit that can be gained from Reconfigure Key
Authentication Protocol?

What do you think?

Thank you for your help every time.
Best regards,
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation

Subject: Re: [dhcwg] [Question]Is this behavior of the Reconfigure Key Authentication Protocol correct?
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Sat, 1 Apr 2006 09:33:47 +0900

Hideshi-san - Your observaation is correect: the authentication key for
reconfiguration assumes that the key cannot be intercepted and used for
sending malicious Reconfigure messages.

- Ralph

On 3/10/06 7:09 AM, "Hideshi Enokihara" <[email-masked]>
wrote:

> Hi all,
> 
> I have some questions regarding Reconfigure Key Authentication Protocol.
> 
> Is this behavior(like following) of the Reconfigure Key Authentication
> Protocol correct?
> ---------------------------------
> 
>        Server  Client
>         |       |
>         |       |
>         | <---- | Solicit
>         | ----> | Advertise
>         | <---- | Request with Reconfigure Accept Option
>         | ----> | Reply with Reconfigure Accept Option
>         |       |       and Authentication Option  (*1)
>         |       |
>         |       |
>         | ----> | Reconfigure with comptuted Authentication (*2)
>         | <---- | Renew or Information-Request (*3)
>         |       |  (depend on Reconfigure message's(*2's) msg-type)
>         | ----> | Reply (*4)
> 
> (*1):The server transmits the 128 bits Reconfigure Key
>      in Authentication option to the clinet.
> (*2):The server computes an HMAC-MD5 of the Reconfigure message
>      using the Reconfigure Key and includes the HMAC-MD5
>      in the authentication information field in an Authentication option
>      included in the Reconfigure message sent to the client.
> (*3):To authenticate a Reconfigure message, the client computes
>      an HMAC-MD5 over the DHCP Reconfigure message,
>      using the Reconfigure Key received from the server,
>      and the client transmits the Renew or Information-Request message
>      without Authentication option to the Server.
> (*4):The server transmits the Reply message without Authentication option.
> ---------------------------------------
> [Question1]
> Is this behavior correct?
> 
> 
> If this behavior is correct, I also have a question in step (*1).
> 
> [Question2]
> If a malicious DHCP server intercepts the Reply message(*1),
> the malicious DHCP server can get Reconfigure Key, I think.
> Then, the malicious DHCP server can send the Reconfigure message with
> fallacious information.
> 
> If this situation happens, I think that the effectiveness of Reconfigure Key
> Authentication Protocol is lost.
> 
> What do you think?
> What is the purpose of Reconfigure Key Authentication Protocol?
> 
> Best Regards,
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg