RE: Security Gateways

[Black_David@emc.com]

Bob,

An RFC does not tell anyone what can or cannot be built;
it specifies what is required for compliance with the RFC.
If someone builds a protocol implementations that doesn't
comply with the requirements of the RFC, they should not
expect to be able to claim RFC compliance for devices 
based on that implementation.

> The marketplace does demand that
> security be possible and available for a device.  

The compliance requirement here is that "possible and
available" be realizable without having to add anything
to the device.  For the structure of interest here,
an FCIP device plus a security gateway, the complete system
[FCIP device, cable, security gateway] would comply with
the FCIP RFC at its external interface (i.e., the external
interface of the security gateway).  The interface between
the FCIP device and the security gateway would be missing
some required security functionality and hence would
not comply with the RFC.  As a result, the FCIP device by
itself would not comply with the RFC.

> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 

If "optional" means "MUST implement, but MAY use", that
expectation would be incorrect.  "MUST implement" (cf.
RFC 2119) is the level of requirement for authentication
and cryptographic integrity that is necessary for FCIP
to be approved as an RFC.  This isn't just "push back"
from the IESG - it is a condition that the IESG required
for its original approval of the IPS WG charter.

> With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 

That combination will comply with the RFC.  OTOH, the
IESG will not permit the FCIP RFC to allow an FCIP device
that lacks the basic security mechanisms to be compliant,
and hence the FCIP device *without* the edge security
device will not comply.

> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.

"By definition" is not the best wording.  Assuming that the
"security edge device" is an IPsec security gateway, the IKE
and ISAKMP  protocols are to negotiate security functionality
and parameters; those protocols are resistant to man-in-the-
middle attacks, but that resistance is based on careful design.

--David


