The AAA Architecture (AAAarch) Research Group met January 29-30, 2001, in Utrecht, The Netherlands.  The meeting was hosted by Utrecht University

Minutes made by: Guus Sliepen, email:

Minutes of the IRTF AAAARCH interim meeting January 29&30, 2001 in Utrecht.


 Cees de Laat           (co-chair, Utrecht University)
 Arie Taal              (Utrecht University)
 Armijn Hemel           (Utrecht University)
 Guus Sliepen           (minutes, Utrecht University)
 Leon Gommans           (Enterasys Networks)
 Henk Jonkers           (Telematics Institute Enschede)
 Sebastian Zander       (GMD Fokus)
 Tanja Zseby            (GMD Fokus)
 David Spence           (Interlink Networks)

29-01  Opening
 9:40  Cees de Laat

Cees welcomes everybody and says what the goal of this interim meeting is: the
goals of the AAAARCH Research Group should be reiterated, and the three drafts
that should have been read shall be read and discussed. Also, Armijn Hemel has
two small documents regarding generic AAA policies which are to be discussed.

Someone asks what the status of the terminology draft is. Currently no progress
has been made since the presentation of the draft in San Diego, but it is
planned to merge our draft with the terminology draft from the Policy Framework
Working Group. Guus Sliepen should contact John Schnizlein and Joe Saloway to
get this going.

29-01  Objects of AAA
 9:50  Cees de Laat

Since the discussion about whether or not to push/pull policies it has become
clear that there are a lot of policies involved in a "Service", but for the
AAA architecture we are only interested in what are called "Generic Policies"
in section 1.3 of draft-irtf-aaaarch-aaa-pol-00.txt. This should be reiterated
in a draft or RFC.

David Spence also mentions that ASMs might also take Generic Policies and
translate them into Application Proprietary Policies. A discussion is then
started about what an ASM is supposed to do. Also questioned is whether
the scheme described in RFC 2903 should be a strictly layered model (like
OSI) or that direct communication between different entities on the same layer
are allowed (for example an ASM speaking directly to another ASM). Of course
nobody can disallow such direct communication, but it must be done in such
a way that communication on the AAA layer and communication on another layer
do not conflict with each other.

Guus Sliepen asks if the RBE component of a AAA server should contain policies
that are to be translated into Application Proprietary Policies by ASM (so that
you never have to write Application Proprietary Policies anymore, but write
them as Generic Policies) or not, because if so the Generic Policy language
should include all features Application Proprietary Policies would also have.
Rough consensus is that this is a nice thing but not necessary.

Cees de Laat says that a draft should discuss the function of the RBE component
of a AAA server, the types of policies that it should process, the ASM
and the relationship and communication between the RBE and the ASM.

Cees explains that the use of the term RBE in RFC 2903 is bad, because the
block that is called RBE in the diagrams actually encompasses far more than
just that. A subgroup should work on writing down this block in more detail.
A whiteboard is then taken into use and a sketch is made:

           |+---------------------------one-session-+         |
           || +---+     +-------------+  +-+  +---+ |         |
      1    || |PD |-    |RBE / Control|  |R| -|PD | |         |    1
    =========>|aaa|-----|Module / Req.|--|B|--|aaa|===================>
           || |   |-    |Manager      |  | | -|   | |         |
           || +---+     +-------------+  +-+  +---+ |         |
           ||   |         |  |  |  |            |   |         |
           ||   |        /   |  |   \           |   |         |
           || +---+     /    |  |    \        +---+ |         |
           || |SEC|    |     |   \    \       |SEC| |         |
           || |   |  +---+   |   +--+  \      |   | |  +----+ |
           || +---+  |API|    \  |PD|   \     +---+ |  |Sess| |
           ||        |asm|     \ +--+    \          |  |Man.| |
           ||        +---+     +--+  \    -------------|    | |
           ||         /|\      |PD|   \             |  |    | |
           ||        / | \     +--+    -----        |  +----+ |
           ||       /  |2 \        \        \       |         |
           |+------/---|---\--------\--------\------+         |
           |      /    |    \        \        \               |
                |      |      |        |        |
              +---+  +---+  +---+   +-----+  +-----+
              |ASM|  |ASM|  |ASM|   |DB   |  |DB   |
              |   |  |   |  |   |   |event|  |pol. |----(Driving Policy)
              +---+  +---+  +---+   |log  |  |repos|
               /|\    /|\5   /|\    +-----+  +-----+
               ...    ...    ...

Also, a table is kept on the whiteboard listing the capabilities of a
generic AAA server:

MUST                  |SHOULD                |MAY
Have Protocol Driver  |Have capabilities     |
(PD) for:             |Have ASM interface  <-?-> Have ASM interface
- AAA requests        |                      |
- Policy Repository   |                      |
- ...?                |                      |
                      |                      |
