Date: Fri, 27 Mar 1998 18:43:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: software@kew.com (Drew Derbyshire - UUPC/extended software support) Cc: spork@super-g.com, hackers@FreeBSD.ORG Subject: Re: S/Key interfaces export restricted? Message-ID: <199803271843.LAA25621@usr07.primenet.com> In-Reply-To: <351BA486.75FB2644@kew.com> from "Drew Derbyshire - UUPC/extended software support" at Mar 27, 98 08:07:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I'm hacking one-timer passwords (S/Key) into popper for limited > > > road work; if the s/key interface is not export restricted, I'll > > > be happy to submit the patch back into the port collection (and > > > to the original authors, if they accept such input). The > > > changes will, of course, be "#ifdef SKEY". > > spork wrote: > > Before you do this, you might want to check qpooper, erm qpopper. While > > it can be a bit wacky at times with bulletin delivery, it includes s/key > > support if built from the port: > > I didn't know that -- clearly, I didn't look deep enough. I saw it had APOP > support, which is the standard, but didn't notice the S/Key. > > > -|super-g|-$ telnet pop.inch.com 110 > > Trying 207.240.140.101... > > Connected to pop.inch.com. > > Escape character is '^]'. > > +OK QPOP (version 2.4b2) at arutam.inch.com starting. > > For reasons which now escape me, I hacked straight 2.4, not the beta, so maybe > a change was made in between. > > > <27325.890940269@arutam.inch.com> > > user spork > > +OK s/key 86 ut16018 > > Unfortunately, I may *still* need to hack the bloody thing. The client is > Netscape Communicator, which definitely doesn't understand APOP or (it > appears) S/key, and so the "bad password" message in pop_pass.c needs to > include the s/key challenge for the user (since Netscape only reports error > messages, not OK responses.) Maybe that was fixed in the beta as well. Before going too much farther, you should read about the POP "AUTH" command in RFC1734. You can get a copy at: http://www.imc.org/rfc1734 The AUTH command is the correct way to add support for authentication types *other* than USER/PASS or APOP. You may also want to look at the existing CRAM-MD5 extension, which is described in RFC2195: http://www.imc.org/rfc2195 You may also want to look at RFC2078 (GSSAPI) and RFC2222 (SASL), which deal with generalizing the authentication API. Specifically, there is alread a registration for SKEY for SASL, which is described in the context of an IMAP session in RFC2222, section 7.3: http://www.imc.org/rfc2222 The IANA registered types are updated at: ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms You should notice that the SKEY registration is "owned" by Netsacpe: John G. Myers <jgmyers@netscape.com> So at a minimum, there's probably already a plugin for Netscape to support this. In general, if you can't find a standard for doing something, you're probably not looking hard enough. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803271843.LAA25621>