RE: iFCP: security position

["Franco Travostino" <travos@nortelnetworks.com>]

At 07:27 PM 9/7/2001, Bill Strahm wrote:
> Why do you care how traffic is
> encrypted ???
> 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, Black_David@emc.com 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

> 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:travos@nortelnetworks.com]
> Sent: Friday, September 07, 2001 4:35 PM
> To: Robert Snively; 'Bill Strahm'; ips@ece.cmu.edu
> Subject: RE: iFCP: security position
>
>
> 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:bill@sanera.net]
> > Sent: Friday, September 07, 2001 3:17 PM
> > To: Franco Travostino; ips@ece.cmu.edu
> > 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: owner-ips@ece.cmu.edu
> [mailto:owner-ips@ece.cmu.edu]On
> Behalf Of
> > Franco Travostino
> > Sent: Friday, September 07, 2001 1:31 PM
> > To: ips@ece.cmu.edu
> > 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: travos@nortelnetworks.com