Authentication of DHCP Relay Agent Options Using IPsec
draft-ietf-dhc-relay-agent-ipsec-02

[Note]: 'Document was withdrawn from consideration after discussion with author, WG chairs, IESG and WG.  There is already another mechanism to secure this communication defined in draft-ietf-dhc-auth-suboption.' added by Margaret Wasserman

[Ballot 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 [4] 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 [12] 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.

[Note]: 'Document has been updated to address discuss comments from Russ and Bert -- on agenda to see if all issues have been resolved or if any remain.' added by Margaret Wasserman

[Ballot discuss]
I think the discussion of Authentication in section 6 needs to be expanded.
  The document recommends the use of IKE with shared secrets, which seems
  fine, but the document does not discuss the form of identity that is being
  authenticated.  I assume that the IP addresses will be employed.

  Also, I am picking up Steve Bellovin's DISCUSS comment.  Steve said:  Is
  replay protection a requirement or not?  If so, IKE needs to be a MUST
  rather than a SHOULD.

Sent an updated document, diff and response (all from Ralph) to Allison, Russ and Bert to see if it will address their discuss issues.  Document update will be published after Minneapolis.

[Ballot discuss]
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 [3] 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?

[Ballot comment]
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.

[Ballot discuss]
This  part is a "discuss" Discuss - the present draft describes pairwise IPSec to provide data integrity and replay protection for relay agents and DHCP servers.  Russ has pointed out that this will need to expand on the identity being authenticated, presumably IP addresses.  Then there's dhc-auth-suboption, which mirrors the client-to-server authentication of 3118, and provides a different way to provide data integrity and replay protection for relay agents and DHCP servers.  My discuss question:

How will these play together?  Why both?

--------

A concern:
              The information in DHCP messages is not generally
              considered confidential, so encryption need not be used
              (i.e., NULL encryption can be used).

This is not always the case - during the configuration of location
information (draft-ietf-geopriv-dhc-lci-option), it's important that the
relays not expose the DHCP information to eavedropping.  Suggest
this advice on mode be changed to "NULL encryption MAY be used,
but this general guidance must not override security considerations of
specific DHCP options, some of which strongly recommend usage
with IPSec with encryption"?

[Ballot discuss]
I think the discussion of Authentication in section 6 needs to be expanded.
  The document recommends the use of IKE with shared secrets, which seems
  fine, but the document does not discuss the form of identity that is being
  authenticated.  I assume that the IP addresses will be employed.