I've been in the middle of a discussion with Alan trying to figure out requirements for a RADIUS library for Moonshot to use. (Our current solution needs a bit of work)
We were having a discussion surrounding RADIUS attribute dictionaries. Typically a RADIUs server or library has a dictionary that maps an attribute number to a name and gives the attribute a type such as integer, string or IP address. Alan points out that it would be easy to give the application the opaque RADIUS value but that if we need to decode the attribute in a manner specific to its type then the dictionary is required. RFC 2138 defines four types of data: strings, integers, IP addresses and times. (Additional types such as IPv6 prefixes are defined by later specifications.) In addition, there's a question about how multi-valued attributes are handled. For example, for the EAP messages and for our use of SAML, we'reassuming that the multiple values are concatenated. An alternative for some attributes would be to treat them as multiple values of a short attribute. I think the interpretation of RADIUS strings and opaque data would be the same as far as we're concerned. GSS-API buffers don't tend to have a trailing null in the C bindings, so I can't see a difference. Integers are MSB-first 32-bit quantities. As are IP addresses and times. So, we have a number of options: 1) Just give the application opaque data with a specific interpretation of multi-valued attributes we hard-code. 2) Require that the GSS-EAP implementation understand the type and multi-value semantics of anything it exposes. That's kind of undesirable because we want the GSS-EAP implementation to eventually be a component of the operating system and we expect deployments to extend the set of attributes thought the use of vendor-specific attributes. We expect facilities like Shibboleth to be able to map AAA attributes into local attributes under the control of a configuration file. 3) Encode the type into the attribute name exposed through GSS-API naming extensions. We'd need to decide how inquire_name_attrs works (an API for enumerating all the attributes an application may request.) It could assume things were strings but applications could request the attribute with a different type if they knew better. Comments very welcome. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
