Message-Authenticator for CoA/DM vs Access Request/Accounting/Status
I've been reading through RFC 2869 section 5.14 http://tools.ietf.org/html/rfc2869#section-5.14 And RFC 5176 Section 3.4 http://tools.ietf.org/html/rfc5176#section-3.4 And from how I understand it and how this is implemented by FreeRadius in 3.0.3 and 2.2.5. Access-Request or Accounting or Status Messages: The Message-Authenticator is calculated after the packet Authenticator has been generated using a HMAC-MD5 with the Message-Authenticator being a zero 16 byte string and then the HMAC-MD5 calculated using the shared secret as the key then replaced over the 16 zero byte field with the calculated value. So a packet would look like this if the User-Name was "bob" with password "hello" and the shared secret of "testing123" Request to HMAC-MD5 calculate: 0101002b14dbc57d377ba1846411553a49bf019b0105626f62501200000000000000000000000000000000 HMAC-MD5 46ecb6b4dde2c7e15a7d2a86fb05f1b2 Resulting request: 0101002b14dbc57d377ba1846411553a49bf019b0105626f62501246ecb6b4dde2c7e15a7d2a86fb05f1b2 Whereas because of this line in RFC5176 with my emphasis on the word before: "The Message-Authenticator Attribute is calculated and inserted in the packet *before* the Request Authenticator is calculated." So this means that the Message-Authenticator HMAC value should be calculated on the assumption the Packet Authenticator is all zero bytes so it would look something like this: 2b90002b000000000000000000000000000000000105626f62501200000000000000000000000000000000 And then the Packet Authenticator and the Message-Authenticator gets added in and you end up with a packet like this: 2b90002b9b6756059c3b56559d67f44418ae1fb70105626f6250125d68bd8fc122f6f2346e51872ba21fc3 Is this correct? As that is how it seems to be working for me. And I just wanted to make sure I was approaching this correctly. As it seems a little strange that the CoA/DM messages would prefer to have a null Authenticator message when calculating a Message-Authenticator. But it seems to be the way it is. Cheers Peter
Peter Lambrechtsen wrote:
So this means that the Message-Authenticator HMAC value should be calculated on the assumption the Packet Authenticator is all zero bytes
Yes. That's how FreeRADIUS works. The code is available, you just need to read it.
so it would look something like this:
2b90002b000000000000000000000000000000000105626f62501200000000000000000000000000000000
And then the Packet Authenticator and the Message-Authenticator gets added in and you end up with a packet like this:
2b90002b9b6756059c3b56559d67f44418ae1fb70105626f6250125d68bd8fc122f6f2346e51872ba21fc3
Not entirely. Order is important. Step 1: 2b90002b000000000000000000000000000000000105626f62501200000000000000000000000000000000 Step 2: 2b90002b000000000000000000000000000000000105626f6250125d68bd8fc122f6f2346e51872ba21fc3 Step 3: 2b90002b9b6756059c3b56559d67f44418ae1fb70105626f6250125d68bd8fc122f6f2346e51872ba21fc3
Is this correct? As that is how it seems to be working for me. And I just wanted to make sure I was approaching this correctly. As it seems a little strange that the CoA/DM messages would prefer to have a null Authenticator message when calculating a Message-Authenticator. But it seems to be the way it is.
You have to calculate one and then the other. There's no way to do both at the same time. Alan DeKok.
On Tue, Jun 10, 2014 at 1:28 AM, Alan DeKok <aland@deployingradius.com> wrote:
Peter Lambrechtsen wrote:
So this means that the Message-Authenticator HMAC value should be calculated on the assumption the Packet Authenticator is all zero bytes
Yes. That's how FreeRADIUS works. The code is available, you just need to read it.
so it would look something like this:
2b90002b000000000000000000000000000000000105626f62501200000000000000000000000000000000
And then the Packet Authenticator and the Message-Authenticator gets added in and you end up with a packet like this:
2b90002b9b6756059c3b56559d67f44418ae1fb70105626f6250125d68bd8fc122f6f2346e51872ba21fc3
Not entirely. Order is important.
Step 1:
2b90002b000000000000000000000000000000000105626f62501200000000000000000000000000000000
Step 2:
2b90002b000000000000000000000000000000000105626f6250125d68bd8fc122f6f2346e51872ba21fc3
Step 3:
2b90002b9b6756059c3b56559d67f44418ae1fb70105626f6250125d68bd8fc122f6f2346e51872ba21fc3
Is this correct? As that is how it seems to be working for me. And I just wanted to make sure I was approaching this correctly. As it seems a little strange that the CoA/DM messages would prefer to have a null Authenticator message when calculating a Message-Authenticator. But it seems to be the way it is.
You have to calculate one and then the other. There's no way to do both at the same time.
Thanks Alan, that is what I had realised (after reading the code, and wanting to make sure I was reading it correctly as C isn't my strong suit). I had mis-understood and now know that the Packet Authenticator needs to be a "proper" one based off the MD5 of the Packet Type/Identifier/Attributes rather than just the purely random number that is used for the Access-Request. After I figured out the MD5 encoding process from Step 2 to Step 3 then everything works. I now have a working JMeter test suite that can make Radius calls including Message-Authenticator for all common packet types Access-Request/Accounting/CoA/DM/Status after hacking TinyRadius. Seems to work well for me. Now I just need to get the build a patch for the JMeter folks to accept. Happy to send you a link if you were interested. Cheers Peter
participants (2)
-
Alan DeKok -
Peter Lambrechtsen