Internet Draft K. Malbrain Intended status: Informational Petz Enterprises LLC Expires: December 31, 2013 September 17, 2013 Problem Statement: Deployment of TLS Strong Authentication draft-malbrain-tls-strong-authentication-00 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 31, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Malbrain Expires December 31, 2013 [Page 1] Internet-Draft TLS Authentication September 2013 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. Abstract The security provided by authenticated TLS connection between clients and servers should protect both parties from "Man-in- the-Middle" (MITM) attacks. Clients should be authenticating that the server they are connected to is the server they requested, and servers that act as client agents need to authenticate that the connection is directly to their client. An extension to the Domain Name System (DNS), The DNS-Based Authentication of Named Entities (DANE) (RFC 6698), allows TLS servers to publish their public certificates for use by TLS clients to authenticate the server connection. Table of Contents An extension to the Domain Name System (DNS), The DNS-Based Authentication of Named Entities (DANE) (RFC 6698), allows TLS servers to publish their public certificates for use by TLS clients to authenticate the server connection................2 1. Introduction..............................................3 2. The Global directory of servers' public keys (DANE).......3 3. TLS authentication of clients by servers..................3 4. MITM and Login Hacker attacks are precluded on strongly authenticated TLS connections................................4 5. Why this is not working as designed to obviate attacks and what can be done about the current state of affairs..........4 5.1. Browser vendors don't like the DANE protocol because it requires an additional DNS request to obtain both the Domain IP address and public certificate for the DNS Server4 5.2. The average internet user doesn't have a signed public certificate and private key pair signed by a CA...........5 5.3. Server software doesn't ask for user certificates during TLS negotiations..........................................5 6. References................................................5 6.1. Normative References ...................................5 7. Acknowledgments...........................................5 Malbrain Expires December 17, 2013 [Page 2] Internet-Draft TLS Authentication September 2013 1. Introduction TLS strong authentication by clients of their servers relies on comparison by the client of public certificates authenticated by TLS session negotiations [RFC 5246 Appendix F] with a trusted copy of the certificate. DANE is a database of public key certificates published by the Domain Name owners in the DNS database, and made available by appropriate DNS queries. On the server side there is currently only client certificate signing by Certificate Authorities (CA) under current TLS strong authentication of clients by servers [RFC 5246 Appendix D]. Few servers demand authentication because of the lack of signed client certificates. 2. The Global directory of servers' public keys (DANE) A network of DNS servers stores and makes available via query the public key certificates and IP address submitted and maintained by their Domain Owners. Whenever a client application needs an authenticated and secure TLS connection into a Domain, DNS supplies the Domain's IP address and public certificate. 3. TLS authentication of clients by servers At the end of TLS session negotiation, the TLS implementation optionally makes available the client's public certificate if requested during TLS negotiations. This currently must be a certificate signed by one of the CA and a hash of the certificate could be used by the server to authenticate the connection to an established client that the server recognizes from previous connections. Otherwise, it is up to the server and client to authenticate the certificate with a non-standard challenge exchange. If the server desires strong authentication and is open to connections from new clients, it should save a hash of the client certificate as part of the account data for authentication in future client logins. Unfortunately, there is no standard challenge/response by the server of the client's public and private key in the current TLS version 1.2. which is needed to use self-signed certificates. Malbrain Expires December 17, 2013 [Page 3] Internet-Draft TLS Authentication September 2013 4. MITM and Login Hacker attacks are precluded on strongly authenticated TLS connections Making use of the public keys from the server certificates, TLS strong authentication includes a challenge that the certificate presenter holds the private key for the public certificate. A MITM attacker inserts a middle point between the client and the server under a forged bogus certificate provided to the client during TLS session negotiations. Since there is a reliable source of server's public certificates available through DANE, it is now possible for the client to recognize the forged certificate used by the bogus connection by comparison with the server certificate registered for the Domain Name with DNS. Likewise the server could utilize a hash of the client's public certificate to recognize connections to previously established accounts prior to demanding the account name and password. 5. Why this is not working as designed to obviate attacks and what can be done about the current state of affairs The ability by TLS to perform for strong authentication by clients of server certificates during TLS negotiations is widely deployed. DANE provides the capability to post and retrieve IP addresses and public certificates for Domain Names in the DNS system. Servers could take the extra step to authenticate client certificates. 5.1. Browser vendors don't like the DANE protocol because it requires an additional DNS request to obtain both the Domain IP address and public certificate for the DNS Server DNS requests and their response are normally made using a single UDP packet. The size of the packet is limited by the DNS protocol to 512 bytes. Either by utilizing larger packet sizes, up to 65536 bytes in IPv4, or by utilizing tcp connections, along with an ability to request and return both the Domain Name IP address and public certificate in a single request could solve this problem. Malbrain Expires December 17, 2013 [Page 4] Internet-Draft TLS Authentication September 2013 5.2. The average internet user doesn't have a signed public certificate and private key pair signed by a CA Certificate generating software is freely available. Browser vendors could incorporate self-signed public/private key certificates on demand. The TLS server authentication of the client could be based on an additional challenge/response message exchange. 5.3. Server software doesn't ask for user certificates during TLS negotiations Server operators need to exercise due diligence in securing client connections beyond the traditional login account and password to guarantee that private information is not being revealed to third parties. Storing and comparing on each connection the hash of the user's public certificate for each server account would provide another layer of security for the internet. 6. References 6.1. Normative References [RFC6698] Hoffman P. and Schlyter, J., "The DNS-Based Authentication of Named Entities (DANE)", RFC 6698, August 2012. [RFC5246] Dierks T. and Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 7. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Copyright (c) 2013 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license- info). Malbrain Expires December 17, 2013 [Page 5] Internet-Draft TLS Authentication September 2013 Copyright (c) 2013 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license- info). Author's Address Karl Malbrain Petz Enterprises, LLC 7575 W Linne Rd Tracy, CA 95377 Email: Malbrain at Yahoo dot com Malbrain Expires December 17, 2013 [Page 6]