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

[Sheng Jiang <[e-mail]>]

Hi, Jinmei,

Thanks for your email. Replies in lines.

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

Replied in another email, too. We do have a plan to extend in DHCPv4. However, it would be in lower priority for us and for WG.

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

We borrow the ideas from multiple other security mechanisms such as rfc 7210. But your concern makes sense. We will change this according to your point.

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

The "MUST" here seems not proper. Let us replace is with "MAY". It makes this point optional and should address your concern.

>Editorial nits:

Editorial nits will be fixed. :)

Best regards,

Sheng + Dacheng