SCSV for TLS Client Credential Protection
draft-badra-tls-identity-protection-01

TLS Working Group                                               M. Badra
Internet-Draft                                                        DU
Intended status: Standards Track                       November 18, 2011
Expires: May 21, 2012

               SCSV for TLS Client Credential Protection
               draft-badra-tls-identity-protection-01.txt

Abstract

   This document defines a special Signaling Cipher Suite Value (SCSV)
   "TLS_IDENTITY_PROTECTION_SCSV" to add client credential protection to
   the TLS protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 21, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Badra                     Expires May 21, 2012                  [Page 1]
Internet-Draft  SCSV for TLS Client Credential Protection  November 2011

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The cipher suite TLS_IDENTITY_PROTECTION_SCSV . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Contributor's Address . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Normative References  . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Badra                     Expires May 21, 2012                  [Page 2]
Internet-Draft  SCSV for TLS Client Credential Protection  November 2011

1.  Introduction

   The TLS [RFC5246] authentication is usually based on either preshared
   keys or public key certificates.  If a public key certificate is used
   to authenticate the TLS client, the TLS client credentials are sent
   in clear text over the wire.  Thus, any observer can determine the
   credentials used by the client; learn who is reaching the network,
   when, and from where, and hence correlate the client credentials to
   the connection location.

   Credentials protection and privacy are the right to informational
   self-determination, i.e., individuals must be able to determine for
   themselves when, how, to what extent and for what purpose information
   about them is communicated to others.

   TLS client credential protection may also be done through a DHE
   exchange before establishing an ordinary handshake with identity
   information.  This wouldn't however be secure enough against active
   attackers, which will be able to disclose the client's credentials.
   Moreover, it wouldn't be favorable for some environments (e.g.,
   performance-constrained environments with limited CPU power), due to
   the additional cryptographic computations and round trips.

   TLS client credential protection may also be possible, assuming that
   the client permits renegotiation after the first server
   authentication [RFC5246]: The client and the server establish a TLS
   session with only server-side authentication and then perform a new
   full TLS Handshake with mutual authentication; the client credentials
   transferred in this stage thus are protected by the secure channel
   established in the first TLS Handshake.  This solution doesn't
   require a change to TLS.  However, this solution requires more
   asymmetric cryptographic computations, which in many environments (in
   particular for less powerful mobile nodes) are the rate limiting step
   in TLS, and therefore, the renegotiation has negative performance
   consequences.  In fact, renegotiation requires another round of an
   asymmetric encryption/decryption, which means the double number of
   asymmetric en-/decryption operations (e.g., with an RSA key) for TLS
   Handshake message processing, for both server and client.  Moreover,
   renegotiation requires twice the number of messages and roundtrips
   than a single TLS handshake, thus significantly increasing the
   overall delay in the session setup.  Additionally, the server is
   forced to complete a full first TLS handshake before it becomes able
   to confirm whether the client has a valid certificate or not.  This
   increased misbalance in processing load in the failure case might
   open an opportunity for misbehaving clients to perform resource
   exhaustion attacks against such servers.

   TLS client credential protection may as well be done by allowing the

Badra                     Expires May 21, 2012                  [Page 3]
Internet-Draft  SCSV for TLS Client Credential Protection  November 2011

   client and the server to add a TLS extension to their Hello messages
   in order to negotiate specific crypto algorithms, and use these to
   protect the client certificate [EAPIP].  However, both the SSLv3 and
   TLS 1.0/TLS 1.1 specifications require implementations to ignore data
   following the ClientHello (i.e., extensions) if they do not
   understand it.  However, some SSLv3 and TLS 1.0 implementations
   incorrectly fail the handshake in such a case.  This means that
   clients that offer extensions may encounter handshake failures.

   TLS client credential protection may be done by a signalling
   mechanism based on a set of cipher suites [Hajjeh].

   This document defines a special Signaling Cipher Suite Value (SCSV)
   "TLS_IDENTITY_PROTECTION_SCSV", with code point {0xXX, 0xXX}, to add
   client credential protection to the TLS protocol.  If a client offers
   the SCSV and the server replies with the ServerHello, the client MUST
   send the ChangeCipherSpec message before the Certificate and the
   CertificateVerify messages and after the ClientKeyExchange message.

   Current TLS specifications note that if the client certificate
   already contains a suitable DH or ECDH public key, then Yc is
   implicit and does not need to be sent again and consequently, the
   client key exchange message will be sent, but it MUST be empty.  Even
   if the client key exchange message is used to carry the Yc, using the
   same Yc will allow traceability.  Consequently, static Diffie-Hellman
   SHOULD NOT be used with this document.

2.  The cipher suite TLS_IDENTITY_PROTECTION_SCSV

   The TLS_IDENTITY_PROTECTION_SCSV is not a true cipher suite (it does
   not correspond to any valid set of algorithms) and cannot be
   negotiated.  By including this cipher suite in the ClientHello
   message, the TLS clients will be able to determine for themselves
   when, how, to what extent and for what purpose information about them
   is communicated to others.

   When a ClientHello is received, the server MUST check if it includes
   the TLS_IDENTITY_PROTECTION_SCSV.  If it does, the server MUST
   request a certificate from the client.  If the server does not
   receive a client certificate in response to the subsequent
   certificate request, then it MUST abort the session by sending a
   fatal handshake failure alert.

   When a ClientHello is received, the client MUST send the
   ChangeCipherSpec message before the Certificate and the
   CertificateVerify messages and after the ClientKeyExchange message.
   The ChangeCipherSpec message is sent to notify the receiving party

Badra                     Expires May 21, 2012                  [Page 4]
Internet-Draft  SCSV for TLS Client Credential Protection  November 2011

   that subsequent messages will be protected under the cipher suite and
   keys negotiated during the TLS Handshake.

3.  IANA Considerations

   IANA is requested to add the TLS cipher suite number 0xXX,0xXX with
   name TLS_IDENTITY_PROTECTION_SCSV to the TLS Cipher Suite registry.

4.  Security Considerations

   The security considerations described throughout [RFC5246] apply here
   as well.

   In order for the client to be protected against man-in-the-middle
   attacks, the client SHOULD verify that the server provided a valid
   certificate and that the received public key belongs to the server.

   Because the question of whether this is the correct certificate is
   outside of TLS, applications that do implement credential protection
   cipher suites SHOULD enable the client to carefully examine the
   certificate presented by the server to determine if it meets its
   expectations.  Particularly, the client MUST check its understanding
   of the server hostname against the server's identity as presented in
   the server Certificate message.

   In the absence of an application profile specifying otherwise, the
   matching is performed according to the following rules:

   o  The client MUST use the server hostname it used to open the
      connection (or the hostname specified in the TLS "server_name"
      extension [RFC6066]) as the value to compare against the server
      name as expressed in the server certificate.  The client MUST NOT
      use any form of the server hostname derived from an insecure
      remote source (e.g., insecure DNS lookup).  CNAME canonicalization
      is not done.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it MUST be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  A "*" wildcard character MAY be used as the left-most name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

Badra                     Expires May 21, 2012                  [Page 5]
Internet-Draft  SCSV for TLS Client Credential Protection  November 2011

   o  If the certificate contains multiple names (e.g., more than one
      dNSName field), then a match with any one of the fields is
      considered acceptable.

   If the match fails, the client MUST either ask for explicit user
   confirmation or terminate the connection and indicate the server's
   identity is suspect.

   Additionally, the client MUST verify the binding between the identity
   of the server to which it connects and the public key presented by
   this server.  The client SHOULD implement the algorithm in Section 6
   of [RFC5280] for general certificate validation, but MAY supplement
   that algorithm with other validation methods that achieve equivalent
   levels of verification (such as comparing the server certificate
   against a local store of already-verified certificates and identity
   bindings).

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted.

   It will depend on the application whether or not the server will have
   external knowledge of what the client's identity ought to be and what
   degree of assurance it needs to obtain of it.  In any case, the
   server typically will have to check that the client has a valid
   certificate chained to an application-specific trust anchor it is
   configured with, following the rules of [RFC5280], before it
   successfully finishes the TLS handshake.

   One widely accepted layering principle is to decouple service
   authorization from client authentication on access.  We therefore
   recommend that authorization decisions be performed and communicated
   at the application layer after the TLS handshake has been completed.

5.  Acknowledgements

   In August 2000, Francisco Corella proposed adding identity protection
   to TLS by changing the order of TLS messages.

   This document borrows text from RFC5746 and from [Hajjeh] as well.

6.  Contributor's Address

   Ibrahim Hajjeh
   Ineovation
   France

Badra                     Expires May 21, 2012                  [Page 6]
Internet-Draft  SCSV for TLS Client Credential Protection  November 2011

   EMail: ibrahim.hajjeh@ineovation.fr

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
              Extension Definitions", RFC 6066, January 2011.

7.2.  Normative References

   [I-D.hajjeh-tls-identity-protection]
              Hajjeh, I. and M. Badra, "Credential Protection
              Ciphersuites for Transport Layer Security (TLS)",
              draft-hajjeh-tls-identity-protection-09 (work in
              progress), November 2009.

   [I-D.urien-badra-eap-tls-identity-protection]
              Urien, P. and M. Badra, "Identity Protection within EAP-
              TLS", draft-urien-badra-eap-tls-identity-protection-01
              (work in progress), October 2006.

Author's Address

   Mohamad Badra
   DU

   Email: mbadra@gmail.com

Badra                     Expires May 21, 2012                  [Page 7]