RE: iFCP: security position

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

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