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

[Robert Snively <rsnively@Brocade.COM>]

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: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, November 09, 2001 5:52 PM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> Interim meeting)
> 
> 
> > 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. 
> 
> 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.
> 
> > 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. 
> 
> 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.
> 
> > 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.
> 
> I'm not sure what you're referring to, but I suspect they
> don't help much here.
> 
> > Assuming security mechanisms are properly implemented, where, 
> > then, is the security hole?
> 
> 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:rsnively@brocade.com]
> > Sent: Friday, November 09, 2001 8:06 PM
> > To: 'Black_David@emc.com'; ENDL_TX@computer.org; ips@ece.cmu.edu
> > Cc: Robert Snively
> > Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> > Interim meeting)
> > 
> > 
> > 
> > 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:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> >  
> > 
> > > > 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
> > 
>