Have Driving Policy   |                      |
                      |                      |
Have Security Module  |                      |
                      |                      |
Do capabilities nego- |                      |
tiation               |                      |
                      |                      |

12:00  Lunch break until 13:30.

29-01  AAA architecture model and message types
13:40  David Spence

David presents the same sheets he used at the MERIT meeting, January the 24th
in 2000. Many questions are asked but it appears that the vision David had one
year ago is still valid.

29-01  Data Objects and Message Types
14:30  David Spence

Section 3 of David's draft is to be gone through and every point can be
discussed. This leads to the following remarks:

In case of the push model, a token is required from the user. This is not
mentioned in the RFCs and therefore should be put in a draft.

One example of the pull model is Radius. A user dials into the "ASM", which
sends a signal to the Radius server (the "AAA Server" in this example) which
then initiates a session. Normally sessions are initiated because of a AAA
request which is sent using protocol 1. However, in this example protocol 2 is
used to send some kind of message from the ASM to the AAA Server to initiate
a session. This leads to the discussion whether instead of protocol 2
protocol 1 should be used in this case. This would transform the architecture
into the following:

             +--------+                   +--------+
             |  AAA   |                1  |  AAA   |
             | Server |                ---| Server |
             +--------+               /   +--------+
                 |                    \
                 | 2                   ------
                 |                           \
             +--------+                       |
             |  ASM   |        ==>        +--------+
             |        |                   |AAA part|
             +--------+                   +--------+
                 |                        |Service |
                 | 5                      |Equipmnt|
                 |                        +--------+
             |Service |

It is mentioned that a AAA Client in the agent model is in fact quite similar
to the Service Equipment + AAA part object, since a client uses an application
that can send out a AAA Request, but this application is not a AAA server nor
does it need to contain the internal structure of a AAA server. Some people
argue, because it has been postulated that protocol (or relation) 1 is
symmetric, that an AAA Client or the AAA part in the Service Equipment then is
nothing more than a very lightweight AAA Server.

3.2, 3.4, 3.5)
Guus Sliepen argues that these are equal or subsets of 3.1. Although most
people seem agreeable, this is now an open issue. Further discussion on the
mailing list is encouraged.

This could possibly be done in several different forms. Is the response to be
read by an application or by a human? Must both be offered? In what detail must
it be offered? Possible things to request are:

- List of offered services/policies
- Parameters that are needed and/or accepted for a certain service/policy
- Accepted values and/or descriptions of individual parameters

If the replies are to be machine readable, then this is similar to a

Another issue is the forwarding of these requests. If policies contain
references to other policies, then the specification request has to be broken
down in requests for each Local or Remote Policy in the entire Distributed
Policy. However, an example is given of a policy that will call upon one of
two possible remote policies, depending on some external parameters. Then how
is the specification request to be forwarded? Possibly by evaluating the
entire Distributed Policy, but only to see which parts are referenced, not to
execute any actions attached to the policies.

Means: pull a policy.

Means: evaluate that policy, but do not execute the actions, instead send those
actions back in a reply so that I can execute them.

Really fits next to 3.1. However, Cees de Laat remarks: "Guus is right, but we
just don't care."

Adds the event log to the diagram on the whiteboard.

Can also be sent to the user instead of a database, and it should also be able
to proxy it or process it in other ways.

Sebastian Zander asks if it should be able to send a request to turn the sending
of accounting messages on and off. David Spence agrees that it probably should.

Some discussion is started about the direction in which these messages flow and
what protocol is used, since accounting messages are typically generated by the
NAS, but normally all requests go from the user to his home organisation.
Accounting messages are also typically coming from the service equipment, and
flow (without a prior request) up through the ASM to the AAA Server via protocol
2. After some discussion Cees de Laat says: "Requests only go via protocol 1,
but data objects go via protocol 2." Most people agree, but after that many look
confused anyway.

Now there is an argument that this has blurred the distinction between the two
protocols so much, that we could say that protocol 1 equals protocol 2.
Cees de Laat tries to save the situation and says that the diagram and the lines
in it are not about protocols, but about relationships. Clearly, even if
everything would use one and the same protocol, the relationships are still
different. It wouldn't hurt though to see if relationship 1 really differs from
relationship 2.

17:50  Meeting is adjourned until next morning, 9:00.

30-01  Overview of things done on Monday.
 9:30  Cees de Laat

Cees de Laat goes through the accomplishments of yesterdays meeting. Upon
telling something about the Driving Policy and how it is similar to the BIOS
of a computer, David Spence asks a question about initial routing. The problem
is that when for example a user dials in. The user needs to get authorised to
use the network. It therefore needs to contact the AAA Server that can give
this authorisation. But if we use DNS to find the location of the AAA Server,
we will find that without network access, we also can't reach a DNS server.

