[TLS] ldaps closure alert http://www.ietf.org/rfc/rfc2830.txt
Peter Williams <home_pw@msn.com> Fri, 22 December 2006 07:25 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxemi-0006JI-EH; Fri, 22 Dec 2006 02:25:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxemh-0006JC-V3 for tls@ietf.org; Fri, 22 Dec 2006 02:25:39 -0500
Received: from bay0-omc2-s25.bay0.hotmail.com ([65.54.246.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxemg-0006u6-Iy for tls@ietf.org; Fri, 22 Dec 2006 02:25:39 -0500
Received: from BAY103-W7 ([65.54.174.107]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 23:25:38 -0800
X-Originating-IP: [69.227.152.254]
X-Originating-Email: [home_pw@msn.com]
Message-ID: <BAY103-W786A74B3E1A66A36590C392CD0@phx.gbl>
From: Peter Williams <home_pw@msn.com>
To: tls@ietf.org
Date: Thu, 21 Dec 2006 23:25:38 -0800
MIME-Version: 1.0
X-OriginalArrivalTime: 22 Dec 2006 07:25:38.0178 (UTC) FILETIME=[60C0AE20:01C7259A]
X-Spam-Score: 2.6 (++)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc:
Subject: [TLS] ldaps closure alert http://www.ietf.org/rfc/rfc2830.txt
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1160176501=="
Errors-To: tls-bounces@lists.ietf.org
http://www.ietf.org/rfc/rfc2830.txt discloses that After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs, and following the receipt of the alert, MAY send and receive LDAP PDUs. The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs, and MAY send and receive LDAP PDUs. An initiating party issues a closure_alert, and starts waiting for ANY alert in response (from the recipient). Thereupon, it MAY starting sending cleartext PDUs directly over the underlying TLS transport. A responding party suffering delays on its TLS input qbuf (on a ciphersuite with null confidentiality in particular) could be sending who knows what warning alerts (std and custom), that will arrive after the initiating party sent its closure_alert. After the first one arrives, it is no longer specified to discard TLS messages, note. Presumably the TLS protocol engine should now process them. >From what I read, the DAP engine is now in a state where it can process any dap pdu responses, indicated to it. _________________________________________________________________ Type your favorite song. Get a customized station. Try MSN Radio powered by Pandora. http://radio.msn.com
_______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] ldaps closure alert http://www.ietf.org/rfc… Peter Williams