TACACS+ 'arg' support #1908

Open
jimdigriz opened this Issue Feb 13, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@jimdigriz
Collaborator

jimdigriz commented Feb 13, 2017

Issue type

  • Defect - Crash or memory corruption.
  • Defect - Non compliance with a standards document, or incorrect API usage.
  • Defect - Unexpected behaviour (obvious or verified by project member).
  • Feature request.

Defect/Feature description

TACACS+ supports bidirectional arbitrary key/values on authorisation and accounting packets (sections 5 and 6), that I have so far quietly ignored.

FR does support non-dictionary attributes, starting place to look is dict_read_process_named_attribute().

@arr2036

This comment has been minimized.

Show comment
Hide comment
@arr2036

arr2036 Feb 13, 2017

Member

During decode can check to see if they're in the dictionary with fr_dict_attr_by_name, and then we'll need a new dictionary function to allocate an unknown attribute with a specific name, attr == 0 and parented from the tacacs root da.

That won't allow the unknowns to be referenced in unlang, or encoded in a foreign protocol like RADIUS or DIAMETER but never mind.

Member

arr2036 commented Feb 13, 2017

During decode can check to see if they're in the dictionary with fr_dict_attr_by_name, and then we'll need a new dictionary function to allocate an unknown attribute with a specific name, attr == 0 and parented from the tacacs root da.

That won't allow the unknowns to be referenced in unlang, or encoded in a foreign protocol like RADIUS or DIAMETER but never mind.

@alandekok

This comment has been minimized.

Show comment
Hide comment
@alandekok

alandekok Feb 13, 2017

Member

We really also need a TACACS+ module, which implements TACACS+ ACLs in the way that people are used to. That module would care about names, not numbers...

Member

alandekok commented Feb 13, 2017

We really also need a TACACS+ module, which implements TACACS+ ACLs in the way that people are used to. That module would care about names, not numbers...

@jimdigriz

This comment has been minimized.

Show comment
Hide comment
@jimdigriz

jimdigriz Feb 13, 2017

Collaborator

Do all DNS servers have to use a BIND9 compatible zone file format? With DDNS, GSLB, 'serial number' and the format not lending its-self to mechanical synthetisation, I suspect no one is that excited by it.

In the case of TACACS+ ACLs are people using them because they want to, or because they have to? Having glanced at some examples online I find it hard to believe it is the former...

I suspect there is quite a lot of carrot moving to FreeRADIUS, and the unlang probably does not make for much of a stick?

No doubt we will need some unlang policy.d stubs and helper modules (IP ACLs from a textfile) though.

Collaborator

jimdigriz commented Feb 13, 2017

Do all DNS servers have to use a BIND9 compatible zone file format? With DDNS, GSLB, 'serial number' and the format not lending its-self to mechanical synthetisation, I suspect no one is that excited by it.

In the case of TACACS+ ACLs are people using them because they want to, or because they have to? Having glanced at some examples online I find it hard to believe it is the former...

I suspect there is quite a lot of carrot moving to FreeRADIUS, and the unlang probably does not make for much of a stick?

No doubt we will need some unlang policy.d stubs and helper modules (IP ACLs from a textfile) though.

@alandekok

This comment has been minimized.

Show comment
Hide comment
@alandekok

alandekok Feb 13, 2017

Member

Do all DNS servers have to use a BIND9 compatible zone file format?

The point is to lower the cost of switching software products. Supplying a Perl script to convert TACACS+ ACLs to FreeRADIUS format (whatever that is) is a good start. An even better thing would be to just use the existing formats, no matter how horrific they are.

Once people have switched to better product, they can then start using real policies, databases, etc.

Member

alandekok commented Feb 13, 2017

Do all DNS servers have to use a BIND9 compatible zone file format?

The point is to lower the cost of switching software products. Supplying a Perl script to convert TACACS+ ACLs to FreeRADIUS format (whatever that is) is a good start. An even better thing would be to just use the existing formats, no matter how horrific they are.

Once people have switched to better product, they can then start using real policies, databases, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment