[Anterior]

[Tabla de Contenidos]

[Siguiente]

Mejoras y Extensiones a TLS

 

Esta página tiene el proposito de describir los Internet Drafts de la IETF que están relacionados con el uso y prácticas relacionadas con TLS.

 

HTTPS

Corrientemente, hay dos Drafts que tienen que ver con la implementación del protocolo HTTP usando TLS como protocolo de transporte, mejor conocido como HTTPS.

Aunque HTTPS está implementado en la mayoría de los web browsers y Web servers, todavía no esta estandarizado.
Actualmente el servicio HTTP corre sobre el port 80, mientras el servicio HTTP/TLS (HTTP sobre TLS) corre sobre el port 443. El centro de la discusión es si HTTP debería seguir utilizando el port 80 para transferencias de datos sin seguridad y usar el port 443 para transferencias de datos seguras, o si HTTP y HTTP/TLS deben utilizar el mismo port 80.

HTTP y HTTPS sobre port 80

<draft-ietf-tls-http-upgrade-00.txt>

La solución presentada en este Draft es agregar a la definición de HTTP el string "TLS/x.y" donde x.y es la versión de TLS.

Un cliente (web browser) debería agregar "Upgrade: TLS/1.0" al pedido inicial, indicando que soporta TLS 1.0, y los servers deberían responder con "101 Switching Protocol", completar el handshake, y continuar con la respuesta "normal" al pedido original.

El potencial problema de ataques del tipo "man-in-the-middle" es precisamente el mismo que el de http/https sobre ports distintos.

HTTP sobre port 80 y HTTPS sobre port 443

<draft-ietf-tls-https-02.txt>

Este Draft describe la práctica corriente de usar HTTP y HTTP/TLS sobre ports de server diferentes.

Conceptualmente, HTTP/TLS es muy simple. Simplemente usar HTTP sobre TLS precisamente como usaríamos HTTP sobre TCP.

Para realizar la conexión, el cliente HTTP (web browser) debería actuar también como el cliente TLS. Este debería iniciar una conexión con el server sobre el port apropiado y luego enviar el TLS ClientHello para empezar el handshake TLS. Cuando el handshake TLS haya terminado, el cliente podría luego iniciar el primer pedido HTTP. Todos los datos HTTP deben ser enviados como "datos de aplicación" de TLS.

El cliente debe autenticar el server con el que se quiere conectar, puede hacer o no el Paso 4 en Autenticación del Server. Por lo general, el server no autentica al cliente.

 

Nuevos Ciphersuites

Cambios recientes en las regulaciones de exportación de US permiten la exportación de software con capacidades de encriptación de datos con claves de 56 bits e intercambio de claves de hasta 1024 bits.
Por otro lado, dada la creciente popularidad de los ECC (Criptosistemas de Curva Elíptica) a causa de que parece que son más seguros que el RSA y más rápido de calcular.

Claves de 56 bits

<draft-ietf-tls-56-bits-ciphersuites-00.txt>

La siguiente tabla enumera los nuevos ciphersuites incorporados a TLS.

Intercambio
de Claves
Clave
Intercambio
Cipher Clave
Cipher
Exportable Hash
RSA 1024 bits DES (CBC) 56 bits SI SHA
RSA 1024 bits RC4 56 bits SI SHA
Diffie-Hellman (efimera, firma DSS) 1024 bits DES (CBC) 56 bits SI SHA
Diffie-Hellman (efimera, firma DSS) 1024 bits RC4 56 bits SI SHA
Diffie-Hellman (efimera, firma DSS) sin límite RC4 128 bits NO SHA

 

Soporte de Elliptic Curve Cryptosystems (ECC)

<draft-ietf-tls-ecc-00.txt>

Este documento describe un agregado a TLS para que soporte el Elliptic Curve Cryptosystem (ECC).
El documento define cipher suites, los cuales usan los siguientes algoritmos de establecimiento de clave: ECES (Elliptic Curve Encryption Scheme), ECDSA (Elliptic Curve Digital Signature Algorithm), ECNRA (Elliptic Curve Nyberg-Rueppel Signature Scheme with Appendix), ECDH (Elliptic Curve Diffie-Hellman Key Agreement), ECMQV (Elliptic Curve Menezes-Qu-Vanstone Key Agreement).

 

Incorporación de Kerberos Cipher Suites a TLS

<draft-ietf-tls-kerb-cipher-suites-03.txt>

Este documento propone la incorporación de nuevos cipher suites para el protocolo TLS para soportar autenticación basada en Kerberos. Las credenciales Kerberos se usan para llevar a cabo una autenticación mutua y para establecer un master secret usado subsecuentemente para asegurar la comunicación cliente-servidor.

La opción de Kerberos debe agregarse en el mensaje ClientKeyExchange como se muestra a continuación:

{ 
    select (KeyExchangeAlgorithm)
    {
        case krb5:            KerberosWrapper;       /* new addition */
        case rsa:             EncryptedPreMasterSecret;
        case diffie_hellman:  ClientDiffieHellmanPublic;
    } Exchange_keys;

} ClientKeyExchange;

struct
{
    opaque Ticket;  
    opaque authenticator;            /* optional */
    opaque EncryptedPreMasterSecret; /* encrypted with the session key
                                        which is sealed in the ticket */
} KerberosWrapper;                   /* new addition */

 

Perfiles para Autorización usando AttributeCertificate

<draft-ietf-tls-ac509prof-00.txt>

El soporte para autorizaciones es requerido por varios protocolos de internet, por ejemplo TLS.

El X.509 AttributeCertificate provee una estructura con la cual se puede brindar tales servicios. Esta especificación define dos perfiles(uno simple y uno full) para el uso de X.509 AttributeCertificates al proveer los servicios de autorizacion.
La provision de autenticación, integridad de datos y servicios confiables para los protocolos de Internet son bien conocidos y muchos transportes seguros son definidos (ej. TLS, IPSEC etc.).
En muchas aplicaciones estos servicios no son suficientes para proveer el tipo de servicios de autorizaciones requeridos.

AttributeCertificates (ACs) provee un metodo que supera estos problemas.
AC tiene una estructura similar a X.509 public key certificate con la principal diferencia que no contiene public key. El tipico contenido de AC es, el miembro de grupo ( group membership), roles, derechos y otra informacion de control de acceso asociada al AC propio.En conjunto con los servicios de autenticacion, Acs provee el significado de transporte seguro de informacion de autorizaciones de aplicaciones.

 

<draft-ietf-tls-attr-cert-01.txt>

TLS posee autorizacion,integridad en los datos y servicios de confiabilidad para los protocolos de Internet.
En muchas aplicaciones estos servicios no son suficientes para proveer el tipo de server de autorizaciones requeridos.
Por ejemplo, el acceso a los recursos puede ser controlado en base a los derechos o roles de los clientes.

Otro requerimiento adicional es el soporte para delegaciones, donde un Server TLS intermediario actúa como Cliente,donde el objetivo final del Server TLS es decidir con estos accesos en base a los derechos de los clientes iniciales.
Mientras TLS no provee el soporte para estas características , AttributeCerficate en conjunto con TLS dan la solución.El draft anterior define un perfil de X.509 AttributeCertificate, el cual es usado en este contexto.

La parte importante embebida en el protocolo TLS es el intercambio entre el client y el server. AC acquisition (desde un issuer o directory) es manejado como un protocolo de alto nivel.

Se agregan dos nuevos mensajes en el Handshake Protocol, ACRequest y ACInfo.

Es estrictamente recomendado que el server solo acepte ACs de cliente autenticados.

Un server el cual se presenta con un AC, el cual es delegable va a poder ennmascararse como propietario del AC a cualquier otro de los servidores a los cuales el AC puede ser delegado. Esto significa que el cliente está efectivamente confiando en el server hasta el punto que el AC es delegable por ese server. Por esta razón se recomienda limitar el alcance de la delegacion de los Acs al minimo requerido.


[Anterior]

[Tabla de Contenidos]

[Siguiente]