Subject: RE: Authentication option

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 15:07:54 -0400

Ralph:

I didn't go back through the messages on this topic, so I apologize if this
has been discussed. But, I don't understand why anyone would ever want to
accept messages that fail the authentication validation. I can understand
using messages that do not have authentication information, but I can't
understand why one would want to use messages where the authentication is
corrupt or bogus (since I'd guess the rest of the packet is very suspect as
well).

I guess one argument FOR using this data is that if there are no other
servers available, getting an address might be 'good'. (I assume in this
case that the DHCPREQUEST would not be authenticated.) Though again, I'd
seriously question the validatity of the data if the authentification fails
to validate. Step 3 below might be clarified to read:

       3. The client replies with a DHCPREQUEST message that MUST include
          authentication information encoded with the same secret used by
          the server in the selected DHCPOFFER message if the authentication
	    was present and valid (otherwise, no authentication is used).

Also, note the typo (nt instead of not) in step 4.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 2:00 PM
To: DHCPv4 discussion list
Subject: RE: Authentication option

I read Barr's suggested text for 5.5.1 and reviewed the relevant mailing 
list messages, and wrote up the following candidate text to replace the 
current text in 5.5.1

I've included BARR's text for comparison.

- Ralph

5.5.1 INIT state

       When in INIT state, the client uses protocol 1 as follows:

       1. The client MUST include the authentication request option in
          its DHCPDISCOVER message along with the client identifier
          option (option code 61) [6] to identify itself uniquely to the
          server.

       2. The client MUST perform the validation test described in
          section 5.3 on any DHCPOFFER messages that include
          authentication information.  If one or more DHCPOFFER messages
          pass the validation test, the client chooses one of the offered
          configurations.

          Client behavior if no DHCPOFFER messages include authentication
          information or pass the validation test is controlled by local
          policy in the client.  According to client policy, the client
          MAY choose to respond to a DHCPOFFER message that has not been
          authenticated.

          The decision to set local policy to accept unauthenticated
          messages should be made with care.  Accepting an
          unauthenticated DHCPOFFER message can make the client
          vulnerable to spoofing and other attacks.  If local users are
          not explicitly informed that the client has accepted an
          unauthenticated DHCPOFFER message, the users may incorrectly
          assume that the client has received an authenticated address
          and is not subject to DHCP attacks through unauthenticated
          messages.

          A client MUST be configurable to decline unauthenticated
          messages, and SHOULD be configured by default to decline
          unauthenticated messages.  A client MAY choose to differentiate
          between DHCPOFFER messages with no authentication information
          and DHCPOFFER messages that do not pass the validation test;
          for example, a client might accept the former and discard the
          latter.  If a client does accept an unauthenticated message,
          the client SHOULD inform any local users and SHOULD log the
          event.

       3. The client replies with a DHCPREQUEST message that MUST include
          authentication information encoded with the same secret used by
          the server in the selected DHCPOFFER message.

       4. If the client authenticated the DHCPOFFER it accepted, the
          client MUST validate the DHCPACK message from the server.  The
          client MUST discard the DHCPACK if the message fails to pass
          validation and MAY log the validation failure.  If the DHCPACK
          fails to pass validation, the client MUST revert to INIT state
          and returns to step 1.  The client MAY choose to remember which
          server replied with a DHCPACK message that failed to pass
          validation and discard subsequent messages from that server.

          If the client accepted a DHCPOFFER message that did nt include
[nt --> not]
          authentication information or did not pass the validation test,
          the client MAY accept an unauthenticated DHCPACK message from
          the server.

At 02:21 PM 8/22/00 -0700, Barr Hibbs wrote:

>Bill et al.,
>
>I promised to try my hand at some text to cover the point about
notification
>of the user, so, here goes!
>
>--Barr
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
>=-=-=-=
>
>5.5.1 INIT state
>
>       When in INIT state, the client uses protocol 1 as follows:
>
>       1. The client MUST include the authentication request option in
>          its DHCPDISCOVER message along with option 61 [6] to identify
>          itself uniquely to the server.
>
>       2. The client MUST validate any DHCPOFFER messages that include
>          authentication information using the mechanism specified in
>          section 5.3.  The client MUST discard any messages which fail
>*****    to pass validation and MAY [SHOULD??] log the validation failure.
>          The client selects one DHCPOFFER message as its selected
>          configuration.  If none of the DHCPOFFER messages received by
>          the client include authentication information, the client MAY
>          choose an unauthenticated message as its selected
>          configuration.  The client SHOULD be configurable to accept or
>*****    reject unauthenticated DHCPOFFER messages.     The client SHOULD
>*****    log the acceptance of an unauthenticated message if it decides
>*****    to choose one.
>
>       3. The client replies with a DHCPREQUEST message that MUST include
>          authentication information encoded with the same secret used by
>          the server in the selected DHCPOFFER message.
>
>       4. The client MUST validate the DHCPACK message from the server.
>          The client MUST discard the DHCPACK if the message fails to
>          pass validation and MAY log the validation failure.  If the
>          DHCPACK fails to pass validation, the client MUST revert to
>          INIT state and returns to step 1.  The client MAY choose to
>          remember which server replied with a DHCPACK message that
>          failed to pass validation and discard subsequent messages from
>*****    that server.  If the client chooses to remember a failed
>*****   message authentication, it SHOULD log that decision, and
>*****   SHOULD revert to normal operation with respect to that server
>*****   after receiving a properly authenticated message from that server.
>
>5.5.2 INIT-REBOOT state
>
>       When in INIT-REBOOT state, the client MUST use the secret it used
>       in its DHCPREQUEST message to obtain its current configuration to
>       generate authentication information for the DHCPREQUEST message.
>       The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK
>       messages if no authenticated messages were received.  The client
>       MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
>***** messages as specified in section 3.2 of [1].  If the client chooses
>***** to accept unauthenticated messages from a server, it SHOULD log that
>***** decision.

