RE: Security Gateways

[Black_David@emc.com]

Bob,

We have a failure to communicate here.  I understand what you
want to build and why you want to build it.  The only interface
in your ASCII diagram that will be compliant with the FCIP RFC
is the Public Environment interface of the "Secure Router".  If
you want to build and sell FC/FCIP devices without security,
that's your choice, but they will not comply with the FCIP RFC.
I don't know how many times I need to say this - there appears
to be some part of the word "NO" that you're failing to grasp :-).
The IESG will not approve an RFC that allows a security-free
FCIP device to claim compliance.

Regarding the IPS charter wording on security - I've been in
contact with one of the Transport ADs in the past few hours,
and if the current charter wording isn't sufficiently explicit,
it will be made much more explicit in the revision to the IPS
charter that has to be prepared for the IESG in the near future.
Not only has this been in the charter, but the fact that
authentication and cryptographic integrity will have to be
"MUST implement" has been known since the discussion of this
topic at the IPS meeting in Pittsburgh almost a year ago.

The IPS framework draft was not written by the IESG - a relevant
draft that was written by an IESG member (one of the Security ADs),
is draft-ietf-saag-whyenc-00.txt, which advocates even more
stringent requirements than those currently imposed on FCIP -
confidentiality would become "MUST implement" in the absence
of a very good technical (not market, not cost) explanation
of why it should not be.

Time to get out the "clue by four" ... lengthy expositions of
why (in someone's opinion) the IESG is wrong (about this or any
other issue) are really not an appropriate use for the IPS mailing
list.  This sort of issue should be pursued directly with the
Area Directors and/or the IESG - among the opportunities for
doing so will be the IESG Open Plenary on Wednesday evening in
London.  Keep in mind that the IESG is the final approval
authority for all RFCs, including the ones we write here in IPS.

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: Thursday, August 02, 2001 12:34 PM
> To: 'Black_David@emc.com'; Robert Snively; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> David,
> 
> As introduction to this phase of our discussion, let me draw
> a picture in (gag) ASCII.
> 
>   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
>      Securely Administered Secure Environment     Public Environment
>   |                                             |                    |
>      FC  +--------------+   TCP/IP w/o
>   |  <-->| FC/FCIP dvc A|<----+ IPSec           |                    |
>          +--------------+     |
>   |                           |      +--------+ |                    |
>      FC  +--------------+     +----->| Secure |     TCP/IP w/ IPSec
>   |  <-->| FC/FCIP dvc B|<---------->| Router |<------------>        |
>          +--------------+     +----->|        |
>   |                           |      +--------+ |                    |
>      FC  +--------------+     |
>   |  <-->| FC/FCIP dvc C|<----+                 |                    |
>          +--------------+
>   |                                             |                    |
> 
>   +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  +  -  -  -  -  -  -  +
> 
> I believe that the interface provided by FC/FCIP dvc A, B, and C
> should be called RFC "FCIP" compliant just as completely as
> the public interface from the secure router is called RFC "FCIP"
> compliant.  In this environment, the FCIP devices will be routinely
> carrying on traffic among themselves without using IPSec, and will
> be carrying on traffic with the public environment using
> securely protected connections.  The secure protection may be
> IPSec as recommended by the RFC "FCIP", but it may also be some
> other sort of secure connection.  If there is a performance and
> a monetary cost associated with IPSec (which my associates assure
> me will be significant for some time in the future), that cost
> is paid one time in this picture.  If IPSec was mandatory
> to implement for RFC "FCIP" compliance, the financial cost would
> be paid three (or maybe four) times in the picture and the
> performance cost would be avoided by invoking the optional disabling
> of the security feature within the securely administered 
> secure environment.
> 
> This example will be a common structure in FCIP environments.
> 
> The example provides lots of options for various kinds of tradeoffs.
> As time goes on, the full integration of security functions in
> FCIP chips may increase the percentage of RFC "FCIP" complaint
> devices that actually contain the optional to implement IPSec
> functions in the FC/FCIP device itself.  At any time, individual
> secure interface boxes (IPSec or other) can be attached loosely or 
> tightly to those FC/FCIP devices that invoke the option to not install
> security internally.  Even the definition of tightly and loosely
> connected is an artificial distinction related to how long the 
> bolts are and whether adjacent racks constitute tightly coupled
> functions.
> 
> To meet these requirements, the only solution I can see is to
> define the RFC "FCIP" such that security is optional to implement
> and optional to use.  While defining the recommended security to
> be IPSec, devices that use no security and devices that use
> alternative security would also be RFC "FCIP" compliant.  They
> of course would list in their manufacturing specifications other 
> RFCs that would be supported, typically including TCP, IP, and 
> the appropriate IPSec RFCs.
> 
> To address the second part of your comments below:
> 
> >>  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.
> 
> The closest wording I can find to that in the charter is:
> 
> "  The WG will address at least the following: 
> 
>     - Security measures, including authentication and privacy, 
>       sufficient to defend against threats up to and including 
>       those that can be expected on a public network.
> 
>    The WG will address security and congestion control as 
>    an integral part of bits protocol encapsulation(s); "
> 
> I can find no hint that those security measures are mandatory
> to implement for compliance with the RFC "FCIP".  They are
> certainly mandatory to specify in the RFC, and we will have done
> so with big flashy warnings (or at least as flashy as ASCII
> allows) that qualify the security limitations for those operating
> in RFC "FCIP" compliant devices that elect not to install
> the optional security mechanisms internally.  I believe that
> our proposal would meet both the letter and spirit of the charter.
> 
> The wording in draft-ietf-ips-framework-00.txt, clause 9, 
> similarly recognizes the requirement we see with wording like:
> 
> "  A partial solution may be obtained by providing enhanced security 
>    services at the interfaces from the existing storage 
> network to the 
>    IP storage network. There, services such as encryption and 
>    authentication may be applied to the non-physically secure portion 
>    of the path, without requiring end-station changes.  
>          
>    Overall security for such a solution may be no better than 
> that of a 
>    SAN presumed to be physically secure, but at least it will not be 
>    perceived as worse. 
>     
>    Link-level security need not be the only solution. In many 
>    applications, privacy of data transmission across the 
> network may be 
>    less significant an issue than controlling who accesses 
> the storage 
>    resources. In such situations, access-control solutions 
> such as the 
>    resource login provided by iSCSI can add value."
> 
> Note that the FC entities making use of the FCIP entities have
> a secure authentication mechanism being proposed as part of the
> FC activities.
> 
> I hope that we have interpreted the wording and intent correctly,
> because if not we should probably modify the charter to allow
> the FCIP proposal.
> 
> 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: Wednesday, August 01, 2001 4:42 PM
> To: rsnively@brocade.com; ips@ece.cmu.edu
> Subject: RE: Security Gateways
> 
> 
> 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
> > ---------------------------------------------------
>