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

Re: Revisited: effect of Start TLS on authentication state

I don't see the compatibility issue as being a big deal in this case.
I don't see any reason to keep a MUST which few if anyone has ever
implemented (those who know of implementations should speak up),
especially with that MUST makes little sense.

At 02:31 AM 12/9/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> If client and server, before or after starting TLS, established
>> strong authentication (possibly with layers), they should not be
>> forced to renegotiate strong authentication.
>
>OK if layers or IPsec is in place.

Obviously without appropriate integrity layers, the connection
is subject to MITM attacks.  (I believe SASL/DIGEST-MD5 layers
support will be mandatory-to-implement in 2831bis.)

Part of the problem with this MUST was that it assumed that
protective layers where being provided by TLS.  This may not
actually be the case.  The null cipher suite may be in use,
and the TLS closure is being used simply to free resources
associated with the TLS stream.

>> Lastly, it is reasonable for a client which has established
>> strong authentication and security layers though SASL to
>> close TLS to reduce resource consumption.
>
>OK, and I can see how TLS can protect the SASL bind from a Denial of
>Service attack and then be dropped, but you mentioned null TLS cipher
>suites - can't that be used instead to get rid of TLS overhead but still
>keep the association?

First, I'm not thinking of "resource consumption" in terms of a DoS
attack (though resource constraint can be attacked in this manner),
but just in terms of what may be expensive-enough resources that an
implementation might want to free them.  Specifically, I was think
of platforms which provide hardware support for TLS.  These systems
often have limitations on the total number of concurrent TLS streams
they can maintain.  It would be reasonable for an implementation
using such to issue TLS closures when the TLS protections were no
longer valuable to it.

>Another thing is that the text about invalidated associations still
>seems misplaced to me.

It seems so to me as well.

>Other situations than TLS start/closure can have
>use for that, e.g. if the DN which the user bound as gets deleted.
>So I suggest this text is moved to a separate section.  The TLS sections
>can then simply say that start/close TLS MAY invalidated the association.
>That's no real change in functionality, since [Protocol] already says
>it is possible.
>
>Like this:
>
>Section whatever: Invalidated associations
>
>   The server MAY at any time invalidate the association, e.g. if the
>   established security association between the client and server has
>   unexpectedly failed or been compromised.  The association remains
>   invalidated until the next successful bind request.

s/MAY/may/.  (I'm fine with adding just this text to the section
introducing associations)

>   When the association is invalidated, the server it MUST reject
>   subsequent operation requests other than Bind, Unbind and Start TLS,
>   and respond with a resultCode of strongAuthRequired to indicate that
>   the client needs to bind to reestablish its authentication.

I'm a little concerned that of the overload here.  strongAuthRequired
means, generally, that stronger authentication is required.  Now,
that could be due to the invalidation of the association, but it could
be due to any number of other reasons.  Additionally, the server could
be willing, after invalidating the association, to continue to allow
the client to attempt operations which don't require that association.

The MUST here is actually extraneous.  Consider a server which instead
of invalidating the association just has another factor which says
that the association is only strong enough for X and Y but not Z.
This would be perfectly compliant with the specification.  Hence,
any developer which doesn't want to implement this MUST can simply
claim that they using other factors to determine when to return
strongAuthRequired.  So, in effect, the MUST is only relevant if
certain implementation details are assumed.  As we cannot assume
those details, the MUST is moot and hence should not stated.

Kurt