Subject: [dhcwg] Question on draft-ietf-dhc-sedhcpv6

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 Aug 2014 21:07:49 +0000

Hi,

In this draft, Section 6.2 says:

"6.2 Processing Rules of a Recipient

   The recipient of a Secure DHCPv6 message could be a DHCPv6 server or
   a DHCPv6 client.  In the failure cases, both DHCPv6 server and client
   SHOULD NOT process received message, and the server SHOULD reply a
   correspondent error status code, while the client does nothing."

But, on links where rogue clients could spoof the identity of
legitimate clients, why should the server reply with an error
status code? If the rogue client gets the error code, it knows
that its attack has failed. If the legitimate client gets the
error code, it will be confused since it hasn't sent anything
that would generate an error.

So, why isn't it the case that the server should do nothing the
same as for clients? Or, at least maybe there could be a
configuration setting the allows servers to ignore failure cases
instead of respond to them?

Thanks - Fred
[email-masked]

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 21 Aug 2014 08:30:35 +0000

Hi, Fred,

Thanks for your comments. The current status is that we probably would get rid of the client authentication on server totally, given the previous comments. It seems the client authentication on server has no much value and there is long way to go to properly setup certificate and trust anchor on clients. The next version probably will have one server authentication on client base on Leaf of Faith model. Still, some technical replies in lines.

>legitimate clients, 

Ideally, the identity of legitimate clients should not be able to be spoofed. It is signed by the private key of client. The server would validate the signature first.

>why should the server reply with an error

The mandatory response is the result of DHC WG discussion. If the above assumption (the identity of legitimate clients could not be spoofed) stands, the error code would only be replied to the legitimate client who send request.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 21 Aug 2014 09:15:21 +0000

Hi, Fred,

It may be helpful for us to re-decide whether we keep the client authentication on server if you could describe your require scenario in details. Then we can evaluate whether client authentication on server based on Leaf of Faith model could meet your requirements, or it has to be certificate with trust anchor on clients.

Regards,

Sheng

>-----Original Message-----
>From: dhcwg [mailto:[email-masked]] On Behalf Of Sheng Jiang
>Sent: Thursday, August 21, 2014 4:31 PM
>To: Templin, Fred L; [email-masked]
>Cc: [email-masked]
>Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6
>
>Hi, Fred,
>
>Thanks for your comments. The current status is that we probably would get
>rid of the client authentication on server totally, given the previous comments.
>It seems the client authentication on server has no much value and there is
>long way to go to properly setup certificate and trust anchor on clients. The
>next version probably will have one server authentication on client base on
>Leaf of Faith model. Still, some technical replies in lines.
>
>Ideally, the identity of legitimate clients should not be able to be spoofed. It is
>signed by the private key of client. The server would validate the signature
>first.
>
>The mandatory response is the result of DHC WG discussion. If the above
>assumption (the identity of legitimate clients could not be spoofed) stands,
>the error code would only be replied to the legitimate client who send
>request.
>
>Best regards,
>
>Sheng
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Aug 2014 16:19:50 +0000

Hi Sheng,

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Thursday, August 21, 2014 1:31 AM
> Cc: [email-masked]; Zhangdacheng (Dacheng); [email-masked]
> Subject: RE: Question on draft-ietf-dhc-sedhcpv6
> 
> Hi, Fred,
> 
> Thanks for your comments. The current status is that we probably would get rid of the client
> authentication on server totally, given the previous comments. It seems the client authentication on
> server has no much value and there is long way to go to properly setup certificate and trust anchor on
> clients. The next version probably will have one server authentication on client base on Leaf of Faith
> model.

Does this mean that the Certificate Option will be dropped from
the next version? In my use case, I am OK with a client taking a
leap of faith in trusting a server, but I am not OK with a server
taking a leap of faith in trusting a client.

> Still, some technical replies in lines.
> 
> Ideally, the identity of legitimate clients should not be able to be spoofed. It is signed by the
> private key of client. The server would validate the signature first.

If legitimate client A signs the message with its correct private key,
yet server S is somehow unable to accept the message, then yes S could
safely return a status code to A. But, if bogus client B signs the
message with a bogus private key, shouldn't S simply ignore the message? 
Otherwise, it would be divulging sensitive information to B, wouldn't it?
 
> The mandatory response is the result of DHC WG discussion. If the above assumption (the identity of
> legitimate clients could not be spoofed) stands, the error code would only be replied to the
> legitimate client who send request.

Maybe I am still not understanding, but I don't think any error code
should be returned to an attacker.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Aug 2014 16:32:15 +0000

Hi Sheng,

> Sent: Thursday, August 21, 2014 2:15 AM
> To: Sheng Jiang; Templin, Fred L; [email-masked]
> Cc: [email-masked]
> It may be helpful for us to re-decide whether we keep the client authentication on server if you could
> describe your require scenario in details. Then we can evaluate whether client authentication on
> server based on Leaf of Faith model could meet your requirements, or it has to be certificate with
> trust anchor on clients.