---

From: "Ralph E. Droms" <[email-masked]>
Date: Wed, 30 Aug 2000 15:37:28 -0400 (EDT)

On Wed, 30 Aug 2000, Bernie Volz wrote:
> But, I don't understand why anyone would ever want to

OK - I read the consensus from the previous conversation as wanting to
allow local client policy to make the decision about both messages with no
authentication and messages that fail authentication.  I'm willing to
change the text if the WG wants to allow the former and disallow the
latter.

> Step 3 below might be clarified to read:
> 

That change makes sense...

> Also, note the typo (nt instead of not) in step 4.

Thanks for catching that typo.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2000 14:23:40 -0700

Hm.   I think one advantage of not accepting options that fail to
authenticate is that it forces people to fix their implementations if
they're broken.   A disadvantage is that if somebody has a really
broken implementation that gets widely deployed, and they won't fix
it, everybody else loses.   So I think making this configurable is
probably the better part of valor.

Another point is: what if the kind of authentication being used by the
server is not supported by the client, so authentication fails not
because it is incorrect, but because it's not decodable.   Is that the
same as an unauthenticated packet, or is it the same as an
authenticated packet whose authentication doesn't work?

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 30 Aug 2000 15:17:14 -0700

> From:  Ralph E. Droms
> Sent: Wednesday, August 30, 2000 12:37 PM
>
>
> > accept messages that fail the authentication validation.
> > I can understand using messages that do not have
> > authentication information, but I can't understand why
> > one would want to use messages where the authentication is
> > corrupt or bogus (since I'd guess the rest of the packet is
> > very suspect as well).
>
> OK - I read the consensus from the previous conversation as
> wanting to allow local client policy to make the decision
> about both messages with no authentication and messages that
> fail authentication.  I'm willing to change the text if the WG
> wants to allow the former and disallow the latter.
>
...my opinion is that clients and administrators probably do need a way to
deal with those situations where something is broken and authentication
doesn't work.  Bernie:  allowing a client to accept an unauthenticated
message while notifying the user seems no more suspect than using
unauthenticated clients and servers.  I believe it is better to specifically
allow this, insisting on useful notifications, than to ignore the
possibility that authentication may break.

> >        3. The client replies with a DHCPREQUEST message that
> >		  MUST include authentication information encoded
> >           with the same secret used by the server in the
> > 		  selected DHCPOFFER message if the authentication
...agreed

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 31 Aug 2000 10:59:54 -0700

>authenticated packet whose authentication doesn't work?

An authentication type mismatch isn't quite the same 
as an unauthenticated packet, because although you
don't have the ability to verify the authentication,
you do know that there is an authentication policy
mismatch. The case to worry about is where the client
demands a stronger form of authentication than the
server is willing to supply.

---

From: "William A. Arbaugh" <[email-masked]>
Date: Thu, 31 Aug 2000 20:58:05 -0400 (EDT)

> server is willing to supply. 
I propose the following:

1. An authentication mis-match should be treated in a similar fashion as
if the server did not include authentication information.  Any thing
further and we're going done the security association negotiation trail
(and it's a long one).

2. While I don't like the idea of accepting packets where the
authentication option failed to verify, the server could just as well have
sent the packet without authentication information and we would accept it
(assumming the client would accept un-authenticated packets).  Therefore,
I propose that:
	a. If the client is configured to accept un-authenticated packets,
then it MAY accept (if further configured) authenticated packets that
fail to verify.  We should stress that this is very dangerous and is only
done for the sake of robustness.
	b. If the client is configured NOT to accept un-authenticated
packets, then the client MUST NOT accept authenticated packets that fail
to verify.

Bill