Message-Authenticator for CoA/DM vs Access Request/Accounting/Status

[Peter Lambrechtsen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140609/00ebc8bb/attachment.html>