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

[Sheng Jiang <[e-mail]>]

Hi, Jinmei & Bernie,

We do have a plan to extend this to DHCPv4. We are going to submit an individual 00 version before the next IETF meeting. However, the secure DHCPv6 is in our priority for now. :)

Best regards,

Sheng + Dacheng

>-----Original Message-----
>From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
>Sent: Friday, May 02, 2014 8:34 PM
>To: 神明達哉; Tomek Mrugalski
>Cc: dhcwg
>Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May
>18
>
>Jinmei:
>
>Thanks for your review and feedback.
>
>Regarding your first point, there's probably nothing (except the option length
>limitations, though RFC 3396 handles that) that would prevent this from being
>adopted for DHCPv4. But it is indeed a question of whether advancing
>DHCPv4 is as important as advancing DHCPv6. Also, the DHC WG charter is
>focused on DHCPv6.
>
>If this work does advance, and there's sufficient interest, I could well see
>someone proposing the same for DHCPv4.
>
>- Bernie
>
>-----Original Message-----
>From: dhcwg [mailto:[e-mail]] On Behalf Of ????
>Sent: Wednesday, April 30, 2014 1:30 PM
>To: Tomek Mrugalski
>Cc: dhcwg
>Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May
>18
>
>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
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg