Subject: RE: iFCP: security position

From: "Franco Travostino" <[email-masked]>
Date: Fri, 07 Sep 2001 19:34:42 -0400

At 06:57 PM 9/7/2001, Robert Snively wrote:
>If I understood their summary correctly, it was a SHOULD NOT
>implement DES.  That seems like an adequate warning without
>creating a double bind.  What I think it means is that a DES-only
>device will not be compliant.  Did I get that right?

Yes. In addition to that ... I will note that the "WG chair exercised his 
prerogative to exclude DES from consideration" (from the interim meeting 
security minutes posted on Aug 30). Since this makes practical good sense 
in an iFCP environment as well, we will comply with whatever verbiage is 
appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as 
we don't see DES-encrypted storage traffic ever ...

-franco

>Bob
>
> > -----Original Message-----
> > From: Bill Strahm [mailto:[email-masked]]
> > Sent: Friday, September 07, 2001 3:17 PM
> > To: Franco Travostino; [email-masked]
> > Subject: RE: iFCP: security position
> >
> >
> > This is going to be very interseting... How do you plan on
> > using standard
> > IPsec clients that have DES as MUST implement when your
> > application that
> > sits above it has a MUST NOT implement requirement.  This
> > would be like
> > having a protocol that tells layer 3 that it MUST run over
> > Token Ring, but
> > MUST NOT run over Ethernet.
> >
> > These are all policy issues that can be solved by having the end users
> > implement appropriate policies, not by standards organizations
> >
> > Bill
> > Sanera Systems Inc.
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Franco Travostino
> > Sent: Friday, September 07, 2001 1:31 PM
> > To: [email-masked]
> > Subject: iFCP: security position
> >
> >
> >
> > After the interim meeting, we restate our security coordinates in the
> > following terms. Additionally, we have expanded our Irvine slides with
> > rationale text and insights that we learnt at the interim
> > meeting. Such
> > amended slide set is available at
> > ftp://standards.nortelnetworks.com/san/ifcp_security_requireme
>nts-v2.pdf
>Comments most welcome.
>
>Keying: IKE
>Pre-shared keys: MUST implement
>Signature key authentication: MAY implement
>Phase-1/Main Mode: MUST implement
>Phase-1/Aggressive Mode: MAY implement
>Phase-2/Quick Mode: MUST implement
>Phase-2/Quick Mode + KE payload: MUST implement
>Identities are IP addresses in all Phase-1/Phase-2 Modes
>
>
>Integrity MAC:
>HMAC-SHA1: MUST implement
>AES (X)CBC MAC: SHOULD implement*
>
>
>Encryption:
>3DES CBC: MUST implement
>AES CTR: SHOULD implement*
>DES: SHOULD NOT implement
>NULL: MUST implement
>
>
>Encapsulation Style:
>Tunnel Mode.
>
>
>(*) IFF there is a Proposed Standard RFC that we can cite by the time we hit
>Last Call. HMAC-SHA1 and 3DES CBC suit us fine otherwise (as justified in
>the slides).
>
>-franco
>iFCP Technical Coordinator
>
>
>
>Franco Travostino, Director Content Internetworking Lab
>Advanced Technology Investments
>Nortel Networks, Inc.
>600 Technology Park
>Billerica, MA 01821 USA
>Tel: 978 288 7708 Fax: 978 288 4690
>email: [email-masked]

---

From: "Bill Strahm" <[email-masked]>
Date: Fri, 7 Sep 2001 16:27:07 -0700

Why do you care how traffic is encrypted ???

Would you rather see Clear traffic than DES traffic ?

These are site security policies, and we as the IETF should stay out of it.
While we as a WG might raise our noses at certain algorithms, it turns out
that DES is SIGNIFICANTLY better than simple clear traffic.  Are we planning
on putting statements saying we won't accept ENIGMA, ROT-13, etc. traffic as
well ?

I am willing to live with the WG chairs prerogative to not require DES as a
MUST implement, because it is all ready a MUST implement in IPsec, therefore
there is no reason for our WG to add additional functionality to IPsec
layers.  I am not willing to give in and say that there is a requirement
that policies that drive the IPsec/IKE engines exclude DES in all cases
(even where the admin wants to allow these protocols)

Bill
-----Original Message-----
From: Franco Travostino [mailto:[email-masked]]
Sent: Friday, September 07, 2001 4:35 PM
To: Robert Snively; 'Bill Strahm'; [email-masked]
Subject: RE: iFCP: security position

