I noticed that the draft is actually self conflicting in terms of the
Signature option:
5.2. Signature Option
... 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. ...
6.1. Processing Rules of Sender
... The Signature option MUST be constructed as explained in
Section 5.2 and be the last DHCPv6 option.
Again, per my earlier comments I think its position should not matter.
---
In 6.2. Processing Rules of Receiver:
The receiving node MUST verify the Signature option as follows: the
receiver MUST ignore any options that come after the Signature
option.
What about the contents of the Signature option itself? The document
needs to indicate which, if any, portion of the Signature option is
included in the signature hashing. (The SEND RFC (3791) excludes the
signature option.)
Note that earlier in section 5.2. Signature Option is written:
6. The content between the option-len field and
the signature field in this Signature option, in
the format described above.
Might be best to just refer to section 5.2 instead of duplicating the
information (less chance for it to conflict)?
---
This probably exposes my ignorance of CGAs, but is the intent in this
draft that the CGA source address used by the client remains the (CGA)
link-local address?
If this is the case (client uses CGA link-local as IPv6 source address),
all is well.
If the CGA address is not the link-local, then there is a conflict with
RFC 3315:
16. Client Source Address and Interface Selection
When a client sends a DHCP message to the
All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
through the interface for which configuration information is being
requested. However, the client MAY send the message through another
interface attached to the same link, if and only if the client is
-> certain the two interfaces are attached to the same link. The client
-> MUST use a link-local address assigned to the interface for which it
-> is requesting configuration information as the source address in the
-> header of the IP datagram.
When a client sends a DHCP message directly to a server using unicast
(after receiving the Server Unicast option from that server), the
source address in the header of the IP datagram MUST be an address
assigned to the interface for which the client is interested in
obtaining configuration and which is suitable for use by the server
in responding to the client.
A non-link-local address is only allowed if the server previously
provided the client with the Server Unicast option.
---
The following text is rather odd:
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.
DHCPv6 never uses an unspecified source address.
Also be good to use "CGA Parameter option" instead of "CGA option", as
that is what the option is called. This is an issue throughout the
document.
- Bernie
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Bernie Volz (volz)
Sent: Saturday, January 17, 2009 11:03 PM
To: JiangSheng 66104; [email protected]; [email protected]
Subject: Re: [dhcwg] "Secure DHCPv6 Using
CGAs"draft-jiang-dhc-secure-dhcpv6-01
I'm (still) a bit concerned about:
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:
Why is this protection positional? Can you explain why you think this is
useful? Why not secure the entire message with this?
The only interesting issue is if a client's message includes both a
SIGNATURE and AUTH (RFC 3315) option -- since in this case, two
different hashes over the entire message would need to be run and that
doesn't work. So, I think the SIGNATURE option MUST NOT include the AUTH
option. (The AUTH option would include the SIGNATURE option as RFC 3315
already requires that it cover the entire client message.)
I wonder whether this positional text is a hold over from DHCPv4 to
handle the Relay Agent Option (82) - which is added at the end? Relaying
in DHCPv6 is done far differently.
If there's a reason why the SIGNATURE needs to be positional, we still
have the AUTH option conflict that would need to be discussed (if the
AUTH option isn't excluded from coverage regardless of where it appeared
in the message, it would require the AUTH to follow the SIGNATURE).
---
The draft allows a node to be a DHCPv6 relay agent. I think more text is
required to detail this. Suppose you have:
Client --> Relay 1 --> Relay 2 --> Server
If Relay 1 includes a SIGNATURE option, and relay 2 does not support
this, what should the server do? How does the server know whether relay
2 validated the SIGNATURE of Relay 1 or not (is there a requirement for
the relay to validate -- it is after all a "node")? Should the server
validate all SIGNATURE options (as in this case, there could be 3 - one
in the Client message, one in the Relay 1 message (which encapsulates
the client's message), and one in the Relay 2 message (which
encapsulates Relay 1's message (which encapsulates the client's
message))?
Perhaps the ability for a relay to be a node should be removed? It keeps
it simpler.
- Bernie
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of JiangSheng 66104
Sent: Tuesday, January 13, 2009 4:43 PM
To: [email protected]; [email protected]
Subject: [dhcwg] "Secure DHCPv6 Using CGAs"
draft-jiang-dhc-secure-dhcpv6-01
The below "Secure DHCPv6 Using CGAs" has been updated, according to
comments that have been discussed in dhc maillist and IETF meeting.
Since early collaboration is requested for this CGA and DHCP interaction
work, this update message is sent to both CSI WG and DHC WG.
Best regards,
Sheng
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Secure DHCPv6 Using CGAs
Author(s) : S. Jiang, S. Shen
Filename : draft-jiang-dhc-secure-dhcpv6-01.txt
Pages : 14
Date : 2009-1-8
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-jiang-dhc-secure-dhcpv6-01.txt
_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
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
