Fwd: BOUNCE ips@ece.cmu.edu: Non-member submission from [Robert Snively <rsnively@brocade.com>]

[Jim McKinney <jmck+@ece.cmu.edu>]

Date: Thu, 2 Aug 2001 12:34:46 -0400 (EDT)
From: owner-ips@ece.cmu.edu
Message-Id: <200108021634.f72GYkB11778@ece.cmu.edu>
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
To: owner-ips@ece.cmu.edu
Subject: BOUNCE ips@ece.cmu.edu:    Non-member submission from [Robert Snively <rsnively@brocade.com>]   

From owner-ips@ece.cmu.edu Thu Aug  2 12:34:44 2001
Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f72GYhe11772
	for <ips@ece.cmu.edu>; Thu, 2 Aug 2001 12:34:44 -0400 (EDT)
Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35])
	by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02520;
	Thu, 2 Aug 2001 09:34:31 -0700 (PDT)
Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19)
	id <Q12Z7G3Z>; Thu, 2 Aug 2001 09:34:31 -0700
Message-ID: <FFD40DB4943CD411876500508BAD027902993717@sj5-ex2.brocade.com>
From: Robert Snively <rsnively@brocade.com>
To: "'Black_David@emc.com'" <Black_David@emc.com>,
   Robert Snively
	 <rsnively@brocade.com>, ips@ece.cmu.edu
Subject: RE: Security Gateways
Date: Thu, 2 Aug 2001 09:34:28 -0700 
X-Mailer: Internet Mail Service (5.5.2653.19)

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