[LACNIC/Seguridad] [LAC-TF] Revisión de IETF I-D: draft-ietf-6man-stable-privacy-addresses-00.txt

[Fernando Gont]

Hola, Matthias,

Muchas gracias por tu feedback! -- Mis respuestas van entre lineas...

On 05/22/2012 02:26 PM, Matthias Bethke wrote:
> Fernando Gont on Mon, May 21, 2012 at 02:51:25AM -0300:
>> Mi plan es poder dedicar algo de tiempo este año a hacer algunos 
>> parches para algunos OSes, y entonces hacer una implementación
>> de draft-ietf-6man-stable-privacy-addresses tanto para Linux como
>> apra *BSDs.
> 
> Chévere. Imagino que el problema más difícil será encontrar un
> método universalmente aplicable de generar la llave secreta y
> después pasarlo del FS al kernel.

Exacto. En particular para que no "desencaje" con el modo de guardar
otra información similar en el kernel de cada sistema. -- Por eso mi
idea es consultar con cada OS antes de ponerme a hacer código, para
que me guien un poco en ese aspecto...



>>> pero quiero mencionar que 2^24 a un milisegundo por intento son
>>>  sólo 2^24/3600/1000 = 4.66 horas -- nada que presentaría un
>>> gran problema en una red sin IDS. Eso es el caso para un
>>> escaneo exhaustivo (sin tomar en cuenta los clusters de MACs)
>>> de un sólo manufacturer de tarjetas. En la realidad vas a tener
>>> que escanear quizás una docena de estos para tener la mayoría
>>> de equipos en una compañía mediana cubiertos.
>> 
>> Ese es el punto: incluso si asumis que vas a tener que escanear
>> varios OUIs (correspondientes a distintos manufacturers), el
>> ataque sigue siendo viable. Por ej., asumiendo 100 manufacturers,
>> y 4.66 horas para cada uno, el ataque tomaria 46 horas (tres
>> dias).
> 
> Están competiendo a confirmar las preconcepciónes sobre Latinos y
> el tiempo, eh? 46 horas son un poco menos que dos días y 466 unos
> 19 =^>

jaja.. tenés razón. :-) El otro dia, cuando me fui a dormir, me di
cuenta que me habia equivocado con los numeros... pero cuando me
desperte al dia siguiente me olvide de corregirme...


> Habiendo leído el draft entero para la primera vez, solamente tengo
> una duda sobre un punto (oh, y hay un typo en la primera línea del
> último paragrafo de sec.2: "that of use of" :)): lo de la
> generación de la llave aleatoria. La concatenación con el número de
> serie me parece que intenta solucionar un problema de un ámbito
> distinto, el del [P]RNG.

Es un muy buen punto. Creo que se podría simplificar un poquito el
algoritmo quitando esto del "numero de serie" -- que de hecho nos
fuerza a agregar un poco de texto sobre "qué hacer si el numero de
serie no se encuentra disponible".


> Si el PRNG no tiene suficiente entropía al tiempo de la
> instalación, hay que esperar o inclusive usar el SLAAC tradicional
> si la instalación requiera conectividad del la red y generar la
> llave después.

Algo a tener en cuenta es que, para esta apicacion en particular, si
bien es cierto que "cuanta mayor entropia tenga el PRNG, mejor", lo
cierto es que simplemente intentamos eliminar patrones previsibles de
las direcciones. Por tal motivo, creo que en gral se puede alcanzar
una entropia adecuada para esta aplicacion.


> Los números de serie son exactamente tan pseudo-aleatorios que los
> MACs: si tienes un poquito de información sobre el sistema que
> buscas, contribuyen muy poca entropía de verdad.

Si, la unica diferencia es que las MACs se leakean de manera mas simple.


> Caso sean idóneos como fuente de entropía, le tocaría al que
> implementa el PRNG a usarlos en la inicialización.

Creo que esto de poner la del numero de serie en el PRNG es un buen
punto. Voy a double-check con Steve Bellovin, quien habia apoyado esta
idea de concatenar el "machine serial number" con la llave.


> Es difícil a probar la conformidad de una implementación si es un 
> criterio "MUST" de cualquier forma: que *es* mi número de serie en 
> primer lugar? Lo que está imprimido en el chassis normalmente no
> se puede leer en el OS excepto en Big Iron. El CPUID si, pero de
> cual procesador? Y si el sistema ni tiene número de serie ni CPUID?
> Quizá la tarjeta de vídeo lo tenga, o algún chip obscuro en el
> sistema -- eso es que requiere el estándar?

Basicamente, el espiritu es que concatenes la clave con un numero que
no sea pervisible, apra aumentar la entropia. No importa en si que
numero usas, salvo que no se repita en cada equipo, y que no sea
facilmente predecible.



> Yo lo pondría como nota a desarrolladores nomas, como "Implementors
> should note that sufficient entropy to generate a key may be
> difficult to obtain at installation time. If this affects the
> system in question, implementations SHOULD preferably defer key
> generation until such time that enough entropy is available or look
> for other sources of difficult-to-guess information such as system
> serial numbers, partition UUIDs etc. to hash into the secret key."

Buen punto. Voy a chequear con Bellovin, y seguramente incorporar lo
que has propuesto.


> Finalmente, no soy experto en eso pero creo que todo encima de 64
> bits de entropía no va a mejorar el resultado si el output es de 64
> bits. O 63 en la verdad, por el #6=0.

Te referis a:

a) No mejora la entropia si F() tiene un output de 64 bit, o,
b) No mejora la entropia si el output de F() se *trunca* a 64 bits?


-- Porque dado que no forzamos ninguna funcion en particular, la
salida de F() podria ser mayor que 64 bits...

Un abrazo, y gracias!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492