Re: [Fedora-directory-users] SASL authentication

[Howard Chu]

>  Date: Fri, 08 Sep 2006 09:01:41 -0600
>  From: Richard Megginson <rmeggins(a)redhat.com&gt; 
>  Josh Kelley wrote:
> > > On 9/7/06, Richard Megginson <rmeggins(a)redhat.com&gt; wrote:
> >> >> I checked RFC 4513  - http://www.ietf.org/rfc/rfc4513.txt - it
> doesn't
> >> >> say anything about the correct result code to return in this case,
> other
> >> >> than it is an error if anything other than success or bindinprogress is
> >> >> returned.  You might want to ask on ldap(a)umich.edu or on
> >> >> IRC.freenode.net #ldap if there is a standard that covers this case.
> > >
> > > Thanks for the suggestion.  I'll ask.
> > >
> > > I skimmed RFC 4513 (sans coffee) and didn't find the section you're
> > > referring to.  I did see that RFC 4422 (last paragraph of section 3.6)
> > > seems to suggest that OS X's and OpenLDAP's behavior is legitimate and
> > > useful. 
Before you go any further with this, please tell us which version of 
OpenLDAP you're using. Current releases (since 2.3.6) return 
invalidCredentials for a SASL bind failure:

ldapsearch -H ldap://:9000 -Y DIGEST-MD5
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
         additional info: SASL(-13): user not found: no secret in database

Probably we should also do something about not returning the 
SASL-specific error code in this case too, to adhere more to the intent 
of rfc4422. Logging it on the server side should be sufficient.

I just checked, and releases 2.1 and 2.2 returned error code 80 here. So 
it seems Apple is relying on a broken behavior.

>  Yes.  But it seems to differ from the behavior of a simple bind
> (rfc4513 
>  5.1.3).  In a simple bind, the server resultCode differentiates these cases:
>  1) Invalid bind DN results in a noSuchObject (well, not exactly 
>  specified, but this is the usual behavior)
>  2) Valid bind DN but invalid password results in invalidCredentials
>  
>  However, the rfc (and also rfc 4511 Appendix A LDAP Result Codes) says 
>  that other codes may be substituted for the above "to prevent 
>  unauthorized disclosures (such as substitution of noSuchObject for 
>  insufficientAccessRights, or invalidCredentials for 
>  insufficientAccessRights)."
>  
>  The SASL doc (rfc4422) says:
>  
>  "It is also important that the server can be configured such that the outcome
> message will not distinguish between a valid user with invalid credentials and an invalid
> user."
>  
>  
>  So it seems that SASL wants the server not to differentiate these cases, 
>  probably for security reasons.  But this makes sasl binds have different 
>  semantics than simple binds.
> > >
> > > Even if the standards permit either behavior (and even if it's
> > > slightly more secure to not reveal additional information, as David
> > > Boreham pointed out), wouldn't it be worth having FDS compatible with
> > > OpenLDAP and OS X?
>  Yes.  And please file a bug about this at http://bugzilla.redhat.com/ 
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

[Fedora-directory-users] SASL authentication

[Josh Kelley]

On 9/8/06, Howard Chu <hyc(a)symas.com&gt; wrote:
>  Before you go any further with this, please tell us which version of
>  OpenLDAP you're using. Current releases (since 2.3.6) return
>  invalidCredentials for a SASL bind failure: 
2.2.13, as provided by RHEL 4.  I had not thought to try a current
release; thanks for the info.

>  Probably we should also do something about not returning the
>  SASL-specific error code in this case too, to adhere more to the intent
>  of rfc4422. Logging it on the server side should be sufficient.
>
>  I just checked, and releases 2.1 and 2.2 returned error code 80 here. So
>  it seems Apple is relying on a broken behavior. 
I guess I really don't understand here.  RFC 4422 says that "outcome
message provided by the server can provide a way for the client to
distinguish between errors" of various sorts, which I assumed could
include errors resulting from attempting to use an unconfigured
authentication mechanism.  And although the RFC says that it is
"important that the server can be configured such that the outcome
message will not distinguish between a valid user with invalid
credentials and an invalid user," it doesn't say that it's necessary
that servers be so configured or that it's broken for servers to not
be so configured.

