I use freeradius-1.1.0 built from FreeBSD ports on FreeBSD. There is the following comment in default raddb/dictionary.sample (this file probably comes from the FreeBSD port): # # Place additional attributes or $INCLUDEs here. They will # over-ride the definitions in the pre-defined dictionaries. # But this doesn't seem to be true or, at least, entirely true. For example, I place the following lines in my raddb/dictionary: # big all-inclusive freeradius dictionary $INCLUDE /usr/local/share/freeradius/dictionary # my local dictionary $INCLUDE /usr/local/local/dictionary.mine And dictionary.mine has this content: #try to override Digest-Response with value from # draft-ietf-radext-digest-auth-06.txt ATTRIBUTE Digest-Response 102 string Then I get the following error on radiusd startup: $ radiusd -sfxxyz -l stdout ... Errors reading dictionary: dict_init: /usr/local/local/dictionary.mine[3]: dict_addattr: Duplicate attribute name Digest-Response Errors reading radiusd.conf Shouldn't I be able to override name->number mapping for attributes ? How to work around this problem ? Is copying the "all-inclusive" dictionary and throwing out the following line the only solution ? ATTRIBUTE Digest-Response 206 string On a related note - is it a good idea in general to have digest authentication stuff defined in main dictionary file and dictionary.freeradius.internal ? Especially given that those definitions are based on the very old and expired draft and are very unlikely to become standard. I think that those definitions should be clearly separated into their own dictionary and they should also somehow be marked as based on the draft-sterman-aaa-sip-00.txt and conflicting with the subsequent drafts, including the latest one (draft-ietf-radext-digest-auth-06.txt). -- Andriy Gapon
Andriy Gapon <avg@icyb.net.ua> wrote:
Errors reading dictionary: dict_init: /usr/local/local/dictionary.mine[3]: dict_addattr: Duplicate attribute name Digest-Response Errors reading radiusd.conf
Shouldn't I be able to override name->number mapping for attributes ?
Yes, so long as the only thing different is the name. ATTRIBUTE Foo-Bar 10 ipaddr ATTRIBUTE Bar-Foo 10 ipaddr is OK. ATTRIBUTE Foo-Bar 10 ipaddr ATTRIBUTE Bar-Foo 10 string is not OK. And why are you trying to re-define Digest-Response? It's already defined in the dictionaries. Can you describe what you think you're doing, or what result you expect to gain from this?
On a related note - is it a good idea in general to have digest authentication stuff defined in main dictionary file and dictionary.freeradius.internal ?
Please *read* the attribute definitions. The definitions in dictionary are RADIUS attributes that go over the wire. The ones in dictionary.freeradius.internal are not.
Especially given that those definitions are based on the very old and expired draft and are very unlikely to become standard.
Standards matter less thyan interoperability. There are many systems deployed with the current digest attributes. Changing them now is not an option.
I think that those definitions should be clearly separated into their own dictionary
Once a standard is published for digest, the attributes in that standard will be placed in their own dictionary.
and they should also somehow be marked as based on the draft-sterman-aaa-sip-00.txt
The ones in "dictionary" are marked as being based on that draft. The ones in dictionary.freeradius.internal are not marked as being based on that draft, because they are not.
and conflicting with the subsequent drafts, including the latest one (draft-ietf-radext-digest-auth-06.txt).
Which came out recently. The FreeRADIUS dictionaries have had the existing definitions for almost four years. Also, the new draft isn't standardized. And the new draft doesn't have any implementations that I'm aware of. And the new draft doesn't conflict with the internal FreeRADIUS attributes, because FreeRADIUS doesn't implement the new draft. If you want to go edit your dictionaries to support a draft which isn't implemented in FreeRADIUS, go ahead. But I can't see why anyone would want to do that. Once the draft is standardized, we'll update the dictionaries and implement the protocol. Until then, editing the dictionaries is a complete waste of time. Alan DeKok.
Alan, thank you very much for your reply. Sorry if my reply breaks message threading for you - I am replying based on the web-archive as I don't receive this list by email. I also want to apologize if my tone seemed too attacking towards freeradius for such a novice that I am. I want to "restart" this discussion while providing some minor comment/replies to your answer. Now to the subject matter: let us imagine some not very distant future when digest authentication extension is finally standardized, there is an RFC for it, there are devices/software that implement it. FreeRADIUS obviously also wants to support this RFC-digest-extension. On the other hand there are still many devices out there that use draft-sterman-aaa-sip-00.txt and FreeRADIUS obviously wants to continue to support them as well. In both cases people would probably like to use "Digest-Response" attribute name (and other digest attribute names), so that it refers to a correct attribute for their configuration. I thought about this a little bit and I think that either some new names would have to be introduces (e.g. "Digest-Response-New" or "Digest-Response-Old") or somehow separate dictionaries would have to be created and users would have to be careful about using them. How would you resolve such situation ? Maybe I am totally missing some other possibilities ? Are there any precedents ? And some comments below: Alan DeKok wrote:
Andriy Gapon <avg at icyb.net.ua> wrote:
Shouldn't I be able to override name->number mapping for attributes ?
Yes, so long as the only thing different is the name.
ATTRIBUTE Foo-Bar 10 ipaddr ATTRIBUTE Bar-Foo 10 ipaddr
is OK.
ATTRIBUTE Foo-Bar 10 ipaddr ATTRIBUTE Bar-Foo 10 string
is not OK.
I wanted (or, at least, I thought that I wanted) something a little bit different - not a new name for the same type, but a different type for the same name. E.g.: $ cat /usr/local/etc/raddb/dictionary ATTRIBUTE My-Local-String 300 string ATTRIBUTE My-Local-String 301 string $ radiusd -sfxxyz -l stdout ... main: debug_level = 0 read_config_files: reading dictionary Errors reading dictionary: dict_init: /usr/local/etc/raddb/dictionary[2]: dict_addattr: Duplicate attribute name My-Local-String Errors reading radiusd.con
[skipped]
Please *read* the attribute definitions. The definitions in dictionary are RADIUS attributes that go over the wire. The ones in dictionary.freeradius.internal are not.
Yes, but they can still create some confusion - dict_attrbyname() will still see them. But this is not important.
Especially given that those definitions are based on the very old and expired draft and are very unlikely to become standard.
Standards matter less thyan interoperability. There are many systems deployed with the current digest attributes. Changing them now is not an option.
Completely agreed, but I am rather talking about moving them into a separate file (BTW, there already seems to be "dictionary.digest") instead of having them directly in "dictionary".
I think that those definitions should be clearly separated into their own dictionary
Once a standard is published for digest, the attributes in that standard will be placed in their own dictionary.
and they should also somehow be marked as based on the draft-sterman-aaa-sip-00.txt
The ones in "dictionary" are marked as being based on that draft.
By "marked" I meant not a mere comment in a dictionary file, but some prefix to their name or something like that, e.g. "PreRFC-Digest-Response". But this is probably too intrusive to do now.
[skipped]
-- Andriy Gapon
Andriy Gapon <avg@icyb.net.ua> wrote:
I also want to apologize if my tone seemed too attacking towards freeradius for such a novice that I am.
You're not attacking, you're worried about situations that haven't occured yet.
Now to the subject matter: let us imagine some not very distant future when digest authentication extension is finally standardized
We will address that situation when it happens. Until then, there isn't a lot of point in discussing this.
How would you resolve such situation ?
Very carefully.
I wanted (or, at least, I thought that I wanted) something a little bit different - not a new name for the same type, but a different type for the same name. E.g.: $ cat /usr/local/etc/raddb/dictionary ATTRIBUTE My-Local-String 300 string ATTRIBUTE My-Local-String 301 string
That's wrong. The server won't accept it. Think what it would mean if the server did accept it. You see My-Local-String in a log file. Which attribute is it? You don't know.
By "marked" I meant not a mere comment in a dictionary file, but some prefix to their name or something like that, e.g. "PreRFC-Digest-Response". But this is probably too intrusive to do now.
There is absolutely no reason to do that. Alan DeKok.
Alan DeKok wrote:
Andriy Gapon <avg at icyb.net.ua> wrote:
I also want to apologize if my tone seemed too attacking towards freeradius for such a novice that I am.
You're not attacking, you're worried about situations that haven't occured yet.
Now to the subject matter: let us imagine some not very distant future when digest authentication extension is finally standardized
We will address that situation when it happens. Until then, there isn't a lot of point in discussing this.
How would you resolve such situation ?
Very carefully.
Alan, let me be more explicit about where I am coming from: Let us suppose that somebody wants to implement a digest authentication extension module according to draft06 while keeping existing implementation too. And he does want to do it now. He also might be willing to contribute that module to FreeRADIUS later. What advice could you give to such a person ? And I will really appreciate your advice as I do appreciate your answers. Thank you. -- Andriy Gapon
Andriy Gapon <avg@icyb.net.ua> wrote:
Let us suppose that somebody wants to implement a digest authentication extension module according to draft06 while keeping existing implementation too. And he does want to do it now. He also might be willing to contribute that module to FreeRADIUS later. What advice could you give to such a person ?
Work in multiple stages: - update the dictionaries, radius.h, and rlm_digest to implement the new method, and don't try to do any backwards compatibility. Once that works, you have a RADIUS server that implements the new method, but doesn't do the old one. - update the dictionaries and radius.h to have the current rlm_digest use the new numbers. The existing numbers are defined only by FreeRADIUS, so you can change them without breaking any existing servers. You may run into attribute conflicts with other dictionaries, like Ascend. See what it takes to fix the conflicts. - investigate the overlap between the old method & new method in rlm_digest. How much code can be re-used? What other changes are necessary? The idea is to work at the problem from both ends until you have a common ground. It should be possible to have the existing module handle both the old and the new methods at the same time. Alan DeKok.
participants (2)
-
Alan DeKok -
Andriy Gapon