Subject: [BEEPwg] Beepcore-C Released at SourceForge

From: "Kristopher Magnusson" <[email-masked]>
Date: Wed, 15 Aug 2001 20:06:58 -0700

15 August 2001, Santa Rosa, CA--Invisible Worlds published Beepcore-C, an implementation of the BEEP framework written in the C language. Beepcore-C is available for immediate CVS access at http://sourceforge.net/projects/beepcore-c. Beepcore-C tarballs will be available for download soon.

Beepcore-C includes profiles for TLS, SASL/Anon, and SASL/OTP. Beepcore-C supports Linux and Solaris as well as Windows NT/2000. Beepcore-C ships as a library and can support environments such as operating system kernels, daemons, and web servers and browsers. Beepcore-C also includes C++ wrappers. And as usual, Beepcore-C ships with full source code covered by the Blocks Public License.

Invisible Worlds acknowledges the support of NeuStar in the development of Beepcore-C, which will serve as the primary communications engine for the NeuLevel "Dot-Biz" registry. Thanks, NeuStar!

......... kris

Kris Magnusson <[email-masked]>
Invisible Worlds, Inc. (http://invisible.net/)

---

From: Chris Newman <[email-masked]>
Date: Fri, 17 Aug 2001 15:16:43 -0700

--On Wednesday, August 15, 2001 20:06 -0700 Kristopher Magnusson 
<[email-masked]> wrote:
> Beepcore-C includes profiles for TLS, SASL/Anon, and SASL/OTP. Beepcore-C
> supports Linux and Solaris as well as Windows NT/2000. Beepcore-C ships
> as a library and can support environments such as operating system
> kernels, daemons, and web servers and browsers. Beepcore-C also includes
> C++ wrappers. And as usual, Beepcore-C ships with full source code
> covered by the Blocks Public License.

Cool.  Someone actually implemented my SASL OTP draft!  I never did more 
than an on-the-wire prototype, since I work on email protocols where OTP 
just isn't practical (due to short-lived connections in POP/SMTP or 
parallel connections from same user in IMAP).

Any plans to implement SASL/DIGEST-MD5 (which I consider the most important 
hash-based authentication mechanism)?

Perhaps integrate with the open-source SASL C library from CMU?
   <ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/>
Then you can share compatible authentication plug-ins.

		- Chris

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Darren New <[email-masked]>
Date: Fri, 17 Aug 2001 17:55:12 -0700

Chris Newman wrote:
> Cool.  Someone actually implemented my SASL OTP draft! 

Actually, only the hex: part is implemented. No word: or init-hex: or
init-word: yet.

> I never did more

Heh. That would explain why I had to do it myself. :-) I kept thinking
"how can this be an RFC with no implementations out there anywhere?" I
think OPIE is out there too, actually.
 
> hash-based authentication mechanism)?

I think this one changes the sizes of packets, which is a little
problematic in our environment right now. It would take more
infrastructure in our library.
 
> Then you can share compatible authentication plug-ins.

We looked at this too. Unfortunately, this library is undergoing a
restructuring right now, changing the internal APIs. The previous
version was undocumented, and the new version is unstable *and*
undocumented, so I didn't really want to sink a lot of time into putting
OTP into it at this time.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. [email-masked]
           When was sliced bread invented?
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: "Zane Thomas" <[email-masked]>
Date: Fri, 17 Aug 2001 18:29:28 -0700

Kristopher,

> covered by the Blocks Public License.

Thanks!

I've been browsing the code a bit but I don't see where "Mapping the BEEP
Core onto TCP" http://www.ietf.org/rfc/rfc3081.txt?number=3081 is
implemented.  Did you do that, or do you feel it is unnecessary and/or
aviodable?

Zane

---

From: "wmills at utah" <[email-masked]>
Date: Fri, 17 Aug 2001 20:41:29 -0700

Zane,

In this implemetation the transport mapping is pretty tightly coupled with
the rfc3080
pieces in some ways.  The handling of IO on the tcp connection is located in

    .../beepcore-c/threaded-os/transport/

in the files

    fpoll.c
    fpollmgr.c
    fiostate.c

What is tightly coupled is the handling/generation of the SEQ messages,
which is
managed in

    .../beepcore-c/core/generic/CBEEP.c

along with channel management and message framing.  At the moment the
interface
between the IO routines and the BEEP core routines in CBEEP.c are handled in
a
very signal oriented way.   Take a look at notify_upper and notify_lower,  I
think these
are the right places to send you.

Mark or Darren...  have I steered him wrong?

-bill mills

---

From: "Marshall T. Rose" <[email-masked]>
Date: Sat, 18 Aug 2001 08:20:51 -0700

> parallel connections from same user in IMAP).

actually, all three beepcore implementations (tcl, java, c) do sasl otp...

> hash-based authentication mechanism)?

it's on the list, although darren's response has the most info...

/mtr

---

From: Chris Newman <[email-masked]>
Date: Sat, 18 Aug 2001 14:47:30 -0700

