[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