RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting)

[Black_David@emc.com]

Bob,

> Let me try this again.  (E-mail sure is a slow medium
> of information exchange.  We need some more face-to-face
> meetings on this subject.)

The next opportunity is Salt Lake City.

>   If secure IPSec connections can be made, I will use
>   those connections.  The information about
>   the boxes and the permissions to connect them are part of the
>   administrative set up necessary to bring them into a secure
>   environment.
> 
>   If that is an exposed connection and carries information that
>   is important enough to be worth protecting, some degree of
>   encryption will be used on ALL data transmitted on the 
>   connection, including the initial information passed to the
>   opposite end point.  If you did that, the WWN would be
>   never be publicly available on the network, but only available
>   through the administrative mechanisms (like walking up to the
>   device through your bullet proof glass doors and examining its
>   labels).

In other words, FCIP relies on the presence of IPsec to provide
adequate security to a mandatory authentication element of FCIP.  I
think that makes IPsec at least "SHOULD use" for FCIP, and possibly
"MUST use".  This would come with some environmental caveats, but
the upshot is that FCIP goes directly from no security to cryptographic
connection integrity without the possibility of just securing the
authentication (unlike iSCSI) - that jump makes me uncomfortable.
FWIW, only cryptographic connection integrity is required - WWNs are
not secret, and hence confidentiality is not in principle necessary
to protect them.
 
>   If you truly truly cared about the connection, you would have
>   gone to the trouble of using keys (perhaps pre-established) 
>   that were not group pre-shared keys.
> 
>   A lot of this is of the nature "if it hurts, don't do it
>   (unless it is worth the pain)".  Who would allow his SAN
>   to pass important data without providing security mechanisms
>   appropriate to the value of the data?  If you care, you would
>   not use group pre-shared keys, but some other kind of keying.
>   If you care, you would use confidentiality protection.
>   It really does not make much sense to criticize a security
>   approach by making the assumption that you are going to 
>   throw away your first lines of defense.

And this makes group pre-shared keys at least "SHOULD NOT use",
probably "MUST NOT use".  Thou shalt not present the user with
security mechanisms that provide only the appearance of security
as opposed to actual security - such mechanisms are more dangerous
than omitting security entirely.  FWIW, I could see a more complex
discussion about making sure that the domain of sharing of
pre-shared keys matches the domain of trust among systems, but
this is a slippery slope, as the concept of "domain of trust" is
inherently not arbitrarily scalable.

>   Since the identity of the box is very much part of the same
>   administrative setup, and because (in the latest revision of
>   our proposal) the forward information exchange to the remote
>   point includes both the known source and the expected destination,
>   either side has the right to terminate the connection if
>   the information is incorrect.  If all the administrative
>   information necessary to form a secure connection and all the
>   administrative information necessary to control access to 
>   FCIP devices is known to a device, it is by definition 
>   authorized to perform the connection.  You must deny untrustworthy
>   devices some part of the necessary information for any security
>   program to work.

I agree with this as far as it goes, but note that WWNs are not
considered secret, and hence any rationale for security that depends
on them being secret is ill-founded (another way of arriving at your
comment about not using group pre-shared keys if they don't provide
enough security).  In turn, this means that if a WWN is part of
the "administrative information necessary to form a secure connection",
it has to be securely associated with something that is authenticated
based on information that really is secret.  If that authentication
is performed by IKE, the result is at least the "SHOULD use" and
"SHOULD NOT use" indicated above.
 
>   As the first connection is formed, it indicates what type of
>   information may flow across it.  Typically, the first connection
>   will permit only class F information (and no other connection will
>   permit class F information).  Any attempt to create a second
>   class F information connection will terminate the entire set of
>   connections, since it is a protocol violation as well as a security
>   violation.  You are correct in saying that the first is the connection
>   that will perform the SLAP authentication.  Note that some part
>   of this protocol is specified by T11 in FC-BB-2, not in FCIP.

Notice the denial of service attack opening here - if the attacker
can form a second class F connection, the entire FCIP inter-switch
link goes down, and SLAP can't do anything about it.  Another opportunity
would be setting up a Class 2 and/or Class 3 connection and bit-bucketing
some portion of the traffic, which will lead to severe indigestion at
the FC switches.  This leads directly to ...

>   Subsequent connections can only be created from the same device
>   and are assigned classes of information and other usage
>   characteristics by that same device.  If any other device tries
>   to do so, and expects to be successful, it must have all the
>   administrative information necessary to create a second secure
>   connection and must have knowledge of what connections the
>   first device's previous connections and FC information exchanges
>   would permit to be set up.  And if it has all that information,
>   it is by definition permitted to establish the connection.
> 
> I really don't see how you can create a bothersome second connection 
> unless you have chosen to allow violation of the security of your
> administration procedures.  And if you allow violation of the
> security of your administration procedures, I don't see how you 
> can prevent a malicious connection using any mechanism at all.

In order to get here, three things appear to have to happen to the
spec:
(1) IPsec, at least the cryptographic integrity (I don't believe
	that confidentiality/encryption, is necessary to solve this
	problem) becomes at least "SHOULD use", possibly with an
	exception for environments in which authentication is not
	needed.
(2) Group pre-shared keys become "MUST NOT use" - the potential
	they create for denial of service is just too dangerous.
	Similar words need to be added about certificate usage.
(3) Something at the FCIP level MUST contain an authorization table
	that maps WWNs to whatever IKE is authenticating (probably an
	IP address via either a pre-shared key or a certificate).
Item (2) will become a deployment obstacle in practice due to the
need to manage IPsec authentication material for every node.
Item (3) will become an issue for use of external IPsec gateways,
because the IKE information has to be obtained from that gateway
promptly when the IPsec SA is setup in order to check that the
WWN is being presented from a node that is allowed to present that
WWN.  Failing to do this results in authorization without
authentication which is a no-no.

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