F5 iRule Example integrating HMAC

Sure.. It was an off-the-wall idea a friend and I had, so glad to put it out there for others to enjoy. I am just glad you had the chops to code it. My attempts were too ugly for the public eye (Network guy coding = very ugly code)...

Kai.. quick question on the logic. It looks like you are validating the cached hmac_values hash against the hmac_cookie value when the two cookies (application cookie and hmac cookie are present). This compares the hash of the two values instead of the values that made the hash. Do you think there is a concern since the actual hashed value is being passed as a cookie? Wouldn't you want to compare the values or is verification of the hash enough validation? Is there any reason you are not rejecting the session from being established or do you see removing the cookie as a forcing function (just scared of creating a scenario where there is an endless cycle of connection attempts with no failure). Lastly, in the response, you used http::header insert instead of http::cookie insert. I know the header command is the older version, but is their a reason you went with header insert? Thanks

Hey Devon,

Doesn't this present a hole in the security, or is comparing the hashed value the check?

The HMAC security check is indeed just a compare funtion.

You compute the HMAC token on each Set-Cookie so that the client gets the fitting HMAC cookie for its APP cookie at the very same time.

On each request you'll then either use the cached HMAC token (cache key = app cookie and X509) or a fresh computed HMAC token (always computable based on the app cookie and X509) to compare it with the received HMAC cookie value.

Also, noticed if the applicaiton cookie or hmac cookie returns nothing, you create a new one. Is there any reason we are not rejecting the session from being established or do you see removing the cookie as a forcing function

Rejecting the session would be to agressive and cause the client to never get the initial app and hamc cookie.

But I do remove the cookie evertime the client is sending just the app cookie or if the hmac and app cookie simply doesn't match. Removing the cookie is the same as the client didn't received/send it. So the application have to issue a new one (after reauthentication, etc.) and while the new Set-Cookie is passed to the client a fresh HMAC cookie is injected to the client again.

So this shouldn't loop as long as nobody is trying to manipulate either of the cookie values.

Note: Don't spend much time in this outdated code. My latest version is much more advanced and easier to understand. I hope to get my testings done till end of the week. I'll then publish the v10 and v11 version to the code share. So stay tuned... ;-)

Cheers, Kai

Hi Devon,

I've just published my latest code to the CodeShare...

High Performance HMAC Cookie Signing

https://devcentral.f5.com/codeshare/high-performance-hmac-cookie-signing

High Performance HMAC Cookie Signing (for v10.x)

https://devcentral.f5.com/codeshare/high-performance-hmac-cookie-signing-for-v10x

Let me know if you have any questions left... ;-)

Cheers, Kai