Subject: Authentication option

From: Ralph Droms <[email-masked]>
Date: Thu, 17 Aug 2000 23:23:22 -0700

In the description of client behavior (section 5.5.1 of 
draft-ietf-dhc-authentication-14.txt), the current draft specifies that the 
client may not use any DHCPOFFER messages that fail the authentication 
validation:

   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 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.

I've received a suggestion that the use of DHCPOFFER messages that fail 
validation should be a client policy; that is, a client should be allowed 
to use those messages if, for instance, no DHCPOFFERs are received that 
pass validation.  Is it acceptable to the WG to make the suggested change?

- Ralph

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 18 Aug 2000 09:59:58 -0400

At 11:23 PM 8/17/00 -0700, Ralph Droms wrote:
>In the description of client behavior (section 5.5.1 of draft-ietf-dhc-authentication-14.txt), the current draft specifies that the client may not use any DHCPOFFER messages that fail the authentication validation:
>
>I've received a suggestion that the use of DHCPOFFER messages that fail validation should be a client policy; that is, a client should be allowed to use those messages if, for instance, no DHCPOFFERs are received that pass validation.  Is it acceptable to the WG to make the suggested change?

         This change sounds quite reasonable to me -- if the
         client is trying to authenticate DHCP servers, that in
         itself is a policy decision on the part of the client.
         Given that, if it chooses to then *not* require an
         authenticated DHCP server, that is perfectly reasonable.
         Of course, it *could* do this with a new,
         non-authenticated DHCPDISCOVER, but why bother?  That
         just increases network traffic to no useful end.

         As part of this change, the draft probably should include
         language that says "and the client SHOULD inform the
         user" that an unvalidated (or whatever you want to call
         it) DHCPOFFER was used.

         Kim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2000 11:19:16 -0400

> pass validation.  Is it acceptable to the WG to make the suggested change?

I think this is right, except that there are actually at least two
ways validation can fail: it can fail because the client doesn't have
the key needed to validate, and it can fail because the client has the
key, and the signature doesn't check out.   I don't know if it makes
sense to distinguish between these two cases, but perhaps it does - if
the signature doesn't check out, it probably means the client or
server is misconfigured, and should be fixed.

Also, it's fairly axiomatic in the security world that if
authentication fails, you make it very clear to whomever is depending
on authentication that it has failed, and let them decide how to
proceed (unless you have just defaulted to not proceeding at all).  It
would be bad to give the user the impression that everything's okay
when it's not.

			       _MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 18 Aug 2000 12:07:42 -0700

> -----Original Message-----
> From:  Ralph Droms
> Sent: Thursday, August 17, 2000 11:23 PM
>
> draft-ietf-dhc-authentication-14.txt), the current draft
> specifies that the client may not use any DHCPOFFER messages
> that fail the authentication validation:
>

...my only concern about wording that permits this is that we may be
permitting unsophisticated users to inadvertently open themselves to
vulnerabilities:
  1.  bogus server sends offer that fails authentication
  2.  client accepts offer, with bogus gateway address
  3.  bogus gateway sniffs packets, captures plaintext passwords, forwards
spam, etc.

Maybe if the text which allows this to be a local policy included a clear
warning of the risks and benefits of implementing it, and I suggest that
instead of "The client SHOULD be configurable to accept or reject
unauthenticated DHCPOFFER messages," the SHOULD be replaced with MAY.

Perhaps something like, "Clients with accept unauthenticated DHCPOFFER
messages MAY be unintentionally compromising their own security, or be
participating in malicious behavior such as distributed denial of service
attacks.  Local administrators should very carefully consider all risks
before permitting this client behavior."

--Barr

---

From: Thomas Narten <[email-masked]>
Date: Fri, 18 Aug 2000 15:24:54 -0400

>   3.  bogus gateway sniffs packets, captures plaintext passwords, forwards

yep. One way to handle this is to say you probably shouldn't do this,
here is why, the default configuration must be not to. But, the
current wording in the spec doesn't prevent the above threat anyway,
so I'm not sure that is the right wording either.

The current wording in the ID says that its a violation of the
authentication spec to use the information if it contains an
authentication option AND you can't authenticate it (for whatever
reason). This means if all the DHCPOFFERS include authentication
options, and you can't verify the authentication, you're out of
luck. The text does say, however, that in this case if there are
packets with WITHOUT authentication options, you can use those (as a
last resort). That seems a bit inconsistent, and wouldn't protect you
against the above threat anyway. So I don't view this is lessoning
overall security.

Also, you want to allow clients to ignore the authentication option
for backwards compatability with the deployed base.  Thus outlawing
this for new clients seems messed up too.

Thomas

---

From: "William A. Arbaugh" <[email-masked]>
Date: Fri, 18 Aug 2000 21:33:48 -0400 (EDT)

> server is misconfigured, and should be fixed.
We should distinguish these cases as a policy may decide to proceed
differently based on the failure mode.

> would be bad to give the user the impression that everything's okay
Agreed. We had log the event.  Perhaps we should make it stronger- inform
user?

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 21 Aug 2000 17:01:39 -0700

> From: William A. Arbaugh
> Sent: Friday, August 18, 2000 6:34 PM
>
> > [Ted Lemon]
> > ways validation can fail ....  I don't know if it makes sense to
> > distinguish between these two cases....
> >
> [Bill Arbaugh]
...damn!  Ted always has such good comments!  I agree with both assessments,
and that we should identify this as an area where local policy and other
implementation considerations are important.

> Agreed. We had log the event.  Perhaps we should make it stronger- inform
...again, this is an implementation and local policy matter, but I agree
that the text should identify the responsibility of the implementor to
provide unambiguous behavior.  Informing the user is useful in many
circumstances, but I've become wary of how to phrase things in an RFC -- for
fear that suggestions become hard requirements, or desirable behavior
ignored because of an imprecise specification of urgency.

Again, I'll try to re-read these sections to find some suggested wording....

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Aug 2000 22:09:51 -0700

> Agreed. We had log the event.  Perhaps we should make it stronger- inform

Well, of course it's dependent on context - you can't warn the user if
there is no user.   But I think this is what we want if it's
possible.   I don't know how one might suggest this in the
specification.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Aug 2000 06:26:26 -0400

>From RFC 2119, the definition of SHOULD:

     3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
        may exist valid reasons in particular circumstances to ignore a
	particular item, but the full implications must be understood and
	carefully weighed before choosing a different course.

In the case at hand, one could certain add a sentence pointing out
that in some cases there may not be an easily identifiable user...
	
Thomas

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 22 Aug 2000 14:21:34 -0700

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 Droms <[email-masked]>
Date: Wed, 30 Aug 2000 14:00:03 -0400

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

       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.

       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
          authentication information or did not pass the validation test,
          the client MAY accept an unauthenticated DHCPACK message from
          the server.