Re: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712)
Bodo Moeller <bmoeller@acm.org> Thu, 14 December 2006 10:38 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gunz0-00027F-Bc; Thu, 14 Dec 2006 05:38:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gunyz-00026J-5Q for tls@lists.ietf.org; Thu, 14 Dec 2006 05:38:33 -0500
Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gunyx-0000zm-FJ for tls@lists.ietf.org; Thu, 14 Dec 2006 05:38:33 -0500
Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gunyv0FxP-0006rt; Thu, 14 Dec 2006 11:38:29 +0100
Received: by tau.invalid (Postfix, from userid 1000) id 2C009124D8; Thu, 14 Dec 2006 11:38:27 +0100 (CET)
Date: Thu, 14 Dec 2006 11:38:27 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: Jeffrey Altman <jaltman@secure-endpoints.com>
Subject: Re: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712)
Message-ID: <20061214103827.GA27545@tau.invalid>
References: <45802B8B.80503@secure-endpoints.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <45802B8B.80503@secure-endpoints.com>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: tls@lists.ietf.org
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>
Errors-To: tls-bounces@lists.ietf.org
On Wed, Dec 13, 2006 at 11:34:19AM -0500, Jeffrey Altman wrote: > 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." > 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." It might be better to be more explicit here. Your proposed text resolves the conflict, but could be puzzling to implementors who haven't seen the Kerberos or TLS_GSS ciphersuite specifications and don't quite know what you're talking about when you mention alternative methods of server authentication. Here is a more elaborate proposal: This message is omitted if the agreed-upon key exchange method is anonymous or uses an alternative method of server authentication. For all non-anoymous key exchange methods specified in this document, the server MUST send this message. For non-anonymous key exchange methods specified elsewhere that do not provide an alternative method of server authentication, the server MUST send this message. This message will always immediately follow the server hello message. This also would clarify that you can't send a certificate message in an anonymous handshake, which apparently isn't strictly forbidden with the current language. (The signature part of the ServerKeyExchange is empty, so there's no point in trying to attach a server certificate to a handshake that is nominally anonymous.) Bodo _______________________________________________ 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