From owner-freebsd-security  Mon Jun  3 08:41:49 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA24878
          for security-outgoing; Mon, 3 Jun 1996 08:41:49 -0700 (PDT)
Received: from cs.pdx.edu (root@cs.pdx.edu [204.203.64.22])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA24864
          for <freebsd-security@freebsd.org>; Mon, 3 Jun 1996 08:41:42 -0700 (PDT)
Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [204.203.64.13])
        by cs.pdx.edu (8.7.3/CATastrophe-2/10/96-P) with ESMTP
        id IAA27592; Mon, 3 Jun 1996 08:41:40 -0700 (PDT) for <freebsd-security@freebsd.org>
Received: from localhost (jrb@localhost [127.0.0.1])
        by sirius.cs.pdx.edu (8.7.3/CATastrophe-9/18/94-C) with ESMTP
        id IAA04957; Mon, 3 Jun 1996 08:41:38 -0700 (PDT) for <freebsd-security@freebsd.org>
Message-Id: <199606031541.IAA04957@sirius.cs.pdx.edu>
To: freebsd-security@freebsd.org
Subject: anyone working with IPSEC stack?
In-reply-to: Your message of "Mon, 03 Jun 1996 16:35:08 +0200."
             <199606031435.QAA06701@sea.campus.luth.se> 
Date: Mon, 03 Jun 1996 08:41:37 -0700
From: Jim Binkley <jrb@cs.pdx.edu>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Has anyone taken the Naval Research Labs code for
their ip security stack ("security at the network layer",
but in fact it's more complicated than that) and ported/munged
it into freebsd?  Seems I'm about to do that this summer.
The following is an overly simplistic explanation of what
the NRL stack code does:

	1. implements RFCs 1825 ... ;i.e., provides
	an AH (authentication header) and ESP (I can never
	remember what ESP stands for, but basically
	encryption/privacy) between provided ip
	src and dest

	1.1 ah and esp are done for both ipv4 and ipv6,
	I'm not interested in ipv6 (at the moment, but there
	is an ipv6 implementation in the code. ah and esp
	are requirements for ipv6).

	2. gives the kernel a new socket mechanism called
	a key socket so that keys can be associated with

	3. includes a tunneling mechanism

The particular crypto algorithms found in the stack are
AH = keyed md5, and ESP=des-cbc.  We will have to upgrade
both of the AH and ESP "transforms" (algorithms basically) 
to SHA and a combined authentication/des algorithm.

Whilst I am asking.  Has anyone done any work with pc cards
that support crypto algorithms, e.g., a des card say?

				regards,

				Jim Binkley
				jrb@cs.pdx.edu