[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Fwd: Re: StartTLS and referral
I propose removing the language in [Protocol] that talks about StartTLS
returning a referral.
Furthermore, I think we need to consider the security ramifications of
clients following referrals and state those in the security
considerations section.
Jim
>>> John McMeeking <jmcmeek@us.ibm.com> 11/20/02 9:33:49 AM >>>
Jim,
I the concern was that someone else on the network would maliciously
send a
referral response to the client while it was negotiating TLS. A
correct
TLS flow would never involve a referral, and hence the sugegstion that
a
client never chase a referral received during StartTLS or other
similarly
sensitive operations.
John McMeeking
"Jim Sermersheim"
<jimse@novell.com> To:
<mcs@netscape.com>, <Kurt@OpenLDAP.org>
Sent by: cc:
<ietf-ldapbis@OpenLDAP.org>
owner-ietf-ldapbis@O Subject: Re:
StartTLS and referral
penLDAP.org
11/20/2002 10:09 AM
I don't get it. Why would StartTLS return a referral? Start TLS is
simply
setting up for the TLS handshake. The response is sent to the client
before
the client presents its certificate. How would the server know, before
sending the StartTLS response that another server might be involved?
To my mind, referrals are typically only returned when an operation
request
contains some DN, and during name resolution, that DN is found ot be
not
local.
Jim
>>> Mark C Smith <mcs@netscape.com> 08/09/02 08:50AM >>>
Interesting issue. Perhaps servers should not return referrals for
startTLS extended ops. and clients should ignore referrals if
returned?
It seems appropriate to provide some advice in this area.
--
Mark Smith
AOL Strategic Business Solutions
Netscape Directory Product Development
My words are my own, not my employer's.
Kurt D. Zeilenga wrote:
> As anyone thought much about the security considerations
> of allowing StartTLS to return a referral. The is no
> discussion in RFC2830 that discusses how an attacker,
> by injecting a StartTLS response into the stream,
> could redirect the client to a server of its choosing
> (with a certificate of its choosing).
>
> Give that many clients auto chase referrals... and
> auto-verify certificates, the client might even not notice
> that it re-connected to a rogue server with a verifiable
> certificate. That is, verifiable with the host name of
> the rogue server name. I don't it would make sense
> operationally to require the client to verify using the
> host name of the original server, but it might sense
> security wise.
>
> Same, I guess, applies to Bind operations... or
> initial discovery of security features.
>
> Anyways, food for thought.
>