My scenario is similar to that described in Section 21 of RFC 3315
where it says:

   "Network administrators may wish to
   constrain the allocation of addresses to authorized hosts to avoid
   denial of service attacks in "hostile" environments where the network
   medium is not physically secured, such as wireless networks or
   college residence halls."

but not quite as bad as that in actual practice because there
is an established trust basis for hosts to trust the DHCPv6
server.

Thanks - Fred

---

From: 神明達哉 <[email-masked]>
Date: Thu, 21 Aug 2014 09:56:00 -0700

At Thu, 21 Aug 2014 16:32:15 +0000,

> is an established trust basis for hosts to trust the DHCPv6

I wasn't in Toronto (or didn't attend the meeting remotely), but there
seems to be some background discussion on this topic in the meeting
minutes: http://tools.ietf.org/wg/dhc/minutes?item=minutes-90-dhc.html

In particular:
  Ted: server authorize client is also useful, though not very clear
  Lorenzo: l2 security may be enough and better

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2014 13:44:07 -0400

>  Lorenzo: l2 security may be enough and better

As I said later, though, on the mailing list, there are in fact use cases where l2 security doesn't really work, and I think sedhcpv6 would be applicable.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Aug 2014 17:48:47 +0000

+1

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, August 21, 2014 10:44 AM
> To: 神明達哉
> Cc: Templin, Fred L; [email-masked]
> As I said later, though, on the mailing list, there are in fact use cases where l2 security doesn't
> really work, and I think sedhcpv6 would be applicable.

---

From: Robert Elz <[email-masked]>
Date: Fri, 22 Aug 2014 06:49:02 +0700

Date:        Thu, 21 Aug 2014 16:19:50 +0000
    From:        "Templin, Fred L" <[email-masked]>
    Message-ID:  <[email-masked]>

  | But, if bogus client B signs the
  | message with a bogus private key, shouldn't S simply ignore the message? 
  | Otherwise, it would be divulging sensitive information to B, wouldn't it?

What sensitive information?   That S is a dhcp server?  Is that sensitive
somehow?  Why?  Or that S actually verifies signatures?  Again, why?  Or that
the bogus signature B knows it provided is in fact bogus .. really?

If something else, then what?

If there is in fact no information being revealed, then it is better to
reply - it allows clients that should be valid (ones that believe that
anyway, ie: not intentionally intruding) but somehow aren't to find out what
has gone wrong, and instead of asking "why is the dhcp server broken?"
ask instead "what's wrong with my credentials?".

kre

ps: the bigger issue with any scheme where a server is asked (or even just can
be asked) to validate client signatures (in an environment that is relatively 
open - less of a problem on a network that for other reasons can be considered
reasonably secure) are DoS attacks on the server simply by bombarding it with
bogus signatures - they're essentially free to create, yet consume notable
resources attempting to verify.   The only (partial) defence to that that I
(one who has essentially no crypto expertise) can devise is to require the
clients to use very low strength keys and have the server simply reject
anything strong - say for RSA, anything more than 512 bits ... for most crypto
that would be (these days) considered unsafe, but it really is probably good
enough for validating dhcp clients, provided that the fact of that validation
isn't used (by itself) to authorise any more than allocation of an address.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Aug 2014 14:40:41 +0000

Hi kre,

> From: Robert Elz [mailto:[email-masked]]
> Sent: Thursday, August 21, 2014 4:49 PM
> To: Templin, Fred L
> Cc: Sheng Jiang; [email-masked]; [email-masked]

You ask good questions, and I honestly don't know what other ways
B might stand to benefit from getting back an error code. The reason
I brought this up is that this is different behavior than what
happens in DHCPv6 authorization. In RFC3315 section 21.4.5.2:

   "The server uses the key identified in the message and validates the
   message as specified in section 21.4.2.  If the message fails to pass
   the validation test or the server does not know the key identified by
   the 'key ID' field, the server MUST discard the message and MAY
   choose to log the validation failure."

So, DHCPv6 auth is drop-silent while the proposed secure DHCPv6 is
drop-and-return-error. I honestly don't know what are all of the
security implications for the two choices, but it just seemed to
me that telling the attacker nothing seemed more secure than telling
the attacker something. Maybe someone with a deeper understanding of
security could provide a better analysis. 
 
> ask instead "what's wrong with my credentials?".

Sure, I get that. I just wonder why DHCPv6 auth and secure DHCPv6
handle error conditions differently, and should the latter document
give 1-2 sentences saying why the design departure was chosen? 

> isn't used (by itself) to authorise any more than allocation of an address.

Right, I think I get that too.

Thanks - Fred