dictionary: override attribute type/id mapping

[Alan DeKok]

Andriy Gapon <avg at 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.