Programmazione di una fase di VPN, autenticazione - non RFC abbastanza chiaro

Question

ho una generazione personalizzata di un sistema operativo Unix.

Il mio compito:. Aggiunta di un IPSec al sistema operativo

sto lavorando su di fase I, fatto inviando i primi 2 pacchetti.

Quello che sto cercando di fare ora sta facendo il Payload Identification. Ho letto RFC 2409 (Apendix B), che discutono i materiali di codifica (SKEYID, SKEYID_d , SKEYID_a, SKEYID_e e il IV making ).

Ora, io uso SHA-1 per authontication e, quindi, io uso HMAC-SHA1 e il mio algoritmo di crittografia è AES-256. Il vero problema è che la RFC non è abbastanza chiara di che cosa devo fare per quanto riguarda la PRF . Dice:

  

"L'uso del PRF negoziati possono richiedere la   uscita PRF da espandere causa   il meccanismo di feedback PRF dipendenze   questo documento ".

Io uso SHA-1, significa che non negoziare un PRF?

A mio parere, AES è l'unico algoritmo che ha bisogno di expention (una lunghezza fissa di 256 bit), quindi, ho bisogno di espandere solo la SKEYID_e?

Se vi capita di conoscere una più chiara, anche se relible, fonte allora la RFC si prega di inviare un link.

Answer 1

Non si può negoziare un PRF basata esclusivamente su RFC2409, quindi non preoccupatevi di questo. 3 chiave Triple-DES, AES-192 e AES-256 tutti richiedono l'algoritmo di espansione chiave nella Appendice B. Molte implementazioni hanno questi, in modo da testare l'interoperabilità non dovrebbe essere difficile.

Answer 2

Le RFC IETF spesso non sono abbastanza chiare. Tuttavia, essi sono scritti per il solo scopo di descrivere l'interoperabilità in modo da trovare un'implementazione di riferimento a uno esplorare il suo codice o prova contro è quasi indispensabile. Infatti 2409 nota particolare:

  

Gli autori incoraggiano implementazione indipendente e test di interoperabilità, di questo protocollo ibrido.

Trovare un'altra implementazione è quello che si ha realmente bisogno; trovando fonte di qualcun altro è ancora meglio. In mancanza di ciò, leggere la bibliografia. E 'stato detto che alcuni RFC scritti da alcune aziende intenzionalmente offuscare o semplicemente nascondere le informazioni necessarie per produrre un'implementazione conforme al fine di costruire 'vantaggio di mercato'. Non v'è alcuna strada maestra per la comprensione 2049.