Problem Statement: Deployment of TLS Strong Authentication
draft-malbrain-tls-strong-authentication-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Karl Malbrain | ||
| Last updated | 2014-03-27 (Latest revision 2013-09-23) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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 their server connection is to the server they requested. Servers that act as client agents need to authenticate that the connection is directly to their client secure against eavesdropping or account/password hacking. 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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)