The IETF Triple A

We have briefly addressed authentication. We also need to discuss the interrelationship
between authentication, authorization, and accounting—or, as described by the IETF,
Triple A.
It is not sufficient just to have identity-based authentication. There is also a need to
support role-based access control. This has been used for many years in private radio
networks to give users specific event-based or role-based access rights. (Motorola calls
them storm plans; Ericsson calls them special event plans.) A storm plan might be, for
example, a preplanned network response to a terrorist attack. The chief of police, chief
of fire, the mayor, or president may acquire a particular set of access rights triggered by
the event. Individuals can have particular access rights and groups of users can have
access rights. The access rights include the right of access to delivery and memory
bandwidth (security data bases, hazardous chemical information, or firefighting information,
for example). Similar topologies can be used to qualify spending rights and
spending power. IETF Triple Aalso supports a criticality flag analogous to preemption
rights in a storm plan (where the chief of police effectively pulls rank to get channel
access). There may be a need to reject legitimate but unwanted users.
In the context of allowing a right of access, level of trust is a relative term. Even if a
cryptographically correct certificate is presented, you can never be completely sure a
person or device is who they claim to be.
The stability of the access protocol also becomes very critical in these applications.
For example, suppose a 747 lands on Downing Street, and 1200 Metropolitan police
officers all press their press-to-talk keys on their radio at the same time, expecting
instant access and authentication. The access bandwidth is sufficient to support 100
simultaneous users. The authentication bandwidth also has to be sufficient to avoid
unacceptable access delay. We thus have another performance metric—protocol performance
(also describable as protocol bandwidth). It is relatively easy to become
protocol-limited—a frustrating situation where you have access bandwidth available
but cannot use it because the protocol cannot respond quickly enough to the
immediate/instantaneous bandwidth need.

IETF Triple A also codifies how to deal with protocol security attacks—man-in-themiddle
attacks, replay attacks, or bid-down attacks (against which timestamping is
generally a useful defense).
Accounting within Triple A includes financial accounting (billing and accountability),
session logging, and audit trails to prove a session took place and to protect
against repudiation (claiming you didn’t order those thousand garden forks). Accounting
audit trails can be used commercially and to track and search for sessions that may,
in retrospect, acquire national security or financial interest (September 11th/ Enron).
207