Minutes of the IRTF AAAARCH interim meeting January 29&30,
2001 in Utrecht.
==============================================================================
Attendants:
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:
+-------------------------------------all-sessions-+
|+---------------------------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:
3.1)
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 |
|Equipmnt|
+--------+
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.
3.3)
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
SLS.
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.
3.6)
Means: pull a policy.
3.7)
Means: evaluate that policy, but do not execute the actions, instead
send those
actions back in a reply so that I can execute them.
3.8)
Really fits next to 3.1. However, Cees de Laat remarks: "Guus is
right, but we
just don't care."
3.9)
Adds the event log to the diagram on the whiteboard.
3.10)
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
draft.
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
XML.
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: |