AAAARCH

Interim meeting Berlin, September 28 & 29, 2000


Minutes made by: Guus Sliepen, email: guus@sliepen.warande.net

Minutes of the IRTF AAAARCH interim meeting September 28&29, 2000 in Berlin.
==============================================================================

Attendants:

 Cees de Laat           (co-chair, Utrecht University)
 John Volbrecht         (co-chair, Interlink Networks)
 Arie Taal              (Utrecht University)
 Arjan van der Vegt     (Utrecht University)
 Guus Sliepen           (minutes, Utrecht University)
 Jiri Kuthan            (GMD Fokus)
 Henk Jonkers           (Telematics Institute Enschede)
 Bharat Bushan          (GMD Fokus)
 Günther Schafer        (GMD Fokus)
 Olaf Riebe             (Acotec)
 Shuichi Tashiro        (Electrotechnical Laboratory Tsukuba)
 Shigeru Miyake         (Hitachi)
 Glen Zorn              (Cisco)
 Rogier Visser          (Ericsson)
 Wim Nouwens            (Ericsson)
 Sebastian Zander       (GMD Fokus)
 Tanja Zseby            (GMD Fokus)
 Georg Carle            (GMD Fokus)
 Axel Nennker           (Deutsche Telekom)

28-09
 9:30  Agenda is being prepared.

------------------------------------------------------------------------------
28-09  Modelling, specification and simulation
10:00  Arie Taal, Arjan van der Vegt

Arjan starts off presenting the AAA simulation he made in Java. Jiri Kuthan asks
if an introduction about the research that lead to the simulation could be
given before showing the simulation. Cees de Laat tells the group that the goal
was to build a generic simulation environment so that other AAA models can be
simulated using that. The purpose is getting information about the issues of
specific models. Arie Taal says that he has modelled a use case with UML for a
generic AAA request. A discussion starts about what exactly a "policy" means in
the use case.

According to Arie, a policy is something like a generic logical proposition,
and in his use case diagram he splits this up into authentication and
authorization.  John Volbrecht thinks that this split is unnecessary and should
be removed from the diagram. Cees de Laat says that a policy is a set of rules
which should be satisfied for a certain request to be granted. John Volbrecht
then says that the use case diagram is incomplete, although there is some
recursion implied in this, this does not show in the diagram.

Arie Taal then goes on and explains that the use case diagram only shows one
piece of the picture of a request; policies should be defined in a recursive
way (a policy might issue it's own requests, which on their turn invoke the
evaluation of other policies). This turns into a discussion about whether
policies should be recursive or not. Recursive policies are more generic and
flexible, but non-recursive policies can be proven to always terminate. It
appears some people attach different meanings to AAA terms, leading to some
miscommunication.

Arie Taal suggests to look at what an "actual" policy looks like, so that
people get an idea of what the issue is. He shows a slide with an example
request and the policy attached to it. Some parts of this policy can be
evaluated locally by the AAA server that got the initial request, but some
parts cannot and evaluation has to be done at a remote AAA server. That implies
that a local PDP must know where to forward certain parts of requests to. Arie
then shows how a request or policy might actually look like as it is
transmitted over the wire. His example is in XML and uses URL's to link policy
parts to other AAA servers.

Cees de Laat asks what the group thinks about the best format would be for
policies. Georg Carle suggests schemata, but Cees de Laat and Arie Taal then
object and say XML is much simpler and more extensible. John Volbrecht remarks
that this maybe is a problem for an IETF group instead of this IRTF group. Jiri
Kuthan says XML also has extensibility problems, because instead of new
schema's new DTDs must be available to all AAA servers to be able to parse
policies which use new features.

11:00  5 minute break.
11:20  End of 5 minute break.

A discussion is started about the language used for the logic that is in the
policies. Arie Taal suggests DNF notation for simple implementation of parsers,
Olaf Riebe suggests hard coding the policies for speed. John Volbrecht says that
this does not really affects the AAA architecture, and DNF should be used for
now, the issue can be discussed later.

