[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "user" and "network layer" security.

Andrade Software & Networking
Andrad@Netcom.Com
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2459      



Mitch Nelson:
> >"User" based security and "network layer" security can each be designed 
> >and implemented in ways that are consistent with the established network
> >architecture.  With some pro-forma cross consultation, one should expect
> >to arrive at reasonable results that provide good security without 
> >conflict and without unduly compromising present network functionality.  
> >The alternative does not  offer as much grounds for optimism.  Therefore it
> >seems that all lanquage related to "user" should be expunged from IPSEC
> >and instead treated in a seperate discussion group.

Phil Karn: 
> If the IPSEC group's work is to ever have any relevance, it must
> return to the original, bare-bones goal of building protected
> "tunnels" at the host-to-host or subnet-to-subnet level of
> granularity. There's still plenty of need for this function, but
> trying to do more than this is likely to continue to get us nowhere.
> 

Mitch and Phil are right.  Security at the IP layer should concentrate
only on providing authentication of packets between IP addresses, 
integrity of the IP packets and their data payloads, and 
encryption of the data payloads.  I believe that the critical 
problems that need to be solved are:

    1. Ensuring that two network level entities are allowed to
       exchange IP packets.  The best solution that I've seen requires
       a trusted central server to issue permits to the two communicating
       entities.  This centralizes access control and auditing.

    2. Enrollment of network entities.  This is a key step that 
       establishes entity trust that must be done correctly or all 
       security in the system will be worthless.

    3. Raw encryption (and authentication) performance can't keep up
       with the network speeds required by routers and protocol stacks.  
       Right now DES and other bulk ciphers are too slow without a 
       hardware boost.  RSA and Diffie-Hellman are so slow that it is 
       impossible to seriously contemplate them.  Especially once you 
       realize that they don't confer a significant advantage in 
       establishing trust between entities (see #2 about enrollment above).
       Hashes such as the MD5 HMAC are a step forward, but they still cost
       hundreds of CPU cycles per byte.

- Alex 

-- 

Alexander I. Alten
7677 Chestnut Way
Pleasanton, CA  94588
USA

Andrade@Netcom.Com
(510) 426-1528   Voice
(510) 417-0159   FaxVoice


Message-Id: <01BBAA1D.AC418850@lobster>
From: John Marchioni <johnmarc@cylink.com>
To: wford@mail.intranet.ca, johnmarc@cylink.com, cadams@nortel.ca
Cc: ipsec@TIS.COM, ietf-pkix@tandem.com, isakmp-oakley@cisco.com
Subject: RE: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted.
Date: Tue, 24 Sep 1996 13:38:27 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

{ JK's comments }

Basically, I agree that the X9.57 ARC should be used for certificates =
but I=20
disagree regarding the use of the X9.57 ARC for the public numbers and =
system parameters.  Why not stick with the X.42 ARC for those?

Regards,

-John Kennedy

p.s. For follow-ups, I suggest we prune down the distribution to only =
Cc:=20
ietf-pkix@tandem.com and ipsec@tis.com


OK by me, I thought X9.42 was still lacking a registered ARC, that's the =
only reason I suggested using X9.57's ARC.  It would be nice, if X9.57 =
does include the Diffie-Hellman certificate profile, to have all related =
OIDs for Diffie-Hellman (the X9.42 OID values) also included in X9.57, =
just a suggestion.

- John Marchioni