IPSEC goes to RFC

RFCs 1825, 1826, 1827, 1828, and 1829 came out today.

These RFCs describe in detail the IPSEC protocol, which is designed to
secure the internet from the ground up. IPSEC permits the
cryptographic encapsulation of all your IP traffic, which means all
your internet communications.

IPSEC is now a Proposed Standard.

Please read them and help us in the effort to universally deploy this
protocol.

Still to come will be a key management system. The current notion is
to store RSA keys in the DNS -- a proposal to do this made by Eastlake
and Kaufman has been accepted by the IETF. Eastlake is now working on
a certificate format that will be an alternative to X.509. The keys
will be used by a modified version of the STS protocol (a signed
Diffie-Hellman exchange) that is being worked on by Phil Karn -- the
key management system is to be called "Photuris" and is currently an
internet draft.

Again, *we need your help*. Cypherpunks write code. Help us make the
internet safe for personal privacy by contributing to this effort.

Perry

Perry wrote:

| RFCs 1825, 1826, 1827, 1828, and 1829 came out today.
| 
| These RFCs describe in detail the IPSEC protocol, which is designed to
| secure the internet from the ground up. IPSEC permits the
| cryptographic encapsulation of all your IP traffic, which means all
| your internet communications.
| 
| IPSEC is now a Proposed Standard.

| Again, *we need your help*. Cypherpunks write code. Help us make the
| internet safe for personal privacy by contributing to this effort.

	How about posting a list of 'things that need doing?'  I
assume one is floating around, possibly even with time estimates?

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

Adam Shostack writes:
> | IPSEC is now a Proposed Standard.
> 
> | Again, *we need your help*. Cypherpunks write code. Help us make the
> | internet safe for personal privacy by contributing to this effort.
> 
> 	How about posting a list of 'things that need doing?'  I
> assume one is floating around, possibly even with time estimates?

The IETF was challenged by Steve Crocker to be ready for use of IPSEC
for the Dallas meeting in December so that no IETFer who wanted to
communicate securely with his home site need be insecure.

To accomplish that, we need to produce versions of the security stack
for many architectures. Right now, we have AIX and 4.4BSD fairly
solidly covered. Less well covered is HPUX. People familiar with code
like the Trumpet Winsock stack, Linux, or who have access to the
innards of SunOS, Solaris, Windows 95, Mac stacks, and others, and can
legitimately release implementations for those platforms, are probably
needed. We need serious commitments from people but of course everyone
is trying to help everyone else along.

Basically, if you know how to hack kernels and networking code and you
have a platform you can work on, we need you.

We also lack work on the key management end of things -- people who
can start playing around with implementing Photuris, even on a "toy"
basis, would probably be of help.

Perry

> Adam Shostack writes:
> > | IPSEC is now a Proposed Standard.
> > 
> > | Again, *we need your help*. Cypherpunks write code. Help us make the
> > | internet safe for personal privacy by contributing to this effort.
> > 
> > 	How about posting a list of 'things that need doing?'  I
> > assume one is floating around, possibly even with time estimates?
> 
> The IETF was challenged by Steve Crocker to be ready for use of IPSEC
> for the Dallas meeting in December so that no IETFer who wanted to
> communicate securely with his home site need be insecure.
> 
> To accomplish that, we need to produce versions of the security stack
> for many architectures. Right now, we have AIX and 4.4BSD fairly
> solidly covered. Less well covered is HPUX. People familiar with code

Could we please share snapshots of any code that exists?  Even if it's
for a totally different OS, it's still extremely helpful if we're short
on time.

> like the Trumpet Winsock stack, Linux, or who have access to the

I'm interested in doing/helping with Linux.  I also have access to
an SGI Indy (less well ready to develop though) and HPUX.

> innards of SunOS, Solaris, Windows 95, Mac stacks, and others, and can
> legitimately release implementations for those platforms, are probably
> needed. We need serious commitments from people but of course everyone
> is trying to help everyone else along.
> 
> Basically, if you know how to hack kernels and networking code and you
> have a platform you can work on, we need you.
> 
> We also lack work on the key management end of things -- people who
> can start playing around with implementing Photuris, even on a "toy"
> basis, would probably be of help.
> 
> Perry

Does it make any sense to talk about loopback interface style wedges to
convert OS native IP to IPSEC?  What about a version of inetd that
wraps apps?

(I'm about to read the RFC's, so not sure if those suggestions make sense
yet.)

I really like the idea of using DNS for (public I assume) keys...

sdw
-- 
Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
OO/Unix/Comm/NN       ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95