Yes. In addition to that ... I will note that the "WG chair exercised his
prerogative to exclude DES from consideration" (from the interim meeting
security minutes posted on Aug 30). Since this makes practical good sense in
an iFCP environment as well, we will comply with whatever verbiage is
appropriate and correct wrt to IPS and IPsec WG jurisdictions. As long as we
don't see DES-encrypted storage traffic ever ...

-franco

Bob

nts-v2.pdf
Comments most welcome.

Keying: IKE

Integrity MAC:

Encryption:
3DES CBC: MUST implement

Encapsulation Style:
Tunnel Mode.

-franco

---

From: "Franco Travostino" <[email-masked]>
Date: Fri, 07 Sep 2001 23:40:15 -0400

>Would you rather see Clear traffic than DES traffic ?

<IMO>In some setups, I'd rather be sending personal backup data in the 
clear (I seemingly don't care at all) than with DES (I seemingly do care 
quite a bit, but I'm also so clueless that anybody with a pocket calculator 
can break my cypher). DES may have its place still in wireless 
communication, or in real-time exchanges where the value of data quickly 
decays over time. It doesn't sound like it's a fit with 
storage,  considering that 3DES is commodity these days. Cryptography has 
evolved a lot over time (MD5 is another museum piece that comes to mind). 
On issues like DES vs. 3DES, I'm comfortable with the IETF driving 
forward-looking statements during such high-churn time for cyphers, even at 
the cost of stepping over the mechanism vs. policy line.</IMO>

At 06:22 PM 9/7/2001, [email-masked] wrote:
>Bill's DES issue goes away if the DES requirements language is
>"SHOULD NOT use".  A facility that insists on using DES has
>been more than adequately warned by the "SHOULD NOT".

OK, we will take this into account.

thanks!
-franco

---

From: Paul Koning <[email-masked]>
Date: Mon, 10 Sep 2001 13:50:00 -0400

> Would you rather see Clear traffic than DES traffic ?

Yes, absolutely.  

That is because clear traffic does not mislead.  It is
obviously not secure.  DES is sufficiently weak that encrypting with
it could be viewed as a form of false advertising.

This is also what is wrong with things like WEP -- these are systems
that pretend to offer security but in fact do not.  And people defend
them with similar arguments.  Or, for that matter, Fred Foobar's
Famous Snake Oil encryption algorithm.  The problem in all these cases
is that the appearance of crypto without the reality is much, much
worse than the absence of crypto.  You should have either strong
crypto, or none.  After all, strong crypto is readily available.

DES shows up as mandatory in IPsec for reasons that were political, not
technical, and that became obsolete several years ago.

     paul

---

From: "Bill Strahm" <[email-masked]>
Date: Mon, 10 Sep 2001 10:58:48 -0700

WEPs problem was not a weakness in encryption security, heck the crypto is
rock solid 128 bit used in every SSL connection on the internet (including
all of your stock transactions, credit card transactions etc.).  Note that
the cryptography is FINE.

What was not fine was the system built around it, specifically, there was no
rekeying algorithm (bad) and they deployed it in such a way that as soon as
you saw a little over a million packets on the wire, it was broken by
default.

The next thing that tends to break crypto systems is random number
generation, there were many hacks on Kerberos based on the usage of a
timestamp to initialize the random number generator.

The third thing that tends to break crypto systems is social engineering
(Please give me your password tends to work about 25% of the time when
random people start calling into your company claiming to be I.T.)

WAY down the list is actually breaking the cipher...  Ok, given 100K and 22
hours, I can break DES... However if my data is only worth 10K and I cange
keys often, then this is acceptable.

Again it is up to the administrator to determine what the acceptable
crytography is.  Heck I use VERY good crypto, but then I have fast machines,
and live in a country that lets me use it.  Until the IPsec WG removes DES
as a MUST implement, I am sorry but it will be in every conforming IPsec
implementation out there.

Bill
Sanera Systems Inc.

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Monday, September 10, 2001 10:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iFCP: security position

Yes, absolutely.

     paul

---

From: Venu Gopal Gandesiri <[email-masked]>
Date: Mon, 10 Sep 2001 13:43:27 -0700

--
**********************************************************************
Dance like no one's watching, love like you've never been
hurt, sing like no one's listening, live like it's heaven
on earth.

 Happiness is a journey, not a destination.

                                VENU GOPAL GANDESIRI
                                Platys Communications Inc
                                3150 A Coronado Drive
                                SantaClara, CA, 95054
                                Phone # : 408-496-4435 (W)
                                Phone # : 408-243-4870 (H)

**********************************************************************

  This email and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to which they are
addressed. Access to this e-mail by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited.