Subject: saag whyenc draft (was RE: Security Gateways)

From: [email-masked]
Date: Thu, 2 Aug 2001 19:10:55 -0400

Bill,

> I don't see the text in
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

I suggest reading all of Section 6, which has a strong bias towards
requiring "the best security available", and keeping that in mind
when reading the "depends heavily on the application" text in
Section 8.  Are you prepared to argue that data requiring
confidentiality will never or almost never be sent via iSCSI or
FCIP?  That is the line of reasoning that this draft leads to.

> With the final statement being that security must be a MUST IMPLEMENT so
> that users have to option of enabling it when the situation calls for.  I
> will talk with Jeff (if I can hunt him down in London) and determine if
> the meaning of this is to require security in all devices, or if it can be
> an optional cost pack... In other words if you want to buy a device it
> would not implement security, but there is an option pack that I will sell
> you at cost to implement the additional security protocols.

Perhaps I can save you some time.  RFC 2119 says:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

The words "absolute requirement" seem clear and straightforward to me.
Therefore if an RFC says "MUST implement <X>" and <X> exists only in
the optional cost pack, the device without the optional cost pack
does not comply with the requirements of the RFC.  It really is that
simple - any device that complies with the RFC MUST implement
all of the "MUST implement" items.

> What I am getting at is cryptography is expensive, especially at multi
> gigabit speeds.  I would not want to require products to incur this cost
> if the feature wasn't determined to be useful by the end customer who has
> the wallet.

IMHO, this argument is unlikely to go very far.  See the last paragraph
of Section 4 and the last four paragraphs of Section 6 in the whyenc draft.

Regarding computational/implementation expense, AES appear to be the best
that's possible for an encryption algorithm, but there are some new
integrity MACs that are much less expensive to implement than HMAC.
I expect more to be said about this during the Security portion of the
IPS meeting in London on Monday evening.

> I also want to be careful about products that are multi
> gigabit products, but to be "standards compliant" include a software
> encryption module that runs at 12 Mbit/Sec and is completely useless.  I
> would rather have that product without security, so that I KNOW that the
> security isn't there...

OTOH, this argument may have some merit, as I would definitely expect
to see things like this sort of brain-damaged software encryption module
if confidentiality becomes a "MUST implement".  Let me be clear that
this applies only to confidentiality -- a small amount of thought about
the consequences of impersonation and a script kiddie's TCP hijack attack
leads to the conclusion that authentication and cryptographic integrity
have to be "MUST implement" for iSCSI, FCIP, and iFCP.

Let us know the results of your discussion.

Thanks,  --David

> -----Original Message-----
> From: Bill Strahm [mailto:[email-masked]]
> Sent: Thursday, August 02, 2001 4:59 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Security Gateways
> 
> 
> I don't see the text in
> http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt
> 
> Infact what I see is
> 8.  Is Encryption a MUST?
> 
>    Not necessarily. However we need to be a bit more precise here.
>    Exactly what security services are appropriate for a given protocol
>    depends heavily on the application it is implementing. Many people
>    assume that encryption means confidentiality. In other words the
>    encryption of the content of protocol messages.
> 
> That being said from the section right above it comes this text
> 
> 7.  MUST is for Implementors
> 
>    We often say that Security is a MUST implement. It is worth noting
>    that there is a significant different between MUST 
> implement and MUST
>    use.
> 
> With the final statement being that security must be a MUST 
> IMPLEMENT so
> that users have to option of enabling it when the situation 
> calls for.  I
> will talk with Jeff (if I can hunt him down in London) and 
> determine if
> the meaning of this is to require security in all devices, or 
> if it can be
> an optional cost pack... In otherwords if you want to buy a device it
> would not implement security, but there is an option pack 
> that I will sell
> you at cost to implement the additional security protocols.
> 
> What I am getting at is cryptography is expensive, especially at multi
> gigabit speeds.  I would not want to require products to 
> incur this cost
> if the feature wasn't determined to be useful by the end 
> customer who has
> the wallet.  I also want to be careful about products that are multi
> gigabit products, but to be "standards compliant" include a software
> encryption module that runs at 12 Mbit/Sec and is completely 
> useless.  I
> would rather have that product without security, so that I 
> KNOW that the
> security isn't there...
> 
> Bill
> 
> 
> On Thu, 2 Aug 2001 [email-masked] wrote:
> 
> > 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
> > [email-masked]       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Robert Snively [mailto:[email-masked]]
> > > Sent: Thursday, August 02, 2001 12:34 PM
> > > To: [email-masked]'; Robert Snively; [email-masked]
> > > 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:    [email-masked]
> > > Brocade Communications Systems     phone:  408 487 8135
> > > 1745 Technology Drive
> > > San Jose, CA 95110
> > > 
> > > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, August 01, 2001 4:42 PM
> > > To: [email-masked]; [email-masked]
> > > 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:[email-masked]]
> > > > Sent: Wednesday, August 01, 2001 6:25 PM
> > > > To: [email-masked]'; Robert Snively; [email-masked]
> > > > 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: [email-masked] [mailto:[email-masked]]
> > > > Sent: Wednesday, August 01, 2001 10:13 AM
> > > > To: [email-masked]; [email-masked]
> > > > 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
> > > > [email-masked]       Mobile: +1 (978) 394-7754
> > > > ---------------------------------------------------
> > > 
> > 
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 3 Aug 2001 22:41:16 -0700 (PDT)

> Are you prepared to argue that data requiring

It's worth keeping in mind that Encrypting File Systems are now widely
supported. So in practice, the data may already be encrypted, and it might
be argued that in such a case, IPsec confidentiality is redundant. 

> if confidentiality becomes a "MUST implement".  

Unfortunately, such a software encryption module would not be
"brain-damaged." Such performance is typical of 3DES implemented in
software on Pentium class processors in the 200 - 300 Mhz range (and
equivalent RISC processors). Software AES implementations will do
almost an order of magnitude better. but that's still a far cry from 1+
Gbps. At those speeds hardware acceleration will be required. 

Ultimately, the credibility of mandating confidentiality depends on the
demonstration that the service can actually be provided at the required
line rates. I expect that we will be able to lay out the evidence by the
Interim Meeting. 

> have to be "MUST implement" for iSCSI, FCIP, and iFCP.

Yup. 

> The paper indicated that PowerPC clock speeds of 600-800 Mhz would be
> required in order for UMAC to handle 1 Gbps line rate...

I agree that it might be challenging to implement a software MAC on an
iSCSI target running at 1+ Gbps line rate. But this is more credible
for an iSCSI initiator running on a new PC with say, 1.7 Ghz clock rate. 
At 1 Gbps, UMAC-4/8 would consume 262.5 Million cycles/second, or
15% of CPU. 

By the interim meeting, we hope to have some presentations on the
performance achievable via hardware acceleration. I'd
note that software MAC algorithms are not necessarily the fastest
algorithms to implement in hardware. So the 2-3 cycles/byte of UMAC
on PowerPC should not be considered the best that can be done, just an
indication of how far we've come from HMAC-SHA1.