[David Spence comments on this part of the minutes:

No, that wasn't what I was trying to say.  That is not a problem because
the User is talking to the service equipment; he is not sending type 1
messages to an AAA server.  So he does not need to reach a DNS.

I was merely trying to point out the current thinking in the AAA WG is that
names of AAA entities use an extended form of NAI rather than domain names
and that realm names are not required to be registered as domain names.
Thus the mapping from name to address is done at the AAA level and does not
use the DNS.  "Routing", the question of which realms are served via which
next hop AAA server, is configured statically.  It may be a good thing for
us to propose that AAA entity names be host names (in the DNS sense) and
that name to address mapping be done via the DNS.  We just need to realize
that we are proposing a change in conventional AAA thinking.]

Radius however has the notion of realms, which serve as a kind of domain names.
A static table for conversion of realm names to IP addresses is typically stored
in the client or service equipment. Everybody feels that using standard DNS is
much cleaner than introducing realms, but how to handle the initial routing
problem then? [/etc/hosts?]

Cees de Laat wants a comparison between realms, DNS and URLs. David Spence
thinks that URLs don't belong in this list, unless we want to look at the
entire addressing problem in AAA (not only addressing servers, but also ASMs,
SEs, objects stored in databases, etcetera).

Discussion is cut short by Cees de Laat.

30-01  Policy-based Accounting
10:05  Tanja Zseby

Tanja remarks that in the beginning of the draft, some terms are defined, but
she would rather like to see them go into the terminology draft. Guus Sliepen
must look into this.

Cees de Laat asks everyone to read a section (starting at 4), then to discuss
it, and then read and discuss the next ones. Some comments are made and some
ambiguous and unclear statements are pointed out. Tanja directly updates the

When section 6 is reached, a discussion is started about what layer(s) in the
AAA architecture model the accounting information has to be processed and/or
evaluated. The discussion wanders off and at a certain moment the interaction
of ASMs with application specific objects in the Policy Repository using a
direct connection between the two is discussed. No real conclusion is reached.

12:00  Lunch break until 13:15.

30-01  Policy-based Accounting (continued)
13:15  Tanja Zseby

Section 7 is read. Some clarifications are made for some of the components and
interconnecting lines in the diagrams.

Leon Gommans misses a diagram for the situation where a clearinghouse is used.
This situation is special, because it is integrated from the user's point of
view, but discrete for the service provider's point of view.

David Spence says that flow diagrams should be made for situations where the
push model is used for accounting, but agent model for authentication, and
probably some other combinations.

[Sebastian Zander comments:

Im a bit confused about the above comments. I think what Dave said is that we
should make flow diagrams for accounting messages in case of all 3 authorization
types. I agree with Dave that a push model seems natural for accounting.
Therefore we assume push model accounting for the diagrams. However i dont want
to limit the generic model at that time and there might be cases where a pull
model is needed. I would like this to be considered in the messages draft.]

30-01  A grammar for AAA policies / Pushing policies considered harmful
14:20  Armijn Hemel

Most people do not understand what the grammar is for. This is because the
context in which the grammar is used is not in the document. However some
quick writing on a whiteboard explains that it is a way for writing down the
Generic Policy language. Several questions are asked.

Guus Sliepen asks David Spence what the policies that are used in Interlink's
AAA Servers look like. David says that they do in fact resemble what is written
on the whiteboard, but there are also some differences.

Then the second document is discussed. David Spence asks why the pushing of
policies is being questioned again, since a conclusion has already been reached.
However, Guus argues that the conclusion of the previous discussion ended in
working harder on the terminology draft, because of the great diversity in kinds
of policies, and the fact that only some of them actually have anything to do
with the AAA architecture at all. And whether or not pushing/pulling of policies
is going to be done or not, there still are many security considerations, and
it's good to have it on paper.

Cees de Laat says that both documents should be combined and turned into a
draft as soon as possible.

30-01  Question round
15:20  Cees de Laat

Arie Taal says he has made a basic AAA Server in Java, also using Corba and

Henk Jonkers is going to work out more accounting examples.

Tanja Zseby and Sebastian Zander say that the session-ID work is progressing
very slowly. It is very complex, and they really could use some input.
Everybody is asked to at least really read the messages that were sent out on
the mailing list regarding this. The session-ID document was emailed to the
AAAarch mail list November 29, 2000 by Tanja Zseby with the subject line
"session ID document". It also needs to be turned into a draft.

15:35  End of the IRTF AAAARCH interim meeting January 29&30, 2001 in Utrecht.

CdL - jan 31th 2001 Visitors of this page: