Last Call Review of draft-ietf-dhc-secure-dhcpv6-07
review-ietf-dhc-secure-dhcpv6-07-secdir-lc-kent-2013-02-28-00

Request Review of draft-ietf-dhc-secure-dhcpv6
Requested rev. no specific revision
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-02-25
Requested 2013-02-14
Other Reviews Genart Last Call review of -07 by Francis Dupont
Secdir Early review of - by Stephen Kent (diff)
Review State Completed
Reviewer Stephen Kent
Review review-ietf-dhc-secure-dhcpv6-07-secdir-lc-kent-2013-02-28
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg03824.html
Reviewed rev. 07
Review result Has Issues
Draft last updated 2013-02-28
Review completed: 2013-02-28

Review
review-ietf-dhc-secure-dhcpv6-07-secdir-lc-kent-2013-02-28



SECDIR review of
        draft-ietf-dhc-secure-dhcpv6-07




Â




I reviewed this document as part of the
        security
        directorate's ongoing effort to review all IETF documents being
        processed by
        the IESG.

 

These comments
        were written
        primarily for the benefit of the security area directors.

 

Document editors and WG
        chairs should treat
        these comments just like any other last call comments.




Â




This
        document proposes use of CGAs to secure DHCPv6 traffic,
        principally to provide
        data origin authentication and connectionless integrity for
        messages
        transferred between a DHCPv6 server (or relay agent) and a
        client. These
        services are derived from the use of a CGA by the communicating
        peers.




Â




The document
        does not provide a thorough system-level description of how the
        security mechanisms
        are to be used, and how clients, servers, and relay agents might
        need to be
        configured accordingly. For example, if the primary focus is
        thwarting fake
        DHCPv6 server attacks, then a client might not need to signature
        a query
        directed to a server. On the other hand, if the goal is to
        enable servers to
        selectively provide service to clients, e.g., based on cached
        CGA values, then
        a client would need to sign a query. The document needs to
        provide additional
        background in this regard, to enable readers (and implementers)
        to understand
        what features need to be present in system components making use
        of these security
        mechanisms. A description of local configuration variables that
        can be used to
        achieve the desired system-level behavior is needed.




Â




Section 3
        provides a very brief discussion of the vulnerabilities
        associated with
        unsecured DHCPv6, and then reviews the security mechanisms
        offered in RFC 3315.
        It notes that the symmetric key management approach offered in
        3315 is
        difficult to manage, a conclusion with which I concur. However,
        the authors
        overstate the simplicity of their proposed approach, deferring
        to the Security
        Considerations section a discussion of public key management. 




Â




This
        section also notes that 3315 suggests use of IPsec to secure
        communications
        between servers and relay agents (or between relay agents), but
        dismisses that
        approach due to complexity. I am less sympathetic to this
        statement. IPsec is
        already implemented in all major operating systems, so an
        argument about its
        complexity, relevant to a set of proposed new mechanisms, is not
        especially relevant.
        Perhaps the authors intend to argue that management of IPsec for
        this
        application is more complex than their proposed solution. If so,
        I suggest that
        the text in bullet âcâ of Section 3 be revised.




Â




Section 4
        describes the
        proposed mechanism. The section states the assumptions that
        underlie use of
        CGAs in this context, but it does so in a confusing manner. The
        use of CGAs
        provides intrinsic authentication of the sender of a signed
        message, in terms
        of the IPv6 address of the sender. For DHCPv6 clients, this may
        be all that is required,
        but the text does not make that argument. For DHCPv6 servers,
        clients (and
        relay agents) simple address authentication does not suffice; a
        client (or a
        relay agent) needs to know that the sender of a message is
        authorized to act as
        a server (or relay agent). The text is not at all clear on this
        point, i.e., it
        fails to state for which entities it is necessary to
        pre-configure CGA
        parameters, to enable meaningful authentication (and
        authorization). 




Â




The text here
        states an
        exception to the need for pre-configuration saying 

Â

that an entity could have â â
        recorded [the
        parameters] from previous communications.â This leap of faith
        (LoF) key management
        approach is discussed again only in Section 7. The discussion
        there is
        superficial. More text is needed to explain when LoF may be
        viewed as
        appropriate, and to address issues such as how a client that
        acquired a serverâs
        CGA would transition to a new server CGA, securely.




Â




Â




Section 4
        ends by noting
        that the âauthentication optionsâ (presumably the signature
        option) can be used
        to counter replay attacks. This is not quite accurate, i.e., it
        is the
        integrity aspect of the signature that provides a basis for
        anti-replay
        mechanisms, vs. the authentication

Â
        

aspect. More worrisome is that fact that there is no
        later mention of
        anti-reply in the document. The authors need to add text
        discussing anti-replay
        in this context.




Â