Arjan van der Vegt shows his simulation. It is a generic model of users, AAA
servers and policy repositories. Users can issue requests, which can either be
evaluated or forwarded by the AAA servers. Since no policy parses has been
written, the requests are always satisfied, because the policies always
evaluate to "true". Work is in progress to build this parser.

John Volbrecht asks that everybody presents questions to Arie Taal so that he
can get an idea of what a policy should be able to describe, what problems it
should solve etcetera. This list of questions will be posted on the mailing
list for further discussion.

------------------------------------------------------------------------------
28-09  AAA at Ericsson
12:00  Wim Nouwens

Wim Nouwens describes with a few sheets what AAA means for Ericsson and why
Ericsson is interested in the AAAARCH research group. John Volbrecht asks Wim
if he has any concrete examples of AAA problems at Ericsson and if Ericsson
would share their insight with the AAAARCH group. Wim says that they currently
are in an orientation and fund raising phase, but that if they start working on
AAA itself they will share with and participate in the AAAARCH group.

Cees de Laat asks Wim Nouwens why they are interested in the AAAARCH group while
Ericsson is already involved in the AAA working group. Wim Nouwens doesn't have
a real answer to that, only that they want to get as much information as
possible at this stage.

Georg Carle asks if Ericsson has specific policy issues. Rogier Visser says that
the Ericsson department in the Netherlands is only looking at accounting and
does not know if they need or want policy servers to handle that.

12:30  45 minute lunch break.
13:30  End of 45 minute lunch break.

------------------------------------------------------------------------------
28-09  Accounting draft
13:30  Tanja Zseby, Georg Carle, Sebastian Zander

Tanja Zseby quickly points out the differences between the previous and the
current version of the draft. She then asks if anyone has comments on it. Cees
de Laat remarks that if the IETF will review it, they will especially hammer at
the message format, so they should be prepared for that.

John Volbrecht has some examples of accounting that do not quite fit into the
model that is described in the draft. Tanja Zseby says that indeed the model
should be generalised. More specific: authentication and authorisation do not
need to follow the same path as the accounting.

Tanja Zseby shows some slides of the Pittsburgh accounting setup. Tanja urges for
a detailed naming scheme or policy for all the topics in AAA so that the model
can be made more clear. John Volbrecht and Tanja agree on making a glossary for
the terms used in AAA.

John Volbrecht remarks that accounting and metering can not only be used for
billing but also as feedback to control and adjust QoS services.

Cees de Laat asks where the PDPs and where the PEPs are in the model. Tanja
Zseby says that that is not clear. Georg Carle says the COPS-PR system combines
both PDPs and Pea's for efficiency, so that there does not need to be a clear
distinction between the two.

The discussion then goes back to terminology. After a while Cees de Laat
suggests that everybody should send in lists of the terms they use, complete
with a technical description. He will then compose an AAA glossary, trying to
be consistent with other IETF naming policies, and will put it on the website.
Everybody agrees on this.

Georg Carle says he thinks the draft is close to being finished and he will
probably ask for final comments on the mailing list. Cees de Laat urges to fix
the terminology issues first (as soon as the glossary is complete of course).
John Volbrecht wants to do a last call for all the AAA documents in December,
so that in the spring they can all be presented to the IETF at some time. Cees
de Laat asks if there are more remarks on the draft. As it appears that there
are no remarks, mainly because not everyone has read the draft, Cees defers the
question to tomorrow.

------------------------------------------------------------------------------
28-09  Accounting and charging at the Telematics Institute
14:40  Henk Jonkers

Henk Jonkers shows some sheets from the Telematics Institute's AB&P group
(accounting, billing and payment). The diagrams on the sheets are worked out
examples of very specific applications. Cees de Laat asks Henk what the generic
parts are that can be identified, because that is what the IETF is interested
in. Henk cannot point out generic parts. Cees suggests that Tanja Zseby and
Henk should work together to map their diagrams onto each other, so that
generic parts can be identified in a real-world application.

John Volbrecht and Cees de Laat then start discussing whether these
applications should be able to be completely handled by AAA or that only the
generic parts should be done by it. John says a lot can be learned from these
real-world applications: difficulties, possibilities, etcetera. Then John
mentions a lot of issues and problems that are touched by AAA. He wants two
things to be done: 1. making models beginning at the lowest level and working up
instead of taking a real application and working down, and 2. make a distinction
between the accounting protocol and the rest. Nobody comments on that.

