Re: [dhcwg] Additional feedback on secure DHCPv6 draft

[Francis Dupont <[e-mail]>]

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

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

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

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

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

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

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

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

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

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

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

=> I proposed this and it was rejected.

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

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

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

=> 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 -
>  including RSASSA-PKCS1-v1_5 include a specifier of the hash algorithm
>  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
>  from X.509 certificates the way you did with public key
>  specifications.

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

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

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

>  Finally, when discussing Relay Agents, there are fields that Relay
>  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

[e-mail] (also [e-mail] for implementation questions)