> -----Original Message-----
> From: Robert Snively [mailto:rsnively@brocade.com]
> Sent: Wednesday, August 01, 2001 6:25 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> I believe this is really a very difficult question, not
> susceptible to a simple SHALL/SHALL NOT response.  
> The technology absolutely allows and encourages
> security edge devices and absolutely allows devices using
> TCP and other protocols to exploit those edge devices or
> not as the system administrator requires.  The marketplace
> absolutely demands those capabilities.  A significant percentage
> of the internet economy is based on separately supplied security.
> I understand that the IETF
> has no interest in devices that are solely for closed
> environments, but the marketplace does not demand that
> a device have security built in to qualify for compliance with a
> protocol.  The marketplace does demand that
> security be possible and available for a device.  
> 
> That is what we have been proposing.
> 
> By definition, "man in the middle" attacks are impossible
> for a security edge device, since the only place that the
> "man in the middle" can be placed is in the encrypted path.
> The physically secured path has no possibility of an
> entry point for such an attack.  
> 
> I can understand why the IESG would push back on this
> question, but I would expect that they also believe that
> an FCIP device without optional security implemented
> is still an FCIP device and is compliant with the FCIP RFC. 
> This should be true whether the TCP path is based on IP,
> HIPPI, IB, a proprietary backplane or any other transport 
> that supports TCP. With an edge security device installed 
> in front of it, it is also a
> secure FCIP device, just like the end-point of a 
> virtual private network is a secure device. 
> 
> That is what we would like the RFC to say.
> 
> Bob
> 
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, August 01, 2001 10:13 AM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> Bob,
> 
> You've made a good case for "optional to use", but not
> "optional to implement".  The basic reason is that there
> is no way to ensure that vendors and/or users will
> restrict the use of an implementation that does not
> include security to situations where "paths of a
> storage environment are physically secured and have 
> no requirement for additional security mechanisms".
> Hence security needs to be present so that it
> can be used when FCIP is deployed in an environment
> that requires security.  Further, the IETF has no
> interest in specification of protocols that are
> *solely* for use in the sort of closed environment
> that you describe, and the IPS WG charter contains
> explicit words to that effect.
> 
> Therefore, the basic FCIP security mechanisms MUST be
> implemented, but usage MAY be negotiated.  At the moment,
> "basic security mechanisms" means authentication and
> cryptographic integrity.  Confidentiality can currently
> be optional to implement, but I think it's a very good
> idea to specify the basic confidentiality mechanism
> (*if* confidentiality of any form is implemented, *then*
> <XXX> MUST be implemented).  The design and specification
> of any negotiation mechanism must resist man-in-the-middle
> attacks on negotiation that would result in turning off
> security where that was not the intended outcome - such
> an approach can include restrictions on implementation
> behavior (e.g., if "no authentication" is not acceptable,
> do not offer or accept it during negotiation).
> 
> If the FCIP draft is sent to the IESG without requiring
> implementation of the basic security mechanisms, it will
> be returned to the WG with instructions to correct
> that shortcoming, along with some choice words from the
> ADs wondering how the WG chairs could have overlooked
> something like this.  As a result, an FCIP draft that
> does not require implementation of the basic security
> mechanisms will not be Last Called in the WG until that
> requirement is added.
> 
> Sorry to be blunt, but there is no flexibility on whether
> the basic security mechanisms are mandatory to implement;
> they will be mandatory to implement, period.
> 
> 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
> ---------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@brocade.com]
> > Sent: Wednesday, August 01, 2001 12:08 PM
> > To: 'Black_David@emc.com'; ips@ece.cmu.edu
> > Subject: RE: Security Gateways
> > 
> > 
> > Dear David,
> > 
> > I would like to address the rather serious question you have
> > raised here about both architectural layering and market
> > requirements.  After considerable thought, based on the
> > explanations below, I have concluded that the FCIP RFC should
> > specify that security is optional to implement and optional to use.
> > 
> > 1)  Concerning architectural layering:
> > 
> > It is clear that the problems of security are well understood
> > within IETF. Numerous solutions have been proposed and
> > many of those have become standard implementations.  The most
> > successful of those (as an example, IPSec) have used the
> > principles of architectural layering very well.  IPSec
> > provides a secure mechanism for transporting any IP-based
> > protocol if the protocol requires such security.  However,
> > the overlaying protocols (as an example, TCP) have no requirement
> > to actually make use of IPSec, and in fact have no particular
> > requirement to make use of IP.  This is as it should be.
> > Each layer is implemented independently of the other.  The
> > services that each layer implements depend on the market
> > requirements for the environment.  By that logic, it is 
> > unnecessary for FCIP to specify any security mechanism at all, 
> > since so many security mechanisms are available.  However,
> > FCIP has provided the additional guidance that, if security
> > in a TCP environment is used, it shall be provided at a layer
> > below the TCP interface.  In particular, it recommends the
> > use of IPSec for TCP/IP environments (and will recommend the
> > appropriate IPSec options).  This additional guidance has nothing
> > to do with the architecture or definition of FCIP and is 
> > merely a recommendation that should improve interoperability.
> > 
> > 2)  Concerning market requirements:
> > 
> > A very high percentage of storage environments today manage
> > their configurations very carefully.  Such careful management is
> > necessary to guarantee redundant paths for proper availability,
> > to provide sufficient paths to provide the required 
> > performance, and to
> > guarantee known paths to improve reparability and consistency
> > of behavior.  As a side effect, a very high percentage of
> > the paths of a storage environment are physically secured and have
> > no requirement for additional security mechanisms.  At present,
> > the only paths that are using security are those very few paths
> > that leave one physically secure environment to transport data to
> > another physically secure environment.  Those few paths 
> > almost universally
> > use security mechanisms at a lower level (as an example, a virtual
> > private network) to achieve their goals.  As a first guess, such
> > paths are well under 1% of the storage paths being used today.
> > 
> > I do not believe that this paradigm will change significantly over
> > the next several years, although of course the percentage of paths
> > requiring transport security may rise over 1%.  The requirements for
> > storage performance and the desire to maintain the storage devices
> > and many of their primary processors in a physically secure
> > environment will assure similar configurations.
> > 
> > In this environment, the market will demand low cost and high
> > performance for the great majority of interconnects and will demand
> > security for a relatively low percentage of interconnects.  
> > 
> > What this implies for technologies like FCIP is that security
> > be available as a separate option, outside the primary FCIP
> > definition.  While still allowing the integration of security
> > inside an FCIP unit, the IETF draft for FCIP  must also 
> allow security
> > to be provided either not at all or by an outside mechanism.  
> > The most common outside mechanism would be a gateway box of 
> some sort.
> > In many cases, the gateway box will be a secure router placed on the
> > external link and servicing a large number of locally attached
> > unsecured FCIP boxes.
> > 
> > CONCLUSIONS:
> > 
> > The FCIP draft should continue to specify a security mechanism,
> > with IPSec being the appropriate candidate, to guarantee 
> > interoperability
> > when security is provided.  The FCIP draft should be modified to
> > indicate that security is optional to implement and optional to use.
> > In addition, it should explicitly indicate that external gateway
> > boxes are allowed implementation mechanisms for security.
> > 
> > As a side question, note that management of storage area networks
> > and FCIP boxes is a separate question and is outside the scope of
> > the FCIP draft.  Both Fibre Channel and Ethernet management paths
> > have security appropriate to the particular management mechanism.
> > As an example, web-based management mechanisms use web-based
> > security tools. 
> > 
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> > 
> > 
> > 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Tuesday, July 24, 2001 7:11 PM
> > To: ips@ece.cmu.edu
> > Subject: Security Gateways
> > 
> > 
> > The following issue was hidden in my long set of
> > comments on the -03 version of FCIP:
> > 
> > > > Delete 12 b).  If an FCIP entity is operating with an external
> > > > security gateway, only the interface on the public side of the
> > > > gateway is compliant with this specification.  The interface
> > > > between the FCIP entity and the gateway is not compliant because
> > > > it is lacking required security features - the FCIP entity
> > > > *includes* the security gateway in this structure.
> > > 
> > > Please post this as a separate issue because several of the
> > > FCIP Authors believe it is appropriate for FCIP and I cannot
> > > represent their opinions.
> > 
> > The issue is not whether it's "appropriate".  The issue
> > is that if an implementation uses an FCIP Entity plus
> > an external security gateway, the only interface that
> > conforms to the forthcoming RFC is the public/external
> > interface on the security gateway.  The interface between
> > the FCIP Entity and the security gateway is private
> > and fails to conform to the security that will be
> > required of all FCIP implementations.
> > 
> > The above paragraph also applies to iSCSI (substitute iSCSI
> > for FCIP in all instances).  Let me also note that iSCSI's
> > ability to use a security gateway is not final at this
> > juncture.  The spectrum of security possibilities includes
> > things like SRP keying of ESP and IPsec transport mode that
> > would make external gateways difficult or impossible to use.
> > 
> > Those who care about being able to use security gateways
> > (or think that there's no need to support their use)
> > should speak up on the list, in London, and/or in Orange
> > County (I would expect the decision not to be made prior
> > to Orange County) and *EXPLAIN WHY* [technical rationale].
> > 
> > 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
> > ---------------------------------------------------
> >  
> > 
>