Subject: [dhcwg] Additional feedback on secure DHCPv6 draft

From: Brian Haberman <[email-masked]>
Date: Mon, 20 Jul 2015 08:25:14 -0400

All,
     Charlie Kaufman has provided a review of the secure DHCPv6 draft.

Brian

-------- Forwarded Message --------
Subject: RE: [secdir] DHCP IPv6 help needed
Date: Thu, 16 Jul 2015 19:28:54 -0700
From: Charlie Kaufman <[email-masked]>
To: 'Brian Haberman' <[email-masked]>, 'Kathleen Moriarty'
<[email-masked]>
CC: 'Stephen Farrell' <[email-masked]>

I've reviewed draft-ietf-dhc-sedhopv6-08, and I have some thoughts on
possible improvements - some are details; others are more
philosophical. I don't have a detailed understanding of DHCPv6, so
some issues may be based on my misunderstanding it. I'll try to
mention my assumptions where I'm less confident in them.

I wasn't sure where to send this, so I'll send it to you and hope you
will forward it appropriately.

A big question that probably should be answered in the introduction or
under security considerations is "what security vulnerabilities are we
trying to mitigate?". To the extent that the primary goal of DHCP is
to hand out network parameters (and in particular, temporary IP
addresses), a badly behaved DHCP server on a link can issue an IP
address that will not work, thus denying service to the requesting
client. If it issues an IP address already in use, it might also deny
service to some other node on the network. A bad client can acquire
large numbers of IP addresses and (at least with IPv4) exhaust the
address pool. It was my understanding that with IPv6 nodes just had to
acquire the network address and could use their own unique ID so that
allocations from a limited pool of addresses was unnecessary.

Given all that, what are the threats?

The other use of DHCP was as an extension to the old BootP protocol,
where an uninitialized node could "boot from the network" and download
its operating system and other extremely security sensitive
information. That process started by getting some parameters via DHCP.
In that case, it would make a lot of sense to make the
protocol more secure, but it would also be harder because when dealing
with an uninitialized machine there is are not going to be trusted
root certificates or any other means of authenticating the messages.

In some cases dealing with the secure initialization of a node, it
would be good if there were a way for the messages to be encrypted as
well as signed. I know of at least one system that uses DHCP to
download a random number of purposes of helping to seed the booting
client's random number generator. It would be better if that exchange
could be encrypted.

A smaller but still global issue: the spec is written as though DHCPv6
were symmetric between the two communicating nodes. My understanding
is that it is a request/response protocol where the client always
initiates exchanges and the server always responds. This implies some
differences in how algorithms are negotiated. It is appropriate that
if a server gets a request with an algorithm it does not support, that
it send an error code with the expectation that the client will try
again. But if the client gets a request with an algorithm it does not
support, it cannot request that the server use a different one. This
will make it difficult for the server to migrate to new algorithms. A
better way would be to introduce a new optional field in requests
listing the supported algorithms. The only real alternative is for the
server to assume that the client supports that algorithms that the
client used in the request and to favor those.

My remaining comments are to the details of the formatting, though
some are pretty important:

The encoding allows only a single certificate. There are very few
cases where this will be useful. In all of the public PKIs deployed
out there, endpoints have certificate chains of at least 2 or 3
certificates and not infrequently 4 or more. The protocol should
probably allow what IKEv2 calls a "certificate bundle".

That, however, will exacerbate what might already be a fatal problem
of very long messages that need to be fragmented. It is very difficult
for a server to protect itself from state exhaustion denial of service
attacks while accepting fragmented datagrams. It might be better to do
something like sending hashes of certificates instead of the
certificates themselves and then providing a mechanism for retrieving
the certificates based on the hashes in a series of messages. But
there are no simple elegant solutions here. I don't have a concrete
recommendation of than to discuss alternatives with implementers.

In the syntax of a signature, it would probably be better to have a
single algorithm identifier that specifies both the hash and the
public key signature algorithm rather than separate identifiers for
the two. That's because some public key signature algorithms -
including RSASSA-PKCS1-v1_5 include a specifier of the hash algorithm
within the encoded signed data. If you include the signature algorithm
redundantly, they you need to say what happens when they
differ. Another alternative would be to take the signature encoding
from X.509 certificates the way you did with public key
specifications.

It is dangerous to use timestamps to avoid replay attacks when
synchronized time is not otherwise needed because it implicitly
requires caching all packets that arrived during the clock-skew
window, and that might be a very large number. You might be better off
using something like TCP-cookies or IKEv2-cookies where if the server
is being overwhelmed it replies with an unsigned reply containing a
nonce and asks the client to resubmit the request with that nonce. If
cleverly designed, the server can compute that nonce as a hash of a
secret and information from the packet header so that it need not keep
state while waiting for the second message.

At the end of section 6.2, there is a mention of minimum and maximum
key lengths. While I think this is a good idea, there does not appear
to be anywhere that this information is encoded in the exchanged
data. The only place I can think of it being useful would be in the
"supported algorithms list" field that I proposed adding. Otherwise,
the sender picks a number and the recipient can take it or leave it.

Finally, when discussing Relay Agents, there are fields that Relay
agents need to be able to add and remove. Unless these are encoded in
some separate part of the message, the sender will have to anticipate
any fields that it knows the relay agent will remove and not include
those under the signature and the recipient will need to know what
fields the relay agent added and exclude those from the signature
calculation. This all seems very fragile. It might be good to do
something explicit about it.

	  --Charlie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 20 Jul 2015 12:49:32 +0000

