Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

[神明達哉 <[e-mail]>]

At Tue, 13 May 2014 08:58:07 +0000,
Sheng Jiang <[e-mail]> wrote:

> >> My main concern is the combination of authenticating clients with the
> >> leap of faith model.  This model isn't suitable for the "grant
> >> different access" usage, since anyone can pretend to be an
> >> authenticated client with that model.
> >
> Ted Lemon>You are right--I don't think there is a use case for leap-of-faith with clients.
>
> The purpose of authenticating clients with the leap of faith model
> is to protect the follow-up client-to-server messages, such as
> Confirm, Renew, Rebind, Decline, Release, Information-request
> messages, hence, more protection for clients.
>
> When there is no security protection, an attacker can try to tamper
> the messages or generate bogus messages at the all the stages of the
> communication between a DHCP client and a server. For example, an
> attacker may send a bogus Release message, masquerading as a client,
> to the server. The network then deny the access from that IP
> address. It would actually affect the client.

I see what you're trying to say, and it makes some sense, but I'd like
to see more precise discussion, rather than just listing random
message types and obscuring details with a word like "such as".  For
example, I don't see (at least not immediately) what kind of
protection can be provided for Information-request in this context.
It's stateless by definition, so a forged Information-request from an
attacker doesn't break anything on other clients.

Also, I don't see the need for leap-of-faith in the case of forged
Release.  The server doesn't have to "leap" when it first sees a
client's public key since it's not for authenticating the client for
that particular request but for authenticating a possible subsequent
Release to confirm that is certainly from the client the server
originally responded to.  Also, for this purpose, the server only has
to remember the client's public key during that DHCPv6 session; it can
immediately forget the public key after that, so it doesn't have to
worry about "resource exhaustion attacks" at all.

I can see one possibility of client authentication + leap-of-faith
from the discussion so far, though: it may help prevent an attacker
from pretending to be a disconnected past client by sending a forged
Solicit (maybe with a forged public key).  If it was granted, there
might be confusion when the legitimate client comes back and tries to
establish another DHCPv6 session (I'm not sure if this inevitably
causes a security threat or could be just some confusion).  If the
server stores the original public key of the legitimate client, it can
reject the forged Solicit.  (Interesting, Solicit is not listed in the
message types you listed above).

> It has been realized that the leap of faith cannot prevent an
> attacker from impersonating legal clients to perform resource
> exhausting attacks against the DHCP server. In order to deal with
> this type of attack, certificate based mechanism needs to be
> provided. We also note that the leap of faith will consume
> additional memory resources of servers to remember the hash values
> of the public keys used by the clients. However, when using SHA-1
> the length of the hash of a public key is no longer than an IPv6
> address. So, we don’t think this will seriously affect the
> performance of the DHCP server.

Any trick to "mitigate" such a threat may be useful, but my main point
was at a more higher level: whether we should worry about this issue
in the first place: for clients this shouldn't be much concern in
practice; for sever, if we don't see the need for client authentication +
leap-of-faith, we don't have to worry about it (note that avoiding
forged Release doesn't require leap-of-faith as I noted above).  So,
only with an example like avoiding a forged Solicit explained above do
we need to worry about it.  But, right now, such a precise discussion
is totally missing in the draft and only some vague fear of a threat
is documented, which made me think whether this is really an issue or
not.  Discussions like specific "mitigation" such as the use of
fingerprint does not address this fundamental point.  I hope I'm clear
about my concern this time...

Now, with this latest understanding, I'd revise my previous specific
suggestion I described in
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15524.html:

- provide a short "applicability considerations" section.  It includes
  some specific common use cases of server authentication and
  client authentication with key management:
  1. authenticating a server, mainly for clients to authenticate the
     information the server provides
  2. authenticating a client, so the server can selectively serve a
     specific client (or deny specific clients)
  3. authenticating a client, so the server can prevent an attacker
     from breaking an existing DHCPv6 session of a legitimate client.
  4. authenticating a client, so the server can prevent an attacker
     from establishing a new DHCPv6 session pretending to be a past
     legitimate client.

  For 1, both CA/preshared or leap-of-faith can be used.  The latter
  is weak in pure security point of view, but probably better than
  no protection by narrowing the attack scope.

  For 2, leap-of-faith cannot be used, since anyone can pretend to be
  a new legitimate client.

  For 3, leap-of-faith is not necessary, since the server uses the
  public key only to confirm that a subsequent message is sent from
  that client (rather than "trusting" the client in the initial
  solicit).

  For 4, both CA/preshared or leap-of-faith can be used, just like
  case 1.

And, for the security consideration on the "resource exhaustion
attacks", we'd note it matters only for cases like 4 in the
applicability categorization.  (With that clarification, we might or
might now want to mention possible mitigation, like the use of
footprint instead of full key information).

If this document is organized like this, I'll feel much more
comfortable.

--
JINMEI, Tatuya