Programming a VPN, Authontication stage - RFC not clear enough

views:

answers:

+1 Q:

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

+1 A:

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.

msw 2010-03-23 15:43:17

Thanks for the tip.I tried to look for my answer in the source code of the Linux 2.6 kernel, but could not find anything usful.Then I turned to some other open source IPSec project, I went through it's code for about 4 hours strait looking for the solution only to find a comment that stats that it is NOT IMPLEMENTED and if I happen to implement it, I may donate the code >.>Can any1 please try and help me on this one? my degree depends on it and I don't have much time, thanks in advance!

John 2010-03-24 11:38:15

The use of "may" in RFCs is a technical term. If you have found an exemplar in the field that does not implement the feature you now have proof that you can comformantly interoperate with at least one implementation. That's actually the best that you can do with an RFC. Since the feature is a "may", other conformant implementations cannot require that you do implement the feature. Unless you have a box that does implement it, you have literally no way to know if you have even gotten it right.

msw 2010-03-24 13:48:12

Even though employees of Cisco wrote the RFC, that in no way guarantees that they have implemented the "may" feature. It may have been a prospective addition that they never found need for. That is, you (as yet) have no evidence that any implementation exists anywhere. As such, you can claim that you are 2049 compliant until such a time as existence is otherwise demonstrated, in which case you are still conformant because of the "may".

msw 2010-03-24 13:54:20

+1 A:

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.

GregS 2010-03-24 14:07:16

Then I need expansion only to SKEYID_e and only while using key length > 160bit) and that's it, right?

John 2010-03-24 21:01:39

For encrypting IKE messages, yes. But you'll also need to to expand SKEYID_d when IPsec transforms ask for greater than 160 bits, for example RFC 3602. In that RFC, section 3.2 says "The minimum number of bits sent from the key exchange protocol to the ESP algorithm must be greater than or equal to the key size." Your IKE code is the key exchange protocol mentioned, so you have to expand SKEYID_d when AES-192 and AES-256 is used for ESP.

GregS 2010-03-25 14:00:15

Thank you very much :)

John 2010-03-27 17:56:14

ansaurus

tags:

views:

answers:

Programming a VPN, Authontication stage - RFC not clear enough

related questions