Subject: [dhcwg] questions about DHCPv6 authentication

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jun 2004 16:18:51 +0900

(Trying to resend it from a different mail address...sorry if this is
a duplicate.)

Hello,

I have a couple of questions on DHCPv6 authentication described in
RFC3315 (Section 21).

1. the RFC says in 21.4.4.4 as follows:

    21.4.4.4. Sending Information-request Messages

    If the server has selected a key for the client in a previous message
    exchange (see section 21.4.5.1), the client MUST use the same key to
    generate the authentication information throughout the session.

  I don't really understand this part...does this assume a separate
  Solicit-Advertise (or Reply if rapid-commit option is used?)
  exchanges to negotiate the key?  If so, what if the server and/or
  the client only implement the "stateless" subset described in
  RFC3736?  Note that RFC3736 says:

    Authenticated DHCP, as described in
    sections 21 and 22.11 of the DHCP specification [1], can be used to
    avoid attacks mounted through the stateless DHCP service.

  I read this to mean that Authenticated DHCP can be used for
  implementations only support RFC3736.  But how can such
  implementations select the key without the "previous message
  exchange"?

2. RFC3315 says in Section 21.4.2 (Message Validation) that

     If the MAC
     computed by the receiver does not match the MAC contained in the
     authentication option, the receiver MUST discard the DHCP message.

   It seems to me this part of the specification some other parts of
   Section 21.4:

   2-1) in Section 21.4.4.2, the RFC allows the client to respond to
        an Advertise even if it fails on authentication:

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

        Doesn't this contradict with Section 21.4.2?

   2-2) this can be a more serious issue.  The RFC says in Section
        21.4.4.4 that:

          If the Reply
          fails to pass the validation test, the client MUST restart the DHCP
          configuration process by sending a Solicit message.

        Doesn't this contradict with Section 21.4.2?  Moreover, it
        seems to me that restarting the configuration process in this
        case can open up a possibility of DoS attack.  What is the
        background of this specification?

Any hints or answers would be highly appreciated.  Thanks in advance,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Christian Strauf <[email-masked]>
Date: Thu, 17 Jun 2004 12:53:18 +0200

Excuse possible dupes, I had trouble with my mailer.

Jinmei-san,

>   implementations select the key without the "previous message
the key distribution is done out-of-band, as stated in section 21.4.3.
Therefore, no inital exchange for key distribution is necessary. The way I
understand this section is that clients must keep using the same key they've
been using for any previous message exchange that included an authentication
option. Stateless DHCPv6 clients are free to use authentication options with
pre-shared keys the same way that RFC3315 clients do.

>         Doesn't this contradict with Section 21.4.2?
Yes, partly. I think the part that is contradictory is "[...] or pass the
validation test [...]". This section clearly -- as you correctly identified in
my eyes -- contradicts the quoted part of 21.4.2 above. I agree that a failed
validation test is very critical and should not be open to local policy (i.e.
no responses to these advertise messages should be made by the client in any
case).

The other part ("[...] no Advertise messages include authentication information
[...]") may indeed be a matter of local policy.

>         background of this specification?
I think that it doesn't contradict section 21.4.2 but as a matter of fact is a
logical consequence if validation tests fail. However, I agree 100% that this
is a potentially dangerous behaviour because it can be used for DoS attacks on
servers and clients. I think that this deserves to be addressed in the Security
Considerations section because appropriate timeouts or similar should be in
place to prevent this kind of attack by malicious hosts that send malformed
replies that will fail validation tests.

> Any hints or answers would be highly appreciated.  Thanks in advance,
I hope that you find my comments useful.

Christian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 18 Jun 2004 16:23:32 +0900

Thanks for the response.

>>>>> On Thu, 17 Jun 2004 12:53:18 +0200, 
>>>>> Christian Strauf <[email-masked]> said:

>> RFC3736?  Note that RFC3736 says:

(snip)

> Therefore, no inital exchange for key distribution is necessary.

I know that.  Perhaps I was not clear enough, but I meant the
following process by "negotiation the key":

(we assume both the client and the server have a shared secret.  It's
okay)

- the client sends a solicit message with an authentication option.
- the server chooses one particular key identified by <DHCP realm,
  client DUID, key id>
- the server sends an advertise message with an authentication option
  authenticated with the selected key
- the client extracts the realm and key ID specified by the server
  from the advertise message.  At this point, the client can identify
  a particular key to be used for authentication in this session.

In fact, RFC3315 says:

   If the server has selected a key for the client in a previous message
   exchange (see section 21.4.5.1),
             ^^^^^^^^^^^^^^^^^^^^
and section 21.4.5.1 talks about a solicit-advertise exchange.

> The way I

Are you assuming the following procedure?

- the client sends an information-request with an authentication
  option.
- the server chooses one particular key identified by <DHCP realm,
  client DUID, key id>
- the server sends a reply message with an authentication option
  authenticated with the selected key
- the client extracts the realm and key ID specified by the server
  from the reply message.  At this point, the client can identify
  a particular key to be used for authenticating the reply message.

and,

- if the client and the server ever make further exchanges of
  information-request and reply, they should use the same key used in
  the first exchange.  (By the phrase of "use that same key for
  validating subsequent messages with the client.")

If so, that *may* make sense.  However, I think it's very hard to
imply the above just from the description in RFC3315.  And in that
sense, I'd first like to know if this is the real intention of the RFC
authors.

> [...]") may indeed be a matter of local policy.

Okay, I tend to agree.

> replies that will fail validation tests.

Hmm, I'm not sure how appropriate timeouts can protect the attack, but
at least I'm happy that I can share my concern on the threat with you.

I'd still like to hear from others, particularly from the RFC authors,
but so far it seems to me that the authentication mechanism will need
some clarification.  Does it make sense to write a separate draft like
"clarifications on the DHCPv6 authentication mechanism"?

					JINMEI, Tatuya

---

From: Christian Strauf <[email-masked]>
Date: Fri, 18 Jun 2004 11:32:45 +0200

Jinmei-san,

>    exchange (see section 21.4.5.1),
thanks for the clarification. I can see the implications for Stateless
DHCPv6 clients now. The problem is that RFC3315 keeps talking about using
the Authentication Option in Solicit-Advertise exchanges for an initial key
negotiation (also in 21.4). However, I don't see why the inclusion of an
Authentication Option in an Information Request option shouldn't work as an
initial key negotiation equally well. Clearly, this is not reflected in
RFC3315 a.t.m.. Paragraph 21.4.4.4 would make perfect sense even for RFC3736
style exchanges but not with the reference to section 21.4.5.1. Paragraph
21.4 should probably also be more general without direct references to
Solicit-Advertise exchanges.

> Are you assuming the following procedure?
[snip]
> imply the above just from the description in RFC3315.  And in that
Yes, I agree with you that this needs clarification.

> sense, I'd first like to know if this is the real intention of the RFC
Good suggestion. I'm very interested in this as well.

> "clarifications on the DHCPv6 authentication mechanism"?
I think it does. I've heard a number of questions regarding the security of
DHCPv6 in enterprise scenarios (it was also addressed in 6NET meetings) and
I believe that such a document may be a good reference for answering these
questions and for further work on DHCPv6 authentication mechanisms (which is
necessary in my eyes because the authentication mechanisms described in
RFC3315, though being sufficient in a good number of scenarios, may be
insufficient for some scenarios where e.g. X.509 based or some other form of
authentication might be desirable). I also know of implementors who would
appreciate a clarification document.

Christian