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

From: [email-masked]
Date: Fri, 9 Nov 2001 17:48:22 -0500

> Those who were at the Irvine Interim meeting will remember that
> the problem with FCIP and NAPTS is a reliance on IP address in
> the determination of which incoming TCP connections belong in a
> given FCIP Link. This proposal solves that problem by requiring
> that FC Entity World Wide Name be transmitted in the first bytes
> sent by the FCIP Entity that initiates a TCP Connect request.
> This allows the FCIP Entity that receives a TCP Connect request
> to match it with any previously received TCP Connect requests
> from the same source. Since the transmitted World Wide Name is
> required to be unique within Fibre Channel, the FCIP Entity
> that receives this information can correctly assign FCIP Link
> relationships without relying on IP Addresses.

From a functional standpoint, this works, but it opens up a security
issue.  The problem is that on the second TCP connection (and subsequent
connections) that claim to be from the same FCIP Entity, the WWN that
is initially sent (and whatever extension is used) is functioning
as an authentication to allow that connection to join the first
TCP connection, but that authentication is unsecured -- the sender
announces the WWN, and the receiver does not (and has no way to)
check it.

There's a fairly obvious denial of service attack here involving
the attacker joining a new connection to an existing one
and then bit-bucketing all the frames sent over the new connection.

Limiting FCIP to one TCP connection among any pair of FCIP entity
identifiers would help, but is not sufficient.  The attack of concern
in this situation involves the attacker crashing the real entity
and opening up a connection in its name, thereby locking out the
real entity when the real entity restarts.

This may be headed in the direction of needing in-band authentication
which I know the FCIP community has been doing their best to avoid.

Sorry to be the bearer of bad news,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Robert Snively <[email-masked]>
Date: Fri, 9 Nov 2001 17:06:22 -0800

David,

For those cases where a secure environment is required, the
new connection comes up through the normal IPSec authentication
and encryption processes.  As a result, the transmission of
the identifying world wide names is already transmitted in an
encrypted format, creatable only by the authenticated and
certified source and interpretable only by the authenticated
and certified destination.  

If the Fibre Channel fabric is also operating in a secure mode,
subsequent Fibre Channel authentication and certification 
is performed using the standard FC SLAP mechanisms. 

In addition to this, there are a whole bunch of policy 
restrictions that are verified as part of the creation
of subsequent connections.  While these are not necessarily
part of the security steps, they prevent the formation of 
connections which do not meet the security rules.

Assuming security mechanisms are properly implemented, where, 
then, is the security hole?

Bob Snively                        e-mail:    [email-masked]
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

---

From: Robert Snively <[email-masked]>
Date: Sat, 10 Nov 2001 08:15:46 -0800

David,

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

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

  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.

  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.

  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.

  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.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 09, 2001 5:52 PM
> To: [email-masked]; [email-masked]
> Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> Interim meeting)
> 
> 
> The assumption that there's a big on/off switch for
> security is not correct (e.g., suppose IPsec is running
> with integrity on and confidentiality off) and
> "authenticated and certified" is a peculiar concept for
> group pre-shared keys, a very likely deployment scenario.
> Also, IPsec has no clue about the WWN, and hence the IKE
> authentication is not linked to the WWN that has to be
> presented (a particular problem with group pre-shared keys,
> but also a risk even with certificates).  In other words,
> "authenticated and certified" doesn't place any restrictions
> on what WWN is presented.  Finally, solving
> an inband authentication problem by requiring that IPsec be
> used to encrypt the WWN is wildly excessive, and besides,
> the WWN has no secret contents- it's a public piece of
> configuration information.
> 
> There is a solution in this general area, but it involves
> linking the WWN to the IKE identity that is authenticated.
> That's probably going to break any attempt to use existing
> off-the-shelf external IPsec gateways because gateways
> don't grok WWNs, and the FCIP implementations won't
> know what identity was used in the IKE authentication
> to the gateway.  This is all a bit peculiar because FC
> currently trust WWNs passed in various FC Login frames
> without authenticating them, but that's T11's area of
> responsibility putting this sort of thing into an IETF
> standard isn't going to be acceptable.
> 
> Only on the first TCP connection, unless you plan to require
> taking the FCIP link down when the second TCP connection
> is added (which strikes me as highly counterproductive).
> The second connection just inherits the results of the SLAP
> performed on the first one, whether its entitled to or not.
> 
> I'm not sure what you're referring to, but I suspect they
> don't help much here.
> 
> The fact that the WWN is not authenticated means that anyone
> who can set up an FCIP connection to an FCIP entity can tap
> into any existing FC traffic flowing on any connection through
> that FCIP entity.
> 
> --David
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:[email-masked]]
> > Sent: Friday, November 09, 2001 8:06 PM
> > To: [email-masked]'; [email-masked]; [email-masked]
> > Cc: Robert Snively
> > Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> > Interim meeting)
> > 
> > 
> > 
> > David,
> >

