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

[Ralph Droms <[e-mail]>]

On May 2, 2014, at 8:33 AM 5/2/14, Bernie Volz (volz) <[e-mail]> wrote:

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

If I recall correctly, similar protocols have been considered in the past for DHCPv4.  Those protocols were not developed because of concerns about the length of individual options and the total length of all of the options (certs can get big) combined with concerns about whether deployed DHCPv4 infrastructure (relay agents) would correctly handle large DHCPv4 messages.

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

Yup.

I would like to see some consideration of the total length of DHCPv6 messages that use this security protocol included in the document.

- Ralph

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