Section 4.2
        discusses
        algorithm agility, but does so only for hash algorithms. This
        section needs to
        be expanded to discuss signature algorithm agility as well.
        Also, the text here
        states that âmainly unilateral notificationâ is the means by
        which an algorithm
        change is made known to a peer communicant, but that not all
        senders in a
        network need to transition to a new algorithm at the same time.
        This section
        needs to describe how an orderly transition to a new algorithm
        can be effected
        in a network. For example, one might add an option that a sender
        could include
        in a message, indicating a preferred list of algorithms
        (signature and has)
        that it supports. This would enable a server to know whether
        clients are
        prepared to transition to a new algorithm.




Â




Much of the
        text in 4.2 should
        be moved to the Security Considerations section, as it is
        motivational material
        not describing the working of the protocol.




Â




Section 5
        describes the
        enhancements to DHCPv6 to support the proposed security
        features. Section 5.1
        defines an option to transfer a CGA parameters (as pre RFC
        3972). This is a
        simple option and I didnât see any problems with the description
        provided. 




Â




Section 5.2
        defines a
        signature option. There is a timestamp here, which is present to
        help âreduce
        the danger of replay attacks.â However, the processing rules for
        a receiver
        (Section 6.2) make no mention of this timestamp. This mismatch
        needs to be
        fixed. The description of what data is protected by the
        signature is a bit
        complex to follow. A diagram is needed. A padding field is
        defined, but there
        is no mention of what padding bits are to be used.




Â




Section 5.3
        defines a
        signature option for relayed replies. It is used to enable
        encapsulation of a
        reply that passes through one or more relay agents, so that
        there are separate
        signatures for each agent and for the target client. The
        description here is
        not clear to me, especially if there is more than one relay
        agent 




Â




Section 5.4
        describes an
        option that carries the IPv6 address of a server, preserving it
        for
        authentication when a reply is relayed through an agent. This is
        a simple
        option, and its description seems fairly clear.




Â




Sections 6.1
        and 6.2
        provides processing rules for senders and receivers,
        respectively. This is a
        very good structure, but, as noted above, some details are
        missing, e.g., there
        is no mention of timestamp use. (If timestamp processing rules
        are defined
        elsewhere, e.g., 3515, then this text should include the
        relevant cite. The
        description of when the CGA, Signature and DUID options MUST and
        MUST NOT be
        used is sufficiently complex that a table needs be included.
        There is a
        reference to an Authentication Option near the bottom of page
        11, but none is
        defined in this document. 




Â




The opening
        discussion for
        Section

 

6.2 is confusing
        when it
        discusses how a Secure DHCPv6 âenabledâ receiver might, or might
        not, discard
        messages that omit the CGA and Signature options. The authors
        may need to
        distinguish between a receiver that is Secure DHCPv6 âcapableâ
        vs. âenabledâ to
        clarify what they mean. Maybe the purported source address of
        the sender plays
        a roll here as well. Discarding a packet for which the required
        options are
        absent is a SHOULD, here. But, near the bottom of page 12, there
        is text that
        says a packet that does not pass all of the checks MUST be
        discarded. These two
        statement need to be reconciled. There is no discussion of how a
        receiver
        verifies that a message is from an authorized server or relay
        agent, e.g., by
        reference to pre-configured CGA data. 

Â

There is no discussion of
        when a receiver
        should cache CGA data for future use, despite an allusion to
        this possibility
        in Section 4. These topics must be addressed if the processing
        rules are to be
        considered complete. The âminbitsâ description is

 

bit confusing, as its name
        specifies a
        minimum key size, but the description discusses both min and max
        key sizes.
        Also, this variable needs to be augmented with an algorithm ID,
        so that it is
        clear to which algorithm the key size applies.




Â




Section 6.3
        describes
        special processing performed by relay agents, above what is
        described for them
        as senders and receivers, in the preceding two sections. Because
        relay agent
        processing has already been discussed in 6.1 and 6.2, the
        additional text here
        seems confusing to me. The closing paragraph is especially
        confusing to me, but
        maybe DHCPv6 experts will find it understandable.




Â




The security
        considerations section states that ââ clients should be
        pre-configured with the
        DHCPv6 server CGA.â This seems important enough to be âSHOULDâ
        vs. âshould.â
        Similar language is used to describe the need to pre-configure
        CGAs for relays
        and servers, and it too needs to be stated more firmly. In both
        cases the text
        states that how secure pre-configuration of CGAs is achieved is
        out of scope. Later
        in this section the authors suggest that a leaf of faith (LoF)
        approach to
        acquisition of these CGAs by clients may be a reasonable
        alternative to secure
        distribution of server CGA values. This suggestion ignores the
        issue of how a
        key change for a server will be accommodated, or how the
        addition of a new
        server would work. Absent a discussion of these issues, the LoF
        suggestion
        seems questionable.




Â




This section
        contains a
        brief discussion of collision attacks against hash functions,
        and why the
        current levels of attacks are not a serious concern in this
        context. Hash
        functions, per se, do not have a ânon-repudiation featureâ so I
        think the text
        here should be improved. Discussion of the hash function
        security in the SeND
        context seems relevant. As noted earlier, the test in 4.2 that
        talks about why
        hash functions are adequately secure for this context should
        move here, and the
        redundancies should be removed.




Â




Â




Â




Â