RE: iFCP: security position

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

This gets back to usage.  So our standard is going to have statements saying
what a user should do ???

Isn't that the purpose of a site security policy, not an IETF RFC ???

Bill

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, September 07, 2001 3:23 PM
To: bill@Sanera.net; ips@ece.cmu.edu
Subject: RE: iFCP: security position


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".

--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: Bill Strahm [mailto:bill@sanera.net]
> Sent: Friday, September 07, 2001 6: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