Subject: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712)

From: Jeffrey Altman <[email-masked]>
Date: Wed, 13 Dec 2006 11:34:19 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Thu, 14 Dec 2006 12:35:56 +0200

Hi Jeffrey,

The text is correct if it's interpreted to apply only to the
ciphersuites defined in RFC2246/4346 (all of which are based on
certificates, or are anonymous)... but I do agree that it would
benefit from clarification. But instead of listing the exceptions
when it's not sent, I'd prefer saying when it *is* sent:

   "The server MUST send a certificate whenever the agreed-upon key
   exchange method uses certificates for authentication (this includes
   all key exchange methods defined in this document except DH_anon).
   This message will always immediately follow the server hello
   message."

Best regards,
Pasi 

> -----Original Message-----
> From: ext Jeffrey Altman [mailto:[email-masked]] 
> Sent: 13 December, 2006 18:34
> To: [email-masked]
> Subject: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 
> Cipher Suite(RFC2712)
>

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 14 Dec 2006 11:38:27 +0100

>    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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Dec 2006 08:44:05 -0500

> a handshake that is nominally anonymous.)

One more revision combining the best of Pasi's and Bodo's text:

     This message is omitted if the agreed-upon key exchange method is
     anonymous or uses server authentication method that does not
     involve certificates.  For all key exchange methods specified in
     this document except for DH_anon, 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.

Jeffrey Altman

---

From: <[email-masked]>
Date: Thu, 14 Dec 2006 16:42:03 +0200

>      will always immediately follow the server hello message.

Improving... except I still prefer an ordering where we first say 
when the message is sent, and the explain the exceptions:

   This message MUST be sent if the agreed-upon key exchange method
   involves certificates for server authentication.  This includes all
   key exchange methods defined in this document except DH_anon. For
   key exchange methods specified elsewhere that are either anonymous
   or provide an alternative method of server authentication, this
   message MUST NOT be sent. This message will always immediately
   follow the server hello message.

Best regards,
Pasi

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 14 Dec 2006 09:44:55 -0500

>    follow the server hello message.

I am happy with this version.

Thanks.

Jeffrey Altman