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
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.
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
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
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
participants (8)
-
Adam Shostack -
Bob Snyder -
David Neal -
ghio＠cmu.edu -
Matt Miszewski -
Nesta Stubbs -
Perry E. Metzger -
sdw＠lig.net