Furthermore, it seems to me that what Apple's trying to do - attempt a
secure authentication method first, then fall back to a nonsecure
authentication method if a secure method is not configured, without
needlessly sending cleartext passwords if the secure authentication
method is configured and rejects the user - is a good idea.  Is
Apple's default approach simply not permitted by the RFCs?  I
understand that for the server to unnecessarily give away
security-related info is potentially bad, but it seems like a minor
concern compared to the gains of permitting "secure by default, fall
back to unsecured" behavior like Apple's default.  (I guess MITM
attacks are a risk with that kind of approach; are they enough of a
risk to negate that approach's value?)

I hope I'm not coming across as argumentative; I just would really
like to understand the issues involved.

If it is a bad idea for the server to distinguish between "invalid
credentials" and "no secret in database," then what is the best way to
get OS X logins to work?  For now I've simply disabled CRAM-MD5 by
moving those libraries out of my /usr/lib/sasl2 directory, but that
seems like a hack.  I guess a better solution would be to permit the
SASL mech_list to be configured from within FDS; should I submit an
RFE on Bugzilla for that?

Thanks.

Josh Kelley

[Fedora-directory-users] SASL authentication

[Rich Megginson]

Josh Kelley wrote:
>  On 9/8/06, Howard Chu <hyc(a)symas.com&gt; wrote:
> > Before you go any further with this, please tell us which version of
> > OpenLDAP you're using. Current releases (since 2.3.6) return
> > invalidCredentials for a SASL bind failure:
>
>  2.2.13, as provided by RHEL 4.  I had not thought to try a current
>  release; thanks for the info.
>
> > Probably we should also do something about not returning the
> > SASL-specific error code in this case too, to adhere more to the intent
> > of rfc4422. Logging it on the server side should be sufficient.
> >
> > I just checked, and releases 2.1 and 2.2 returned error code 80 here. So
> > it seems Apple is relying on a broken behavior.
>
>  I guess I really don't understand here.  RFC 4422 says that "outcome
>  message provided by the server can provide a way for the client to
>  distinguish between errors" of various sorts, which I assumed could
>  include errors resulting from attempting to use an unconfigured
>  authentication mechanism.  And although the RFC says that it is
>  "important that the server can be configured such that the outcome
>  message will not distinguish between a valid user with invalid
>  credentials and an invalid user," it doesn't say that it's necessary
>  that servers be so configured or that it's broken for servers to not
>  be so configured.
>
>  Furthermore, it seems to me that what Apple's trying to do - attempt a
>  secure authentication method first, then fall back to a nonsecure
>  authentication method if a secure method is not configured, without
>  needlessly sending cleartext passwords if the secure authentication
>  method is configured and rejects the user - is a good idea.  Is
>  Apple's default approach simply not permitted by the RFCs?  I
>  understand that for the server to unnecessarily give away
>  security-related info is potentially bad, but it seems like a minor
>  concern compared to the gains of permitting "secure by default, fall
>  back to unsecured" behavior like Apple's default.  (I guess MITM
>  attacks are a risk with that kind of approach; are they enough of a
>  risk to negate that approach's value?) 
SASL is supposed to attempt to negotiate
the strongest auth available.
>  I hope I'm not coming across as argumentative; I just would really
>  like to understand the issues involved.
>
>  If it is a bad idea for the server to distinguish between "invalid
>  credentials" and "no secret in database," then what is the best way to
>  get OS X logins to work?  For now I've simply disabled CRAM-MD5 by
>  moving those libraries out of my /usr/lib/sasl2 directory, but that
>  seems like a hack.  I guess a better solution would be to permit the
>  SASL mech_list to be configured from within FDS; should I submit an
>  RFE on Bugzilla for that? 
Yes.
>  Thanks.
>
>  Josh Kelley
>
>  -- 
>  Fedora-directory-users mailing list
>  Fedora-directory-users(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Fedora-directory-users] SASL authentication

[Josh Kelley]

On 9/8/06, Richard Megginson <rmeggins(a)redhat.com&gt; wrote:
>  Josh Kelley wrote:
>  > If it is a bad idea for the server to distinguish between "invalid
>  > credentials" and "no secret in database," then what is the best way
> to
>  > get OS X logins to work?  For now I've simply disabled CRAM-MD5 by
>  > moving those libraries out of my /usr/lib/sasl2 directory, but that
>  > seems like a hack.  I guess a better solution would be to permit the
>  > SASL mech_list to be configured from within FDS; should I submit an
>  > RFE on Bugzilla for that?
>  Yes. 
Submitted at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206053;
thanks.

Josh Kelley