freeradius-server
freeradius-server copied to clipboard
FreeRADIUS
RFC 6218 implementation
https://tools.ietf.org/html/rfc6218
Defines AES key wrap, which is used in some Cisco products. This is a way to have "enhanced" (as they put it) signing for RADIUS packets.
The main difficulty is that there are additional keys used to sign the packet. So the packet creation now goes:
- encode packet
- with place-holder for Message-Authenticator
- with place-holder for Cisco stuff
- sign packet with Cisco stuff
- and place into packet
- sign packet with normal shared secret
The encoding routine (or something before that) will need to know to create an "empty" attribute of the right length, filled with zeros.
After encode, but before signing, the packet has to be signed with the extra AES "key wrap" key.
Then, the packet can be signed like normal.
You don't need to add empty attributes, you just need to have the signing code pretend there were empty attributes, and then append the whole lot to the packet at the end. The way Message-Authenticator is handled currently is pretty annoying, it'd be good to avoid implementing additional signing in the same way.
Hmm... the simplest thing, TBH would then be to have the Cisco attribute always added as the last attribute in the packet. It can then do encode + sign as one operation. But that's fragile.
Perhaps a better solution would be to have the encode routine also encode a call stack of "additional operations" to do on the packet. Those additional operations could then be called during the signature phase.
That removes any special-case for Message-Authenticator. And lets you add additional AES key wrap using a standard framework.
So it's the Message-Authentication-Code attribute which is the pain to generate. The other attribute just carries keying material. There are really two parts to this, generating the MAC, and fixing all the calls to the mppe code so it can provide the keying material in the Cisco format.
Additional operations could be part of the encoder ctx structure. I guess we'd also need to validate the MAC when receiving key-wrapped packets?
It should probably be implemented as a module, run in the send Access-Accept phase.
The module can take care of grabbing the MPPE key attributes, copying the keys to a new attribute, and deleting the old attributes.
The module could also use a new API to say "hey, do a callback after encoding the packet, so that I can mangle the attribute some more".
That way the server core has minimal changes. Just an API for "remember callback", and "call callback before signing the packet"
The MAC should also be validated when receiving these packets. That's a little more difficult...
We should probably allow for custom extensions to the dictionaries... via encode=keywrap or something like that. Those can be parsed by the dictionary code. Then, the Cisco keywrap module could add a callback saying "that's me!" for sign / verify.
We should probably allow for custom extensions to the dictionaries... via encode=keywrap or something like that. Those can be parsed by the dictionary code. Then, the Cisco keywrap module could add a callback saying "that's me!" for sign / verify.
Yeah, definitely. We need to do that anyway for multi-protocol stuff.
We could also add a special mac=<foo> tag to certain attributes, which again hits a callback registered by a module. There are quite a few instances where that'd be useful.
After some thought, this looks to not be necessary. Few people implement it, and recent developments mean that these features are no longer necessary.