Hi,
please, find a review of this document:
Secure DHCPv6 Using CGAs
draft-ietf-dhc-secure-dhcpv6-00.txt
<JMC>
There is no text about authorization (cf. my comments on
draft-ietf-csi-dhcpv6-cga-ps-02 on the csi WG ML), so, if I am
correct, your proposal doesn't protect against 'rogue' DHCP server
(i.e. the rogue DHCP server has generated/configured a CGA and sends
erroneous information signed with the private key corresponding to its
CGA). Or did I miss something?
<JMC>
1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6 [RFC3315])
enables DHCP servers to pass configuration parameters. It offers
configuration flexibility. If not secured, DHCPv6 is vulnerable to
various attacks, particularly fake attack.
The requirements of using CGA to secure DHCPv6 have been introduced
in [I-D.draft-ietf-csi-dhcpv6-cga-ps]. This document analyzes the
security issues of DHCPv6 in more details. This document is aiming to
provide mechanisms for improving the security of DHCPv6, thus the
address of a DHCP message sender, which can be a DHCP server, a reply
<JMC>
s/a reply/a relay
<JMC>
agent or a client, is able to be verified by a receiver. It improves
communication security of DHCPv6 interaction. The security mechanisms
specified in this document is mainly based on the Cryptographically
Generated Addresses (CGA [RFC3972]).
Secure DHCPv6 is applicable in environments where physical security
on the link is not assured (such as over wireless) or where available
security mechanisms are not sufficient, and attacks on DHCPv6 are a
concern.
[snip]
3. Security Overview of DHCPv6
[snip]
Communication between a server and a relay agent, and communication
between relay agents, can be secured through the use of IPSec, as
described in section 21.1 in [RFC3315]. However, IPSec is quite
complicated. A simpler security mechanism may have better deploy
<JMC>
"However, IPSec is quite complicated."
May you clearly explain why, please?
<JMC>
ability. Furthermore, the manual configuration and static keys are
potential issue makers. Relay agents MAY require other security
mechanisms besides IPSec.
<JMC>
s/IPSec/IPsec
<JMC>
[snip]
5. Extension for Secure DHCPv6
This section extends DHCPv6. Two new options and a new DUID type have
been defined. The new options MUST be supported, if the node has been
configured to use Secure DHCPv6. The new DUID type MUST be supported
in the relay scenarios.
5.1. CGA Parameter Option
The CGA option allows the verification of the sender's CGAs. The
format of the CGA option is described as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CGA_PARAMETER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Parameters (variable length) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<JMC>
OPTION_CGA_PARAMATER is 15 bits long and option-len is 17 bits long: I
assume this is a typo :)
<JMC>
Jiang & Shen Expires October 12, 2010 [Page 6]
Internet-Draft draft-ietf-dhc-secure-dhcpv6-00.txt April 2010
option-code OPTION_CGA_PARAMETER (TBA1).
option-len Length of CGA Parameters in octets.
CGA Parameters A variable-length field containing the CGA
Parameters data structure described in Section 4
of [RFC3972]. This specification requires that
the public key found from the CGA Parameters
field in the CGA option MUST be that referred by
the Key Hash field in the Signature option.
Packets received with two different keys MUST be
silently discarded. Note that a future extension
MAY provide a mechanism allowing the owner of an
address and the signer to be different parties.
5.2. Signature Option
The Signature option allows public key-based signatures to be
attached to a DHCPv6 message. The Signature option COULD be any place
within the DHCPv6 message. It protects all the DHCPv6 header and
options before it. Any options after the Signature option can be
processed, but it should be noticed that they are not protected by
this Signature option. The format of the Signature option is
described as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIGNATURE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id | SA-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-id-KH | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (64-bit) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash (128-bit) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Signature (variable length) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<JMC>
Same comment as above about a typo: OPTION_SIGNATURE/HA-id/HA-id-KH
are 15 bits long and option-len/SA-id/Reserved are 17 bits long.
<JMC>
option-code OPTION_SIGNATURE (TBA2).
Jiang & Shen Expires October 12, 2010 [Page 7]
Internet-Draft draft-ietf-dhc-secure-dhcpv6-00.txt April 2010
option-len 32 + Length of signature field in octets.
HA-id Hash Algorithm id. The hash algorithm is used
for computing the signature result. RSA
signature [RSA] with SHA-1 [sha-1] is adopted.
In order to provide hash algorithm agility, SHA-
1 is assigned an initial value 0x0000 in this
document.
<JMC>
Be careful with this field: as explained in RFC4982, someone may
launch a downgrading attack.
<JMC>
SA-id Signature Algorithm id. The signature algorithm
is used for computing the signature result. RSA
signature with RSASSA-PKCS1-v1_5 algorithm is
adopted. In order to provide algorithm agility,
RSASSA_PKCS1-v1_5 is assigned an initial value
0x0000 in this document.
<JMC>
Maybe, it would be useful to have the same values (and so the same
length for this field) in your proposal and in
draft-cheneau-csi-send-sig-agility.
<JMC>
HA-id-KH Hash Algorithm id for Key Hash. Hash algorithm
used for producing the Key Hash field in the
Signature option. SHA-1 is adopted. In order to
provide hash algorithm agility, SHA-1 is
assigned an initial value 0x0000 in this
document.
<JMC>
IMHO, as commented above, a downgrading attack may be possible or did
I miss something?
<JMC>
[snip]
6. Processing Rules and Behaviors
6.1. Processing Rules of Sender
A DHCPv6 node, which could be a server, relay agent or client, can be
configured to send Secure DHCPv6 messages only if CGAs have been
configured on it.
The node MUST record the following configuration information:
CGA parameters Any information required to construct CGAs, as
described in [RFC3972].
Keypair A public-private key pair. The public key used
for constructing the signature MUST be the same
in CGA parameters.
CGA flag A flag that indicates whether CGA is used or not.
If a node has been configured to use Secure DHCPv6, the node MUST
send a message using a CGA, which be constructed as specified in
Section 4 of [RFC3972], as the source address unless they are sent
with the unspecified source address. In the message, both the CGA
option and the Signature option MUST be present in all DHCPv6
messages. The CGA Parameter field in the CGA option is filled
according to the rules presented above and in [RFC3972]. The public
key in the field is taken from the configuration used to generate the
CGA, typically from a data structure associated with the source
address. The Signature option MUST be constructed as explained in
Section 5.2 and be the last DHCPv6 option.
<JMC>
In Section 5.2, it is said "The Signature option COULD be any place
within the DHCPv6 message.". So, what is the correct policy regarding
the location of the Signature option?
<JMC>
In relay scenario, a DHCPv6 server MUST include an OPTION_SERVERID
[RFC3315] in Relay-reply message and put its CGA in the Server
Address field of the DUID in the OPTION_SERVERID. The CGA of DHCPv6
<JMC>
I assume this is where DUID-SA is used, correct? If so, maybe, clearly
mention this.
<JMC>
server will not lose during relaying so that the client can verify
CGA address and signature.
6.2. Processing Rules of Receiver
The node that supports the verification of the Secure DHCPv6 messages
MUST record the following configuration information:
Minbits The minimum acceptable key length for public
keys used in the generation of CGAs. The default
SHOULD be 1024 bits. Implementations MAY also
set an upper limit for the amount of computation
Jiang & Shen Expires October 12, 2010 [Page 10]
Internet-Draft draft-ietf-dhc-secure-dhcpv6-00.txt April 2010
needed when verifying packets that use these
security associations. Any implementation SHOULD
follow prudent cryptographic practice in
determining the appropriate key lengths.
<JMC>
In RFC3972, the RSA key length SHOULD be at least 384 bits. The
consequence is that your proposal cannot be compliant with all legacy
SEND nodes.
<JMC>
[snip]
In the relay scenarios, a DHCPv6 server obtains the CGA of a client
from the peer address field in the Relay-forward message. A DHCPv6
client obtains the CGA of a server from the Server Address field of
the DUID in the OPTION_SERVERID.
<JMC>
I assume this is where DUID-SA is also used, correct? If so, maybe,
clearly mention this.
<JMC>
Hope that may help you and thanks in advance for your reply.
Best regards.
JMC.
2010/4/12 <[email protected]>:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Dynamic Host Configuration Working Group of
> the IETF.
>
>
> Title : Secure DHCPv6 Using CGAs
> Author(s) : S. Jiang
> Filename : draft-ietf-dhc-secure-dhcpv6-00.txt
> Pages : 15
> Date : 2010-04-12
>
> The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
> DHCP servers to pass configuration parameters. It offers
> configuration flexibility. If not secured, DHCPv6 is vulnerable to
> various attacks, particularly fake attack. This document analyzes the
> security issues of DHCPv6 and specifies security mechanisms, mainly
> using CGAs.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> dhcwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
