[TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712)
Jeffrey Altman <jaltman@secure-endpoints.com> Wed, 13 December 2006 16:33 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX2j-0002o5-G7; Wed, 13 Dec 2006 11:33:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX2i-0002nz-PH for tls@lists.ietf.org; Wed, 13 Dec 2006 11:33:16 -0500
Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuX2g-0006f5-Sw for tls@lists.ietf.org; Wed, 13 Dec 2006 11:33:16 -0500
Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBDGXEhF022689 for <tls@lists.ietf.org>; Wed, 13 Dec 2006 11:33:14 -0500 (EST)
Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000037630.msg for <tls@lists.ietf.org>; Wed, 13 Dec 2006 11:34:29 -0500
Message-ID: <45802B8B.80503@secure-endpoints.com>
Date: Wed, 13 Dec 2006 11:34:19 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: tls@lists.ietf.org
X-Enigmail-Version: 0.94.1.2
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Spam-Processed: www.secure-endpoints.com, Wed, 13 Dec 2006 11:34:29 -0500 (not processed: message from valid local sender)
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: tls@lists.ietf.org
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Subject: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712)
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jaltman@secure-endpoints.com
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="===============1433101425=="
Errors-To: tls-bounces@lists.ietf.org
During the review of TLS 1.x while writing the Internet Draft describing the proposed TLS_GSS ciphers, Stefan Santesson noticed the following text from RFC4346 Section 7.4.2: "7.4.2. Server Certificate "When this message will be sent: "The server MUST send a certificate whenever the agreed-upon key exchange method is not an anonymous one. This message will always immediately follow the server hello message." This text appears in all versions of TLS. However, RFC2712 states in Section 3: "The server's certificate, the client CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be omitted since authentication and the establishment of a master secret will be done using the client's Kerberos credentials for the TLS server." In my opinion, RFC2712's behavior is correct. The TLS server must not send a certificate to the client when the key exchange is being performed in such as manner as not to rely on the public key pair associated with a certificate. The text in RFC4346 7.4.2 is correct assuming that certificate based public key is the only form of server authentication. As demonstrated by RFC2712, there are other methods of performing server authentication that do not involve certificates. I propose the following change to TLS 1.2 Section 7.4.2: "The server MUST send a certificate whenever the agreed-upon key exchange method is not anonymous and does not provide an alternative method of server authentication. This message will always immediately follow the server hello message." This text permits the behavior described by RFC2712 and the forthcoming TLS_GSS Internet Draft. Jeffrey Altman
_______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5… Jeffrey Altman
- RE: [TLS] Conflict between TLS 1.1 (RFC4346) and … Pasi.Eronen
- Re: [TLS] Conflict between TLS 1.1 (RFC4346) and … Bodo Moeller
- Re: [TLS] Conflict between TLS 1.1 (RFC4346) and … Jeffrey Altman
- RE: [TLS] Conflict between TLS 1.1 (RFC4346) and … Pasi.Eronen
- Re: [TLS] Conflict between TLS 1.1 (RFC4346) and … Jeffrey Altman