La programación de un escenario VPN, autenticación - lo suficientemente RFC no está claro

Question

Tengo un encargo de la estructura de un sistema operativo Unix.

Mi tarea:. Adición de una IPSec para el sistema operativo

Estoy trabajando en la Fase I, hecho que envía los 2 primeros paquetes.

Lo que estoy tratando de hacer ahora es hacer la identificación de carga útil. He estado leyendo RFC 2409 (Apéndice B), que discute los materiales de incrustación (SKEYID, SKEYID_d , SKEYID_a, SKEYID_e y la IV decisiones).

Ahora, utilizo SHA-1 para authontication y por lo tanto yo uso HMAC-SHA1 y mi algoritmo de cifrado es AES-256. El problema real es que el RFC no es lo suficientemente clara de lo que debería hacer con respecto a la PRF . Dice:

  

"El uso de PRF negociados puede requerir la   PRF salida se expanda debido a la   el mecanismo de retroalimentación PRF empleado por   este documento. "

Yo uso SHA-1, ¿significa que no negocio un PRF?

En mi opinión, AES es el único algoritmo que las necesidades expention (una longitud fija de 256 bits), por lo que, ¿necesito para expandir sólo el SKEYID_e?

Si por casualidad usted conoce una más clara, aunque relible, entonces la fuente de RFC por favor enviar un enlace.

Answer 1

No se puede negociar un PRF basada únicamente en RFC2409, por lo que no se preocupe por eso. 3 claves Triple-DES, AES-192 y AES-256, requieren el algoritmo de expansión de claves en el Apéndice B. Muchas implementaciones tienen estos, lo que las pruebas de interoperabilidad no debería ser tan difícil.

Answer 2

Los IETF RFC a menudo no son lo suficientemente clara. Sin embargo, están escritos con el único propósito de describir la interoperabilidad por lo que encontrar una implementación de referencia ya sea a explorar su código o una prueba en contra es casi imprescindible. En efecto 2409 específicamente notas:

  

Los autores animan aplicación independiente, y las pruebas de interoperabilidad, de este protocolo híbrido.

Encontrar a otra implementación es lo que realmente necesita; la búsqueda de la fuente de otra persona es mejor aún. De no ser así, leer la bibliografía. Se ha dicho que algunos RFC escritos por algunas empresas intencionadamente obfuscate o simplemente ocultan la información necesaria para producir una aplicación conforme con el fin de construir 'ventaja en el mercado'. No hay camino real para la comprensión de 2049.