Re: Bind and StrongAuthRequired

[Peter Bachman <peterb@cequs.com>]

Kurt,

The necessity to invoke strongAuthRequired seems to come into play in the following
wording:

- strongAuthRequired: The server has detected that an established
     underlying security association protecting communication between
     the client and server has unexpectedly failed or been compromised.

That failure could exist on layers on which the SASL mechanism is aware of, or not
aware of. It's going to be aware of strongAuth failures which were already
in place, but if something is going on in the Transport Layer, how would it
know to then return that result code? SASL can use the external mechanism to
get data from TLS, but that's when it's already being used. Perhaps that's
why strong(er) is used.

-pb


On Fri, 26 Jul 2002 09:30:53 -0700
"Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:

>When returned in a BindResponse, strongAuthRequired is defined
>to have a different meaning [RFC 2251]
>   - strongAuthRequired: the server requires authentication be
>     performed with a SASL mechanism
>
>then when returned in other responses [protocol]:
>>        strongAuthRequired (8)    
>>           Except when returned in a Notice of Disconnect (see section 
>>           4.4.1), this indicates that the server requires the client to
>>           authentication using a strong(er) mechanism.
>
>As currently worded, a bind strongAuthRequired response
>doesn't require the client to use stong(er) mechanism,
>only a SASL mechanism.  It may be the case that a
>non-SASL mechanism mechanism (e.g., TLS+simple) might
>be stronger than some of the available SASL mechanisms
>(e.g., DIGEST-MD5).
>
>The result code should, as in the general case, indicate
>that the client is to use a stong(er) mechanism, regardless
>of whether its SASL-based, TLS+simple, or some other
>authentication method. (Of course, the client should
>select the strongest mechanism available.)
>
>Hence, it is my opinion that the description of
>strongAuthRequired in section 4.2.3 of [protocol] be
>updated to be consistent with the general description
>of the result code provided in A.2 of [protocol].
>
>I note that there are implementations in existence today
>which return/expect strongAuthRequired in a Bind Response
>to indicate that a strong(er) mechanism is to be used.  I
>note as well that as this change generalizes the meaning
>of the result code when used in a BindResponse, the change
>should not invalid any existing implementation.
>
>-- Kurt
>


-- 
------------------------------------------------------------------------------

peterb@cequs.com
Peter Bachman
Cequs Inc.
------------------------------------------------------------------------------