[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: authmeth: re-fetching supportedSASLmechanisms



I concur that the underlined text is especially problematic.
However, not much more than whole paragraph.

LDAP servers are allowed to list mechanisms based upon availability
and the stronger mechanism may no longer be available post
authentication, this method is flawed.  For it to valid method
for detecting a MITM mechanism downgrade attack, the server would
have to be required to provide the same list as it provided before
authentication.

Additionally, the client and server would have to be required to
establish integrity protection.  Lastly, this method does nothing
to detect other SASL downgrade attacks, such as cipher-suite
downgrading.

I know of no client which implements this method for detection
of MITM downgrading attacks.

I believe it more appropriate to recommend that clients/servers
refuse to negotiate unacceptable (per local policy) mechanisms.

Kurt

At 09:06 AM 11/17/2003, Hallvard B Furuseth wrote:
>authmeth-08 section 3.3.5 says:
>
>   If the client is configured to support multiple SASL mechanisms, it 
>   SHOULD fetch the supportedSASLmechanisms list both before and after 
>   the SASL security layer is negotiated. This allows the client to 
>   detect active attacks that remove supported SASL mechanisms from the 
>   supportedSASLMechanisms list and allows the client to ensure that it 
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   is using the best mechanism supported by both client and server.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Delete the underlined text.  It does not allow the client to ensure
>that.  The password has already been sent with a weaker mechanism by
>the time the client discovers that a stronger mechanism is available.
>
>-- 
>Hallvard