Subject: Re: SASL C API and BEEP C API

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 4 Jan 2002 18:32:13 -0800

> Marshall, if I misunderstood anything, please feel free to clarify the
> problems.

looks fine to me.

/mtr

---

From: Chris Newman <[email-masked]>
Date: Fri, 04 Jan 2002 18:57:33 -0800

I can live with those changes.

		- Chris

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 4 Jan 2002 16:56:41 -0500 (EST)

Hi guys,

I've been having some discussions with Marshall Rose about beepcore-c's
use of the SASL C API to implement the SASL part of RFC3080 in their
library.  We've run across a few limitations in the current C API, and I
have work arounds, but I'd like to hear other opinions on them.

The first is fairly easy.  BEEP (as a protocol) needs to know if security
layer negotiation took place, regardless of whether authentication
succeeded or failed, because if the negotiation is attempted, it is
required that all open BEEP channels are closed.  My "easy" solution to
this is that the ssf part of the oparams structure would be set by the
mechanism if negotiation was attempted at all, regardless of the result.
(obviously, if negotiation fails and a failure is returned to the
application, the security layer is unusable regardless of the SSF value).
This would allow applications to do a sasl_getprop(SASL_SSF) after a
failed authentication to determine if a security layer negotiation had
occurred.

The second problem is a slightly more messy problem.  The two APIs work in
very conflicting ways with regards to how profiles are registered and when
this occurs.  The main problem is that the beepcore API needs to have a
complete list of all possible mechanisms before any connection is
established that might possibly need them.  This is for both servers and
clients.  The SASL API is built around much more "traditional" SASL
profiles where such a list is not needed until after a connection occurs.
Later, on a per connection basis, the mechanisms that are advertised can
be determined, but they must have been registered beforehand.

After some discussion between Marshall and myself, I believe that the
easiest way to satisfy both APIs is to make a slight modification to the
definition of sasl_listmech().

Basically, I would clarify the definition to:
1. Allow it to be called for client sasl_conn_t's as well as server
sasl_conn_ts.
2. Allow it to take a NULL sasl_conn_t, which would indicate that it
should list all mechanisms that the library is capable of providing, even
if they may not be available in all cases.

#2 is the really important one, I believe that Marshall found a way around
#1.  Of course, it feels like it is breaking some of the abstraction that
the library is providing, and therefore leaves a slightly bad taste in my
mouth.

If others had ideas about better ways to proceed here, I'd like to hear
them.  Obviously avoiding major changes to either API is preferred.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | W3VC President * Scotch & Soda Technical Coordinator
Andrew Systems Group * Cyert Hall 235 * 412-CMU-TREK | ABTech Exec
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/CC/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W- N- o?
K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b+ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 4 Jan 2002 18:32:13 -0800

looks fine to me.

/mtr

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 4 Jan 2002 18:32:13 -0800

looks fine to me.

/mtr

---

From: Chris Newman <[email-masked]>
Date: Fri, 04 Jan 2002 18:57:33 -0800

- Chris

---

From: "Marshall T. Rose" <[email-masked]>
Date: Fri, 4 Jan 2002 18:32:13 -0800

looks fine to me.

/mtr