Stephen D. Williams writes:
> Could we please share snapshots of any code that exists?  Even if it's
> for a totally different OS, it's still extremely helpful if we're short
> on time.

Thats certainly something people expect to do -- I'll begin letting
people at my code in a couple of weeks.

There is a mailing list for IPSEC developers right now -- people who
have read the RFCs and decide to get serious might want to subscribe.

> I'm interested in doing/helping with Linux.  I also have access to
> an SGI Indy (less well ready to develop though) and HPUX.

Kernel sources are important here -- if you don't have kernel sources
IPSEC may be a challenge to put into a kernel...

> Does it make any sense to talk about loopback interface style wedges to
> convert OS native IP to IPSEC?  What about a version of inetd that
> wraps apps?

Steve Bellovin has a summer student who did an interesting wedge on
PCs running packet driver interfaces in which he interposed his stuff
between the stack and the real packet driver. However, this can only
be of use for host-host keying and not user-user which is the real goal.

.pm

On Thu, 10 Aug 1995, Stephen D. Williams wrote:

> 
> > Adam Shostack writes:
> > > | IPSEC is now a Proposed Standard.
> > > 
> > > | Again, *we need your help*. Cypherpunks write code. Help us make the
> > > | internet safe for personal privacy by contributing to this effort.
> > > 
> > > 	How about posting a list of 'things that need doing?'  I
> > > assume one is floating around, possibly even with time estimates?
> > 
> 
> Could we please share snapshots of any code that exists?  Even if it's
> for a totally different OS, it's still extremely helpful if we're short
> on time.
> 
> > like the Trumpet Winsock stack, Linux, or who have access to the
> 
> I'm interested in doing/helping with Linux.  I also have access to
> an SGI Indy (less well ready to develop though) and HPUX.


I'd like to also volunteer to do the linux port, whether it be
coordination patches, hacking code, finding people, whatever.


Also, if other cypherpunk subscribers feel that this topic
is inappropriate for the list (not likely) or that it would
generate too much traffic for the list (?) I can create a new
majordomo list dedicated to the effort in 10 minutes.

The aforementioned 'To Do List' could be the signup message
you get when joining the list.

Just a suggestion,
David.


David Neal <dneal@usis.com> - GNU Planet Aerospace 1-800-PLN-8-GNU
Unix, Sybase and Networking consultant. "...you have a personal responsibility 
to be pro-active in the defense of your own civil liberties." - S. McCandlish

dneal@usis.com said:
> I'd like to also volunteer to do the linux port, whether it be 
> coordination patches, hacking code, finding people, whatever.

> Also, if other cypherpunk subscribers feel that this topic is 
> inappropriate for the list (not likely) or that it would generate too 
> much traffic for the list (?) I can create a new majordomo list 
> dedicated to the effort in 10 minutes.

The detailed discussions of planning such a port probably are inappropriate 
for cypherpunks.  Lord knows we need to conserve space for Foster conspiracy 
theories.....

I think a seperate list might not be a bad idea.  Either on your server or on 
something like vger.rutgers.edu, which is pretty much the linux mailing center 
of the universe right now. :-)

We should probably also check on comp.os.linux.networking and linux-net@vger.rutgers.edu to make sure someone isn't already working on this.

The ideal author would be outside the US, since the patches would need to be mailed to Linus for inclusion in the kernel, and that brings up some interesting ITAR issues.

Bob

I would like to be involved with any final stages of the Linux port.  I 
run a now, fairly defunct business off of my Linux Box and can afford 
some troubles in alpha testing.  Let me know when things are near a 
testing stage guys.

Oh, and by the way, thanks for doing this everyone.  It is VERY important!

Matt

On Thu, 10 Aug 1995, David Neal wrote:

> I'd like to also volunteer to do the linux port, whether it be
> coordination patches, hacking code, finding people, whatever.
> 
> 

> David Neal <dneal@usis.com> - GNU Planet Aerospace 1-800-PLN-8-GNU
> Unix, Sybase and Networking consultant. "...you have a personal responsibility 
> to be pro-active in the defense of your own civil liberties." - S. McCandlish
>

There seem to be a bunch of people interested in helping with a Linux
version of IPSEC. If you guys could spontaneously self-organize it
might help -- I unfortunately am not in a good position to do it for
you :-)

Having a Linux version would be extremely key -- I'm very glad to see
the enthusiasm for it.

.pm

sdw@lig.net (Stephen D. Williams) wrote:

> I really like the idea of using DNS for (public I assume) keys...

I don't.

