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 revision | No specific revision (document currently at 07) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2013-02-25 | |
| Requested | 2013-02-14 | |
| Authors | Sheng Jiang , Sean Shen | |
| Draft last updated | 2013-02-28 | |
| Completed reviews |
Genart Last Call review of -07
by
Francis Dupont
Secdir Early review of -?? by Stephen Kent Secdir Last Call review of -07 by Stephen Kent |
|
| Assignment | Reviewer | Stephen Kent |
| State | Completed | |
| Review |
review-ietf-dhc-secure-dhcpv6-07-secdir-lc-kent-2013-02-28
|
|
| Reviewed revision | 07 | |
| Result | Has Issues | |
| Completed | 2013-02-28 |
review-ietf-dhc-secure-dhcpv6-07-secdir-lc-kent-2013-02-28-00
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.
Â
Â
Â
Â