[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: commit: ldap/libraries/libldap cyrus.c
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> The text which concerned me (and this code) is from RFC 2222:
>
> In the case that a profile explicitly permits multiple successful
> SASL negotiations to occur, then in no case may multiple security
> layers be simultaneously in effect. If a security layer
> is in effect
> and a subsequent SASL negotiation selects no security layer, the
> original security layer remains in effect. If a security
> layer is in
> effect and a subsequent SASL negotiation selects a second security
> layer, then the second security layer replaces the first.
>
> This implies that there could be 0, 1,or 2 ACTIVE SASL handles
> associated with an LDAP handle:
> One for in-progress authentication
> One for active security layer
>
> When the authentication completes, if a (new) security layer
> was established, then the "in-progress" would replace the
> "active". Otherwise, the "active" would remain in force.
This seems pretty clear, but is difficult to apply to our situation since the
Cyrus SASL API doesn't support it. It also is written in a context where SASL
is the only authentication system in use, and a new SASL negotiation
immediately follows an existing session.
The code in this patch aborts an existing SASL session by sending an
anonymous Bind request. This is explicitly allowed by section 4.2.1 of RFC
2251, although that section implies that the security layers should not be
dismantled. But again, the Cyrus API we're working with doesn't give us any
other choice. Given this circumstance, the consideration in RFC 2222 doesn't
really apply, because there is an intervening non-SASL "session" between the
two SASL negotiations.
So again, I think we need to make a distinction between having consecutive
SASL Binds, and a SASL Bind followed by a Simple Bind. In the case of
consecutive SASL Binds, the RFC 2222 text must apply. In the case of a Simple
Bind, I believe the SASL security layers must be destroyed along with the
credentials. Otherwise you are mixing Simple authentication IDs with SASL,
which makes no sense.
>
> Kurt
>
> At 01:12 PM 4/30/2003, Howard Chu wrote:
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> >
> >> Actually, portions of RFC 2251 apply here as well. Personally,
> >> I find the text is quite ambiguous here. We likely should
> >> raise some clarification points to LDAPBIS.
> >
> >I didn't see anything particularly relevant in RFC 2829. Now
> that you mention
> >it, I see in RFC2251 (sect 4.2.1) that a client MUST establish a new
> >connection if the chosen SASL mechanism doesn't support the
> changing of
> >credentials. In our case, whether the mechanism supports it
> or not, the SASL
> >library really doesn't.
> >
> >It seems to me that the current text in 4.2.1 is overly
> restrictive. The
> >approach that is implemented in these patches is equally
> secure to dropping
> >the connection and starting over. I would advocate this
> method for LDAPBIS.
> >
> >> Kurt
> >>
> >> At 06:38 AM 4/30/2003, hyc@OpenLDAP.org wrote:
> >> >Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
> >> >
> >> >Modified Files:
> >> > cyrus.c 1.83 -> 1.84
> >> >
> >> >Log Message:
> >> >ITS#2424 reset SASL on an existing connection
> >
> > -- Howard Chu
> > Chief Architect, Symas Corp. Director, Highland Sun
> > http://www.symas.com http://highlandsun.com/hyc
> > Symas: Premier OpenSource Development and Support
>
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support