Edited Minutes of the 1/29/02 IPS Security Conference call

[Black_David@emc.com]

These minutes have been edited somewhat.  Summary of important topics
discussed on the call:

- IKE Identity Payloads.  Allowing use of FQDNs in addition to IP
	addresses as IKE identities will resolve an issue regarding
	dynamic addresses raised on the list.  The entire list of
	possible IKE identities needs to be reviewed as part of this change.

- IPsec and authorization.  New iSCSI MIB model proposes to list IKE
	identities for authorization purposes, iSNS can also help with this.

- IPsec certificates.  A warning will be added about large keys increasing
	the likelihood of IKE running into IP fragmentation which often
	causes failure in practice.

- Rekey intervals - The intervals specified in the draft were calculated
	under overly pessimistic assumptions and hence are unduly short.
	They'll be removed and replaced with a general description of the
issue.

- Security policy, Send Targets and iSNS.  Independent of whether iSNS is in
	use an iSCSI Initiator needs to know whether IPsec is needed to
contact
	a Target.  Beyond that, IKE can handle all required feature
negotiation.
	iSNS can distribute the info about whether a target requires IPsec,
and
	can store IKE proposals for convenience.  An attribute indicating
whether
	a Target requires IPsec will be added to SLPv2 for iSCSI.  The
easiest
	way to deal with Send Targets is to make it homogeneous wrt IPsec
usage
	- if IPsec is used for the session on which the Send Targets is
	performed, it's used to contact the Targets obtained.

- Dangling SAs.  Paul Koning was correct about the prohibition of dangling
	SAs being excessive.  The requirement to delete phase 2 SAs when the
	corresponding phase 1 SA goes away will be removed.

- Transport mode vs. tunnel mode.  A key observation is that unlike remote
	access, IP Storage protocols do not generally need to dynamically 
	allocate IP addresses through IPsec tunnels.  Long email with
diagrams
	will be forwarded to the list shortly.  This removes the
specification
	and significantly reduces interoperability concerns in this area,
	removing the last major obstacle to requiring tunnel mode.

	Summary of proposed requirements for tunnel and transport mode:
	- Tunnel mode would be REQUIRED in all cases for interoperability.
	- RFC 2401 classifies every IPsec implementation as either a host
		or security gateway; Transport mode would also be REQUIRED
		for host IPsec implementations.  This condition is *solely*
		about IPsec implementations - it is in principle possible to
		use a security gateway in conjunction with any iSCSI, FCIP,
		or iFCP system, even to the point of integrating the gateway
		onto an HBA or NIC.
	More details below.
- Tunnel mode address usage.  Configuration and discovery can be painful
	if the inner and outer IP addresses are different.  There are no
good
	solutions to this in the current IPsec world beyond manual
configuration.
	Query to list on this topic coming shortly.

Detailed minutes:

We got into a discussion of the -07 draft, posted in December. The
changes were relatively minor from -06; major difference was the attempt
to be more general by referring to "IP storage protocols" when text
intends to apply to iSCSI, FCIP and iFCP. That way, if a new IP storage
protocol comes along it will be covered and we won't have to revise the
draft again. Participants were urged to read over the -07 drafts and send
any issues to the iSCSI security list and/or the IPS WG list. 

We then talked about IKE identity payloads. David Black noted that the
current text requires use of IP addresses as identifiers. This is limiting
because if the addresses are dynamically assigned you will effectively be
requiring group pre-shared keys, which was what we were trying to avoid by
favoring aggressive mode for pre-shared keys. 

The solution is to change the text to also enable use of FQDNs as
identifiers. There was discussion about whether other ID payloads would
also be acceptable. This depends on whether we are talking about transport
mode or tunnel mode. For transport mode, IP subnets or ranges doesn't make
sense; it might make sense for tunnel mode. It was resolved that Bernard
will consolidate the text relating to ID payloads and make a proposal to
the list on how it should be changed, so that we can make progress. 

We then got into a discussion of IPsec and authorization. In our
discussion of SLPv2 security as part of the IPS security effort, we had
gotten into a discussion of whether IPsec could be used for SLPv2
security, instead of the RFC2608 security. We decided this was ok, and
Erik Guttman subsequently incorporated IPsec into the RFC2608bis security
model, removing the previous model. This has caused some discussion about
how authorization is done. For example, how do you know that a host is
authorized to act as SA? DA? 

David noted that with FQDN identifiers, an iSCSI target might be
configured with a list of authorized FQDNs. Assuming that IPsec
authentication was successful, this list of FQDNs could be examined to
determine Initiator authorization. IPsec is also capable of doing some
basic authentication, by configuring Initiators and Targets with the
appropriate trusted roots. The trusted root for IPS protocols might be
different from trusted roots for other purposes. The implication here is
that IPsec is really most appropriate for intra-domain use -- as has been
pointed out by the IESG. 

Looked at the other way, an Initiator doing iSCSI logon authentication via
a mutually authenticating method (e.g. SRP) would know whether a Target
was authenticated or not. David Black pointed out that with CHAP the
Target is not authenticated, only the Initiator, so you might not always
know that. 

It is also possible for iSNS to supply authorization information, which
can make the process of maintaining this more scalable. Text will be
drafted describing how authorization could be accomplished: via iSNS,
manually, etc. 

It was noted that since RFC2608bis now incorporates the IPsec security
text, that we can probably remove the text from the IPS security draft and
just reference RFC2608bis, assuming it goes through. This seems cleaner
and less likely to result in conflicts down the road. 

We had a short discussion of IPsec certificate handling. It was noted that
PKIX is going to be working on this -- but that they have traditionally
been slow at completing things. We talked a bit about the IKE cert
fragmentation problem. Hillarie Orman's draft on key sizes implies a
2048bit key recommendation for use with AES. The larger key sizes in turn
imply larger certs, particularly if OIDs are added. This means that an IKE
certificate chain will almost certainly cause fragmentation, and even a
single cert may get close to causing IKE fragmentation. 

IKE fragmentation is a problem because most NATs will drop fragments as
will many routers (recent versions of Cisco IOS can handle this
correctly). David Black requested that we insert a warning describing the
problem. Unfortunately it is a nasty one because it doesn't really have a
good solution in the current version of IKE. 

There was a discussion of dangling IKE Phase 2 SAs. These are not
prohibited in RFC 2401-2409, and some implementations have them. Yet the
IPS security draft prohibits them. This text should probably be removed --
delete the section discussion how IKE phase 2 SAs should be deleted on
receipt of an IKE phase 1 delete. Bernard took this as an action item. 

There was a discussion of IKE rekey intervals. The Bellare et al. paper is
really about the birthday attack problem. That is, since CBC modes depend
on the previous ciphertext block, if two ciphertext blocks are identical
and the next plaintext block is also identical then the next ciphertext
block is also identical. This allows an attacker to find areas of
repetition within the plaintext. 

A single birthday attack instance is expected to occur in 2^(X/2) blocks,
where X is the block size in bits. Probabilities for birthday attack
occurrence are easily calculated via combinatorics. 

The current draft text is extremely conservative in that it requests that
rekey occur in considerably less than 2^(X/2) blocks. This seems excessive
in that even a single birthday attack instance doesn't leak much
information -- you just know that two plaintext blocks are the same. To
get more information you'd need quite a few birthday attack instances,
which is very unlikely in just 2^(X/2) blocks.  So the proposal is to
redo the calculations using the 2^(X/2) formula. David Black requested
some explanation of the issue as well. 

We also talked about the status of ESPv3. This is currently non-normative
(not required by IP Storage protocols), and David Black requested that it
stay that way unless it was in IPsec WG last call by IETF 54 in Yokahama,
Japan. 

We talked about iSNS security policy. The goal of the IPS security
document is to specify IPsec parameters well enough so that
implementations will be able to negotiate things and interoperate off the
bat. As a result, the minimum piece of configuration required is whether
an IPS endpoint requires IPsec or cleartext. This can't be determined from
IKE alone without risking a long timeout, something undesirable for a disk
access protocol. 

The information can be configured manually, or can be supplied via
iSNS. If an Initiator can obtain IPsec security policy from other means
(manually, via IPsec security policy functionality) then it need not query
the iSNS server for this information. However, if it doesn't have the
information, it can use iSNS to obtain an IKE proposal payload for a
particular Target. 

The question was asked about what security configuration information
could/should be provided by SLPv2. The minimum configuration would be an
SLPv2 attribute describing whether a Target supports IPsec. 

It was noted that if iSNS or SLPv2 is used to determine security policy or
configuration, then these protocols MUST be secured. Otherwise, an
attacker could provide bogus security policy to convince a host to connect
to it in cleartext. Authorization is important too, or else an attacker
who had an IPsec certificate could masquerade as an iSNS server or SLPv2
DA and provide bogus information. 

We then got into a discussion of tunnel mode vs. transport mode. David
Black noted that in many situations, IPS gateways are not functioning as
IPsec gateways or an IP router. Thus, the IPS gateway will not routing
packets through it -- both the inner and outer tunnel addresses will be
consumed by the IPS gateway. 

As a result, the IPS gateway will not need to assign addresses for use
with IPsec tunnel mode. This simplifies things considerably. 

It was resolved that Bernard would put together text explaining the
various configurations and the implications, based on David's original
message on the subject. 

With respect to the IPsec tunnel mode vs. transport mode debate, David
proposed the following: IPsec tunnel mode is a MUST implement for both
Initiators and Targets; IPsec transport mode is also required where
RFC2401 says it is required. 

RFC 2401 requires Transport mode for everything but IPsec gateways. 
The end result of this is that a Target might be able to just implement
Tunnel mode if it were to act as an IPsec gateway; however, if it is not a
gateway, then it MUST implement transport mode.

For the specific case of an iSCSI initiator, only tunnel mode would
be "MUST implement", as that is the minimum requirement for
interoperability.
If an initiator's IPsec implementation is an IPsec gateway (as RFC 2401
defines and uses that term), then it would not be required to implement
transport mode.

The question was raised of whether having to do both transport and tunnel
mode
was excessive. Would this be a problem for hardware vendors?  David
Black felt that this approach seemed like the only way to satisfy both
those vendors who want to enable separate gateway boxes as well as those
who prefer the efficiency and end to end approach of IPsec transport mode.
Existing IPsec implementations conform to RFC 2401, and hence this
requirement
(transport mode required where RFC 2401 says it is required) should not
cause
problems for use of such implementations.  Finally, David felt that not
only was adhering to this aspect of the IPsec architecture a good thing to
do in principle, but in practice it should also help avoid Last Call
objections that iSCSI is misusing IPsec by departing from the architecture.

In connection with the latter point, a question was raised about whether
not requiring AH could cause difficulties.  It will not, because the
ipsec WG is in the process of revising RFC 2401 to (among other
things) remove the current requirement for AH.

Sorry for the delay in getting these out.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------