RE: Separate SA for each TCP connection

["Joseph D. Harwood" <jharwood@vesta-corp.com>]

Hello,

A couple of comments below.

Best Regards,
Joseph D. Harwood
(408) 838-9434
jharwood@vesta-corp.com
www.vesta-corp.com


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Ernest Dainow
> Sent: Monday, February 18, 2002 7:53 AM
> To: 'Bernard Aboba'
> Cc: 'ips@ece.cmu.edu'
> Subject: Separate SA for each TCP connection
>
>
>
> I think that the requirement that every TCP connection must have
> its own SA
> (Security Association) has a number of problems.
>
> First of all, it is difficult to enforce on the receiving side, if the
> sending end does not comply with this requirement and uses an existing SA
> for a second TCP connection. When IPSec receives a packet with a
> valid SPI,
> it cannot discover that the packet was sent on a different port
> number than
> the SA was set up for until after the security processing.
>
> To meet this requirement, extra checking must be done to compare every
> packet to the SPD (Security Policy Database) after security processing. If
> this is done, then various interoperability problems may occur when
> communicating with an end device that is using standard IPSec.

This checking on inbound traffic is a required part of IPsec (RFC2401,
Section 5.2.1).

>
> The SPD is configured with Source IP:Port, Destination IP:Port. When an
> administrator configures this, the source port is not known and so a wild
> card is usually used. In standard IPSec implementations, this means that
> multiple connections to the same destination address:port will travel down
> the same SA.
>
> Interoperability between standard IPSec and IPS IPSec may be needed in a
> number of situations:
> 1. Using tunnel mode to connect to a storage device behind a gateway, such
> as a firewall (which terminates the IPSec connection).
> 2. Connections to an iSNS or SLP server which likely will be
> implemented on
> an industry standard OS that uses standard IPSec.
> 3. If the IP/IPSec stack on the IPS device is used as a TCP offload engine
> for traffic other than storage. Common uses might be for
> management such as
> telnet.
>
> The only reason for this requirement that I could find is in Section 5.8.3
> of draft-ietf-ips-security-09.txt.
>
> "IPsec implementations that only support machine authentication typically
> have no way to distinguish between user traffic within the kernel. As a
> result, where machine authentication is used, once an Ipsec SA is opened,
> another user on a multi-user machine may be able to send traffic down the
> IPsec SA. To limit the potential vulnerability, iSCSI, iFCP or
> FCIP security
> implementations MUST negotiate a separate IPsec Phase 2 SA for each
> connection, with descriptors specific to that connection."

How does requiring each connection to have its own Phase 2 SA mitigate the
vulnerability in this scenario?

>
> This is a general feature/limitation of IPSec. IPSec by
> definition operates
> at the network layer. If application layer authentication is desired, it
> should be done by the application. iSCSI has the option to use
> SRP or other
> authentication methods. Proposals have been made for FCIP to provide an
> option for user authentication based on SRP, consistent with iSCSI, but
> current direction has been to favor a Fibre Channel based authentication
> scheme (yet to be defined).
>
> The potential interoperability problems resulting from the requirement to
> have a separate SA for each TCP connection is not worth the attempt to
> "limit" this vulnerability, when other clean ways exist to establish user
> authentication.
>
> Ernie Dainow
>