stf and shoebox NAT routers
Historically, I've used FreeBSD machines as NAT routers. Call me a traitor if you must, but it's getting harder to justify not simply putting one of those little Linksys/Netgear/SMC/whatever NAT routers in place and having the FreeBSD machine be a server behind the box instead. One of the last considerations remaining is IPv6. Most boxes now have the concept of a DMZ host. They will, aparently, perform simple address substitution on the IP header for packets that arrive of an unknown protocol and send them to the DMZ host (living on the inside LAN - thus calling it a DMZ host is a bit of a misnomer, but that's a semantic debate for another occasion). This would be ideal for 6to4 - incoming packets would simply arrive and be processed. The trouble appears to be the outgoing side. The machine's actual IPv4 address is not the same as the *outside* IPv4 address, so one of two things is happening (I'm not sure which): Either the blanket prohibition on RFC-1918 addresses having anything to do with 6to4 is getting in the way, or stf0 having a foreign prefix (that is, a prefix that does not relate to a physical interface on the machine) is confusing it. 6to4 is the IPv6 connection solution I prefer. Is there any way stf can be taught to live behind an IPv4 NAT? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
6to4, stf and shoebox NAT routers
(I sent a version of this e-mail earlier today without the patch, but my
return address was not the same as the subscribed one, so I think it got
ate. Appologies if this is a dupe)
Historically, I've used FreeBSD machines as NAT routers.
Call me a traitor if you must, but it's getting harder to justify not
simply putting one of those little Linksys/Netgear/SMC/whatever NAT
routers in place and having the FreeBSD machine be a server behind the
box instead.
One of the last considerations remaining is IPv6.
Most boxes now have the concept of a DMZ host. They will, aparently,
perform simple address substitution on the IP header for packets that
arrive of an unknown protocol and send them to the DMZ host (living on
the inside LAN - thus calling it a DMZ host is a bit of a misnomer, but
that's a semantic debate for another occasion). This would be ideal for
6to4 - incoming packets would simply arrive and be processed. The
trouble appears to be the outgoing side. The machine's actual IPv4
address is not the same as the *outside* IPv4 address, so one of two
things is happening (I'm not sure which): Either the blanket prohibition
on RFC-1918 addresses having anything to do with 6to4 is getting in the
way, or stf0 having a foreign prefix (that is, a prefix that does not
relate to a physical interface on the machine) is confusing it.
I've come up with the attached patch. It simply allows you to optionally
neuter the RFC-1918 checks. The problem is that there are some instances
where those checks would still be good to have - specifically, in the
code that checks IPv6 prefixes of incoming packets. There's no reason to
allow RFC-1918 addresses to appear there. But being able to be selective
would mean having to do a bit more rearchitecture than I feel like, at
least today. :-)
--- net/if_stf.c.orig Thu Jul 15 01:26:06 2004
+++ net/if_stf.cFri Mar 11 11:54:23 2005
@@ -89,6 +89,7 @@
#include sys/module.h
#include sys/protosw.h
#include sys/queue.h
+#include sys/sysctl.h
#include machine/cpu.h
#include sys/malloc.h
@@ -183,6 +184,13 @@
struct if_clone stf_cloner = IFC_CLONE_INITIALIZER(STFNAME, NULL, 0,
NULL, stf_clone_match, stf_clone_create, stf_clone_destroy);
+SYSCTL_DECL(_net_link);
+SYSCTL_NODE(_net_link, IFT_STF, stf, CTLFLAG_RW, 0, 6to4 Interface);
+
+static int no_rfc1918check = 0;
+SYSCTL_INT(_net_link_stf, OID_AUTO, permit_rfc1918, CTLFLAG_RW,
+no_rfc1918check, 0, permit RFC-1918 addresses);
+
static int
stf_clone_match(struct if_clone *ifc, const char *name)
{
@@ -567,6 +575,9 @@
isrfc1918addr(in)
struct in_addr *in;
{
+ if (no_rfc1918check)
+ return 0;
+
/*
* returns 1 if private address range:
* 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6to4, stf and shoebox NAT routers
Turns out there is also a check in stf_output that I need to neuter for
this configuration. Attached is a revised patch.
--- net/if_stf.c.orig Thu Jul 15 01:26:06 2004
+++ net/if_stf.cFri Mar 11 15:05:52 2005
@@ -89,6 +89,7 @@
#include sys/module.h
#include sys/protosw.h
#include sys/queue.h
+#include sys/sysctl.h
#include machine/cpu.h
#include sys/malloc.h
@@ -183,6 +184,13 @@
struct if_clone stf_cloner = IFC_CLONE_INITIALIZER(STFNAME, NULL, 0,
NULL, stf_clone_match, stf_clone_create, stf_clone_destroy);
+SYSCTL_DECL(_net_link);
+SYSCTL_NODE(_net_link, IFT_STF, stf, CTLFLAG_RW, 0, 6to4 Interface);
+
+static int no_rfc1918check = 0;
+SYSCTL_INT(_net_link_stf, OID_AUTO, permit_rfc1918, CTLFLAG_RW,
+no_rfc1918check, 0, permit RFC-1918 addresses);
+
static int
stf_clone_match(struct if_clone *ifc, const char *name)
{
@@ -455,11 +463,13 @@
* we shouldn't generate output. Without this check, we'll end up
* using wrong IPv4 source.
*/
- ia6 = stf_getsrcifa6(ifp);
- if (ia6 == NULL) {
- m_freem(m);
- ifp-if_oerrors++;
- return ENETDOWN;
+if (!no_rfc1918check) {
+ ia6 = stf_getsrcifa6(ifp);
+ if (ia6 == NULL) {
+ m_freem(m);
+ ifp-if_oerrors++;
+ return ENETDOWN;
+ }
}
if (m-m_len sizeof(*ip6)) {
@@ -567,6 +577,9 @@
isrfc1918addr(in)
struct in_addr *in;
{
+ if (no_rfc1918check)
+ return 0;
+
/*
* returns 1 if private address range:
* 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6to4, stf and shoebox NAT routers
Hajimu UMEMOTO wrote: I posted my proposed patch to current@ for review in the past. But, no one responded. Could you test this? This is for 6-CURRENT at Feb 1. If it doesn't apply cleanly, please let me know. Domo arigato gozaimasu! It had fuzz when applied to 5.3-RELEASE, but it did apply. I am at work, behind the wrong firewall, so I cannot test this completely, but with your patch applied and turned on, I can see that configuring my machine (which lives in 172.16 space) with a foreign 6to4 prefix on stf0 results in ping6 packets being transmitted correctly (tcpdump shows a correct ipv6 packet and shows an ipv4 header with the packet being from my 172.16 machine and going to the correct destination). I have high hopes that the return side will work when it's deployed for real. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6to4, stf and shoebox NAT routers
Well, I'm screwed. I set up the Linksys router so that the FreeBSD machine is the DMZ host on the inside. Sending 6to4 to the router's outside address results in tcpdump showing these on the inside: 22:09:36.138924 [linksys mac address] ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has [linksys outside ip] tell [linksys inside ip] Which, quite frankly, is laughable. If that weren't enough, the packets come out of the linksys router with the source IP address being from the inside (meaning, it didn't get NATted). Humph. So it appears that for now, I will have to keep a 2nd interface active on this box solely for the purpose of doing IPv6. What a nightmare. On Mar 11, 2005, at 4:38 PM, Nick Sayer wrote: Hajimu UMEMOTO wrote: I posted my proposed patch to current@ for review in the past. But, no one responded. Could you test this? This is for 6-CURRENT at Feb 1. If it doesn't apply cleanly, please let me know. Domo arigato gozaimasu! It had fuzz when applied to 5.3-RELEASE, but it did apply. I am at work, behind the wrong firewall, so I cannot test this completely, but with your patch applied and turned on, I can see that configuring my machine (which lives in 172.16 space) with a foreign 6to4 prefix on stf0 results in ping6 packets being transmitted correctly (tcpdump shows a correct ipv6 packet and shows an ipv4 header with the packet being from my 172.16 machine and going to the correct destination). I have high hopes that the return side will work when it's deployed for real. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bridging with pcmcia cards
Julian Elischer wrote: bridging is not a function of it being a pc-card.. This is true, particularly with netgraph bridging. actually bridging may already work with wi cards also netgraph bridgiung may also work... Bridging cannot work with wi cards, since they do not support promiscuous transmission (that is, sending frames with other than their own MAC address). Moreover, anyone seriously desiring to bridge wi cards very likely wants to actually do something that is more than bridging -- they probably want to be an access point (ala Apple's virtual airport functionality). The difference between that and just bridging is that the wireless clients can see each other with certainty (that is, no hidden node issues) and they can turn on power saving (that is, having the receiver duty cycle be less than 100%). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
Peter wrote: However, Gates said, there are problems for commercial users relative to the (GNU General Public License), and we are just making sure people understand the GPL. end Quote. But the issue is that wasn't the end of the quotation. Later on, Bubba says, And so people should understand the GPL. When people say open source, they often mean the GPL. In the past, the line from Microsoft has been reduced publicly to Open source is bad because the GPL is viral. They are trying to tar non-GPLed open source projects with the same FUDdy brush. So I think pointing out areas where they don't live by their own FUD is a very important thing to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on IBM's radar screen?
Garance A Drosihn wrote: I think the recent debacle with the T20 and A20 laptops actually helped to get us noticed. Here someone in IBM probably made a dumb programming mistake which happened to make freebsd unusable on their hardware, and they got a whole bunch of their *customers* (owners of one of these laptops) beating them up for the problem. Not freebsd.org making vague promises of sales based on freebsd, but actual customers using freebsd on IBM hardware. IBM wants to sell as much hardware as they can, and so they are bound to be interested when they notice that some of their customers are using freebsd. I was particularly gratified that when the story got slashdotted, a lot of support came from people who didn't run FreeBSD, but did feel our pain - Linux folks are in this sense part of the same community used to the same shoddy treatment by hardware vendors (if you're not running Winblows, it's unsupported, so go away). They helped make the response larger and noisier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
802.1q vlan patches for if_fxp
A colleague of mine has reported the necessity of adding this patch to
if_fxp.c to support 802.1q vlans. I must admit that I am not familiar
enough with the vlan code to understand what good this does. This patch
is against 4.1-RELEASE. If it is a good thing, I would like to add it to
-current and MFC it back in time for 4.3. If it isn't, I'd like to tell
my friend why. Thanks in advance.
*** pci/if_fxp.c.orig Wed Jul 19 09:36:36 2000
--- pci/if_fxp.cTue Aug 8 23:18:37 2000
***
*** 52,57
--- 52,65
#include net/bpf.h
+ #include "vlan.h"
+ #if NVLAN 0
+ #include net/if_types.h
+ #include net/if_arp.h
+ #include net/ethernet.h
+ #include net/if_vlan_var.h
+ #endif
+
#if defined(__NetBSD__)
#include sys/ioctl.h
***
*** 417,422
--- 425,433
ether_ifattach(ifp, enaddr);
bpfattach(sc-sc_ethercom.ec_if.if_bpf, ifp, DLT_EN10MB,
sizeof(struct ether_header));
+ #if NVLAN 0
+ ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header);
+ #endif
/*
* Add shutdown hook so that DMA is disabled prior to reboot. Not
***
*** 599,604
--- 610,618
* Attach the interface.
*/
ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
+ #if NVLAN 0
+ ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header);
+ #endif
/*
* Let the system queue as many packets as we have available
* TX descriptors.
*** modules/fxp/Makefile.orig Fri Jan 28 05:26:29 2000
--- modules/fxp/MakefileTue Aug 8 23:28:25 2000
***
*** 2,7
.PATH:${.CURDIR}/../../pci
KMOD = if_fxp
! SRCS = if_fxp.c opt_bdg.h device_if.h bus_if.h pci_if.h
.include bsd.kmod.mk
--- 2,11
.PATH:${.CURDIR}/../../pci
KMOD = if_fxp
! SRCS = if_fxp.c opt_bdg.h vlan.h device_if.h bus_if.h pci_if.h
! CLEANFILES= vlan.h
!
! vlan.h:
! touch vlan.h
.include bsd.kmod.mk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security: add md5 to suid change notification?
Greg Black wrote: Nick Sayer wrote: Would it generally be viewed as helpful to add the option of reporting the md5 for the files listed in /var/log/setuid.*? I don't see the benefit in this if either the md5 binary or the comparison file are on writable storage (which is almost always going to be true). Then why bother checking at all? Someone can trojan ls, or even easier, arrange to trojan suid binaries without changing the things that show up in that listing. Besides, security conscious folks could set the immutable flag for md5 and/or the comparison file (and probably sh and ls while they're at it) if they like. For the point kris made, I'm not sure he understood what I was suggesting -- I'm not suggesting just printing the md5 of the files when you notice they've changed, but adding the md5 as another trigger for deciding which files have changed. Adding it as a field in /var/log/setuid.* would achieve this end. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
/etc/security: add md5 to suid change notification?
Would it generally be viewed as helpful to add the option of reporting the md5 for the files listed in /var/log/setuid.*? It would make the lines in that file very long, but in many cases they already break the 80 character boundary anyhow. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Open Hardware Initiative (was Re: FreeBSD vs Linux, Solaris, and NT)
Matt Dillon wrote: Yes, it's a pretty sad state of affairs. What annoys me the most is that companies actually believe they are protecting something when they don't make their device driver source or hardware documentation available. It has been well proven for years that the most withholding accomplishes for the vast majority of these device drivers is a slight delay--- perhaps a week or two, before competitors figure out what they've done. Pirates don't care... they want the binaries anyway, they aren't programmers. And the open-source community has always strictly adhered to copyright and license restrictions. So all these companies are doing is making life harder for themselves and for their products. Unnecessarily. The XFree folks have some godaweful stories about the crap they've had to wade through to get video manufacturers on-board. Some video manufacturers have figured it out, a lot haven't. [...] I think the time is right to reward companies that "get it". I propose that the way to do this is to create an "open hardware" trademark that can be used for marketing by companies that sell hardware for which they either provide sufficient documentation that a fully featured device driver can be written without reverse engineering, or for which they provide at least one open-source driver. The idea is to do for friendly hardware vendors what the "OSI certified" mark (www.opensource.org) does for open-source software. I wrote ESR about this, since it's something that would have fit in well with OSI's mission, but he declined to take it up, as OSI was fully committed. He did mention, however, that an OSI board member had tried this in the past, but suggested that perhaps now the time is right. I invite discussion on what the OHI (Open Hardware Initiative) requirements should be and how best to proceed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sony vaio jog dial hacks
Well, I've gotten pointed to some stuff and am working on a driver for the Sony SPIC chip, but I have some concerns: In order to map the device in, you need to poke at the PCI config registers of the intpm0 chip. This means either having to add this functionality in to the intpm driver (or at least into its attach routine), or having to choose between intpm and spic functionality or adding another quirk in or somehow being able to get the dev_t of the intpm device so I can do pci_read_config() and pci_write_config() to map the thing in. In what is basically an ISA driver. Bizarre. Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RPC not taking the same service twice: a bug or a security measure?
[EMAIL PROTECTED] wrote: On 8 Nov, Bill Paul wrote: A coworker seems to have found an issue with portmap on FreeBSD. Aparently, if you try and register the same service twice, but with different protocols (UDP vs TCP), it doesn't work. I'm not entirely sure I believe this, and I am digging for more details, but I am writing to see if anyone can tell me anything that will save me having to do the investigative work. :-) I'll follow up with more details as I can. No you won't, because both you and your cow-orker are smoking entirely too much crack. (Him for hallucinating this problem in the first place, and you for believing him enough to post this query here.) Hey!! There is no need for this type of response. It's obvious the person writing has good intentions, but has not read a TCP/IP book, that's worth a damm. I would consider it a personal favor, if this might be responded to in a less attacking manner. No, no. He's right. We were smoking too much crack. :-) The problem turns out that we try to unregister the service before we register it. On solaris we use rpcb_unset(), which is protocol specific. On Freebsd, we use pmap_unset() which does not consider protocol. It would unregister the one we registered on the other protocol moments ago. I guess on FreeBSD there is no way to unregister selectively such as with rpcb_unset(), so we will just have to be a little more careful. :-) In my own defense, I'd like to point out that I've read lots of good TCP/IP books. It's RPC that I know very little about. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RPC not taking the same service twice: a bug or a security measure?
A coworker seems to have found an issue with portmap on FreeBSD. Aparently, if you try and register the same service twice, but with different protocols (UDP vs TCP), it doesn't work. I'm not entirely sure I believe this, and I am digging for more details, but I am writing to see if anyone can tell me anything that will save me having to do the investigative work. :-) I'll follow up with more details as I can. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KDE2, konsole_grantpty and FreeBSD
KDE2 uses a utility called "konsole_grantpty". This is an suid program. Its job is to chown the master side (/dev/pty??) of the pty pair for konsole, which is KDE's "xterm" sort of thing. By isolating this action in a child, konsole itself does not require suid. konsole_grantpty does its job by performing the actions called for on ttyname(3) (that is, it is passed a file descriptor on fd 3 of the device it needs to fiddle). The problem is that ttyname() fails on all /dev/pty?? devices. This is because the first thing ttyname does is perform a tcgetattr() to see if it's really a terminal or not. This fails. So something has to give. Either konsole_grantpty has to find some other way of turning a file descriptor into a /dev entry in a way that can't be exploited by someone else redirecting stuff into it, or ttyname() has to be made a bit more lax, or pty's have to look like tty's to ttyname(). Anyone have any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KDE2, konsole_grantpty and FreeBSD
I have cobbled together a solution with fstat() and devname(). Interestingly enough, elsewhere in konsole, a call to ttyname() with an FD on the master side appears to actually work, so I don't know what the hell is up with that. :-/ Nick Sayer wrote: [...] The problem is that ttyname() fails on all /dev/pty?? devices. This is because the first thing ttyname does is perform a tcgetattr() to see if it's really a terminal or not. This fails. [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ESS Solo users, try this patch
The last patch improved, but did not completely eliminate the warnings.
This one appears to do the job perfectly. The question is, does calling
DELAY() like this cause any concerns for anyone?
Index: solo.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pci/solo.c,v
retrieving revision 1.8
diff -u -r1.8 solo.c
--- solo.c 2000/08/09 07:14:56 1.8
+++ solo.c 2000/08/11 17:01:22
@@ -756,7 +756,7 @@
static int
ess_dmapos(struct ess_info *sc, int ch)
{
- int p = 0;
+ int p = 0, i = 0, j = 0;
u_long flags;
KASSERT(ch == 1 || ch == 2, ("bad ch"));
@@ -766,11 +766,20 @@
/*
* During recording, this register is known to give back
* garbage if it's not quiescent while being read. That's
- * why we spl, stop the DMA, wait, and be vewy, vewy quiet
+ * why we spl, stop the DMA, and try over and over until
+ * adjacent reads are "close", in the right order and not
+ * bigger than is otherwise possible.
*/
ess_dmatrigger(sc, ch, 0);
- DELAY(20);
- p = port_rd(sc-vc, 0x4, 2) + 1;
+ DELAY(20);
+ do {
+ DELAY(10);
+ if (j 1)
+ printf("DMA count reg bogus: %04x %04x\n",
+ i, p);
+ i = port_rd(sc-vc, 0x4, 2) + 1;
+ p = port_rd(sc-vc, 0x4, 2) + 1;
+ } while ((p sc-dmasz[ch -1 ] || i p || (p - i) 0x8) j++
+1000);
ess_dmatrigger(sc, ch, 1);
}
else if (ch == 2)
ESS Solo users, try this patch
I believe that sometimes ESS sound chips can give back whacky numbers
under some circumstances when the dma count register is read while DMA
is in progress. I believe this may be a good workaround. I'm considering
applying this, but I'd like it to get some more testing first.
If you have an ESS Solo: Try this and see if recording 16 bit stereo
44100 audio doesn't generate hwptr warnings.
If you have some other ESS chip, see if you can modify the getpos
entry of the applicable driver to do something like this.
In preliminary testing, I've never seen _good_ adjacent reads be more
than 1 number apart, but 16 gives room for slow processors. I've
never seen j have to go past 3 (and past 2 only once in a great while).
If it gets past 1000, then IMHO the DMA count register has become a
pretty good random number generator. :-) The 1000 factor is to avoid
infinite loops if the impossible happens. :-)
--- src/sys/dev/sound/pci/solo.c2000/08/09 07:14:56 1.8
+++ src/sys/dev/sound/pci/solo.c2000/08/11 04:43:30
@@ -756,7 +756,7 @@
static int
ess_dmapos(struct ess_info *sc, int ch)
{
- int p = 0;
+ int p = 0, i, j = 0;
u_long flags;
KASSERT(ch == 1 || ch == 2, ("bad ch"));
@@ -766,11 +766,17 @@
/*
* During recording, this register is known to give back
* garbage if it's not quiescent while being read. That's
- * why we spl, stop the DMA, wait, and be vewy, vewy quiet
+ * why we spl, stop the DMA, and try over and over until
+ * adjacent reads are "close".
*/
ess_dmatrigger(sc, ch, 0);
- DELAY(20);
- p = port_rd(sc-vc, 0x4, 2) + 1;
+ do {
+ if (j)
+ printf("DMA count reg bogus: %0x %0x\n",
+ i, p);
+ i = port_rd(sc-vc, 0x4, 2) + 1;
+ p = port_rd(sc-vc, 0x4, 2) + 1;
+ } while ((i p || (p - i) 0x10) j++ 1000)
ess_dmatrigger(sc, ch, 1);
}
else if (ch == 2)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Solo-1 appears to work (was Re: US$100 prize for adding ESS Audiodrive support to pcm)
I invite anyone capable to please test the Solo-1 driver. So far as I am able to test, it appears to work, but further field trials would be a good thing, especially in light of the wacky workaround that I found necessary to get recording to work (see the latest commit). Unless show-stoppers appear in the near future, I am inclined to award the US$100 prize to Cameron Grant, who provided a driver that was most of the way there. I would also like to publicly recognize and thank Klaus Klein who pointed me towards the (actually, his) NetBSD driver. Perusing his source gave me the hint about the record audio being big endian (thank ewe, ESS). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Drivers for Dollars (was Re: US$100 prize for adding ESS Audiodrive support to pcm)
Alan Clegg wrote: Out of the ether, Andrzej Bialecki spewed forth the following bitstream: On a simmilar note: what about a driver for ESS Maestro 2E? I'm certainly willing to pay twice as much ($200) for working sound in most of laptops within my reach... Add $100 from me. There is one that works for some folks out there by [EMAIL PROTECTED], but it does not work for me. Since my experience with the Solo driver (it's still not quite done) bounty, I will put up a page where folks offering "driver bounties" can make their offers known. Such sites exist for software in general, but I will make one just for FreeBSD drivers. More later. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ESS Solo driver almost there (was Re: US$100 prize for adding ESS Audiodrive support to pcm)
Channel 2 works now, and channel 1 is almost working. I ran across this note in the NetBSD source for their Solo driver... /* * Apparently the Audio 1 DMA controller's current address * register can't roll over a 64K address boundary, so we have to * take care of that ourselves. The second channel DMA controller * doesn't have that restriction, however. */ It would make sense that the results I'm seeing with the current driver might be caused by this bug (it sounds like a square wave is slecting between the audio playback and a white noise source when playing back 16 bit audio. The frequency of the square wave is proportional to the data rate at the time). Does anyone know how one might place a restriction on a PCM driver's DMA buffer that it not cross a (physical) 64k boundary? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
US$100 prize for adding ESS Audiodrive support to pcm
I have for a long time said to myself that I would take the documents available and hack together a pcm driver for the audio chip built into my Asus P5A machine, and never sat down and done it. So, rather than whine to myself about it, or whine about nobody else doing it, I'll put my money where my mouth is. PCI vendor id 0x125d, device id 0x1969. The first person to commit a working driver for it, or to submit to me a working driver for me to commit on their behalf, will be paid US$100. I reserve the right to judge whether the driver "is working," but I will at least demand that half-duplex recording and playback at all supported bitrates work, and that basic mixer functions work for pcm, line, aux, cd and mic (all as record sources or playback devices). The source code must be made available under the FreeBSD license (or a compatible one) that does not infringe on any other copyrights, and submissions must be made in good faith. At most, one prize will be awarded. Any code committed by me will, of course, have full credit given to the submitter and will not be deemed a work made for hire under copyright law. Accounts on a machine with this device running -current can be made available if necessary to other committers (sorry if this is unfair, but there's an issue of trust at work here). If US$100 seems cheap, I'm sorry. But the number is 5 times the price of an OSS license. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: US$100 prize for adding ESS Audiodrive support to pcm
The driver that was recently committed by Cameron Grant now appears to perform correct playback on the hardware I have available to me. I invite all ESS Solo chip owners to give it a try and let us know if it works for you. Recording does not yet work for me (and aparently neither record nor playback works for Cameron), however, so the prize remains available. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with 6-in-4 tunnels in 4.1-RC?
My -stable machine just turned deaf on its gif0 interface. I can see the encapsulated packets coming in and out and they look correct... 12:18:25.138253 205.178.90.194 204.123.2.236: 3ffe:1200:301b::1 3ffe:1001:1:f001::2: icmp6: echo request (encap) 12:18:25.191209 204.123.2.236 205.178.90.194: 3ffe:1001:1:f001::2 3ffe:1200:301b::1: icmp6: echo reply (encap) but the replies never make it into gif0, so far as I can see. /etc/rc.conf has: ipv6_enable="YES" ipv6_network_interfaces="lo0 de0" ipv6_prefix_de0="3ffe:1200:301b:0" ipv6_gateway_enable="YES" ipv6_static_routes="default" ipv6_route_default="default -interface gif0" ipv6_router_enable="YES" gif_interfaces="gif0" gifconfig_gif0="205.178.90.194 204.123.2.236" What happened? :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl interface for apm?
Warner Losh wrote:
In message [EMAIL PROTECTED] Wes Peters writes:
: Poul-Henning Kamp wrote:
:
: In message [EMAIL PROTECTED], [EMAIL PROTECTED] wri
: tes:
:
: So what does everyone think? Is it suitable to add a read only
: sysctl 'machdep.apm_powerstate' that reports either AC, nn%,
: or N/A ? Or should the format be numeric (999 = AC, =100 = battery %,
: -1 = N/A)? Or should we not bother? :-)
:
: yes it is suitable.
:
: Perhaps machdep.apm.powerstate, leaving room in the namespace for other
: apm parameters? Charging state and battery life leap immediately to
: mind.
No. DO NOT CALL IT APM. APM is i386 specific and is doing its best
to die off in favor acpi.
If you must call it apm, do *NOT* cause being on AC power to override
the batery %. These are two different things and should be reported
as such.
machdep.apm.battery:0..100 (for battery percentage)
machdep.apm.runtime:0.. (for the reported battery life remaining)
machdep.apm.ac: 0 1 (1 means we're running off AC)
machdep.apm.charging: 0 1
machdep.apm.batteries: 0.. (number of batteries apm says are there)
But why bother? The apm command gives you this already. :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
The "why bother" is easy -- one should not have to belong to group
operator to determine the current battery state. Too many things
already have to be sgid (at least) without making this another reason.
I took a middle ground. I have two ints, machdep.apm_battlevel
and machdep.apm_powerstate. The power state number is
-1 to 5 for unknown, critical, low, medium, high (which four imply
battery power), AC or charging (which two imply AC power).
These patches are actually against -stable, but I will get this
into -current shortly.
Suggestions as to how to correct the errors I probably made in
the sysctl interface are welcome. :-)
--- apm.c.orig Tue Feb 8 12:39:18 2000
+++ apm.c Mon Jul 17 10:47:13 2000
@@ -107,6 +107,65 @@
SYSCTL_INT(_machdep, OID_AUTO, apm_suspend_delay, CTLFLAG_RW, apm_suspend_delay, 1,
"");
SYSCTL_INT(_machdep, OID_AUTO, apm_standby_delay, CTLFLAG_RW, apm_standby_delay, 1,
"");
+static int apm_get_info(apm_info_t aip);
+
+/*
+ * 0-100 battery life remaining as percentage
+ * -1 unknown
+ */
+static int
+sysctl_apm_battlevel SYSCTL_HANDLER_ARGS
+{
+ int val;
+ struct apm_info stat;
+
+ if (apm_get_info(stat))
+ val=-1;
+ else {
+ if (stat.ai_batt_life100)
+ val=-1;
+ else
+ val=stat.ai_batt_life;
+ }
+ return sysctl_handle_int(oidp, val, sizeof(val), req);
+}
+
+/*
+ * 5 = battery charging (implies AC power)
+ * 4 = AC power
+ * 3 = battery high
+ * 2 = battery low
+ * 1 = battery critical
+ * -1 = unknown
+ */
+static int
+sysctl_apm_powerstate SYSCTL_HANDLER_ARGS
+{
+ int val;
+ struct apm_info stat;
+
+ if (apm_get_info(stat))
+ val=-1;
+ else {
+ if (stat.ai_batt_stat == 0)
+ val = 5;
+ else if (stat.ai_acline)
+ val = 4;
+ else if (stat.ai_batt_stat 3)
+ val=-1;
+ else
+ val=stat.ai_batt_stat;
+ }
+ return sysctl_handle_int(oidp, val, sizeof(val), req);
+}
+
+SYSCTL_PROC(_machdep, OID_AUTO, apm_battlevel, CTLTYPE_INT|CTLFLAG_RD, 0,
+ sizeof(sysctl_apm_battlevel), sysctl_apm_battlevel,
+ "I", "Current APM battery level");
+SYSCTL_PROC(_machdep, OID_AUTO, apm_powerstate, CTLTYPE_INT|CTLFLAG_RD, 0,
+ sizeof(sysctl_apm_powerstate), sysctl_apm_powerstate,
+ "I", "Current APM power state");
+
/*
* return 0 if the function successfull,
* return 1 if the function unsuccessfull,
Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
"Jeroen C. van Gelderen" wrote: [...] Since user authentication is needed by more than one program it should live in it's own process. Right now there is code duplication and it is impossible to change the authentication policy without messing with sshd. What we _really_ need is some mechanism to recognize the difference between a user program and a system library, with an eye towards granting privileges to trusted libraries without letting those privileges leak past the library in question. I don't claim that this is an _easy_ thing to do, nor that it is a particularly standard thing to do. But the mechanism of having some sort of daemon or service whose job it is to just do !strcmp(pw-pw_passwd,crypt(foo,pw-pw_passwd)) is, I think, kind of overkill. Perhaps some sort of syscall to change the euid that only works in privileged libraries would work. User authentication is only one example. There are many things that only root can do where letting non-root do the job is not dangerous, but granting non-root permission in a general way is. Another good example is daemons that must bind listening sockets 1024, but don't need root otherwise. The entire binary must be suid up to the bind, at which point the program may renounce the suid bit (setreuid(getuid(),getuid());). Wouldn't it be more secure if a library could selectively grant low ports to _selected_ non-suid programs (perhaps with a config file)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
Matthew Dillon wrote: [lost attribution. Nick wrote this] : :What we _really_ need is some mechanism to recognize the difference :between a user program and a system library, with an eye towards :granting privileges to trusted libraries without letting those privileges :leak past the library in question. Oh god, its MULTICS! Run! Run! Run for the hills! See? Final proof that those who don't know history are bound to repeat it. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Post-shutdown hook for UPS shutdown?
Mike Smith wrote: The canonical way to do this is actually to shudown and reboot. In the _startup_ phase, while the root filesystem is still mounted readonly, you check the UPS status. At this point, you have access to the disk in a read-only fashion, and you can power-off (or have the UPS die) at any time. By the way, for anyone interested, one way to achieve this if your UPS is too dumb to provide a "power good" signal is to take a 12vdc wall-wart and plug it into an _unprotected_ outlet. Connect this to a serial port, + to ground, - to DCD. Presto - that port's DCD signal now is a wall-power-good signal. You might optionally put a 1k resistor across the two pins to make sure that any filter caps bleed quickly off (a 12 ma load at 12 volts). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rexec as root
I would like to gather some opinions in regards to _very slightly_ backing off on rexec's security. rexec makes the following checks, and refuses to allow usage if any are true: uid == 0 password is blank user is in /etc/ftpusers I put it to everyone that the first and third checks are equivalent and redundant. Moreover, since the first check can be done by the third check (and is at install time by default) without recompiling rexecd, removing the first check results in no real loss of security, while slightly increasing flexibility for those who have some need for it. Yes, the r commands are deprecated. But they are still there, and I am all for allowing the administrator to decide to override defaults rather than forcing them to alter the source and recompile it. Comments? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPv6 Bridging don't work together
I have a filtering bridge that I am also trying to use as a 6to4 router. Alas, IPv6 does not appear to work correctly with the bridge. If I configure the interface on one side of the bridge, it is not ping6able by hosts on the other side. If I configure both sides with separate prefixes, then both of the prefixes show up on all of the hosts. I don't really care if I can bridge IPv6 or not, truth be told. With IPv6 the vast number of subnets makes it unnecessary to bridge. But I need to be able to either keep the two interfaces totally separate despite the bridging of other protocols (specifically IPv4) or I need bridging to work correctly. Either way. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPv4-IPv6 conversion suite?
I have just set up IPv6 on my network at home, and there was much rejoicing. :-) Now the problem is that legacy apps don't have v6 support. One idea I have floating around in my head is the idea of a socks-like combination of libc support and faith to allow IPv6-only networks to participate in ipv4 using faith as a proxy. Such a library would merely need a single input -- an IPV4PREFIX. It would take the socket(), connect(), etc calls for the AF_INET domain and turn them into AF_INET6 calls with the address being made out of the IPv4 input address and the IPV4PREFIX. With this in place, entire IPv6 networks could "hide" behind a single IPv4 address with which they could conduct IPv4 business, while using IPv6 natively. IMHO common deployment would speed the retirement of IPv4. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
XDR porting problems
in RELENG_4, /usr/src/include/rpc/xdr.h, there is... #ifdef _KERNEL typedef bool_t (*xdrproc_t) __P((XDR *, void *, u_int)); #else /* * XXX can't actually prototype it, because some take two args!!! */ typedef bool_t (*xdrproc_t) __P((/* XDR *, void *, u_int */)); #endif This causes heartburn for a program I'm trying to port. Specifically, compiling a .cxx says that I am using too many arguments. Changing the 2nd typedef to typedef bool_t (*xdrproc_t) __P((XDR *, void *, ...)); fixes this. I am not enough of a language pedant to understand all possible ramifications of this change. Can anyone suggest any alternatives? I dug around quite a bit and could find no way to compile the code in question without changing the system include files. If this is the right thing to do, I would like to commit it. If there is a better thing to do, I'd like to hear about it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RFC: if_wi.c bridging patch
I have had some wi cards for a while, and while I have managed to get
an Airport to work (a friend helped me out), I believe that adding wi
to the list of bridge compatible interfaces may be helpful.
According to the documentation, the IBSS mode of the driver doesn't
work. That's too bad, as in combination with this patch, you could
make your own "airport" this way. IBSS is desirable because it allows
power management mode to work on the BSS client machines. C'est la
guerre.
I don't have a wi in a position that is comfortable for me to test.
But if someone can verify that this works, I will commit it.
This is relative to RELENG_4.
--- if_wi.c.origThu Apr 13 16:36:37 2000
+++ if_wi.c Thu Apr 13 16:48:53 2000
@@ -102,6 +102,10 @@
#include net/bpf.h
+#ifdef BRIDGE
+#include net/bridge.h
+#endif
+
#include machine/if_wavelan_ieee.h
#include i386/isa/if_wireg.h
@@ -425,8 +429,31 @@
ifp-if_ipackets++;
/* Handle BPF listeners. */
- if (ifp-if_bpf) {
+ if (ifp-if_bpf)
bpf_mtap(ifp, m);
+
+#ifdef BRIDGE
+ if (do_bridge) {
+ struct ifnet *bdg_ifp;
+ bdg_ifp = bridge_in(m);
+ if (bdg_ifp == BDG_DROP) {
+ if (m)
+ m_free(m);
+ return; /* and drop */
+ }
+ if (bdg_ifp != BDG_LOCAL)
+ bdg_forward(m, bdg_ifp);
+ if (bdg_ifp != BDG_LOCAL bdg_ifp != BDG_BCAST
+ bdg_ifp != BDG_MCAST) {
+ if (m)
+ m_free(m);
+ return; /* and drop */
+ }
+ /* all others accepted locally */
+ }
+ else
+#endif
+ {
if (ifp-if_flags IFF_PROMISC
(bcmp(eh-ether_dhost, sc-arpcom.ac_enaddr,
ETHER_ADDR_LEN) (eh-ether_dhost[0] 1) == 0)) {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Is traditional unixes kernel really stable ?
Gustavo V G C Rios wrote: Why not starting a microkernel arch? IMHO the microkernel is the emperor's new clothes (so is OOP, but that, I suspect, I won't get quite so much agreement on). Context switching has been mentioned, but in addition to that, the real problem is that it really doesn't change anything. It may somewhat simplify a non-critical driver like a serial port or a mouse or the like, but if a SCSI HBA driver crashes, it's likely going to make life for the microkernel very hairy, just like it would a full kernel. And a driver bug can cause the hardware to wedge the machine whether the driver is in protected or user mode too. Most people who I talk to who bring up microkernel do it because they see the process of compiling a FreeBSD kernel and think that microkernels are somehow the opposite of that. If that's the case, they should believe that Solaris is a microkernel, which it patently is not. NT comes closer, with its rings of protection, but you can hardly call that a picture of stabiliy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
md_image compression?
I'm sort of thinking in my head about adding the ability for the md driver to handle gziped images. md's drvinit() looks like the perfect place to do this. if strcmp(type,"md_image_gzip") then gunzip the image and so on. Obviously this trades RAM for disk space. The target implementation is the i-opener - X terminal transmogrification. I think I can cram the whole thing into the 16M flash card, and with compression of that image, I can cram a lot more. To implement it, I have some questions: 1. Is there a way to de-allocate or otherwise reuse the original compressed image after the unzip is finished? 2. What is the best strategy for allocating the output image? malloc(9)? 3. This would effectively add libz to the kernel. Does anyone object, given the proviso that this whole mess would hide inside of an option (MD_PRELOAD_GZIP springs to mind)? Perhaps instead the md unzipper could be loaded as a module. The module could be thrown away using the same mechanism as #1 once the decompression is finished. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: upgrade issue from 2.2.x - 3.2
Ben Jackson wrote: I just did that upgrade (been with freebsd since 1.1!) and everything seems pretty smooth. I did a 2.2-3.1 upgrade on another machine so I'm probably glossing over some aout issues (mainly that you have to find them and move them into a separate directory). One thing that confused me for several days and I just figured out: sysctl moved from /usr/sbin to /sbin. I have /usr/sbin in my path first, so I was getting to old one. It almost works, but not quite. It only displays about 15 `kern.' variables and then quits. Perhaps the upgrade option should at least warn of that possibility (maybe obvious, but somewhat unexpected) or even include a list of files that once existed in FreeBSD but no longer do (to facilitate removing them). I'm thinking about digging out a 2.2.x install cd to build that list for myself. --Ben To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Whenever I do an upgrade, I always do an ls -alt on /modules, /sbin, /bin, /usr/bin, /usr/sbin, /usr/libexec (ignoring the a.out ld.so) and /usr/lib. The bottom of the list in each case (where bottom means a date significantly before the rest) needs to be analyzed and probably deleted. In the case of /usr/lib, old libraries probably can be moved into /usr/lib/compat (a.out ones go in /usr/lib/compat/a.out, of course). I always catch some stuff using this procedure. :-) I also end up hand-merging the backup of /etc made by the upgrade, /usr/src/etc for the version in question, and /etc to try and make it look as much like a fresh install with customizations as I can. I doubt that any reasonable programatic way to do this can be done, apart from what the upgrade already does. smime.p7s Description: S/MIME Cryptographic Signature
CFD: bogomips CPU performance metric
Linux generates a meric of CPU performance as a byproduct of calibrating a delay loop. We don't require doing any such thing, and so adding it would be purely cosmetic. However, I allege that cosmetic things aren't in and of themselves evil, so long as they don't break anything in the process. I would like to generate a number that will hopefully be reasonably compatible with the one Linux spits out. The best method I have come up with is to have a similar (the same?) count down loop in assembler. Have it count down from 1,000,000 and see how much nanotime() has gone by. NANSPERSEC/nansused = bogomips. A 1 bogomips machine will take an extra second to do this (anything likely to be even able to run FreeBSD should exceed 1 BM - yes, ha ha), and a kBM CPU can do it in 1 ms. Perhaps in the future a prescaler might be required, but this whole thing is just really chrome anyway. Would anyone scream and projectile-vomit if I added this to identcpu.c? S/MIME Cryptographic Signature
CFD: bogomips CPU performance metric
Linux generates a meric of CPU performance as a byproduct of calibrating a delay loop. We don't require doing any such thing, and so adding it would be purely cosmetic. However, I allege that cosmetic things aren't in and of themselves evil, so long as they don't break anything in the process. I would like to generate a number that will hopefully be reasonably compatible with the one Linux spits out. The best method I have come up with is to have a similar (the same?) count down loop in assembler. Have it count down from 1,000,000 and see how much nanotime() has gone by. NANSPERSEC/nansused = bogomips. A 1 bogomips machine will take an extra second to do this (anything likely to be even able to run FreeBSD should exceed 1 BM - yes, ha ha), and a kBM CPU can do it in 1 ms. Perhaps in the future a prescaler might be required, but this whole thing is just really chrome anyway. Would anyone scream and projectile-vomit if I added this to identcpu.c? smime.p7s Description: S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: Are you sure about this? Having constant p, g, x and y for every telnet client and server surely makes it much easier to attack? In theory you could probably pregenerate all of the arithmetic. Maybe we're not using the constant names the same way. In SRA the modulus and base are constants. I don't think that those being public helps an attacker too much. The client and server must agree on these values before you start an authentication, so at the very least a single failed authentication attempt would provide these values to an attacker anyway. And it's computationally too difficult to generate suitable values on the fly. Each side picks Xmine, each side passes Nmine=B^Xmine % m, each then computes K=B^(Nhis*Xmine) % m. That's straight DH, right? SRA then uses the common K to make a DES key to pass auth data from client to server. Simple. You can attack the protocol either by brute forcing DES, factoring the DH exchange, or with MiM. I regard each of these tasks as approximately equally difficult. I could hack SRA to use larger numbers, even pre generate them on the server, but that would break compatibility with existing SRA implementations (which do exist, believe it or not). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 15 Aug 1999, Dave Walton wrote: Great. Fire off a quick note to Bill Clinton asking if it's ok. grumble Um, I will have to make sure, but my understanding is that src/crypto on freefall (at least) is US-only, so that should be ok. Anyone who wants to grab the SRA stuff from that University in Germany and add it to an international equivalent would be welcome to do so. I can provide a server for interoperability testing (but I probably can't help any more than that). -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBN7dWz0CLGriVtPIREQKPOwCfV7/dsuLVWjm0HbX0g8tZdcQZPPsAn2qb 25Cov0asJ7cpG/rSiPyA8XKZ =RRup -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Dave Walton wrote: On 14 Aug 99, at 5:43, Nick Sayer wrote: Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Again, the problem is that there is administrative overhead - a separate password database is required. Yes, there is /etc/tpasswd to deal with. I guess what I should have said is that I'd love to see SRP integrated into FreeBSD (as PAM, perhaps?). Properly done, the various system utilities would keep passwd, master.passwd and tpasswd in sync, and SRP authentication/encryption would be available to telnet, ftp, or anything else. True enough. You'd have to force your users to run 'passwd' once as a conversion step, and you'd have to modify scripts like 'adduser' to set up the new format. (Disclaimer: Authentication and PAM are way outside of anything I know anything about, so I really have no idea what it would take to make that work.) Keep in mind, also, that as long as AUTHTYPE_SRP and AUTHTYPE_SRA are different numbers, both could be present. I would even conceed that SRP should be tried before SRA. But I'd sure as hell rather use SRA than nothing. Ok, Nick implements SRA for folks in heterogenous NIS environments, and Kris implements SRP for those of us without that restriction. How's that for a non-cryptographic compromise? :) I can commit SRA into src/crypto/telnet immediately, if it is appropriate to do so. Unfortunately, this whole discussion ignores one ugly problem: client availability. It's a chicken and egg problem. But I am sure that if we build it, they will come. But only if it comes by default and has no overhead and works with legacy systems -- that is, it is a no effort drop-in. People who type telnet will just magically see that their session is encrypted without them doing anything different. THAT'S the only way it will start to happen. smime.p7s Description: S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 15 Aug 1999, Dave Walton wrote: Great. Fire off a quick note to Bill Clinton asking if it's ok. grumble Um, I will have to make sure, but my understanding is that src/crypto on freefall (at least) is US-only, so that should be ok. Anyone who wants to grab the SRA stuff from that University in Germany and add it to an international equivalent would be welcome to do so. I can provide a server for interoperability testing (but I probably can't help any more than that). -BEGIN PGP SIGNATURE- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBN7dWz0CLGriVtPIREQKPOwCfV7/dsuLVWjm0HbX0g8tZdcQZPPsAn2qb 25Cov0asJ7cpG/rSiPyA8XKZ =RRup -END PGP SIGNATURE- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Whither makefiles for src/crypto/telnet/* ?
Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Again, the problem is that there is administrative overhead - a separate password database is required. It is certainly _also_ a candidate to be included (they can all live side by side), but it does not replace the need that SRA fills. SPK requires a separate database because the server needs to know what the password actually is, not just that the one that was typed is correct. Unix passwords are not suitable because you can't turn hamburger back into steak by running the grinder backwards. :-) When both sides of a conversation have a shared secret, you can assure mutual authentication in a way that is not possible with straight Diffie-Hellman. But Unix passwords can't be considered a shared secret because the server doesn't actually know what the password is. It merely knows when an attempt is correct. A workaround for this is to supply the password salt to the client early in an authentication protocol, then treat the encrypted password as a shared secret. That works, except that more and more unixes are starting to use non-portable crypt() procedures. The client has to have the same crypt() as the server in order for the authentication to succeed. Users with $x salts would not be able to log in from non-FreeBSD machines unless our crypt() was compiled into their telnet. S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Nick Sayer wrote: [...] SPK requires a separate database [...] I meant SRP. SRP is based on SPEKE, which is what I got it confused with. S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Fri, 13 Aug 1999, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. I got started on this, to the extent of storing the SRP data in the passwd file as an additional password crypt() method That will be incompatible with folks who, for example, use the old style passwords in a YP map in order to be compatible with other platforms in the same domain. As long as you require a shared secret there will be either extra overhead to maintain it (in a separate password database) or an exclusion of some platforms because of inabilities to generate the shared secret (because they have different crypt()s than we do). Not requiring a shared secret allows monkey-in-the-middle. But the goal here is to do better than nothing at all while not adding any administrative overhead. If you add overhead, people won't use it. SRA is a compromise between security and ease of use. "Compromise" is not a four letter word. S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Sat, 14 Aug 1999, Nick Sayer wrote: Kris Kennaway wrote: On Fri, 13 Aug 1999, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. I got started on this, to the extent of storing the SRP data in the passwd file as an additional password crypt() method That will be incompatible with folks who, for example, use the old style passwords in a YP map in order to be compatible with other platforms in the same domain. By definition you cannot get around the need to store additional authentication information to use SRP - it uses large integer mathematics "along the lines of" RSA public-key cryptography to authenticate the user securely, so it's not transparent as you correctly note. Using YP to share the password maps is problematic, since SRP "passwords" have a different format than other algorithms. I don't know enough about YP to speak on this, but if you can get away with sharing an arbitrary-length "password hash" over YP then all SRP-capable clients can use it. That's not the point, though - if you want to use legacy computer platforms, you have to expect to use legacy passwords. The point is that you can do so AND have an increase in security of communications. Is the result perfect? No. Is it better than sending it in the clear? Yes. Is it JUST AS EASY for everyone concerned as sending it in the clear? Yes. So it's just as easy to do a little as do nothing. Why, then, is it considered so horrible to have the option of doing a little? I haven't looked at the SRA algorithm, but it's not obvious to me how you can simultaneously provide a well-encrypted (against an attacker who is watching the setup phase) session, and at the same time only use the (traditional UNIX) password and hash. I would be happy to answer that. You do a traditional Diffie-Hellman. You use the resulting shared secret to send the username and password from client to server, DES encrypted. The resulting shared secret can also be used as a DES (or other) key for session encryption after you're done. It is vulnerable to MiM. I have said as such a dozen times now. It should be painfully obvious that plaintext sessions are vulnerable to a hell of a lot more than just that. At the best all you're doing is obfuscating the data stream, which becomes dangerous if people think of it as "encrypted telnet". Of course, I may well be wrong - do you have a pointer to a paper describing the SRA algorithm? No, but I have the source and have made it available to anyone inside the US. I have also stated that it is available outisde the US, so anyone could use their favorite search engine and get it. As long as you require a shared secret there will be either extra overhead to maintain it (in a separate password database) or an exclusion of some platforms because of inabilities to generate the shared secret (because they have different crypt()s than we do). Not requiring a shared secret allows monkey-in-the-middle. But the goal here is to do better than nothing at all while not adding any administrative overhead. If you add overhead, people won't use it. With a SRP-capable client and server, the client need know nothing other than the password entered by the user. Agreed. The server is configured at passwd(8) time. This is the beauty of SRP - it IS transparent, while at the same time being "secure" in the ways which a plaintext or CHAP authentication is not (I don't have references to the papers which describe the benefits of SRP handy, but I could find them if needed). I will easily conceed that SRP is more secure than SRA. But I disagree that it is as transparent as you claim. S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even that, how many people reading this e-mail use it? Once you have authenticated, you can use that to negotiate a session key, which can be used to encrypt the remainder of the session. Same with SRA. If you have a non-SRP client, you can still authenticate against the server using a plaintext password, and treating the server-side data as a fancy password hash, but you obviously lose all the benefits (as well as compromising your password if you use it from both types of client) There are other costs, however. Your SRP equipped host cannot participate in a heterogenous YP environment without maintaining SRP passwords separately (and killing the purpose of YP in the process). Even in a homogenous YP environment you have to synchronize valuse of N and g (according to the Stanford web site) throughout the organization. SRA is a compromise between security and ease of use. "Compromise" is not a four letter word. Many would argue that in
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Sat, 14 Aug 1999, Sheldon Hearn wrote: On Fri, 13 Aug 1999 23:42:48 MST, "Dave Walton" wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Cool, another non-exportable system available to US users only. :-) Not true: SRP used for authentication only does exponentiation and modulo operation on large integers..no cryptographic primitives, so it's freely exportable. The SRP distribution does also contain code which encrypts the data stream after authentication, which is restricted from export, but on the other hand it's also not hard to put back. SRA is not in the same boat there. It uses Diffie-Hellmen to obtain a shared secret and then passes the authentication information from client to server with DES. S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Sat, 14 Aug 1999, Nick Sayer wrote: That's not the point, though - if you want to use legacy computer platforms, you have to expect to use legacy passwords. The point is that you can do so AND have an increase in security of communications. Is the result perfect? No. Is it better than sending it in the clear? Yes. Is it JUST AS EASY for everyone concerned as sending it in the clear? Yes. So it's just as easy to do a little as do nothing. Why, then, is it considered so horrible to have the option of doing a little? Because the end-users won't understand this, and use the system as if it was perfect, when in fact it provides few guarantees. The only thing it doesn't guarantee is that you won't get hit by MiM, and that someone won't spend a couple days to try and factor the DH exchange. It does guarantee (to the same strength as SRP) that your session won't get hijacked or sniffed. From where I sit you're not giving SRA enough credit for what it is capable of. I haven't looked at the SRA algorithm, but it's not obvious to me how you can simultaneously provide a well-encrypted (against an attacker who is watching the setup phase) session, and at the same time only use the (traditional UNIX) password and hash. I would be happy to answer that. You do a traditional Diffie-Hellman. You use the resulting shared Where do you store the keys, or do you generate them dynamically? The latter would take time to verify primality. If by "keys" you mean the DH generator and such, they are constants in the code at present. It is possible to extend the protocol in such a way as to pass them from server to client, but at present it does not do this. Having them be constant does not significantly weaken DH. If they weren't, you'd have to pass them from the server at session start. This is also essentially the way SSL does it, without some of the protocol overhead, and without trust verification of certificates. Sort of. SSL uses RSA to encrypt some data, because it requires the server to have a key pair (and the server public key must be certified). secret to send the username and password from client to server, DES encrypted. The resulting shared secret can also be used as a DES (or other) key for session encryption after you're done. It is vulnerable to MiM. I have said as such a dozen times now. Yup. It should be painfully obvious that plaintext sessions are vulnerable to a hell of a lot more than just that. I agree. The server is configured at passwd(8) time. This is the beauty of SRP - it IS transparent, while at the same time being "secure" in the ways which a plaintext or CHAP authentication is not (I don't have references to the papers which describe the benefits of SRP handy, but I could find them if needed). I will easily conceed that SRP is more secure than SRA. But I disagree that it is as transparent as you claim. Because it does not interoperate with legacy servers over NIS? Any other reasons? If you're saying that you're going to have a new format of the second field of the master passwd file ($3$[^:]* ?), then I suppose the only other one left is having to convert legacy password files and manage the N and g values that SRP requires. You'll have to fix things that add users to have them default to the new scheme. And don't sniff at breaking NIS. Most sites I deal with use it. And I don't know of any site that uses NIS that isn't heterogenous, which requires the legacy password format. S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even that, how many people reading this e-mail use it? One-time passwords have their own usability problems which make them not a general-purpose solution. There are other costs, however. Your SRP equipped host cannot participate in a heterogenous YP environment without maintaining SRP passwords separately (and killing the purpose of YP in the process). Even in a homogenous YP environment you have to synchronize valuse of N and g (according to the Stanford web site) throughout the organization. In my scheme I distribute these as part of the password "hash". N and g are both public values known to both client and server(s). SRP has them in configuration files. They have to be set up. I also have prototype code which can store multiple password hashes in the password file, and retrieves "secondaries" in a new field in struct passwd. You could conceivably set it up to keep a DES password in sync with the SRP one, and distribute only the DES over NIS. I don't know how extensible NIS is, but maybe we could hide the other hashes in there as well for those who understand them. NIS is not very extensible. It has too much history. Many would argue that in the language of cryptography and data encryption, the word "compromise&q
Re: Whither makefiles for src/crypto/telnet/* ?
Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Again, the problem is that there is administrative overhead - a separate password database is required. It is certainly _also_ a candidate to be included (they can all live side by side), but it does not replace the need that SRA fills. SPK requires a separate database because the server needs to know what the password actually is, not just that the one that was typed is correct. Unix passwords are not suitable because you can't turn hamburger back into steak by running the grinder backwards. :-) When both sides of a conversation have a shared secret, you can assure mutual authentication in a way that is not possible with straight Diffie-Hellman. But Unix passwords can't be considered a shared secret because the server doesn't actually know what the password is. It merely knows when an attempt is correct. A workaround for this is to supply the password salt to the client early in an authentication protocol, then treat the encrypted password as a shared secret. That works, except that more and more unixes are starting to use non-portable crypt() procedures. The client has to have the same crypt() as the server in order for the authentication to succeed. Users with $x salts would not be able to log in from non-FreeBSD machines unless our crypt() was compiled into their telnet. smime.p7s Description: S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Nick Sayer wrote: [...] SPK requires a separate database [...] I meant SRP. SRP is based on SPEKE, which is what I got it confused with. smime.p7s Description: S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
Mark Murray wrote: Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, The commerce department says otherwise. It's still not exportable even if it interfaces to encryption code. smime.p7s Description: S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
Narvi wrote: On Sat, 14 Aug 1999, Mark Murray wrote: Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). This makes the most sense. Thrash it out as a port, and if that works, we can bring it into both repositories. Why not just wait and bring the openssl library in? If it even talks to openssl, it's not exportable. A new telnet authentifications method that just we used is not terribly usefull. A. It's not new. B. Not just we use it. It may not be tremendously widespread, but I assert that just as many people use SRA as use SRP or SSLtelnet (probably a lot more people use ssh). smime.p7s Description: S/MIME Cryptographic Signature
Re: Using legacy sysinstall to upgrade live system
dannyman wrote: Uhmmm, what if we don't have a floppy drive? Do the old SunOS trick: 1. Boot single user. 2. dd the boot floppy image to your swap partition. 3. Reboot, specifying wd(0,b)/kernel (or appropriate). ? smime.p7s Description: S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Fri, 13 Aug 1999, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. I got started on this, to the extent of storing the SRP data in the passwd file as an additional password crypt() method That will be incompatible with folks who, for example, use the old style passwords in a YP map in order to be compatible with other platforms in the same domain. As long as you require a shared secret there will be either extra overhead to maintain it (in a separate password database) or an exclusion of some platforms because of inabilities to generate the shared secret (because they have different crypt()s than we do). Not requiring a shared secret allows monkey-in-the-middle. But the goal here is to do better than nothing at all while not adding any administrative overhead. If you add overhead, people won't use it. SRA is a compromise between security and ease of use. Compromise is not a four letter word. smime.p7s Description: S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Sat, 14 Aug 1999, Nick Sayer wrote: Kris Kennaway wrote: On Fri, 13 Aug 1999, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. I got started on this, to the extent of storing the SRP data in the passwd file as an additional password crypt() method That will be incompatible with folks who, for example, use the old style passwords in a YP map in order to be compatible with other platforms in the same domain. By definition you cannot get around the need to store additional authentication information to use SRP - it uses large integer mathematics along the lines of RSA public-key cryptography to authenticate the user securely, so it's not transparent as you correctly note. Using YP to share the password maps is problematic, since SRP passwords have a different format than other algorithms. I don't know enough about YP to speak on this, but if you can get away with sharing an arbitrary-length password hash over YP then all SRP-capable clients can use it. That's not the point, though - if you want to use legacy computer platforms, you have to expect to use legacy passwords. The point is that you can do so AND have an increase in security of communications. Is the result perfect? No. Is it better than sending it in the clear? Yes. Is it JUST AS EASY for everyone concerned as sending it in the clear? Yes. So it's just as easy to do a little as do nothing. Why, then, is it considered so horrible to have the option of doing a little? I haven't looked at the SRA algorithm, but it's not obvious to me how you can simultaneously provide a well-encrypted (against an attacker who is watching the setup phase) session, and at the same time only use the (traditional UNIX) password and hash. I would be happy to answer that. You do a traditional Diffie-Hellman. You use the resulting shared secret to send the username and password from client to server, DES encrypted. The resulting shared secret can also be used as a DES (or other) key for session encryption after you're done. It is vulnerable to MiM. I have said as such a dozen times now. It should be painfully obvious that plaintext sessions are vulnerable to a hell of a lot more than just that. At the best all you're doing is obfuscating the data stream, which becomes dangerous if people think of it as encrypted telnet. Of course, I may well be wrong - do you have a pointer to a paper describing the SRA algorithm? No, but I have the source and have made it available to anyone inside the US. I have also stated that it is available outisde the US, so anyone could use their favorite search engine and get it. As long as you require a shared secret there will be either extra overhead to maintain it (in a separate password database) or an exclusion of some platforms because of inabilities to generate the shared secret (because they have different crypt()s than we do). Not requiring a shared secret allows monkey-in-the-middle. But the goal here is to do better than nothing at all while not adding any administrative overhead. If you add overhead, people won't use it. With a SRP-capable client and server, the client need know nothing other than the password entered by the user. Agreed. The server is configured at passwd(8) time. This is the beauty of SRP - it IS transparent, while at the same time being secure in the ways which a plaintext or CHAP authentication is not (I don't have references to the papers which describe the benefits of SRP handy, but I could find them if needed). I will easily conceed that SRP is more secure than SRA. But I disagree that it is as transparent as you claim. S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even that, how many people reading this e-mail use it? Once you have authenticated, you can use that to negotiate a session key, which can be used to encrypt the remainder of the session. Same with SRA. If you have a non-SRP client, you can still authenticate against the server using a plaintext password, and treating the server-side data as a fancy password hash, but you obviously lose all the benefits (as well as compromising your password if you use it from both types of client) There are other costs, however. Your SRP equipped host cannot participate in a heterogenous YP environment without maintaining SRP passwords separately (and killing the purpose of YP in the process). Even in a homogenous YP environment you have to synchronize valuse of N and g (according to the Stanford web site) throughout the organization. SRA is a compromise between security and ease of use. Compromise is not a four letter word. Many would argue that in the language of cryptography and data encryption, the word compromise
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Sat, 14 Aug 1999, Sheldon Hearn wrote: On Fri, 13 Aug 1999 23:42:48 MST, Dave Walton wrote: If you really want to work on an encrypted telnet, check out The Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). I'd love to see SRP integrated into the FreeBSD telnet/telnetd. Cool, another non-exportable system available to US users only. :-) Not true: SRP used for authentication only does exponentiation and modulo operation on large integers..no cryptographic primitives, so it's freely exportable. The SRP distribution does also contain code which encrypts the data stream after authentication, which is restricted from export, but on the other hand it's also not hard to put back. SRA is not in the same boat there. It uses Diffie-Hellmen to obtain a shared secret and then passes the authentication information from client to server with DES. smime.p7s Description: S/MIME Cryptographic Signature
Re: Whither makefiles for src/crypto/telnet/* ?
Kris Kennaway wrote: On Sat, 14 Aug 1999, Nick Sayer wrote: That's not the point, though - if you want to use legacy computer platforms, you have to expect to use legacy passwords. The point is that you can do so AND have an increase in security of communications. Is the result perfect? No. Is it better than sending it in the clear? Yes. Is it JUST AS EASY for everyone concerned as sending it in the clear? Yes. So it's just as easy to do a little as do nothing. Why, then, is it considered so horrible to have the option of doing a little? Because the end-users won't understand this, and use the system as if it was perfect, when in fact it provides few guarantees. The only thing it doesn't guarantee is that you won't get hit by MiM, and that someone won't spend a couple days to try and factor the DH exchange. It does guarantee (to the same strength as SRP) that your session won't get hijacked or sniffed. From where I sit you're not giving SRA enough credit for what it is capable of. I haven't looked at the SRA algorithm, but it's not obvious to me how you can simultaneously provide a well-encrypted (against an attacker who is watching the setup phase) session, and at the same time only use the (traditional UNIX) password and hash. I would be happy to answer that. You do a traditional Diffie-Hellman. You use the resulting shared Where do you store the keys, or do you generate them dynamically? The latter would take time to verify primality. If by keys you mean the DH generator and such, they are constants in the code at present. It is possible to extend the protocol in such a way as to pass them from server to client, but at present it does not do this. Having them be constant does not significantly weaken DH. If they weren't, you'd have to pass them from the server at session start. This is also essentially the way SSL does it, without some of the protocol overhead, and without trust verification of certificates. Sort of. SSL uses RSA to encrypt some data, because it requires the server to have a key pair (and the server public key must be certified). secret to send the username and password from client to server, DES encrypted. The resulting shared secret can also be used as a DES (or other) key for session encryption after you're done. It is vulnerable to MiM. I have said as such a dozen times now. Yup. It should be painfully obvious that plaintext sessions are vulnerable to a hell of a lot more than just that. I agree. The server is configured at passwd(8) time. This is the beauty of SRP - it IS transparent, while at the same time being secure in the ways which a plaintext or CHAP authentication is not (I don't have references to the papers which describe the benefits of SRP handy, but I could find them if needed). I will easily conceed that SRP is more secure than SRA. But I disagree that it is as transparent as you claim. Because it does not interoperate with legacy servers over NIS? Any other reasons? If you're saying that you're going to have a new format of the second field of the master passwd file ($3$[^:]* ?), then I suppose the only other one left is having to convert legacy password files and manage the N and g values that SRP requires. You'll have to fix things that add users to have them default to the new scheme. And don't sniff at breaking NIS. Most sites I deal with use it. And I don't know of any site that uses NIS that isn't heterogenous, which requires the legacy password format. S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even that, how many people reading this e-mail use it? One-time passwords have their own usability problems which make them not a general-purpose solution. There are other costs, however. Your SRP equipped host cannot participate in a heterogenous YP environment without maintaining SRP passwords separately (and killing the purpose of YP in the process). Even in a homogenous YP environment you have to synchronize valuse of N and g (according to the Stanford web site) throughout the organization. In my scheme I distribute these as part of the password hash. N and g are both public values known to both client and server(s). SRP has them in configuration files. They have to be set up. I also have prototype code which can store multiple password hashes in the password file, and retrieves secondaries in a new field in struct passwd. You could conceivably set it up to keep a DES password in sync with the SRP one, and distribute only the DES over NIS. I don't know how extensible NIS is, but maybe we could hide the other hashes in there as well for those who understand them. NIS is not very extensible. It has too much history. Many would argue that in the language of cryptography and data encryption, the word compromise has only one meaning. So you would rather that plaintext
Re: SRA+IDEA Telnet
Narvi wrote: How exactly do you plan to get this to the FreeBSD internationsl server that has the crypto repository? The short answer is that I don't. Unfortunately the trick that PGP used of publishing it in a book and exporting that won't work anymore, because I believe the commerce department now says that source code printed in a book that can be scanned and OCRed is, in fact, "machine readable" and unexportable. I originally obtained SRA code from a University in Germany. I obtained my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if 0'ed out stuff that's not needed. However, SRA is perfectly able to supply a compatable DES encryption key, so you can just add SRA to telnet and have SRA+DES. In fact, given that SRA isn't all that hard to break, one could argue that DES probably good enough (I hear it now -- if SRA isn't that hard to break, why bother? Answer: Because it's harder to break than plaintext. Factoring SRA would take a few days. Just watching for login: and password: takes nothing). I obtained the Makefiles for libtelnet, telnetd and telnet from the /usr/src/secure Attic and modified them so that they would enable encryption, authentication, SRA and DES (after adding SRA code, of course). I can discuss what I did with non-US citizens only in broad terms like the above. I can't assist and I can't provide source. The good news is that I believe the Bernstein case is headed finally for the Supreme Court and if all goes well source code may well be exempted from export regulations by deeming it protected speech. S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
Kris Kennaway wrote: On Fri, 13 Aug 1999, Nick Sayer wrote: I originally obtained SRA code from a University in Germany. I obtained my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if 0'ed out stuff that's not needed. Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). Alas, the commerce department says that even code that has no cryptography in itself, but that _interfaces_ to a crypto library is unexportable. As an example, I have a hack for pine that interfaces it to Openssl (the pine4+ssl port). That code is unexportable even though it talks to a library that talks to a crypto library. This despite the fact that it is distributed separately from the crypto itself. The same applies to mod_ssl (at least when it is present within the US). You can't pass that around even though it does no encryption by itself at all (the fact that it may be available outside the US doesn't matter either. You still can't export it even if it was originally IMported for it to get here in the first place). Yes, it sucks, and no, I am not making this up. I'm not sure what functionality this provides above something like SSLtelnet (in ports) or ssh, though. Probably much easier for folks to just use those. The whole point is to have the default system come with something better than plaintext logins that has no administrative overhead. If the default telnet/telnetd (in the DES distribution) had this functionality, it would end up being far more automatic than having to go and build and install ANY alternative in the ports or having to set up either Kerberos or S/key. I use and am a big fan of SSH. But I had to install and configure it. If we're ever going to reach the day when cryptographic security is so routine we don't even think about it, we have to start having it present _by default_. Kris S/MIME Cryptographic Signature
SRA+IDEA Telnet
Ok. I have put up a rough cut of my proposed src/crypto/telnet stuff with SRA authentication and IDEA encryption. It requires the libutil from 3.2 (or better), but it appears to work pretty well. Please don't download it if you're outside the US. But if you are in the US, you can grab it from ftp://ftp.kfu.com/pub/sra-idea.FreeBSD-32.tgz Move your existing /usr/src/crypto/telnet out of the way and unpack the tgz into /usr/src/crypto. Then cd into telnet and make. In particular, anyone who sees any stupid stuff in the Makefiles (I had to guess a lot) or anything that would break existing (kerberos) functionality, please let me know. It seems to me, though, that since there were no Makefiles in there before the kerberos stuff must be using its own Makefiles with these source files or some such magic. smime.p7s Description: S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
Narvi wrote: How exactly do you plan to get this to the FreeBSD internationsl server that has the crypto repository? The short answer is that I don't. Unfortunately the trick that PGP used of publishing it in a book and exporting that won't work anymore, because I believe the commerce department now says that source code printed in a book that can be scanned and OCRed is, in fact, machine readable and unexportable. I originally obtained SRA code from a University in Germany. I obtained my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if 0'ed out stuff that's not needed. However, SRA is perfectly able to supply a compatable DES encryption key, so you can just add SRA to telnet and have SRA+DES. In fact, given that SRA isn't all that hard to break, one could argue that DES probably good enough (I hear it now -- if SRA isn't that hard to break, why bother? Answer: Because it's harder to break than plaintext. Factoring SRA would take a few days. Just watching for login: and password: takes nothing). I obtained the Makefiles for libtelnet, telnetd and telnet from the /usr/src/secure Attic and modified them so that they would enable encryption, authentication, SRA and DES (after adding SRA code, of course). I can discuss what I did with non-US citizens only in broad terms like the above. I can't assist and I can't provide source. The good news is that I believe the Bernstein case is headed finally for the Supreme Court and if all goes well source code may well be exempted from export regulations by deeming it protected speech. smime.p7s Description: S/MIME Cryptographic Signature
Re: SRA+IDEA Telnet
Kris Kennaway wrote: On Fri, 13 Aug 1999, Nick Sayer wrote: I originally obtained SRA code from a University in Germany. I obtained my implementation of IDEA from PGP. In fact, I used idea.[ch] and #if 0'ed out stuff that's not needed. Couldn't you work the code so it obtains all its' encryption functions from an external library, such as the system's libdes? That would let you export the code, since it doesn't provide any encryption functions itself, and international people could use the international DES library (for other encryption algorithms, pick a freely available implmenetation such as the one from openssl). Alas, the commerce department says that even code that has no cryptography in itself, but that _interfaces_ to a crypto library is unexportable. As an example, I have a hack for pine that interfaces it to Openssl (the pine4+ssl port). That code is unexportable even though it talks to a library that talks to a crypto library. This despite the fact that it is distributed separately from the crypto itself. The same applies to mod_ssl (at least when it is present within the US). You can't pass that around even though it does no encryption by itself at all (the fact that it may be available outside the US doesn't matter either. You still can't export it even if it was originally IMported for it to get here in the first place). Yes, it sucks, and no, I am not making this up. I'm not sure what functionality this provides above something like SSLtelnet (in ports) or ssh, though. Probably much easier for folks to just use those. The whole point is to have the default system come with something better than plaintext logins that has no administrative overhead. If the default telnet/telnetd (in the DES distribution) had this functionality, it would end up being far more automatic than having to go and build and install ANY alternative in the ports or having to set up either Kerberos or S/key. I use and am a big fan of SSH. But I had to install and configure it. If we're ever going to reach the day when cryptographic security is so routine we don't even think about it, we have to start having it present _by default_. Kris smime.p7s Description: S/MIME Cryptographic Signature
Whither makefiles for src/crypto/telnet/* ?
A long time ago I got some kinky modifications to telnet from a place in Germany the purpose of which was to encrypt telnet sessions. It did a Diffie-Hellman up front and used the common secret as a DES key sort of the way Kerberos does. It was called SRA telnet. It was vulnerable to monkey-in-the-middle, but it was better than nothing and unlike other encrypted session systems it had NO administrative overhead. I also added IDEA as an alternative encryption method just to sort of up the ante a bit. At one point I seem to remember that the cryto telnet sources sort of got combined inexorably with Kerberos, which made the idea of adding SRA in order to get a standalone encrypted telnet to be standard-issue sort of die. But today, just out of curiosity, I decided to see if it would be possible to resurrect the idea. In the scrypto section, I see that the telnet stuff is set aside nicely in its own spot. I was able to add my patches just fine, but it appears that the Makefiles are somewhere else. Maybe in with the kerberos stuff or something? Does anyone know how telnet actually gets built when you want a telnet/telnetd that uses encryption? I would once again like to add SRA to telnet/telnetd. There is something to be said for having something reasonably secure in the default (at least for the domestic audience) distribution. Yes, we can all go add the ssh port, but having an encrypted telnet work right out of the box is a good thing. So I can pretty easily turn this into something that can be added right into src/crypto/telnet, but I need to find out about the Makefile issue. Can anyone help? Thanks in advance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Whither makefiles for src/crypto/telnet/* ?
A long time ago I got some kinky modifications to telnet from a place in Germany the purpose of which was to encrypt telnet sessions. It did a Diffie-Hellman up front and used the common secret as a DES key sort of the way Kerberos does. It was called SRA telnet. It was vulnerable to monkey-in-the-middle, but it was better than nothing and unlike other encrypted session systems it had NO administrative overhead. I also added IDEA as an alternative encryption method just to sort of up the ante a bit. At one point I seem to remember that the cryto telnet sources sort of got combined inexorably with Kerberos, which made the idea of adding SRA in order to get a standalone encrypted telnet to be standard-issue sort of die. But today, just out of curiosity, I decided to see if it would be possible to resurrect the idea. In the scrypto section, I see that the telnet stuff is set aside nicely in its own spot. I was able to add my patches just fine, but it appears that the Makefiles are somewhere else. Maybe in with the kerberos stuff or something? Does anyone know how telnet actually gets built when you want a telnet/telnetd that uses encryption? I would once again like to add SRA to telnet/telnetd. There is something to be said for having something reasonably secure in the default (at least for the domestic audience) distribution. Yes, we can all go add the ssh port, but having an encrypted telnet work right out of the box is a good thing. So I can pretty easily turn this into something that can be added right into src/crypto/telnet, but I need to find out about the Makefile issue. Can anyone help? Thanks in advance. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Porting strategy - pine4 + SSL
I have made a preliminary patch (hack?) to add SSL to pine (it's like
clicking the 'server requires secure connection' box - POP or IMAP over
SSL).
The pine4 port is fairly involved. Adding my stuff is almost downright
trivial. It amounts to adding
BUILD_DEPENDS= ${PREFIX}/lib/libssl.a:${PORTSDIR}/security/SSLeay \
${PREFIX}/lib/libcrypto.a:${PORTSDIR}/security/SSLeay \
${PREFIX}/lib/libRSAglue.a:${PORTSDIR}/security/SSLeay \
${PREFIX}/lib/librsaref.a:${PORTSDIR}/security/rsaref
RESTRICTED= Contains cryptography - no export from US
DISTFILES+= pine4+ssl-1.0
MASTER_SITES+= ftp://ftp.kfu.com/pub/
(the pine4+ssl-1.0.tar.gz file isn't there yet. :-) )
and modifying the Makefile to add EXTRAAUTHENTICATORS=ssl to the end
of the build command.
How should I do this? Should I copy the pine4 port entirely?
Should I modify the existing pine4 adding conditional stuff to
handle ssl? Can someone suggest a hackish way to piggyback onto
the existing pine4 port with a new port consisting only of the
steps above, but preserving the steps of the original port?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