Georg Carle asks about diameter and it's competing position with the AAAARCH
group. Cees de Laat says that diameter already does a lot of things which the
AAAARCH group requires from AAA and that if diameter is the best tool for AAA
after a little tweaking, it should be recommended to the AAA working group, but
otherwise an IETF working group should work on it. Diameter already carries
requests around, and this research group should probably describe how the
request structure should look like.

16:05  Cees de Laat adjourns the meeting to next day, 9:00.

29-09
 9:00  John Volbrecht has great difficulty getting WaveLAN to work.
 9:15  Cees opens the meeting by presenting the agenda for this day.
 
------------------------------------------------------------------------------
29-09  Hard questions, identifying research topics
 9:25  John Volbrecht

John Volbrecht says there will be more meetings and that it would be good if
some of this research will help other projects even if the AAAARCH research
group doesn't come up with something useful for the IETF. The research done
could be useful for diameter.

There are some hard problems in AAA John Volbrecht wants to see answered. The
first one he mentions is session IDs. Should they be structured like a
key ring? Should they be hierarchical (having the tree property) or free-form?
Where do we need the session IDs exactly? Should there be session IDs for
each A or for a generic AAA session? To what should the IDs be bound? How
should the different IDs themselves be tied together? Cees de Laat draws a
picture describing that binding can be between the three As of AAA, between
services and between kingdoms, so that there are a lot of possibilities. John
Volbrecht suggests forming a subgroup that will describe and evaluate all of
these problems, and also work out a "session" terminology for inclusion with
Cees' glossary.

The second problem is how a request should look like. What information should go
in it? How should the format/data structure look like? Should or how should
requests be translated to other requests? What are the consistency requirements?
Should there be upper bounds to the time a request lives? What about possible
DoS attacks? Scalability? Performance?

What is the relation between authorisation and signalling? Should signalling be
part of AAA or not? How should failures in signalling be handled?

The last question is about the binding between authentication and authorisation.
Should it be possible to reuse authentication information without having to log
in or authenticate for each new request? What about the security implications of
that? Which AAA servers should be responsible for caching authentication
information? What if caching leads to inconsistencies?

11:00  10 minute break.
11:10  End of 10 minute break.

------------------------------------------------------------------------------
29-09  AAA context document
11:10  Leon Gommans

Leon Gommans shows an introductory slide of a generic interaction between a user
and a service, and John Volbrecht and others fall over the word "trust" Leon has
used. Leon means something very broad by this, but John says especially terms
like this should be firmly defined.

Leon Gommans shows some examples of services and raises the question who is
going to pay for the services, who is going to bill it, how is payment done,
who takes the risk when payment is not done, etcetera. He then shows several
business models and applies them to the examples he showed earlier. Apparently,
the AAA models depend greatly on the business model that is used. The point is
that people will have different viewpoints of AAA depending on how they
perceive the service.

Some people remarks that these examples are very good for use cases and that
they give a list of issues that should be able to be handled by AAA models.
Bharat Bhusman then introduces the concept of actors, stake holders and other
persona which are part of these use cases. Bharat suggests "playing" one of
these scenarios with these actors to see what the problems are. Some people
propose to do it directly, but Cees de Laat says this can be done after lunch.

------------------------------------------------------------------------------
29-09  Policy based document usage control
12:05  Shuichi Tashiro

Shuichi Tashiro shows some sheets describing his policy based document usage
control system. The document itself can talk with some kind of AAA servers
which then can authorise the disclosure of the document.

Several questions rise about the business model that is used for this system.
Shuichi Tashiro explains that it is a prepaid system.

12:35 Lunch break.
13:35 End of lunch break.

------------------------------------------------------------------------------
29-09  Example scenario
13:35  Leon Gommans

After a while the example of a broadband Internet service provider and a video
on demand content provider is selected, where the BISP acts as a portal for the
CP. Bharat Bhusman explains that there is a distinction between the actors.
Some are primary persona, others are secondary. The user for example is a
primary person when it comes to getting the video delivered, but the user is
only a secondary person in the case where accounting has to be done.

