Network Working Group P. Hoffman Petición de Comentarios: 3207 Internet Mail Consortium Obsoleto: 2487 Febrero 2002 Categoría: En proceso de estandarización Traducción: Juan de la Fuente Costa Extensión del servicio SMTP SMTP seguro sobre la capa de transporte seguro. Estado de este documento Este documento especifica un estándar de seguimiento de protocolo para la comunidad de Internet, abierto a discusión y sugerencias para mejorarlo. Para conocer el estado de estandarización y estado de este protocolo es aconsejable consultar la edición actualizada de "Estándares Oficiales Sobre Protocolos de Internet" (STD1). La distribución de este documento es ilimitada. Nota de Copyright Copyright (C) The Internet Society (1998). Todos los derechos reservados. Resumen Este documento describe una extensión al protocolo SMTP (Protocolo Simple de Transferencia de Correo) servicio que permite utilizar TLS (Capa de Transporte Seguro) para proporcionar una comunicación privada y autenticada a través de Internet. Este sistema permite a los agentes SMTP proteger algunas o todas sus comunicaciones de fisgoneos y ataques. 1. Introducción Los servidores SMTP [RFC281] y los clientes, normalmente se comunican en texto claro a través de Internet. En la mayoría de los casos, esta comunicación atraviesa uno o más routers que no están controlados o que no son confiables para el sujeto. Dichos dispositivos no confiables podrían permitir a un tercer elemento monitorizar o alterar el contenido de la comunicación entre el servidor y el cliente. Además, hay un frecuente deseo de que dos agentes SMTP sean capaces de autenticarse con las identidades del otro. Por ejemplo, un servidor SMTP seguro solo permite comunicaciones de otros agentes SMTP que conozca, o actuará de forma diferente para los mensajes recibidos de un agente que conozca frente a otro que desconozca. Hoffman Estándar [Pág. 1] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 TLS [TLS], comúnmente conocido como SSL, es un mecanismo habitual para habilitar comunicaciones TCP con privacidad y autenticación. TLS es ampliamente usado junto con el protocolo HTTP, y es usado también para añadir seguridad en muchos otros protocolos que funcionan sobre TCP. Este documento sustituye al RFC 2487. 1.1. Terminología Las palabras clave "TENER", "NO TENER QUE", "REQUERIDO", "PODRÍA", "NO PODRÍA", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PODER", y "OPCIONAL" en este documento han de ser interpretados como se describe en el [RFC 2119]. 2. Extensión STARTTLS La extensión STARTTLS de SMTP se presenta como sigue: (1) El nombre del servicio SMTP definido aquí es STARTTLS; (2) El valor de la palabra clave EHLO asociada con la extensión es STARTTLS; (3) La palabra clave STARTTLS no tiene parámetros; (4) Se define un nuevo verbo SMTP, "STARTTLS"; (5) No se añaden parámetros adicionales a ningún de los comandos SMTP. 3. La palabra clave STARTTLS La palabra clave STARTTLS se usa para indicarle al cliente SMTP que el servidor SMTP esta en disposición de negociar el uso de TLS. No lleva parámetros. 4. El comando STARTTLS El formato del comando STARTTLS es: STARTTLS Hoffman Estándar [Pág. 2] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 Sin parámetros. Una vez el cliente ha enviado el comando STARTTLS, el servidor responde con uno de los siguientes códigos de respuesta: 220 Listo para empezar TLS 501 Error de sintaxis (parámetros no permitidos) 454 TLS no disponible temporalmente Si el cliente recibe la respuesta 454, deberá decidir si continuar o no con la sesión SMTP. Esta decisión esta basada en una política local. Por ejemplo, si se esta usando TLS para la autenticación del cliente, este intentará continuar la sesión, en el caso de que el servidor lo permita incluso sin usar autenticación. Sin embargo, si la conexión TLS esta siendo negociada para permitir cifrado, un cliente que reciba una respuesta 454 necesitará decidir si enviar o no el mensaje sin cifrado TLS, si esperar e intentarlo más tarde, o si terminar el proceso y notificar el error al emisor. Un servidor SMTP referenciado públicamente NO TIENE QUE requerir el uso de la extensión STARTTLS cuando se va a distribuir el correo de forma local. Esta regla previene los problemas de interoperabilidad entre las extensiones STARTTLS y la infraestructura SMTP de Internet. Un servidor SMTP referenciado públicamente es un servidor que se ejecuta en el puerto 25 de un host de Internet listado en el registro MX (o un registro A en el caso de que el registro MX no este presente) para el nombre de dominio en la parte derecha de una dirección de correo de Internet. Cualquier servidor SMTP puede rechazar mensajes para enviar basados en la autenticación suministrada durante la negociación TLS. Un servidor SMTP que no este públicamente referenciado puede requerir que el cliente realice una negociación TLS previa a aceptar cualquier comando. En este caso el servidor DEBE de enviar el siguiente código de respuesta: 530 Debe enviar primero un comando STARTTLS para cualquier comando distinto de NOOP, EHLO, STARTTLS, o QUIT. Si el cliente y el servidor están usando la extensión ENHANCEDSATUSCODES ESMTP [RFC2034], el código de estatus mostrado DEBERIA DE SER 5.7.0. Después de recibir una respuesta 220 al comando STARTTLS, el cliente TIENE QUE comenzar la negociación TLS antes de enviar cualquier otro comando SMTP. Si, una vez enviado el comando STARTTLS el cliente descubre que algún fallo impide comenzar la negociación TLS, en ese caso, DEBERIA cancelar la conexión. Hoffman Estándar [Pág. 3] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 Si el cliente SMTP esta usando técnicas de "pipelinning" definidas en el RFC 2920, el comando STARTTLS debe de ser el último comando dentro de un grupo. 4.1 Procesamiento posterior al comando STARTSSL Una vez completada la negociación TLS, ambas partes TIENEN que decidir inmediatamente si continuar o no en base a la autenticación y la privacidad conseguida. El cliente SMTP y el servidor pueden decidir continuar incluso cuando la negociación haya terminado sin autenticación y/o privacidad puesto que la mayoría de los servicios SMTP están configurados sin autenticación y privacidad, pero algunos servidores o clientes SMTP solo permitirán continuar si se ha alcanzado cierto nivel de autenticación y privacidad. Si el cliente SMTP decide que el nivel de autenticación o privacidad no es suficientemente elevado para continuar, DEBERÍA enviar inmediatamente un comando SMTP QUIT cuando haya concluido la negociación TLS. Si el servidor SMTP decide que el nivel de autenticación o privacidad es insuficiente para continuar, entonces DEBERIA responder a todos los comandos SMTP desde el cliente (todos aquellos distintos del comando QUIT) con el código de respuesta 554 ( con una cadena de texto asociada al error que indique algo similar a "Comando rechazado debido a falta de seguridad"). La decisión de hacer o no confiable la autenticación de la otra parte de la negociación TLS es un problema local. Sin embargo, algunas reglas generales a la hora de tomar estas decisiones son: - Un cliente SMTP debería de intentar autenticarse únicamente con servidores SMTP cuyo certificado tenga un nombre de dominio que sea el mismo al que el cliente piensa que se esta conectando. - Un servidor SMTP referenciado públicamente probablemente inten- tará aceptar cualquier certificado verificable de un cliente SMTP, y posiblemente querrá incluir información distintiva entre el certificado en la cabecera del receptor de los mensajes que han sido distribuidos o enviados por el cliente. 4.2 Resultado del comando STARTTLS Una vez realizada la negociación TLS, el protocolo SMTP vuelve a su estado inicial (el estado del servidor SMTP posterior a recibir un mensaje 220 de servidor preparado). El servidor TIENE QUE descartar cualquier información recibida desde el cliente, como el argumento del comando EHLO, que no ha sido obtenido de la propia negociación Hoffman Estándar [Pág. 4] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 TLS. El cliente TIENE QUE descartar cualquier información obtenida del servidor, como la lista de extensiones SMTP, que no ha sido obtenida de la negociación TLS. El cliente DEBERÁ de enviar un comando EHLO como primer comando tras una negociación TLS con éxito. La lista de las extensiones SMTP mostradas en respuesta a un comando EHLO recibido después de la negociación TLS PUEDE SER diferente que la lista mostrada antes de la negociación. Por ejemplo, un servidor SMTP no tiene porque anunciar el soporte para un mecanismo SASL [SASL] hasta que un cliente haya enviado un certificado adecuado durante la negociación TLS. Ambos, cliente y servidor TIENEN QUE conocer si hay una extensión TLS activa. Un cliente NO TIENE QUE intentar iniciar una sesión TLS si ya esta activa otra. Un servidor NO TIENE QUE devolver la extensión STARTTLS en respuesta a un comando EHLO recibido una vez se ha completado la negociación. 4.3 STARTSSL en el puerto de envío El comando STARTSSL es una extensión ESMTP valida cuando se utiliza en el puerto de envío como se define en el [RFC 2476]. De hecho, desde que el puerto de envío es por definición el puerto de un servidor no publico, la extensión STARTTLS puede ser particularmente útil para la autenticación de este servicio. 5. Ejemplo de uso El siguiente dialogo ilustra como se inicia una sesión TLS entre cliente y servidor: S: C: S: 220 mail.imc.org SMTP servicio listo C: EHLO mail.example.com S: 250-mail.imc.org ofrece una calurosa bienvenida S: 250-8BITMIME S: 250-STARTTLS S: 250 DSN C: STARTTLS S: 220 Adelante C: C & S: C & S: C: EHLO mail.example.com S: 250-mail.imc.org acepta el saludo S: 250-8BITMIME S: 250 DSN Hoffman Estándar [Pág. 5] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 6. Consideraciones de seguridad Ha de resaltarse aquí que SMTP no es un mecanismo fin a fin. Por lo tanto, si un par cliente/servidor decide añadir privacidad TLS, no están securizando desde el agente emisor del mensaje hasta el destinatario. De hecho, la entrega de un elemento de correo electrónico puede viajar a través de más de dos servidores SMTP, añadiendo privacidad TLS a un par de servidores no se garantiza que la cadena de servidores SMTP que intervienen haya sido privada. Si vamos más allá, únicamente porque un servidor SMTP pueda autenticar a un cliente SMTP, esto no significa que el mensaje de correo electrónico desde el emisor SMTP haya sido autenticado cuando el destinatario lo recibe. Ambos, cliente y el servidor SMTP deben de comprobar que el resultado de la negociación TLS han conseguido un grado de autenticación y privacidad aceptable. Ignorar este paso invalida completamente el uso de TLS como elemento de seguridad. La decisión sobre si se ha logrado o no la autenticación y privacidad se valora localmente, esta es una medida que depende de la implementación, y no es objeto del presente documento. El cliente y servidor SMTP deberá tratar cuidadosamente el resultado de la negociación TLS. Si la negociación resulta negativa, o si en los resultados de la misma se permiten únicamente algoritmos o longitudes de clave los cuales son probadamente inseguros o no son suficientemente fuertes, o si la autenticación no es suficientemente buena para alguna parte, el cliente ha de escoger finalizar la sesión SMTP de forma inmediata con un comando QUIT, o el servidor deberá decidir no aceptar ningún otro comando SMTP. Un ataque de hombre en el medio puede ser ejecutado eliminado la respuesta "250 STARTTLS" del servidor. Esto hace que el cliente no intente iniciar una sesión TLS. Otro de los ataques de hombre en el medio es permitir al servidor anunciar el soporte para STARTTLS, pero alterando la petición de inicio de sesión TLS y la respuesta del servidor. Las contramedidas a este respecto para cliente y servidor pasan por forzar una correcta negociación TLS y establecer un nivel de cifrado adecuado previo al envío de cualquier mensaje. Las implementaciones de dichas contramedidas deberán permitir registrar la TLS empleada en la comunicación con uno de los puntos y mostrar una alerta si no se usa la misma en una sesión posterior. Si la negociación TLS falla o el cliente recibe una respuesta 454, el cliente tiene que decidir como proceder. Principalmente hay tres opciones: continuar con el resto de la sesión SMTP, reintentar la negociación TLS más tarde, o finalizar la sesión y rechazar el mensaje enviándolo al remitente. Si se produce un fallo, el cliente puede asumir que el servidor será capaz de negociar en TLS próximamente, y que por lo tanto se volverá a intentar la negociación Hoffman Estándar [Pág. 6] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 más tarde, cuando expire un tiempo asignado localmente, trascurrido el cual, el cliente debería rechazar el mensaje de correo electrónico y enviarlo al remitente. Sin embargo, si el cliente y servidor únicamente utilizan TLS para la autenticación, el cliente intentará continuar con la sesión SMTP, en el caso de que algunas de las operaciones por parte del cliente sean aceptadas incluso cuando el cliente no este autenticado. Antes del comienzo de la negociación TLS, cualquier interacción con el protocolo se realizará en texto claro y puede ser modificada por terceros. Por este motivo, tanto clientes como servidores TIENEN que descartar cualquier información obtenida previamente a la negociación TLS hasta que esta se haya completado. La extensión STARTTLS no puede garantizar la autenticidad del autor de mensaje, a no ser que todos los saltos de la cadena de distribución sean autenticados incluido el primer servidor SMTP. Para garantizar este propósito se puede emplear [SMTP-AUTH] para autenticar la distribución y partes seguras MIME, [MIME-SEC] para verificar el autor del mensaje de correo electrónico. En resumen, [SMTP-AUTH] aporta mayor sencillez y flexibilidad para la autenticación del cliente SMTP y un mecanismo externo SASL [SASL] que PUEDE ser usado junto con el comando STARTTLS para facilitar una identidad autorizada. 7. Referencias [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. Hoffman Estándar [Pág. 7] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Anexo Este documento es una revisión del RFC 2487, que esta propuesto para Estándar. Los cambios en relación con dicho documento son: - Sección 4.3: Añadida la sección "STARTTLS en el puerto de envio" - Sección 5 y 7: Mayor detalle en relación con los ataques de hom- bre en el medio. - Sección 5: Mayor detalle en los casos en que un servidor debe o no anunciar la extensión STARTTLS. - Sección 5: Modificados los requisitos en los clientes SMTP trás recibir una respuesta 220. - Sección 5.1: Clarificada la descripción de la verificación de certificados. - Sección 6: Eliminado el fallo en el ejemplo que indica que el cliente ha de enviar un nuevo comando EHLO, como se describe en la sección 5.2 - Sección 7: Clarificación del párrafo del grado de privacidad. Cambio significativo en las contramedidas frente a ataques de hombre en el medio. - Sección A: Referencia actualizada del RFC 821 al RFC 281. Dirección del Autor Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 Phone: (831) 426-9827 EMail: phoffman@imc.org Hoffman Estándar [Pág. 8] RFC 3207 Extensión del SMTP - SMTP seguro sobre TLS febrero 2002 Declaración completa sobre los Derechos de la propiedad intelectual Derechos de la propiedad intelectual (C) La Sociedad de Internet (2002). Todos los derechos reservados. Puede copiarse este documento y/o sus traducciones, también pueden ser añadidos a otros documentos, y se pueden elaborar trabajos derivados que añadan o por otra parte expliquen o ayuden en su aplicación para ser, copiadas, publicadas y distribuidas, totalmente o en parte, sin restricción de ningún tipo, siempre y cuando se incluyan de forma íntegra el aviso de copyright anterior y este párrafo en todas las copias y los trabajos derivados. Por lo tanto, este documento no puede modificarse de forma alguna, quitando el aviso del derecho de la propiedad intelectual o referencias a la La Sociedad de Internet u otras organizaciones de Internet, excepto cuando sea necesario debido al desarrollo de estándares de Internet y en ese caso deben seguirse los procedimientos para los derechos de la propiedad intelectual definidos en los estándares de Internet, o según se requiera cuando se traduzca a otras lenguas distintas del inglés Los permisos concedidos limitados lo son a perpetuidad y no se revocarán por La Sociedad de Internet, sus sucesores o concesionarios. Este documento y la información contenida en él se proporcionan "TAL CUAL" LA SOCIEDAD DE INTERNET Y LA DIVISIÓN DE INGENIERIA DE INTERNET DECLINAN TODAS LAS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUYENDO PERO NO LIMITANDO A CUALQUIER GARANTÍA QUE EN EL USO DE LA INFORMACIÓN CONTENIDA NO SE INFRINGIRÁ NINGÚN DERECHO O CUALQUIER GARANTÍA IMPLÍCITA DE COMERCIALIZACIÓN O LA APTITUD PARA UN PROPÓSITO PARTICULAR. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hoffman Estándar [Pág. 9]