IKE Subsetting Comments

[Black_David@emc.com]

Although not discussed in detail at the interim meeting, I offer
the following comments on IKE subsetting:

[A] Authentication algorithms.  IKE contains four authentication
	algorithms:
	- Signature authentication, usually based on certificates
		binding identities to signature keys [RFC 2409, Section
		5.1].
	- Public key encryption authentication (2 algorithms), usually
		based on certificates binding identities to encryption
		keys [RFC 2409, Sections 5.2 and 5.3]
	- Pre-shared key authentication, based on demonstrating
		possession of the pre-shared key.  There is an
		administrative responsibility to only provide that key
		to appropriate systems, as there is no other IKE
		identity check performed [RFC 2409, Section 5.4].
As William Dixon indicated in his presentation, the public key
encryption algorithms are good candidates for deletion, and the
improveike draft (draft-ietf-ipsec-improveike-00.txt) also
recommends dropping them.  I would recommend that they at least
be "NOT REQUIRED to implement".  Going further (e.g., to "SHOULD
NOT use") takes a risk on the direction of the ipsec WG that
I don't see as necessary.

Pre-shared key authentication is the simplest, and hence a good
selection for "MUST implement".  To make signature authentication
a "SHOULD implement" or "MUST implement", I would want to see
additional text about certificate usage and validation including
topics such as single certificate vs. chain, certificate authorities
(esp. issues arising when multiple authorities are possible),
certificate revocation, and use of self-signed certificates. 
The goal would be to limit the complexity of recommended or
required certificate processing.  The Aboba draft contains a
start on this, and I would ask the authors of that draft to
come back with a more complete and concrete set of recommendations
in this area.  Can we wait for such a set of recommendations
before embarking on further discussion of certificate usage
restrictions?  There are potentially huge gains in reduction
of IKE code and complexity from restrictions in this area, but
we need to start with recommendations from experts.

[B] Operating modes.  The fundamental issue here is whether to
require Main Mode and/or Aggressive Mode for IKE Phase 1.  Main
Mode hides identities at the cost of an extra round trip in the
IKE Phase 1 protocol.  Also, as described in both the Aboba draft
(draft-aboba-ips-iscsi-security-00.txt) and the improveike draft
(draft-ietf-ipsec-improveike-00.txt), Main Mode is not secure
against man-in-the-middle attacks when used with dynamically
assigned IP addresses (e.g., from DHCP).  IMHO, this makes
Aggressive Mode a "MUST implement", as I would expect at least
iSCSI initiators to be deployed in environments where DHCP
is used for IP address assignment.  This problem with Main
Mode is arguably an oversight in its specification, but it's
a specified, deployed, interoperable, and REQUIRED oversight,
and one that we don't have the ability to change.  The change
recommended in the improveike draft is for IKEv2 (aka son-of-IKE),
which is off in the future somewhere.

In addition, I suggest also making Main Mode a MUST, as it
has advantages in some situations (identity hiding), it is a
MUST in RFC 2409 and it is present in essentially all
implementations of IPsec.  This will avoid a potentially
deep and unproductive rathole discussion on Main Mode vs.
Aggressive Mode. 

Thanks,
--David
 
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------