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

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

At Tue, 29 Apr 2014 20:21:33 +0200,
Tomek Mrugalski <[e-mail]> wrote:

> Since we have upcoming holiday on May 1st (which happens to be a reason
> for extended weekend in many parts of Europe) and the topic in question
> is not trivial, this WGLC is a bit longer than usual.
>
> Please send your comments by May 18th 2014. If you do not feel this
> document should advance, please state your reasons why.

I've read the document.  I don't have a particular opinion on whether
it should advance, mainly because I'm not a security expert.  I have
some comments that may hopefully be useful, though:

Some higher level points
- (maybe already discussed before but) the concept of using public key
  authentication in DHCP makes some sense to me, but I wonder why we
  are discussing this specifically for DHCPv6.  As far as I know
  there's no such counterpart in DHCPv4 (the only related thing I can
  google is draft-gupta-dhcp-auth-02.txt, which expired long ago), am
  I correct?  If so, is that because *v4 is just too legacy and isn't
  worth improvements anymore?  Or does that reflect some DHCP specific
  points that make public key authentication not so viable?  If it's
  the latter, doesn't it also apply to this proposal?

- The description of the draft is a bit vague (which may have to be
  clarified anyway), but if I understand it correctly, it assumes that
  both clients (each of them) and servers maintain their pair of
  public-private keys, and a client offers and uses its own key to
  authenticate messages from the client to servers.  Is that correct?
  If so, does this make sense?  My general understanding is that
  authenticating DHCP messages from clients to server is not that
  critical, and it's quite unlikely that servers maintain public keys
  of all possible clients so the servers would have to rely on the
  leap-of-faith model.  They then may have to worry about the
  "resource exhaustion attacks" (although I'm not sure if this is a
  big issue, see below).

Other non editorial comments on the draft:
- Section 5.1:
   Public Key     A variable-length field containing public key. The
                  key MUST be represented as a lower-case hexadecimal
                  string with the most significant octet of the key
                  first. Typically, the length of a 2048-bit RSA

  Is there any specific reason it's represented as a string?  Not
  necessarily bad, but I thought more common practice here is to
  simply use the binary value of the key.  DHCP options in wire format
  are not expected to be human readable anyway, so I don't see the
  point for using a string here.

- In Section 6.2:

   On the recipient that supports the leap of faith model, the number of
   cached public keys or unverifiable certificates MUST be limited in
   order to protect against resource exhaustion attacks.  If the

  This is mainly concerned about servers, correct?  If so, I'm not
  sure how severe this "attacks" are; DHCP servers generally need to
  maintain some state for each client (unless that's stateless only
  server) and would naturally already have some limitation on that
  resource.  Shouldn't the general defense be enough for this
  particular resource, too?  (But I was also not sure if it makes
  sense to use (public key) authentication for messages from clients
  in the first place; see higher-level discussions above)

- Related, it seems some part of Section 6.2 is more specific for
  clients and some other part is more specific to servers.  So it may
  be helpful if we have separate subsections focusing on these
  particular cases.  Just a suggestion.

Editorial nits:
- Section 4.3
   they may fall back the unsecure model, if both client and server
  s/fall back the/fall back to the/
  (I found the missing 'to' of this kind in several other places in
  the draft)

- Section 4.3
   whether to accept the messages.  If the client accept the unsecure
   messages from the DHCPv6 server.  The subsequent exchanges will be in
   unsecure model.
  s/server.  The/server, the/

- Section 4.3
   on the server policy.  If the server mandidates the authentication,
  s/mandidates/mandates/

- Section 6.1
   messages, MUST contain either a the Public Key or Certificate option,
  s/a the/the/ (?)

- Section 6.2
   error status code, defined in Section 5.4, back to the client..
  s/.././

--
JINMEI, Tatuya