Subject: RE: Security Use Requirements

From: [email-masked]
Date: Wed, 7 Feb 2001 17:39:06 -0500

I'm not Scott, but some of Doug's comments deserve a rather
blunt response:

> If there is 'required to implement' security that is later found
compromised
> by a man in the middle or through a spoofing mechanism, would such a
mandate
> in the end ensure an open door for those familiar with this 'required to
> provide' security weakness?  Could you recommend a security scheme that is
> safe from this type of attack?

There's no such thing as a perfect security mechanism that is secure from
all attacks for all time.  The reason for using off-the-shelf mechanisms
like
IPSec and TLS is that peer review in the security community has eliminated
not only all of the obvious problems, but also all of the non-obvious ones
that
have turned up.  Asking for a mechanism that is guaranteed to be immune
from all possible attacks is a veiled argument for no security, and is hence
nonsense.

Assuming that keys that are supposed to remain secret do remain secret,
TLS and IPSec are safe from all of the obvious man-in-the-middle attacks
*when properly configured* and are likewise safe from the obvious
spoofing attacks provided that the key distribution mechanism used
works correctly (which can be a tall assumption).  In some cases,
other components also need to be secured, for example, if DNS
names are used as identities, DNS may have to be secured via
something like DNSSEC depending on how DNS is used.

Both IPsec and TLS are frameworks into which various encryption and hash
algorithms can be inserted, so evolution away from algorithms in which
weaknesses are discovered is possible over time (and furthermore is left
in the hands of the security experts who are in the best position to make
these judgements).

> Could security mandates be limited to user authentication and
authorization?
> Compression-Encryptions passes are computationally expensive processes
that
> offer little benefit in many configurations.  If there is a mandated
> security, cryptographic resources should be limited to authentication.

Unfortunately, the answer is "no" if the desire is to avoid computationally
expensive operations on each message exchanged after connection
setup.  The problem is that in order to do authentication sufficient
for a public network, cryptographic integrity is required on the connection
to
avoid well known hijack attacks on TCP (after authentication, the adversary
hijacks the connection by taking over one end of it - attack scripts are
readily
available for this).  The algorithms for cryptographic integrity (e.g., used
to
compute HMACs) tend to be computationally expensive (as much as
encryption, if not moreso), and my current understanding is that unlike
the transition from 3DES to AES/Rijndael that reduces the computational
overhead of encryption, no such overhead reduction is in sight for the
hash algorithms used for integrity (e.g., SHA-1).

--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: "Douglas Otis" <[email-masked]>
Date: Wed, 7 Feb 2001 17:18:04 -0800

David,

> like IPSec and TLS is that peer review in the security community has
> eliminated not only all of the obvious problems, but also all of the
> non-obvious ones that have turned up.  Asking for a mechanism that is
> guaranteed to be immune from all possible attacks is a veiled argument
> for no security, and is hence nonsense.
>

My comment was not a veiled argument for no security but rather an open
question.  I would wish to argue for only mandating authentication and
integrity and make privacy an option.  If to follow NFS and use of GSS-API
(http://www.ietf.org/rfc/rfc1961.txt) as mentioned by David Robinson, with
recommend (Kerberos V5) (http://web.mit.edu/kerberos/www/) and Internet size
security (Lipkey) (http://www.ietf.org/rfc/rfc2847.txt for authentication
and integrity where perhaps just the dynamic portion of the PDU headers are
encrypted as a type of checksum.  Privacy seems like an expensive
proposition to make mandatory for the entire data payload.

System as well as security management is an expensive subject.  The use of
the SCSI device to indicate authorization implies an undefined interface to
this device.  Should this WG also consider a specification for informing the
SCSI device the system or user authorization.  Should such information be
considered an aspect of security related to IPS?

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 7 Feb 2001 17:55:05 -0800

Opps, Correction:  GSS-API (http://www.ietf.org/rfc/rfc2078.txt) It has been
updated...

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 7 Feb 2001 18:53:32 -0800

Michael,

Mandating additional resources to implement privacy would not allow this to
be a customer made trade-off.  Allowing it as product feature option would.

Doug

> Why not allow the customer to make the tradeoff between security and
> performance?
>
> 	-mre
>

---

From: Michael Eisler <[email-masked]>
Date: Wed, 7 Feb 2001 18:20:07 -0800 (PST)

-mre

---

From: Michael Eisler <[email-masked]>
Date: Wed, 7 Feb 2001 19:21:16 -0800 (PST)

> be a customer made trade-off.  Allowing it as product feature option would.

Implementors who implement mandatory privacy can choose to allow customers to
toggle privacy on or off. This approach allows customers to make the tradeoff.

If privacy is not mandatory to implement, then customers will inevitably 
encounter the situation where a client-side ips product has privacy and the
server does not, and vice versa. This removes from the customer the ability to
make the trade-off.

	-mre

---

From: Michael Eisler <[email-masked]>
Date: Wed, 7 Feb 2001 20:20:03 -0800 (PST)

> If the trade-off is the expense of required physical resources to implement
> privacy, then mandating presents of these resources does not allow the

What physical resources, a few kilobytes of code?

> customer a choice of whether they wish the expense.  Should the

Not mandating the presence of those resources results in interoperability
problems, and impacts customer choice more severely. As Mr. Robinson pointed
out, the lack of mandatory to implement security services in NFSv[23] resulted
in only a handful of implementations supporting such services. So the customer
has no choice about whether to use stronger security flavors that a minority
of NFS implementations support, unless he wants to limit his vendor list to a
handful. Hence my rhetorical question: "Why not allow the customer to make the
tradeoff between security and performance?"

The question for the WG should be whether privacy is critical or not. If is
critical, then privacy must be mandatory to implement. If it is not then the
specification had better make convincing arguments why it isn't critical,
otherwise we can expect IESG or the Area Advisor to reject the specification.
Been there, done that.

I find it hard to believe that privacy in ips is not critical. Much of the
data being rendered is rather valuable.

	-mre

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 7 Feb 2001 20:00:43 -0800

Michael,

If the trade-off is the expense of required physical resources to implement
privacy, then mandating presents of these resources does not allow the
customer a choice of whether they wish the expense.  Should the
specification indicate an optional means of enabling data privacy, then
should the customer select data privacy and has bore the expense of this
feature in their initial selection, the specification would allow privacy.
Keeping privacy an option affords the greatest product range.

Doug