RE: iFCP: security position

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

You are better off staying silent on DES.  DES is a MUST implement
protocol...  I can live with adding additional requirements to IPsec (as
long as they are reasonable), but contradicting current requirements seems a
little out of place.  When IPsec decides DES is not strong enough, they will
move it from a MUST implement protocol, to a SHOULD NOT implement protocol,
to a MUST NOT implement protocol (maybe not, I don't see any MUST NOT
implement ROT-13 requirements)

Bill

-----Original Message-----
From: Robert Snively [mailto:rsnively@brocade.com]
Sent: Friday, September 07, 2001 3:58 PM
To: 'Bill Strahm'; Franco Travostino; ips@ece.cmu.edu
Subject: RE: iFCP: security position


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?

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