Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 6218 implementation #2264

Open
alandekok opened this Issue Jul 20, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@alandekok
Copy link
Member

alandekok commented Jul 20, 2018

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.

@alandekok alandekok changed the title RFC 6421 implementation RFC 6218 implementation Jul 20, 2018

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Jul 20, 2018

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.

@alandekok

This comment has been minimized.

Copy link
Member Author

alandekok commented Jul 20, 2018

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.

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Jul 20, 2018

Yes, that sounds reasonable.

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Jul 20, 2018

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.

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Jul 20, 2018

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?

@alandekok

This comment has been minimized.

Copy link
Member Author

alandekok commented Jul 20, 2018

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.

@arr2036

This comment has been minimized.

Copy link
Member

arr2036 commented Jul 20, 2018

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.

@FreeRADIUS FreeRADIUS deleted a comment from reza-ebrahimi Aug 10, 2018

@FreeRADIUS FreeRADIUS locked as off topic and limited conversation to collaborators Aug 10, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.