FCIP: WWN short frame and IPsec

[Black_David@emc.com]

[Subject line changed to match topic under discussion.]

Venkat,

> > The existing text in the IPS security draft on pre-shared keys and IKE
> > authentication modes is fine in the absence of the recent WWN short
> > frame addition.  That addition changes the security properties of FCIP
> > by introducing an inband authentication/authorization for which it
> > is necessary to provide security.  Doing so without using an inband
> > authentication protocol impacts group pre-shared keys and other things.
> 
> The main intent of WWN short frame is merely a mechanism to identify an
FCIP
> entity peer and its properties not an inband authentication/authorization
> mechanism.

While that may have been the intent, the WWN is serving as inband
authentication/authorization (e.g., to allow a new TCP connection to
join the set of connections that make up an FCIP inter-switch link -
see explanation in my previous message about how not securing this
makes denial of service attacks possible).

> The assumption here is that as long as IPSec performs a source IP address
> validation against IKE address identifiers, a receiving FCIP entity is
> guaranteed that the short frame was sent by the source referred to in the
> source IP address. If it makes through the authentication (ESP) process,
> the WWN can be processed for FCIP link identification. Even when an
external
> IPSec gateway is in use, that gateway has already established the
necessary
> IKE Phase 1 so any Phase 2 SAs over which the received short frames arrive
> are also secured from a spoof.

In other words, IPsec is being used to secure the short WWN frame, which is
always present.  That has at least two consequences:

(1) IPsec has to be at least "SHOULD use", not "MAY use", and I can't
	promise that this won't turn into "MUST use".
(2) The identity presented in the IKE authentication for the Phase 1 SA
	MUST be checked against the WWN in the short frame to ensure that
	the WWN is presented by an IKE identity that is authorized to do
	so.  It's not acceptable to assume that these two would match if
	they were checked.

> If group pre-shared keys are in use, and one member of the group
impersonates
> another member and sends an attack FCIP Short Frame, that would create/add
> that connection at the receiving FCIP entity. However, this attack is
probably
> no different from a man-in-the-middle attack even in the absence of the
> FCIP Short Frame, when the group pre-shared key has been compromised and
an
> attacker has gained it. For FCIP implementations (unlike iSCSI) we do not
> expect large groups being handed out "generic" group pre-shared keys.

It's not that simple.  One of the things that concerns me here is that
improved FC security (e.g., the SLAP work mentioned by Bob) will not be
able to check the WWN in the short frame on TCP connections other than
the first.  The fastest way to resolve this issue is to make group
preshared keys "SHOULD NOT use" or "MUST NOT use" (both of which 
are stronger than "we do not expect"). 

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
---------------------------------------------------