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