---

From: [email-masked]
Date: Mon, 12 Nov 2001 12:22:31 -0500

Bob,

> meetings on this subject.)

The next opportunity is Salt Lake City.

>   device through your bullet proof glass doors and examining its

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

>   devices some part of the necessary information for any security

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

> 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

---

From: [email-masked]
Date: Mon, 12 Nov 2001 13:22:56 -0500

Ralph,

See my response to Bob's mail.  The situation is 1) with a few
additions - the particular way in which FCIP has designed this
identity mechanism makes group pre-shared keys a bad idea, and
saying they SHOULD NOT or MUST NOT be used is part of the solution.

I would prefer that FCIP use an FC level identifier rather than
an IP address for identifying FC entities, but in the current
design, that identifier is being used as an unsecured means of
authentication, and hence some way of securing that
authentication needs to be found.  The reply to Bob outlines
how to go about getting IKE and IPsec to solve this problem; the
alternative of having FC try to solve this problem doesn't seem
tractable to me because the problem occurs with the TCP connections
after the first one, and FC is not going to want to rerun SLAP
just because a second TCP connection has been set up (and in fact
may not be able to).

Thanks,
--David

> From: Ralph Weber [mailto:[email-masked]]
> Sent: Monday, November 12, 2001 7:54 AM
> To: IPS Reflector
> Cc: [email-masked]
> Subject: Re: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> Interim meeting)
> 
> 
> David,
> 
> You appear to be saying one of two things:
> 
> 1) The NAPTs solution, as proposed, requires that FCIP eschew the
>    use of group pre-shared keys, or
> 2) The problems with the best on offer FCIP NAPTs solution design
>    are sufficient to convince the IESG that FCIP is justified in
>    prohibiting the use of NAPTs.
> 
> Although time may have altered opinions, I will note that option
> 2) conforms to the position of several people on the FCIP development
> team during the Irvine meeting. Certainly, option 2) greatly
> simplifies the changes required in FCIP.
> 
> It is clear that you will object to ANY form of identification
> that an FCIP Entity offers for one of the following reasons:
> 
>   a) Offering IP addresses is unacceptable because of NAPTs, and
>   b) Offering any other value is unacceptable because it is not
>      secure with group pre-shared keys.
> 
> Unless option 1) above is your real concern, it appears that the
> FCIP development team has spent two months on a near fruitless
> exercise, whose only benefit is a strong proof that FCIP should
> not support NAPTs.
> 
> Ralph...
> 
> [email-masked] wrote:
>

---

From: Venkat Rangan <[email-masked]>
Date: Mon, 12 Nov 2001 15:51:54 -0800

David,

Section 5.8.2 of the draft-ietf-ips-security-04.txt covers the use
pre-shared keys. In that section, we state that:

"This vulnerability is typically not of concern with iFCP and FCIP,
since iFCP and FCIP devices typically use statically defined addresses,
so that individual pre-shared keys are possible within IKE main mode."

If statically defined addresses is not workable due to the presence
of NAPTs, we state that:

"As a result, where iSCSI, iFCP, or FCIP Entities utilize dynamic address
assignment along with pre-shared key authentication, IKE Agressive Mode
MUST be used."

These two statements taken together would appear to provide the
necessary tools to implement a secure FCIP deployment with both static
and dynamic address assignment.

On your statement about the implicit assumption about the identity of
an FCIP Entity based on its IP Address, Section 2.4 states the following:

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

We also state in Section 2.3:

"When pre-shared keys are used for authentication, IKE Aggressive Mode
SHOULD
be used, and IKE Main Mode SHOULD NOT be used."

Thus, if IPSec IKE Phase 1 negotiation has succeeded between a pair of
IP Addresses, the FCIP Entity referred to in the FCIP Short Frame which
carries the remote FCIP Switch WWN and FCIP Identifier is also validated
as a trusted FCIP Entity. This allows for an external gateway to deal
with the IKE Phase 1, and the receving FCIP Entity is assured that the
FCIP Short Frame is really from a trusted peer (in that configuration).

There is a question of how one would set up an IKE Phase 1 validation of
IP Address-based idenity in the presence of NAPTs, but that is a general
problem fo which IPSec WG needs to provide the right set of tools (which is
on its way.) I believe the draft-aboba-nat-ipsec-04.txt is just one proposal
being considered. There may be others as well.

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

Regards,

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 12, 2001 10:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
Interim meeting)

Ralph,

Thanks,
--David

---

From: [email-masked]
Date: Tue, 13 Nov 2001 12:55:06 -0500

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

> 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

---

From: Venkat Rangan <[email-masked]>
Date: Mon, 19 Nov 2001 13:53:31 -0800

David,

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

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

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 9:55 AM
To: [email-masked]; [email-masked]
Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
Interim meeting)

Venkat,

-- Pre-shared keys

Thanks,
--David