Arie Taal and Leon Gommans, with the help of Bharat Bhusman, draw up a use case
of a user with a TV who wants to "add channel" to his cable subscription (like
requesting Canal+). Although no final diagram has been drawn, a lot of issues
did come to light in trying so. Most of the discussion was about the viewpoint
that should be taken: from the top (user view of an application or service),
middle (AAA servers) or bottom (signals, bytes, protocols).

------------------------------------------------------------------------------
29-09  Next steps, plenary meeting, charter in spring
14:45  Cees de Laat, John Volbrecht

Cees de Laat presents a revised list of documents on the homepage. He walks
through the list and discusses what should be done:

- Henk Jonkers should provide some accounting examples and map them onto use
  cases.

- Policy based accounting from Tanja Zseby, Georg Carle and Sebastian Zander is
  almost finished (apart from terminology), they could probably form a separate
  research group.

- Modelling and simulation of the Utrecht University group should be split, so
  that modelling documents can be adapted and reformatted according to what is
  learned today and be converted into a draft.

- Policies across organisations etcetera has not been researched a lot and it is
  a big and broad subject. Georg Carle suggests it is quite general (it also
  applies to QoS) and it should therefore be treated more general and not
  specific for AAA.

- Look at issues relevant to AAA working group protocol. If the AAAARCH group
  does it's job thorough and in time we could probably influence diameter.

- John Volbrecht wants documentation describing session IDs, request formats and
  other components, speed and scalability issues and how to split authorisation
  and signalling.

Cees de Laat and John Volbrecht then come up with a to do list:

* IETF meeting is the 12th of December, so all documents should be finished by
  approximately the 20th of November.

* Subgroups should be formed to work on pending issues. Tanja Zseby suggests
  putting requests for participation in subgroups on the list.

* Phone conferences will be held every three weeks until the upcoming IETF
  meeting to discuss further issues and the progress of all the work.

* Everybody who works on documents should mail links to them to Cees de Laat,
  and also inform him of any changes. Cees will put the links together with the
  "last changed" date on the webpage so that everybody can keep track of them.
  Other interesting links can also be mailed.

* Georg Carle suggests that there should be a list of questions, problems and
  important issues with description on the homepage.

* John Volbrecht urges that everybody should also send in an abstract of what is
  going to be in the final documents.

* Tanja Zseby urges that the importance of our work should be made clear in the
  documents and during the IETF meeting.

Georg Carle et al are willing to investigate the authorisation and
signalling problem after they are done with their current tasks (probably
march).

The Utrecht University group will look further into simulating an AAAARCH model.

Cees de Laat will look in Terana at the plans of the next generation
infrastructure which will form a real target for AAA.

Some talks then start about Active Networking and all the 802.* standards there
are.

------------------------------------------------------------------------------
28-09  Question round
15:55

- Tanja Zseby wants that the goals for the meeting will be more clear next time.
  Although there are lots of different goals (everybody wants AAA for his
  specific application), there are common goals, and they are important for this
  IRTF.

- Shigeru Miyake made a webpage with photos of the social events surrounding the
  meeting. Cees de Laat will put a link to them on the AAAARCH homepage.

- Jiri Kuthan would like to see document with a road map of the AAAARCH research
  group. He misses an overview.

- Leon Gommans thinks that more "real life" examples should be available to give
  the AAAARCH a focus.

- Bharat Bhusman agrees with Leon Gommans.

- Arie Taal says there are a lot of terminology problems and a lack of a good
  model for true generic AAA (as opposed to use cases).

- John Volbrecht says a lot has been done already, and that is a good thing. He
  thanks the hosts.

- Guus Sliepen says that there are unanswered questions which cannot be solved
  by talking more about it, but only by doing real implementations and
  simulations.

- Cees de Laat finally concludes by saying that this was a fruitful meeting. He
  did not really anticipate that, because the mailing list was very silent.
  There has been a lot of input from everybody. He also thanks the hosts.

16:20  End of the IRTF AAAARCH interim meeting September 28&29, 2000 in Berlin.


CdL - may 1th 2000 Visitors of this page: