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

[Venkat Rangan <vrangan@rhapsodynetworks.com>]

David,

> 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. 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 reveived short frames arrive
are also secured from a spoof.

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.

> In addition, that assumption makes IKE and ESP cryptographic
> integrity at least "SHOULD use" for FCIP, and I can't promise that
> the Security ADs will settle for "SHOULD use" as opposed to "MUST
> use".  The reason for this change from the "MAY use" that applied
> prior to the introduction of the WWN short frame is that the
> authentication/authorization performed by that short frame is a
> class of function that is far more important, expected, and widely
> used than cryptographic integrity - the assumption uses cryptographic
> integrity to secure a mandatory authentication mechanism and hence
> increases the requirement for cryptographic integrity.

If a receiver does not trust the sender of an FCIP Short Frame, it
can choose to use IKE and ESP cryptographic integrity. If it believes
that another IPSec gateway has established secure connections to the
peer, it processes the FCIP Short Frame, much the same way as any other
FCIP encapsulated frame. 

> And as things currently stand, the "administrative establishment" of
> that association will need to be done not only at the sender of the
> short frame, but also at the recipient.  When IKE is in use, both
> establishment of the association and the check at the receiver (IKE
> identity for IPsec SA and WWN in short frame that arrived on that SA
> are associated) will need to be "MUST"s.

At the recipient, one could state that a validation of the IKE address
identifier (the IP address of the source FCIP entity) SHOULD be performed
against the set of IP addresses that are allowed to send the WWN specified
in the short frame. If this makes it impractical to use group pre-shared
keys, that deployment can always use non-group pre-shared keys or use
public key certs.

Regards,

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com


-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, November 13, 2001 9:55 AM
To: vrangan@rhapsodynetworks.com; ips@ece.cmu.edu
Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
Interim meeting)


Venkat,

Let me try to summarize and explain without quoting your entire message:

-- Pre-shared keys

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.

-- WWN short frame and administration

> "The usage of SLPv2 by FCIP is described in [64]. FCIP Entities assume
> that once the IKE identity of a peer is established, the FCIP Entity
> Name carried in FCIP Short Frame is also implicity accepted as the
> authenticated peer.  Any such association between the IKE identity and
> the FCIP Entitiy Name is administratively established."

> Do you see any further clarification required in this area? 
> Also, is there
> any conflict with the FCIP Short Frame proposal (the NAPTs) solution?

Work is definitely required here, because that short frame is
serving an authentication/authorization purpose and hence the means
need to be provided to adequately secure it.  The assumption in the
second sentence above isn't sufficient because it opens up nasty
attacks including the denial of service ones I described earlier.
In addition, that assumption makes IKE and ESP cryptographic
integrity at least "SHOULD use" for FCIP, and I can't promise that
the Security ADs will settle for "SHOULD use" as opposed to "MUST
use".  The reason for this change from the "MAY use" that applied
prior to the introduction of the WWN short frame is that the
authentication/authorization performed by that short frame is a
class of function that is far more important, expected, and widely
used than cryptographic integrity - the assumption uses cryptographic
integrity to secure a mandatory authentication mechanism and hence
increases the requirement for cryptographic integrity.

And as things currently stand, the "administrative establishment" of
that association will need to be done not only at the sender of the
short frame, but also at the recipient.  When IKE is in use, both
establishment of the association and the check at the receiver (IKE
identity for IPsec SA and WWN in short frame that arrived on that SA
are associated) will need to be "MUST"s.  Group pre-shared keys make
these sort of checks difficult to specify and use properly - the fastest
way to resolve this is to make group pre-shared keys "MUST NOT use"
for FCIP.

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