Subject: Authentication draft- INFORM message details

From: "William A. Arbaugh" <[email-masked]>
Date: Mon, 24 May 1999 14:10:08 -0400 (EDT)

I'm finishing up the edits and additions to the draft based on the input
from the last meeting.  Before I send around the entire draft for review,
I want to run the details on the INFORM message for protocol 1 (shared
secret MAC) by everyone. I've attached the paragraph below. Please comment
directly to me or the list. The executive summary is that authentication
on INFORM messages should be policy based.  The server can decide to
accept or reject unauthenticated INFORM messages.

DHCPINFORM: Client behavior

Since the client already has some configuration information, the client
may also have established a shared secret value, K, with a server or
servers. Therefore the client SHOULD use the authentication request as in
a DHCPDISCOVER message when a shared secret value exists. The client MUST
treat any received DHCPACK messages as it does DHCPOFFER messages, see
Section 4.1.

DHCPINFORM: Server behavior

The server MAY choose to accept unauthenticated DHCPINFORM messages, or
only accept authenticated DHCPINFORM messages. 

When a client includes the authentication request in a DHCPINFORM message,
the server MUST respond with an authenticated DHCPACK message. If the
server does not have a shared secret value established with the sender of
the DHCPINFORM message, then the server MUST respond with an
unauthenticated DHCPACK message (see discussion below).

DISCUSSION: It would be nice if the server could respond with a DHCPNACK
rather than an unauthenticated DHCPACK, but my reading of  2131 indicates
that this is not possible without changing the state machine. Please
correct me if I am wrong.