RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt

["Bill Strahm" <bill@sanera.net>]

Just to step in...

I am concerned that we are going to standardize on some new toys that have
1) Unknown properties, possibly not to my liking
2) Unknown licensing requirements - Definitely not to my liking

I have to ask this question
What is wrong with requiring as a minimum, the required IPsec transforms,
and not go beyond that for a MUST implement.  Many people are going to argue
that DES is not good enough, well I hate to say it, but DES is better than
clear text - which almost by definition IS good enough.  I am also concerned
with the time needed to get these transforms into implementations that are
purchasable to be integrated with solutions.

When AES and its various modes are vetted over the next few years, I expect
IPsec to start requiring these things... Then we get it for free (i.e. IPsec
requires them, we require IPsec), if we do it now as the only REQUIRED
implementation and the mode we choose is found to be fundamentally weak -
our whole security story collapses on itself

Bill
Sanera Systems Inc.

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Joseph Tardo
Sent: Monday, August 27, 2001 9:36 AM
To: Mark Winstead; Black_David@emc.com; sandeepj@research.bell-labs.com;
ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Some additional issues raised at that workshop:

1. Typical security protocols, in particular the IPsec transforms, require
authentication to extend beyond the ciphertext to some additional cleartext
(e.g., the SPI and replay counter for ESP). Such use needs to be carefully
designed, and there are no current standardized proposals with proven
security.

2. To support ESP NULL, any such mode needs to be defined so as to support
authentication without confidentiality.

--Joe

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mark Winstead
Sent: Monday, August 27, 2001 6:06 AM
To: 'Black_David@emc.com'; sandeepj@research.bell-labs.com;
ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Last Friday, NIST held a modes of operation workshop (for the protection and
privacy of sensitive but unclassified data, NIST authorizes suitable
algorithms and techniques for use by federal government departments and
agencies).

OCB is one of three modes considered that achieve both privacy and
authentication, as well as the potential to scale well for speed. All three
either have patents or have been submitted for patents. IMHO w/o coding
them, only two of the three, OCB and Integrity Aware Parallelizable Mode
(IAPM) will scale well to support 10 Gbs and more. IAPM's patent is held by
IBM, OCB by Phil Rogaway.

The patent issue came up during the discussion time -- no one present knew
of a provably secure mode with the properties of OCB that was unpatented.
One could find an unpatented mode for privacy, say counter mode, and then
add a MAC that provides authentication, but that is an extra step (plus I
think you might run into the patent problem again in finding a MAC that will
permit 10 Gbs speed).

Mark Winstead

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Tuesday, August 21, 2001 8:17 PM
To: sandeepj@research.bell-labs.com; ips@ece.cmu.edu
Subject: RE: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt


Sandeep,

There is a patent on it, and a license is required to ship product.
The license should be available under fair, reasonable, and non-
discriminatory terms, but will not be free.  A reasonable guess
would be that iSCSI licensing terms would be similar to the 802.11
terms, and that a suitable IETF intellectual property rights notice
will be forthcoming.

OTOH, this does seem to run counter to the usual IETF preference
for unpatented technology over patented technology provided that
the unpatented technology is a functionally suitable replacement
for the patented technology.  Whether there are functionally suitable
unpatented replacements for OCB is an issue for further discussion,
ditto the requirements and preferences that lead to the recommendation
of OCB.  A draft on OCB would need to go through the ipsec WG if we
were to use OCB, and my impression is that at least some portion of
that community has a very strong preference for unpatented technology.

I hope this is what you were looking for in the way of comments.

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: sandeepj@research.bell-labs.com
> [mailto:sandeepj@research.bell-labs.com]
> Sent: Tuesday, August 21, 2001 7:49 PM
> To: ips@ece.cmu.edu
> Subject: Re: FW: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
>
>
> David,
>
> Could you comment on the intellectual rights issues
> here, particularly on AES-OCB, which will be mandatory
> according to this draft (Sec 2.1)
>
> http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm
> mentions the licensing terms for 802.11 products.
>
> Secondly, appendix tables A.5 and A.6 seem to indicate
> that AES-CTR+UMAC performance is better than AES-OCB.
> Has AES-OCB been chosen since it requires lesser keying
> material and memory ?
>
> thanks
> -Sandeep
>
> > FYI - this is about use of IKE and IPsec algorithm selection
> > considerations.  --David
> >
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, August 21, 2001 7:25 AM
> > Subject: I-D ACTION:draft-aboba-ips-iscsi-security-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title           : Securing iSCSI using IPsec
> > Author(s)       : B. Aboba et al.
> > Filename        : draft-aboba-ips-iscsi-security-00.txt
> > Pages           : 35
> > Date            : 20-Aug-01
> >
> > This document discusses how iSCSI may utilize IPsec to provide
> > authentication, integrity, confidentiality and replay protection.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-aboba-ips-iscsi-security-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-aboba-ips-iscsi-security-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-aboba-ips-iscsi-security-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ---------------------------------------------------------
> + Date: Tue, 21 Aug 2001 09:29:53 -0400
> + Content-Type:
> multipart/mixed;boundary="----_=_NextPart_002_01C12A44.418236C0"
>
> ATT36560
>
> <ftp://internet-drafts/>
> Transfer-mode: ftp.ietf.org
> ---------------------------------------------------------
>