Just an FYI - for DHCPv6, there are no relay agent issues as the client's message is encapsulated as an option in the relay message and hence the client's message (and server's reply to client) are not modified in any way. So I believe the last pargraph of the comments can be ignored (not applicable).

(For sedhcpv4, this is an issue but also well understood - giaddr and option 82 are the issue there.)

- Bernie (from iPad)

> On Jul 20, 2015, at 8:25 AM, Brian Haberman <[email-masked]> wrote:
> 
> All,
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Jul 2015 16:03:33 +0200

In your previous mail you wrote:

(By default I answer here in the mailing-list)

Note I reviewed and contributed to this draft, and I am one of its
implementors (it successfully interoperated at the Hacktathon Saturday).

>  Given all that, what are the threats?

=> for me the main 2 examples is the guy which tries to get your address
(i.e., inpersonate your application server) and the bad guy which
releases your address (i.e., basic denial of service).
But in fact the goal is to raise the DHCPv6 security from its current
level (i.e., nearly no usable security at all) to a point where it is
not too ridiculous compared to SEND (RFC 3971).

>  root certificates or any other means of authenticating the messages.

=> yes, the secure bootstrapping problem is a hard one but as SEND
solves it there is no reason to not be able to provide a similar thing
for DHCPv6...

>  client's random number generator. It would be better if that exchange

=> in this case it makes more sense to use secure DHCPv6 (or a DHCPv6 like
feature in a security protocol, e.g., IKEv2) to negociate parameters for
the transfer of critical/sensible infos.

>  initiates exchanges and the server always responds.

=> in fact it is not 100% true: the DHCPv6 spec defines an exchange
which is initiated by the server (and as far as I know nearly never
use in the real world).
BTW there was very long discussion about how to use the secure DHCPv6
protocol so this symmetric presentation is more a result of this that
a deep design idea.

>  This implies some

=> I am afraid the current solution is just to have a mandatory to
support algorithm so the only negotiation is in the client -> server way.

>  probably allow what IKEv2 calls a "certificate bundle".

=> I proposed this and it was rejected.

>  recommendation of than to discuss alternatives with implementers.

=> same comment. And the discussion about the intented uses (plural
important here :-) did not help...

>  the two.

=> I did the same comment but it was rejected. BTW it doesn't really
matter as the current result is like a 16 bit ID with a sparse allocation.

>  That's because some public key signature algorithms -
>  within the encoded signed data.

=> I thought about P-256 ECDSA where the hash algorithm is a waste.

>  If you include the signature algorithm redundantly, they you need
>  to say what happens when they differ.

=> it is an implementation issue (and as an implementator I can say
it will simply make the verify to fail when the public key is loaded).

>  Another alternative would be to take the signature encoding

=> hum, I prefer to stay as far as possible from ASN.1...

>  window, and that might be a very large number.

=> in fact DHCPv6 (and SEND where the timestamps idea came from) doesn't
need a small delay anti-replay so it is enough to cache the last
timestamp. BTW as far as I know the timestamp mechanism is optional
in secure DHCPv6.

>  You might be better off using something like TCP-cookies or
>  IKEv2-cookies.

=> The SEND nonce mechanism was considered too but if it is critical
in SEND to avoid identical packets in DHCPv6 there is a transaction ID
so it was not included in the protocol.

>  agents need to be able to add and remove.

=> DHCPv6 relays encapsulate (in the client -> server way) and decapsulate
(in the server -> client way) messages without changing even a bit so
they are transparent for secure DHCPv6.

Thanks

[email-masked] (also [email-masked] for implementation questions)

---

From: 神明達哉 <[email-masked]>
Date: Tue, 28 Jul 2015 05:27:25 +0900

At Mon, 20 Jul 2015 16:03:33 +0200,
Francis Dupont <[email-masked]> wrote:

> >  trying to mitigate?".
[...]
> releases your address (i.e., basic denial of service).

These can be prevented with the existing RFC3315 authentication
mechanism.  So we'd need to explain why we need to introduce a new
mechanism to prevent them.  To that end, and in my understanding of

> not too ridiculous compared to SEND (RFC 3971).

but unless we show how we can practically integrate PKI (or some other
way for public key distribution/sharing) with secure DHCPv6, or at
least show how TOFU could effectively prevent some class of threats
that are not so marginal, it would still look equally "ridiculous" and
wouldn't be convincing.  This has been my own concern (but admittedly
I failed to resolve myself), and, according to the external reviews
and Brian's initial feedback, this concern seems to be shared by
others.

I'm not sure how we can move forward from this point.  I'm pessimistic
about revising the document so it can show the integration of PKI or
more persuading scenarios of TOFU based on the history of this
document.  So the only alternative I can think of is to make it super
clear that "this is still mostly as 'ridiculous' as the RFC3315
authentication mechanism as we don't know how to integrate PKI, but
we'll just define this mechanism as public key based authentication is
generally considered the modern practice" (with more sophisticated
rhetoric:-).

I didn't attend the dhc meeting in Prague (or remotely) so I don't
know if there was any discussion on the possible next step for this
document.  Is there any agreed way to move forward?

--
JINMEI, Tatuya