Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hi Tim:

Thanks for the comments … and for looking at the document!

The document does say “manually configured key management may suffice, but does not provide defense against replayed messages. Accordingly, IKE …”. I think we’d change this may to MAY using normative language and we describe the limitations. As to the discussion about obsoleting, there are some cases where manual keys could still be desired (debugging, when using multicast – as is possible for relay to relay/server communication). So, I’m not sure we need a change?

But, if you have specific text changes you would like to see made, please provide them!

-          Bernie

From: Timothy Carlin [mailto:tjcarlin@iol.unh.edu]
Sent: Friday, December 09, 2016 12:04 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>; dhcwg@ietf.org; Yogendra Pal (yogpal) <yogpal@cisco.com>
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hello all,

I have done a brief review of this draft and I have some additional thoughts.

Regarding the use of Manual Keys, ipsecme is currently having a discussion about phasing out the use of Manual Keys.  See this thread for full context (Subject: [IPsec] RFC4301, rfc7321bis and Manual keys): https://mailarchive.ietf.org/arch/search/?email_list=ipsec&gbt=1&index=cMBLIx_ZzQVWP7lX1l-clgGdtvU

The document also recommends combined mode algorithms, such as AES-GCM, or AES-GMAC.  These algorithms, and similar, generally disallow the use of manual keys for security purposes.  For example, according to RFC4543, Section 2, implementations MUST use automated key management (e.g. IKEv2), as manual keying does not guarantee that a nonce and key is not reused and therefore makes these algorithms insecure.

Best Regards,
Tim Carlin, UNH-IOL

On Fri, Dec 9, 2016 at 11:27 AM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:
I discussed some of these issues with Tomek a bit.

Regarding the non-normative language issue, we have a proposal as follows:
- We will move the existing (non-normative language) into draft-ietf-dhc-rfc3315bis as it is best we don't require (but recommend) IPsec for DHCPv6. This would also correct the open issue we have in the draft-ietf-dhc-rfc3315bis document regarding the algorithms to use.
- We will reword this draft (in the 02) to use the normative (i.e., MUST) language. That way, if a vendor claims to be in compliance with this (future) RFC, they would have to fully support IPsec for the relay to server communication.

> idnits report some issues with references. The text cites RFC2409, but it was obsoleted by RFC4306.

I could be wrong, but my understanding is that RFC 2409 documents IKEv1. This was indeed obsoleted by IKEv2 (which is actually specified in RFC 7296 now -- 4306 was obsoleted by 5996 which was obsoleted by 7296). The reason we have both here is that we are referencing IKEv1 and IKEv2. I'm not so sure if there is any value in specifying IKEv1 anymore given that this us now almost 20 years old. I think the best move might be to change " Accordingly, IKE [RFC2409] / IKE2 [RFC7296] with preshared..." to just be " Accordingly, IKE2 [RFC7296] with preshared ..." and drop RFC 2409 altogether.

> idnits also complains about a disclaimer for pre-RFC5378 work. I think this is ok, because you're providing an updated text from RFC3315.

Correct.

>The document is very specific as to what is updated in RFC3315 (section 21.1), but it's blurry regarding RFC1542 update. Is there any specific text that is being updated? If there is, please clearly state so. If there isn't, maybe this draft doesn't update RFC1542?

For 1542, it really "extends" it since that document was silent about IPsec ... so we can remove this.

And, I wonder if we should even say it updates 3315 as that might imply it is "required" -- and we'll be updating draft-ietf-dhc-rfc3315bis already, as mentioned above. Thus I propose to just remove that (in the meta data and in the text).

I'll wait a few days to see if anyone has any comments to this thread before publishing the -02 revision.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org<mailto:dhcwg-bounces@ietf.org>] On Behalf Of Tomek Mrugalski
Sent: Friday, December 09, 2016 9:58 AM
To: dhcwg@ietf.org<mailto:dhcwg@ietf.org>
Subject: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hi,

There are my review of the draft. Apologies for sending it up so late, but I was travelling a lot recently. Finally got back home and catching up on my IETF duties.

Section 3 uses non-normative language like "it is highly recommended"
and "relay agents A and B must be configured to use IPsec". This is a standards track document, so why not normative language? I would very much prefer to have a normative text. When a vendor claims "my solution supports this RFC", what would it mean in its current form? The text is not normative, so technically someone could claim compliance and not do any of the IPsec at all.

The text in section 3 is also a bit conflicting. One part says "highly recommended" and the next sentence says "must". This should be consistent. My preferred way would be to go with "implementations conformant to this document MUST ...". This wording does not enforce vendors to implement it, but if they want to claim compliance, they really need to be able to do IPsec.

idnits report some issues with references. The text cites RFC2409, but it was obsoleted by RFC4306. If you have specific reasons why you reference the old text, please state it in the text explicitly.
Otherwise, just update the references.

idnits also complains about a disclaimer for pre-RFC5378 work. I think this is ok, because you're providing an updated text from RFC3315.

When you upload the next rev, make sure you bump up reference to
sedhcpv6 to -18.

The document is very specific as to what is updated in RFC3315 (section 21.1), but it's blurry regarding RFC1542 update. Is there any specific text that is being updated? If there is, please clearly state so. If there isn't, maybe this draft doesn't update RFC1542?

Other than the normative text clarification and 1542 update clarification, I think the draft is in very good shape. With my co-chair hat off, I support this work. With one more rev it should be ready to go.

Tomek

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg