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

[Matthias Bethke]

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.

> > 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 =^>
Pero claro, veo tu punto: está todo dentro del factible.


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. 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. 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. Caso sean idóneos como fuente de entropía, le
tocaría al que implementa el PRNG a usarlos en la inicialización.

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?

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."

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.

un abrazo,
	Matthias
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20120522/2cb51a79/attachment.sig>