--- Begin Message ---
At 10:55 PM 5/4/2003, Vithalprasad Gaitonde wrote:
>"But I'm thinking RFC 2251, 4.4.1 should be clarified as well:
> - strongAuthRequired: The server has detected that an
>establish
> security association between the client and server has
> unexpectedly failed or been compromised, or that the
> server now requires the client to authenticate using a
> strong(er) mechanism."
>But what does strong(er) imply in the case which we are talking
>about...
In this case, it's the former part of the description which applies.
That is, the code indicates that a security association has failed.
>does that mean the client has to go over TLS or use some SASL
>bind and not use a clear text simple bind ?
It means either a security association has failed or the
better mechanisms are needed.
>.at least that was the
>conventional meaning of strongauthrequired.
>
>Prasad
>
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/3/2003 4:08:01 AM >>>
>At 01:59 PM 5/2/2003, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>> We should probably have a result code like invalidIdentity which
>is
>>>> sent back with a notice of disconnection (section 4.4.1 protocol
>draft)
>>>> followed by a closing of the connection by the server.
>>>
>>> RFC 2251, 4.4.1:
>>>> - strongAuthRequired: The server has detected that an
>established
>>>> underlying security association protecting communication
>between
>>>> the client and server has unexpectedly failed or been
>compromised.
>>>
>>> I think it would be reasonable to return this in this case as well.
>>
>>Why ask for _strong_ auth, and not just auth?
>
>First, we've clarified the result code, in general, to mean:
>> 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.
>
>But I'm thinking RFC 2251, 4.4.1 should be clarified as well:
> - strongAuthRequired: The server has detected that an
>establish
> security association between the client and server has
> unexpectedly failed or been compromised, or that the
> server now requires the client to authenticate using a
> strong(er) mechanism.
>
>That is, generalized the result code here as well. I also
>think other codes should be allowed in the Notice. I think
>it reasonable for implementations to return a variety of
>other codes including busy, other, adminLimitExceeded,
>unwillingToPerform, and confidentialityRequired.
>
>Kurt
--- End Message ---