Programming a VPN, Authontication stage - RFC not clear enough

I have a custom build of a Unix OS.

My task: Adding an IPSec to the OS.

I am working on Phase I, done sending the first 2 packets.

What I am trying to do now is making the Identification Payload. I've been reading RFC 2409 (Apendix B) which discuss the keying materials (SKEYID, SKEYID_d, SKEYID_a, SKEYID_e and the IV making).

Now, I use SHA-1 for authontication and thus I use HMAC-SHA1 and my encryption algorithm is AES-256. The real pro开发者_如何学运维blem is that the RFC is not clear enough of what should I do regarding the PRF. It says:

"Use of negotiated PRFs may require the PRF output to be expanded due to the PRF feedback mechanism employed by this document."

I use SHA-1, does it mean I do not negotiate a PRF?

In my opinion, AES is the only algorithm that needs expention (a fixed length of 256 bit), so, do I need to expand only the SKEYID_e?

If you happen to know a clearer, though relible, source then the RFC please post a link.

---

You cannot negotiate a PRF based solely on RFC2409, so don't worry about that. 3 key Triple-DES, AES-192, and AES-256 all require the key expansion algorithm in Appendix B. Many implementations have these, so testing interoperability should not be that hard.

---

The IETF RFCs are often not clear enough. However, they are written for the sole purpose of describing interoperability so finding a reference implementation to either explore its code or test against is almost essential. Indeed 2409 specifically notes:

The authors encourage independent implementation, and interoperability testing, of this hybrid protocol.

Finding another implementation is what you really need; finding someone else's source is better still. Failing that, read the bibliography. It has been said that some RFCs written by some firms intentionally obfuscate or simply hide the information needed to produce a conformant implementation in order to build 'market advantage'. There is no royal road to understanding 2049.