Sam Hartman wrote: > We need a couple of RADIUS attributes. Realistically I don't think we > can get our attributes from the standard IETF namespace: it's basically > running out of attributes. There's work in radext > (draft-ietf-radext-radius-extensions) to extend the namespace.
That document is in WG last call. It's waiting for me to update it. I hope to do that this week. > we could create a normative dependency on that work. I have two > concerns: > > 1) It's moving kind of slowly. It's done. :) > 2) It requires significant changes to client and server RADIUS > libraries. For example the libraries I'm familiar with identify > attributes either by a 32-bit identifier (16 bits of vendor and 16-bits > of attribute) or as a vendor plus an attribute. It's not entirely > obvious what interface changes will need to be made to support these new > attributes, but it's quite clear something is required and it's not done > yet. There are multiple implementations of the new format. It requires minimal changes to existing libraries. I know, I've done it. IIRC, adding support for the new format (int/ipaddr alone) is ~200 lines of code. If anyone needs help, I'm glad to assist. > For those of us implementing today it's be really convenient to use > RADIUS attributes from a VSA space. Personally I don't see the problem > with this so long as the organization in question is willing to give up > change control of at least those attributes to the IETF. It's possible > we could get push back from the IESG. It's not really any more work to use the new formats. If people are going to be hacking RADIUS implementations anyways to add channel bindings, adding support for the new format is a small effort. > I'd like to ask the WG though about whether we are willing to try and > use VSA space in a standard assuming we can get change control of the > attributes in question. I think it will significantly help our > time-to-market and will not have any cost other than cleanliness of > standard. I think requiring the new RADIUS format isn't much of a problem. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
