Internet DRAFT - draft-badra-tls-ciphersuite-identity-protection

draft-badra-tls-ciphersuite-identity-protection






TLS Working Group                                               M. Badra
Internet-Draft                                                        DU
Intended status: Standards Track                               I. Hajjeh
Expires: September 28, 2012                                   INEOVATION
                                                          March 27, 2012


 Credential Protection Ciphersuites for Transport Layer Security (TLS)
           draft-badra-tls-ciphersuite-identity-protection-00

Abstract

   This document defines a set of cipher suites to add client credential
   protection to the Transport Layer Security (TLS) protocol.  By
   negotiating one of those ciphersuites, 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.  The
   ciphersuites defined in this document can be used only when public
   key certificates are used in the client authentication process.

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 September 28, 2012.

Copyright Notice

   Copyright (c) 2012 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



Badra & Hajjeh         Expires September 28, 2012               [Page 1]

Internet-Draft     Credential Protection Ciphersuites         March 2012


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Conventions Used in This Document . . . . . . . . . . . . . 3
   2.  The Credential Protection Ciphersuites  . . . . . . . . . . . . 3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


































Badra & Hajjeh         Expires September 28, 2012               [Page 2]

Internet-Draft     Credential Protection Ciphersuites         March 2012


1.  Introduction

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

   This document specifies a set of cipher suites to add client
   credential protection to the TLS protocol.  These cipher suites reuse
   existing key exchange algorithms with certificate-based
   authentication, and reuse existing cipher and MAC algorithms from
   [RFC5246], [RFC5288], and [RFC5932].

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  The Credential Protection Ciphersuites

   The name of cipher suites defined in this document includes the text
   "CP" to refer to the client credential protection.  An example is
   shown below.


   CipherSuite                         Key Exchange   Cipher        Hash
   TLS_CP_RSA_WITH_AES_128_CBC_SHA     RSA            AES_128_CBC   SHA1


   The client indicates its willingness to protect its credentials by
   including one or more ciphersuites described here in the
   ClientHello.cipher_suites.  These cipher suites MUST be placed at the
   top of the cipher suite list.

   When one of the cipher suites defined through this document is
   negotiated, the client MUST send the ChangeCipherSpec message before
   the Certificate and the CertificateVerify messages and after the
   ClientKeyExchange message.













Badra & Hajjeh         Expires September 28, 2012               [Page 3]

Internet-Draft     Credential Protection Ciphersuites         March 2012


            Client                           Server

            ClientHello       -------->
                                             ServerHello
                                             Certificate
                                             CertificateRequest
                              <--------      ServerHelloDone
            ClientKeyExchange
            ChangeCipherSpec
                                             ChangeCipherSpec
                              <--------      Finished
            Certificate
            CertificateVerify
            Finished          -------->
            Application Data  <------->      Application Data


   If no certificates are available, the client MUST NOT include any
   credential protection cipher suite in the ClientHello.cipher_suites.

   If the server selects a cipher suite with client credential
   protection, the server MUST send a certificate appropriate for the
   negotiated cipher suite's key exchange algorithm, and MUST request a
   certificate from the client.  If the server, agreeing on using a
   credential protection cipher suite, 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.
   The client certificate MUST be appropriate for the negotiated cipher
   suite's key exchange algorithm, and any negotiated extensions.

   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.


3.  Security Considerations

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

   Active attackers can modify messages and insert, remove, or replace
   cipher suites.  An attacker could attempt to get the peers to
   negotiate a cipher suite that does not provide client credential
   protection.  However, actives attacks and eavesdroppers are



Badra & Hajjeh         Expires September 28, 2012               [Page 4]

Internet-Draft     Credential Protection Ciphersuites         March 2012


   impossible here because the client MUST terminate the connection
   immediately upon failure to receive a valid Finished from the server
   without sending the Certificate and CertificateVerify messages.  Such
   clients MUST generate a fatal "decrypt_error" alert prior to
   terminating the connection.

   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.

   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.




Badra & Hajjeh         Expires September 28, 2012               [Page 5]

Internet-Draft     Credential Protection Ciphersuites         March 2012


   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.


4.  IANA Considerations

   This section provides guidance to the IANA regarding registration of
   values related to the credential protection cipher suites.


   CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5              = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA              = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA         = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA          = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA          = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA256       = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA256       = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA     = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA     = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA256  = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA256  = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_GCM_SHA256  = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_GCM_SHA384  = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_ARIA_128_CBC_SHA256      = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_ARIA_256_CBC_SHA384      = { 0xXX,0xXX };
   CipherSuite TLS_CP_RSA_WITH_ARIA_128_GCM_SHA256      = { 0xXX,0xXX };



Badra & Hajjeh         Expires September 28, 2012               [Page 6]

Internet-Draft     Credential Protection Ciphersuites         March 2012


   CipherSuite TLS_CP_RSA_WITH_ARIA_256_GCM_SHA384      = { 0xXX,0xXX };



5.  Acknowledgements

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

   This document borrows text from [Hajjeh].


6.  References

6.1.  Normative References

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

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [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.

   [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
              Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
              August 2008.

   [RFC5932]  Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites
              for TLS", RFC 5932, June 2010.

6.2.  Informative 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.






Badra & Hajjeh         Expires September 28, 2012               [Page 7]

Internet-Draft     Credential Protection Ciphersuites         March 2012


Authors' Addresses

   Mohamad Badra
   DU

   Email: mbadra@gmail.com


   Ibrahim Hajjeh
   INEOVATION

   Email: ibrahim.hajjeh@ineovation.com







































Badra & Hajjeh         Expires September 28, 2012               [Page 8]