Public keys in the DNS is a bad idea because it makes it difficult to
update the database, especially in large organizations.  When a host's
key is issued or changed then they would have to get the nameserver
admin to change it for them.  This could become a major problem/
inconvenience for many, many people.  The host should be able to give
its own key in response to a query.  That key could, of course, be
signed by any number of trusted signators to guarentee authenticity.

Matthew Ghio writes:
> sdw@lig.net (Stephen D. Williams) wrote:
> 
> > I really like the idea of using DNS for (public I assume) keys...
> 
> I don't.
> 
> Public keys in the DNS is a bad idea because it makes it difficult to
> update the database, especially in large organizations.

Thats one of a number of reasons why the DNS dynamic update facility
has been created.

> The host should be able to give
> its own key in response to a query.

What makes you assume we are using hosts as the keyed endpoints in the
usual case? Users are also getting keys, and querying them will be
difficult until humans all come equipped with implanted radio
transmitters. See "The Presidents Analyst" for a possible solution to
that problem, but I prefer DNS :-)

Perry

On Thu, 10 Aug 1995, Matthew Ghio wrote:

> sdw@lig.net (Stephen D. Williams) wrote:
> 
> > I really like the idea of using DNS for (public I assume) keys...
> 
> I don't.
> 
> Public keys in the DNS is a bad idea because it makes it difficult to
> update the database, especially in large organizations.  When a host's
> key is issued or changed then they would have to get the nameserver
> admin to change it for them.  This could become a major problem/
> inconvenience for many, many people.  The host should be able to give
> its own key in response to a query.  That key could, of course, be
> signed by any number of trusted signators to guarentee authenticity.
>
There are some other problems too I believe.  I have worked for a decent 
sized network who did all user authentication at the terminal servers for 
dial-in accounts thru DNS.  This wasn't too bad for just passws and 
stuff, but wouldn't this cause some bloat in the nameservers database?  
As well as cause problems security wise when it comes to updates.  Would 
these automatically not be cached in any form by the site making the 
request?  This also causes a problem for smaller time people who perhaps 
have a PPP/SLIP connection 24/7 but have nameserve done by their prvider, 
and I for sure don't want my provider to be in control of those keys. 
 

Nesta Stubbs		  "under the streamlined chrome shell, you'd 
Cynico Network Consulting   find the same victorian mechanism." WG
nesta@wwa.com

Nesta Stubbs writes:
> There are some other problems too I believe.  I have worked for a decent 
> sized network who did all user authentication at the terminal servers for 
> dial-in accounts thru DNS.  This wasn't too bad for just passws and 
> stuff, but wouldn't this cause some bloat in the nameservers database?  

HESIOD is an excellent demonstration that it works just fine.

> As well as cause problems security wise when it comes to updates.  Would 
> these automatically not be cached in any form by the site making the 
> request?  This also causes a problem for smaller time people who perhaps 
> have a PPP/SLIP connection 24/7 but have nameserve done by their prvider, 
> and I for sure don't want my provider to be in control of those keys. 

Why not? After all, they are signed. You can have them held by your
worst enemy and it should be just fine. Thats the idea of public key
signatures.


.pm

> 
> 
> Nesta Stubbs writes:
> > There are some other problems too I believe.  I have worked for a decent 
> > sized network who did all user authentication at the terminal servers for 
> > dial-in accounts thru DNS.  This wasn't too bad for just passws and 
> > stuff, but wouldn't this cause some bloat in the nameservers database?  
> 
> HESIOD is an excellent demonstration that it works just fine.
> 
> > As well as cause problems security wise when it comes to updates.  Would 
> > these automatically not be cached in any form by the site making the 
> > request?  This also causes a problem for smaller time people who perhaps 
> > have a PPP/SLIP connection 24/7 but have nameserve done by their prvider, 
> > and I for sure don't want my provider to be in control of those keys. 
> 
> Why not? After all, they are signed. You can have them held by your
> worst enemy and it should be just fine. Thats the idea of public key
> signatures.

Not only that but it's common now for DNS servers to give short TTL
for the answers (multiple A recs for load balancing), no big deal
to have pseudo-subdomains that are pointed at a different server
(Even over slip/ppp) than normal name service.

I believe the root servers answers for intermediate nodes are cached
normally, so key.george.bub.com doesn't cause a root hit after
bub.com has been resolved.

Quite a few domains do run their own name servers, and it's not too tough
to create auto-update scripts, etc.

There's no reason that DNS has to be the only mechanism.  Default
to one method then fallback to others, like direct IP port connection
for query.

> .pm
> 

sdw
-- 
Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
OO/Unix/Comm/NN       ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95