> think OPIE is out there too, actually.

I did the work primarily to deprecate the SKEY mechanism in RFC 2222 (so 
SASL can go to draft standard status), although OTP is quite useful for 
scenarios where connections are long-lived and the client tends to get 
pretty broad access to server facilities through the protocol (e.g., 
telnet).  OTP is a reasonable choice for a server which _only_ runs 
long-lived BEEP connections, but I think DIGEST-MD5 would be a better 
choice.

Corporate sites tend to care more about user/password management than 
security in my experience.  Most large corporate and ISP sites use LDAP to 
manage users, but OTP is impractical for that scenario since LDAP isn't 
designed for frequent updates.  So OTP won't deploy at most large sites 
today.  If the standards community unites behind DIGEST-MD5 and work to get 
it integrated with LDAP is done right, then we might be able to get it 
deployed at corporate sites, which would be a big improvement over the 
current defacto standard of plaintext passwords.

I know the DIGEST-MD5 protocol is a bit ugly thanks to its HTTP digest 
roots, but we need a cross-protocol alternative to plaintext passwords, so 
we needed buy-in from all the application communities (HTTP, LDAP, email, 
etc).

>> Any plans to implement SASL/DIGEST-MD5 (which I consider the most
>> important hash-based authentication mechanism)?
>

The security layer in DIGEST-MD5 is optional, so a first cut without it 
would be great (indeed we haven't released the security layer support for 
iPlanet Messaging Server yet).  But I think the security layer is worth the 
effort eventually, since it provides a useful speed vs. security tradeoff 
relative to TLS encrypted sessions.

		- Chris

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 20 Aug 2001 14:48:15 -0400 (EDT)

> OTP into it at this time.

Hi,

I think you might be being a bit unfair with your assessment of the Cyrus
SASL library.  Neither SASLv1 or SASLv2 are currently undocumented from
the application programmer side.  Granted, the documentation is not the
best in the world, but it's certainly not nonexistent.  Our next release
of SASLv2 (hopefully later this week) will also include a brief plugin
writer's guide, which should be enough to get started.  To date, there
hasn't really been much interest in developing expansive documentation for
plugin writers because, well, there aren't that many plugins to write.
Certainly we are willing to assist anyone in writing a mechanism, and the
PLAIN and ANONYMOUS plugins that are included in Cyrus SASL are also good
starting points to look at.

As far as SASLv2 being unstable, yes, we are currently catagorizing our
releases as beta-quality.  The API, however, is essentially fixed at this
point, so any development against the library should not break in future
releases.  In fact, we've completed porting Cyrus IMAPd to the new library
(though have done no release of this code as of yet).  We've also talked
to Sendmail, who are looking at porting 8.13 to use SASLv2.  As of now,
any development of new applications against the Cyrus SASL should happen
against SASLv2, which features much improved memory management and
handling of client-send-first and server-send-last situations (as well as
many other features).

I'd like to finish by saying that we'd be excited about including an OTP
plugin in our distribution, and would be willing to help in any we could.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Cyert Hall 235 * 412-CMU-TREK
               | Cyrus SASL Developer, /usr/contributed Gatekeeper

---

From: Darren New <[email-masked]>
Date: Mon, 20 Aug 2001 12:13:43 -0700

Rob Siemborski wrote:
> best in the world, but it's certainly not nonexistent. 

No, it looks decent. It's just that if I'm doing the plug-ins, I'd want
to know what it's supposed to do. Code is not documentation, in spite of
Open Source ;-)

> Our next release
> writer's guide, which should be enough to get started.

That would be very helpful, yes.

> To date, there

It doesn't have to be extensive. It just has to be something better than
"reverse engineer 800 lines of C code to try to figure out what it does,
then make your code do the same thing, only different." :-) Especially
with beta-release code, where a bug in the code *becomes* a bug in the
specification.

For example, one of the stumbling blocks of using PLAIN or ANONYMOUS as
a starting point was the fact that neither of those actually has a
custom password database, and neither of those changes that database
upon login. Nor do they require any sort of locking. How am I *supposed*
to support this? Do any of the other plug-ins support this sort of
stuff? Without documentation, it's difficult to decide how useful the
library actually is from that point of view.

> starting points to look at.

I see that my message spoke in the present tense. That was indeed
inaccurate.

At the time I had to make the decision, the concensus from the Cyrus
supporters was "wait for the API to settle." Certainly, *now* the API is
fixed, and *soon* there will be some docuemtation, but at the time I
made the decision a couple of months ago, this wasn't the case. We were
under contractual deadlines, so waiting for the Cyrus stuff to stabilize
wasn't worthwhile at the time. FWIW, a very similar process occurred
with Apache, so you're in good company. ;-)

Note that I'm not bashing the Cyrus stuff in any way. It just wasn't
appropriate for us at the time we had to make the decision. 
 
> plugin in our distribution, and would be willing to help in any we could.

Perhaps eventually we will incorporate Cyrus into our BEEP libraries.