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
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
