Internet DRAFT - draft-badra-tls-identity-protection
draft-badra-tls-identity-protection
TLS Working Group M. Badra
Internet-Draft DU
Intended status: Standards Track March 27, 2012
Expires: September 28, 2012
SCSV for TLS Client Credential Protection
draft-badra-tls-identity-protection-02.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 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
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 September 28, 2012 [Page 1]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The cipher suite TLS_IDENTITY_PROTECTION_SCSV . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
6. Contributor's Address . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Badra Expires September 28, 2012 [Page 2]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
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 September 28, 2012 [Page 3]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
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 established by changing the
order of the messages that the client sends after receiving
ServerHelloDone [CORELLA]. It consists of sending 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
that subsequent messages will be protected under the cipher suite and
keys negotiated during the TLS Handshake. However, at its
publication date, this solution required a major change to the TLS
state machine as well as a new TLS version. Currently, it is
possible to change the order of the message by defining new TLS
extensions [Google].
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
Badra Expires September 28, 2012 [Page 4]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
is communicated to others.
Clients that choose to protect their credentials MUST provide the
TLS_IDENTITY_PROTECTION_SCSV SCSV in their ClientHello.
When a ClientHello is received, the server MUST check if it includes
the TLS_IDENTITY_PROTECTION_SCSV:
o If the server does not support the client credential protection
described here, the server MUST abort the handshake (by sending a
fatal handshake_failure alert).
o If the server supports the client credential protection described
here, 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 MAY abort the session
by sending a fatal handshake failure alert.
A TLS server who supports the TLS_IDENTITY_PROTECTION_SCSV MUST
compute the verify_data as follows:
verify_data
PRF(master_secret, finished_label, Hash(handshake_messages + { 0xXX,0xXX }))
[0..verify_data_length-1];
where "+" denotes concatenation.
{ 0xXX,0xXX }
The code of TLS_IDENTITY_PROTECTION_SCSV SCSV.
When a ServerHello 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
that subsequent messages will be protected under the cipher suite and
keys negotiated during the TLS Handshake.
Badra Expires September 28, 2012 [Page 5]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
Client Server
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
ChangeCipherSpec
<-------- Finished
Certificate
CertificateVerify
Finished -------->
Application Data <-------> Application Data
Once a client received and validated the Finished message from the
server, it MUST send the Certificate and the CertificateVerify
messages to the server. If the client unsuccessfully validated the
Finished received from the server, the client MUST abort the
handshake (by sending a fatal decrypt_error alert).
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.
Actives attacks and eavesdroppers are impossible 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
Badra Expires September 28, 2012 [Page 6]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
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.
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
Badra Expires September 28, 2012 [Page 7]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
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
The author would like to acknowledge Martin Rex and the TLS mailing
list members for their comments on the document.
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
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.
Badra Expires September 28, 2012 [Page 8]
Internet-Draft SCSV for TLS Client Credential Protection March 2012
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
7.2. Informative References
[I-D.agl-tls-encryptedclientcerts]
Langley, A., "Transport Layer Security (TLS) Encrypted
Client Certificates",
draft-agl-tls-encryptedclientcerts-00 (work in progress),
October 2011.
[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 September 28, 2012 [Page 9]
