In Part I, I have shown what I did to get the build and installation going. In
Part II, I will show what steps I took to get a simplest test like the following
A EAP-MD5 test that involves an OpenDiameter server (aaad), an OpenDiameter
client (nasd), and a EAP-MD5 client (pacd) talking to nasd using PANA. All three
parties reside on one single host.
Simple as the test is, a lot of work is needed in OpenDiameter's case, as we
will see soon.
Some Background Information
The Diameter Protocol
Diameter is intended to be the next generation AAA protocol that replaces
RADIUS. Wheather and when it will replace RADIUS is not for me to discuss here,
but it has already found uses in a lot of applications, notably in 3GPP and
WiMAX infrastructures. I will assume that you are familiar with AAA or RADIUS
and I will just try to point out a few concepts that is unique in Diameter and
we will encounter in our little test.
Diameter nodes like server and NAS talk connection-oriented protocols of TCP
or SCTP, as opposed to the connectionless protocol of UDP used by RADIUS. The
connections are also maintained and monitored by using watch-dog messages. As a
result, in Diameter, "peer" is used to refer to the ends of a connection, and
please don't confuse it with the "peer" used in EAP which is really the
supplicant. One Diameter node could have multiple peers and a peer table usually
exists in its configurations.
Diameter introduces the concept of application which is a major mechanism for
extensibility. Each application is identified by a unique 32 bit application
ID. EAP is implemented as an application too in Diameter and it is assigned an
ID of value 5.
AVPs and dictionary
Just like RADIUS, Diameter's function largely involves carrying attributes
around. However, the attribute space is much bigger in Diameter and the
structure to carry them is a new design that is called Attribute-Value Pair, or
AVP. Naturally, when there are attributes, there will be dictionaries for the
nodes to look them up.
NAI, realm routing
Network Access identifier (NAI) is the standard form of user Identity. It
normally contains a realm part, like [email protected] The realm part can be used
by Diameter nodes to decicde which peer/domain it should be sent to, hence
the concept of "realm routing". A routing table can be found in a Diameter
node that contains information about for what realm what action should be taken
and which peer should be used. It is most commonly used by Diameter agents that
does proxy or relay, and since our little test doesn't involve an agent, it
shouldn't matter. However, in Opendiameter's nasd implementation, it also uses
the realm to decide which Diameter server should it forward messages to, and
that is why I mention it here.
PANA stands for Protocol for carrying Authentication for Network Access. The
idea is like this. In a 3-party EAP model, the authenticator acts as an
pass-through device that relays authentication requests from a supplicant to an
authentication server. A EAP packet doesn't travel itself and needs to be
carried in some other transport protocol. RADIUS and Diameter can both be used
to carry EAP from the authenticator to the authentication server. However, on
the other side of authenticator that faces the supplicant (the Access Side) a
different carrier protocol is needed. Often an authenticator that directly
faces a layer 2 network uses a layer 2 carrier protocol like 802.1x(EAPOL) and
PPP. However, if an authenticator sits deeper inside a network and does not face
the edge, it might make sense to use an uppler layer transport to do the job.
PANA is such a carrier protocol that is IP based and operates in layer 3.
OpenDiameter's nasd uses PANA, and in PANA terminology nasd is a PAA (PANA
authentication agent) which accepts EAP requests from supplicant. The other
end of PANA connection is called PaC (PANA Client). In OpenDiameter, the pacd
program acts as a combined PaC and supplicant.
Binaries from OpenDiameter
As already mentioned, we will be using the server binary (aaad), authenticator/
NAS binary (nasd) and the PANA client + Supplicant binary (pacd). Opendiameter
also generates a series of test clients and test servers, but we will not use
OpenDiameter Config files
OpenDiameter's configuration files are mostly .xml files that are in XML format
and each .xml file has an companion .dtd file for Document Type Definition
Sorry, more compilation please
I must admit that in Part I, which should take care of all compilations, I
omitted one inconconvenient fact that requires a quick re-complilation. The
reason is that it only affects nasd which may not be essential for a lot of
uses where people are only interested in the server.
In the code that came with 1.0.7-i, nasd somehow has commented out lines
related to Diameter EAP application in its initialization part. That not only
makes nasd not usable for Diameter EAP, but also pretty much makes it unsable
for anything. The reason is that nasd defines its peer table inside of
the nasd_diameter_eap.xml (which is weird by itself since EAP is just one
application) and the file won't even be read with those lines commented out.
so, we need to apply the following simple diff and redo "make; make install"
in the opendiameter root directory.
On some systems I have also seen problems during build phase when linking to
crypto libraries, and I suspect it has something to do with system's openssl
libcrypto.a. Since it is not universal, I omitted them, but now I feel I
probably should point them out too. You can omit this if you didn't have any
problem following Part I.
complaints about dlopen() when compiling ACE
You could work-around it by this quick hack on ACE_wrappers/configure file:
linking errors about MD5 when building OpenDiameter
I also have a quick-n-dirty patch for this. Since it involves a few files, I
have listed it in the appendix part of this article. Again, don't bother if you
didn't have problem in Part I.
Update Shared Library Information
When use your binaries after first time building opendiameter, it might fail
complaining about libACE. That is caused by an un-updated shared-library
database on the system after new libraries are generated. I fixed it by this:
We did do "make install" before, but unfortunately there are mutliple things
that are missing in the process and we need a do-over.
The binaries of aaad and nasd are installed correctly at /usr/local/bin. There
are configuration files copied at /usr/local/etc/opendiameter, but I discovered
that a few issues exist:
missing .dtd files for certain .xml files
nasd has a file that includes a wrong .dtd file name.
the include path to a dictionary file are all set to relative path which makes
the binaries only able to be invoked from the parent directory of the "config"
directory, otherwise the dictionary files could not be found by them.
there are inconsistencies between dictionary files used by peers.
nasd's eap dictionary file is completely outdated.
I suggest to follow the following steps to fix those issues:
copy over aaa and nasd config files manually from your OpenDiameter source
tree to /etc/opendiameter. Even though the default installation goes to
/usr/local/etc/opendiameter, I found there seems to be assumptions in the code
about the path /etc/opendiameter. So to avoid issues, I suggest directly go to
with those changes, now start aaad and nasd by simply invoking them (as root)
without any parameters (They don't have much command line options anyway). You
should see constant messages about watch-dog if the connections are successful,
(7867|3038682000) Watchdog msg from [localaaa.localdomain1.net.localdomain1.net], state=1207434903, time=1207435199
I suggest that you start aaad before nasd. Based on my experience, on different
systems, if doing the other way around, it either takes longer or nasd crashes.
Fix up pacd
The files installed at /usr/local/etc/opendiameter/pana don't seem to be
usable by pacd either, so I decided not to use them at all. Unfortunately, I
didn't find any proper candiate from the source tree. The best I came up
with was an ugly solution (appologies!) by downloading from the latest
opendiameter repository with some modifications.
go to your source tree's applications/pana directory, and this is where the
pacd binary is at.
use svn to download just the pana config directory from the opendiameter
svn co https://diameter.svn.sourceforge.net/svnroot/diameter/cplusplus/applications/pana/config
(if you don't have svn installed, it is easy. For example, in ubuntu, do
sudo apt-get install subversion)
The newer dictionary file is not exactly consistent with the 1.0.7-i's
version used by nasd, and that will cause problem. In theory, the newer ones
should be latest, but to avoid trouble, I reverted the newer one to older one
instead. Just copy the one used by nasd, and update its correponding .dtd file
<!DOCTYPE dictionary SYSTEM "pana_dictionary.dtd">
Configure aaad, nasd and pacd for the final EAP-MD5 test
Finally, after all the hassle, we are ready to do some "true" configurations.
enable eap application in nasd and aaad.
As I mentioned, EAP is implemented as an application in Diameter. And during
initial connection establishment, peers will exchange capability information
(in CER/CEA messages) and see if both support some common applications. For our
test, we must enable both aaad and nasd to support EAP.s
EAP applicaiton's assigned ID is 5.
Just add the line
in both aaad_diameter_server.xml and nasd_diameter_eap.xml after the line of
I will use [email protected] for our EAP-MD5 test. Note that I assigned
it to be in the same domain as our Diameter server.
That tells nasd that, for requests of the realm localdomain1.net, forward it to
Make the requirement of User-Name avp consistent between aaa and nasd:
The dictionary files used by peers are supposed to be consistent. There is one
little inconsistency between them that will cause problem. In nasd's
nasd_diameter_eap_dictionary.xml file, the AVP User-Name is defined as
mandotory but it is not the case in aaad. Remove the mandotory part from it
and make them consistent.
Restart your aaad and nasd like before, and make sure they have established
Now start pacd from the applications/pana directory like this: (as root)
./pacd -f config/pana_setup.xml
And if you see messages from pacd window like this, then you are good.
Peer: Success received.
Authentication success at peer
Welcome to the world, [email protected] !!!
I don't know about you, but I feel tired by now after all this, and that is just
a EAP-MD5 test that can't be made simpler. As I stated before, I am new to
OpenDiameter myself and my way of doing things might not be the right way, so be
cautioned there! I am also sorry that at the point I don't have much more to
contribute, but I do hope this little two-part article can help other
OpenDiameter beginners. If it does help you to get started, I encourage you to
contribute back by sharing your tricks too.
In my opinion, OpenDiameter does not seems to be in a mature stage yet. It suits
to serve as a starting point to develop your own applications or to conduct
your Diameter tests in the labs, but I am not sure about more serious
deployments. Again, I could be totally off, but if that is the case, I hope
the true experts could step up and provide more documentations.
I am also very much looking forward to the next release (1.0.8) which is
delayed. And I hope all those issues I have met, if they are real, will be fixed
and more importantly, more documents please!
 OpenDiameter README file from 1.0.7-i source package