Authentication of DHCP Relay Agent Options Using IPsec
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
(Steven Bellovin) Discuss
Discuss (2004-01-07 for -** No value found for 'p.get_dochistory.rev' **)
Is replay protection a requirement or not? If so, IKE needs to be a MUST rather than a SHOULD.
(Russ Housley) (was No Objection, Discuss) Discuss
SecDir Review was conducted by Steve Bellovin and Steve Kent. Steve Bellovin had a DISCUSS on an earlier version of this document regarding replay protection. Not all of those concerns have been adequately addressed. Steve Kent uncovered a few concerns regarding alignment with 2401bis and the other IPsec documents that are in the RFC Editor queue. While my comments are long, I believe that most are very simple to address. One or two points may require dialogue. The document Introduction says that the goals are: > > 1. protect the integrity of the data that the relay adds > 2. provide replay protection for that data > 3. leverage the existing IPsec mechanism > I think that you are also trying to authenticate the relay agent as the source of the data. In section 4, 3rd paragraph, please change "privacy" to "confidentiality." In section 4, There are many other forms of DoS attack. I suggest that this text ought to say that the ones discussed are samples. Consider this one: the attacker can assign false DNS servers, with obvious bad consequences. In section 5, 1st paragraph, please change "IPsec trust relationship" to "IPsec security association (SA)." In section 5, Selectors discussion, a traffic selector consist of the address AND UDP (as the protocol) AND the well-known ports for the targets. The current wording leads the reader to believe that the selectors are only the addresses, which is incorrect. In section 5, key Management discussion, says: > > IKE  with preshared secrets must be used. > s/must/MUST/ It also says: > > DHCP messages ... should only be accepted from DHCP peer > s/should/SHOULD/ And, why isn't this a MUST? Third, it is fair to say that pre-shared secrets are sufficient when working in a small, single administration context; however, the ephemeral Diffie-Hellman exchange used by IKE is useful and desirable even in this context. Since it is ephemeral, it does not add to the administrative burden. Fourth, I'm concerned about the qualifier "If replay protection...." Replay protection is identified as a goal in the Introduction. Please reword this portion mandate implementation; however, implementations SHOULD support manual keying for environments where replay protection is not needed. Please see the analysis in RFC 3562 regarding preshared secrets. Fifth, more detail on IKE options needs to be specified. The document does not specify which modes ought to be used, what identity forms are to appear in certificates when they are used, which forms of public key authentication must be supported, and so on. Please look at RFC 3788, section 5, for an example of how to specify IKE usage. In section 7, I would like to see a SHOULD use IKE. This relates to the above point on section 5 that an ephemeral Diffie-Hellman exchange used by IKE is useful and desirable. Second, the references to  is good, but the section should talk about residual vulnerabilities. In particular, attacks on the link between the client and the first relay agent need to be discussed. Also, please state the reasons that link-layer security does not solve all of the problems being discussed. Please reference the updated IPsec documents, like 2401bis. All of these documents are in the RFC Editor queue.
(Bert Wijnen) Discuss
Discuss (2004-01-08 for -** No value found for 'p.get_dochistory.rev' **)
From the OPS Directorate review: High order bit: This draft needs to be more specific with respect to the intended IPsec and IKE usage. Section 6 This draft references only IPsec documents such as RFC 2401 and 2406, but not IKE, which is odd since it does say that IKE with preshared secrets SHOULD be supported. In places there is confusion as to how keys are to be derived (manually or dynamically). For example, in Section 8 it seems to imply that manual keying MUST be supported. "Relay agents and servers can use IPsec mechanisms  to exchange messages securely as described in this section." What specific IPsec security properties are required? Support for ESP with non-null transform? Support for ESP with null transform? Support for AH? Replay protection? "If there is a single relay agent between the DHCP client, there MUST be an IPsec trust relationship established between the relay agent and the DHCP server." What are we saying here? That there needs to be a manual key put in place for use with IPsec? If so, what are the SA parameters to be used? Or are we trying to say that IKE is to be used with any of the authentication modes? I'm not sure. " In Figure 1, relay agent A and the DHCP server must have an IPsec session through which DHCP messages are exchanged." It would be more specific to talk about setup of IKE Phase 1 and Phase 2 SAs if that is what is intended. The draft could use a paragraph on IKE identifier payloads specifying which ones are REQUIRED for implementation. Also it would be helpful to state which MODES are required. Tunnel mode? transport mode? Aggressive Mode? Main Mode?
(Margaret Cullen) Yes
(Harald Alvestrand) No Objection
(Brian Carpenter) No Objection
Echoing Harald's No-Objection
(Bill Fenner) No Objection
(Ned Freed) No Objection
(Ted Hardie) No Objection
(Scott Hollenbeck) No Objection
(David Kessens) No Objection
(Allison Mankin) (was Discuss) No Objection
My Discuss is satisfied by new text explaining applicability considerations. I've changed my position to a no-objection in anticipation of the 02 draft
(Jon Peterson) No Objection
Comment (2004-01-08 for -** No value found for 'p.get_dochistory.rev' **)
It seems a little weird to me that there is a MUST (beginning of Section 6) for the use of IPsec if there is a single relay agent in the path, but that there is no MUST/SHOULD for cases in which there are multiple relay agents. (I think that's actually the only MUST in the document, and there's one SHOULD that I can see.) Perhaps the "must" in the first (and perhaps fourth and fifth) sentence of the second paragraph of Section 6 merits capitalization? Nit - "Attributes" seems to be misspelled in the last bullet of Section 5.