On 29.04.2014 20:21, Tomek Mrugalski wrote:
> Hi all,
> 
> This message starts DHC working group last call about advancing Secure
> DHCPv6 with Public Key document as a Standards Track RFC. The authors
> believe that this version addressed all the issues raised and is ready.
Apologies that I didn't participate in the discussion and didn't
review this draft earlier.

<dhc co-chair hat off>
I read draft-ietf-dhc-sedhcpv6-02 and support this work. I think there's
significant value in this work. I agree with previous commenters that
the specific use cases could be described somewhere, perhaps in the
introduction section. One use case where it could be useful is a high
security network, like a military base or a R&D department that wants to
protect its secrets. This authentication could be mutual - legitimate
employers are provided with devices that have preconfigured keys and
this mechanism is an additional step in access control. On the other
hand, the employees want to make sure that they indeed connect to the
legitimate network, not a spoofed one. Another use case could be a paid
hotspot. Unknown clients are assigned a different set of
addresses/options that get them to the site where they can pay for the
service. Once the service is paid, the client becomes known and future
configuration will get him direct connection, thus bypassing annoying
login/pay portal. Having to go through the captive portal only one could
be a big advantage of this mechanism.

The server authentication could also be useful. Mobile clients can
store list of previously visited networks that are known to work.

I think it is important to add a section that enumerates those and
similar use cases. Otherwise you risk that this work will be stalled
and you'd be asked to write a separate problem statement document.

Section 1 claims that messages exchanged between relay agents and
servers are less vulnerable. That is usually true, but it is possible
for client to spoof a relay. Instead of sending plain messages,
it could send Relay-forward messages with spoofed options and
Solicit or Request inside it. I don't see any obvious attack vector
here, though.

Nitpick: I'm confused what the fourth paragraph is Section 3 is about.
It starts discussion about manual key distribution, but then explains
flaws of reconfigure key authentication. These are not really related
topics, so I think it would read better if the text was split into 2
paragraphs.

Section 4:
soltuion => solution
certificates are can be used => certificates can be used

Nitpick: The text mentions clients and DHCPv6 servers. It reads a bit
awkwardly. It should be either "DHCPv6 clients and DHCPv6 servers" or
"clients and servers". You may mention in Terminology section what
clients and servers mean and then use that shorter version throught
the text. It will just read easier.

Section 4.3 says "the DHCPv6 server (for most of known DHCPv6
implementations) would just omit or disregard unknown options and still
process the known options." Are you aware of any implementations that
do not follow this principle?

"If the client accept the unsecure messages from the DHCPv6 server.
The subsequent exchanges will be in unsecure model." Those two
sentences should be combined into one.

"If the server mandidates the authentication..." =>
"If the server's policy requires the authentication..."

Section 5.1: The Public key format is confusing. Should it be binary
data or hex? Second sentence suggests that it's hex string. 2048bit key
requires 256 bytes if sent as a binary. However, if you send it as
hex string, it requires 512 bytes. Obviously, better way is to send
it as binary, as it is size optimal.

+1 for having packet size discussion in the document. Here's my take
on it:

Section 5.2 says that the maxium certificate length is 65535 bytes.
There are other limits that would practically never allow you to put
that large option. The first soft limit is MTU of the interface, which
is typically 1500 bytes - IPv6 header size - UDP header - DHCPv6
header - size of mandatory options - size of certificate option
header. (Some may point out that the min. MTU for IPv6-capable links
is 1280, so the limit may be even lower than that). This is a "soft"
limit. If you cross it, DHCPv6 messages will get fragmented. There's
nothing in RFC3315 that forbid that, but I never saw fragmented DHCPv6
packets out in the wild and I expect that it may cause problems
(firewalls dropping fragments, simple clients not supporting
fragmentation etc.). You can get above that limit, but you'd be
walking on an increasingly exotic territory. The next limit is imposed
by Payload length in IPv6 header. Its max. value is 65535, so you need
to decrease it by mentioned UDP/DHCPv6/options headers. So even
max. UDP packet is not enough for storing the max size of the option
you propose. I'd be very interested in seeing how existing
implementations behave when they receive 64k packets. If you really
want to go above that, there are jumbograms (see RFC2675). Although I
haven't checked that, my gut feeling is that current implementations
will be puzzled when they get a jumbogram-wrapped DHCPv6 packet. Note
that the current text of section 5.2 implies that jumbograms are
required to deliver the biggest OPTION_CERT_PARAMETER option. I do not
know how big X.509 certificates can be. If they are approaching 1500
bytes, you should have a section discussing the issues I mentioned.

This document defines two mandatory algorithms: SHA-256 for hash and
RSASSA-PKCS1-v1_5 for signature. I'm not a security expert by any
means, so I'm not questioning those choices, but it would be useful if
you could include some background information why you chose those two.

Time stamp in section 3. You chose the timestamp to follow RFC5905
format (64 bit, starting 1 Jan 1900). DHCPv6 already defines a time
format (see section 9.2 in RFC3315), which unfortunately is only
32bits. NTP format has the advantage of being 64 bits, but
unnecessarily covers dates from 20th century. RFC3315 style on the
other hand begins 1 Jan 2000, but is only 32 bits. Perhaps it would
make sense to define a new format: 64 bit, starting in 2000? This is
just somthing to consider. I'm ok if you want to keep current format.

They last paragraph in 5.3 says that authentication option is not
covered. So it's unclear for me how should I calculate the digests
if both authentication and signature options are present.

Section 5.4 defines new value of status code called
NotSupportAlgorithm. The name sounds a bit awkward.
AlgorithmNotSupported sound better in my opinion. Also, its definition
says that the server does not support algorithms that the sender
(presumably the client) used. What is the opposite is true: client does
not support an algorithm that the server used? Up until now, client
never did send status codes. Is the case where client needs to
communicate this failure to the server described in the text? Also, I
think the status descriptions should be reworded to use either
server/client or sender/receiver.

Further in the same section: SignitureFail => SignatureFail. That
misspelling appears in multiple sections.

Section 6.1: which MUST contructed => which MUST be contructed

Section 6.1 "Upon receiving an AuthFailNotSupportLoF error status
code [...] the client MAY switch to other certificate or public
key if it has.  But it SHOULD NOT retry with the same certificate/
public-key." Why SHOULD NOT and not MUST NOT?

"Upon receiving a SignitureFail error status code, the client MAY
resend the message.". I have 2 issues with that. First, if the
receiver was unable to verify the signature first time, why would
retransmission fix anything? It is likely that the repeated
transmissions will also fail signature verification. Second, there
should be some clarification regarding retransmission not being
immiediate. Otherwise, you risk clients flooding the server. I think
some clarification like "upon receiving non-success status code, the
client follows normal retransmission routines defined in RFC3315"
would do the trick here.

Section 6.2: "In the failure cases, both DHCPv6 server and client
SHOULD NOT process received message, and the server SHOULD reply a
correspondent error status could, while the client does nothing."
Isn't this a configuration policy? I can imagine a case where clients
that failed authentication are still served, but they get a different
threatment (like a separate subnet with captive portal that explains
what they are supposed to do).

The paragraph that discusses leap of faith should say that specific
behavior depends on configured policy.

Section 6.4 rough synchronized clocks => roughly synchronized clocks

Section 7 "The clients may decline..." => "The clients may discard..."
('decline' has special meaning in DHCPv6 context).

Section 8: Why do you need reserved (0000) value in Hash algorithm
table?

I'd like to see a section describing key rollover. It doesn't have to
be long. Just a paragraph or two would suffice.

<co-chair hat on>
I'll chat with Bernie early next week and we'll wrap up this WGLC
shortly afterwards.

Tomek