Transcript (Minutes) made by: Renee Cohen (www.ecaptions.com>

 
IRTF, March 22, 2001.
Authentication, Authorization, Accounting Architecture
 

CEES DE LAAT:  Welcome everybody, I would like to start this meeting, in the 50 this IETF.  It's now 1 o'clock.  We have two hours today.  Till 3 o'clock.  There are a lot of agenda items that you can see.  So I try to keep strict timing schedules so we do not overrun and even give presentors all the time.

I can also inform you that we are requested an extra, or that we requested to be able to use a room this evening.  And we got the something room at 8 o'clock.  So for more detail discussion, from the stage that we are now going to in this session, we can do more details stuff this evening.  So, at 8 o'clock in the Rochester room,

         The first thing to do is the blue sheets, as you all know, we are from IRTF, so therefore, we.

( I R T F.  They are not blue sheets, so they are pink in our case, so I will start to circulate them here. )

The organizational thing to do now, agenda bashing, somebody present who wants to delete items or add items, or is somebody here who is not here on the agenda or the other way around?

I presume once, second, again, there's approved.  Okay.  So, we need to find a note taker.  I took care of that before the meeting, and you are going to take notes, thanks for that.

And I have two opening remarks, so, I'll switch to the opening remarks.

So, I've written down on this slide what happened since our meeting in San Diego.  As you know, we had a meeting in San Diego, on the sun day before the IETF, because the official IETF slots were full then.  By the way, I can inform you that it turned out that the Thursday evenings are always not scheduled at IETF, and that the chair of the IETF, if informs possible, schedule I R T F groups, at least at Thursday evening, if not in the regular groups.  So they have a decent chance of success at the IETF meetings.

So, since San Diego, a couple of things happened.  We had an interim meeting, at the University where I come from, and that was I think at the end of January.  We turned out to have quite a full discussion about putting more structure and detail in some parts of the model.  But I will come back to that, as a result of the draft which is now half written, mostly by Dave, but I will present that as a first draft today.

Since then, three new drafts appeared.  They will be discussed today, two drafts were reworked, so, the policy base accounting, and policy model.  We had only two tele conferences since then, so everybody was quite busy in their normal jobs, since San Diego.

So, the tele conferences started in February, and before you know it, it's March.  The tele conferences were not heavily populated.  I must say, the least, about 8 or ten participants.  The discussion, and that's another thing, since then we have started the discussion with the grid forum people, about their models and how they want to do security and our models, which are quite similar, but we will hear more of that later.

I have to say, one thing, which is really concerning me.  About spacing and participation and con, is a part from about four places, it's quite poor.  I must say, so I would love to see more enforcement people in, through essential, where things need to happen.

I did already mention the evening meeting.  Tonight, at 8 o'clock, we will have a meeting, in the Rochester room, I think, about opposite to this room.  On this floor.

And we will, that's another discussion item, which I want to propose this, should we go for some re chartering?  There are groups existing for one year and four months.  Should we re charter, adapt our charter or not.  So to at least give you some food for thinking, in these opening remarks, I will show you the charter as it is now and where we are.

This is just from the charter.  So what the goal of this group is to come up with an architecture that can support, and services that can inter operate across organizational boundaries.  Are exstensible yet common across a wide variety of Internet services and enable concept of AAA for spanning many stake holders or what we call many kingdoms.  Provides application independent session management mechanisms, contains strong security mechanisms that can be tuned to local policies, and is scale able to the size of the global Internet.  Which is also quite a challenge.

So, the goal is to diseven tangle the policy working from the application, dependent and to application independent part, and to create a model of that.

So, the goals are, the items which are in the charter which we would do, have noted here, develop generic AAA model by specifically including authentication and accounting.  That is already underway.  R C 2903 which gives a model, that needs to be detailed, and details filled in, and so that's on the way.

Develop audit ability framework specification that allows the system, for functions to be checked in a multi organization environment.  Which means not yet.  I get.  Should happen.  Nobody is working on that yet.

Develop a model that supports management of a mesh of inter connected AAA servers.  You can say that that's underway.  The main issue is using generic model.  Not yet.

But, given the drafts which are now coming, that could get underway quite soon.

Work with AAA working group to align short term AAA protocol requirements with long term requirements as much as possible, I made the statement that that could be worse, but I hardly imagine how.  Given the meeting last Monday or Tuesday.

But, we should see what can be done there.  Define distributed policy framework, coordinate with policy framework working groups and others, and that's underway and we have common discussions, so that's working.

Develop an accounting model that allows authorization to define the type of accounting, that's almost done.  That's one of the drafts which is already quite stable for quite sometime.

Implement a simulation model, that's underway.  And complete the work in Q 32,000, that was ambitious.  I said that in the charter, and well, we should, and well, we failed in that because we are sitting here today.

So, only for the letter, I should revise the charter.  We have I believe, discussion on the mailing list or at least I got one suggestions, so, we should you revise it to define the type one interface in a high level and abstract way.  I think that would be very useful.  There are already in the draft and some papers, it's done, work done on this.  Define functionality of the driver policy, define functionality of type two interface, work with the grid forum and Internet two to include application specific security work which is going on that has applications for this work.  We have discussions about that with Shibboleth, and the grid forum as we will hear later.

Define exactly which docs to produce and get it done.  More or less, if you go to the home page, you will find a table of work items and documents, and I think we should maybe tonight go through that and really get altogether done.  I would remove the time constraint to create room for research, in times since I am from the University, I of course love that, and it's a bit dangerous.  And so this is general information, what we also did since last time, I obtained domain name.  WWW Dot AAA A R C H.Org, and that points now, and of course, that's our home for this research group.

That's all I have to say as opening remarks.  John?

JOHN VOLLBRECHT:  We'll talk, I think the, I think there will be presentations this afternoon of, I think it will be a charge for a lot of interactive, you know, work this evening, and I'm actually, I hope that that, you know, that people who want to interact, and actually understand better what some of the thinking behind things is, would come tonight, because we'll have a chance to do a lot more interactive conversations.

CEES DE LAAT:  So as someone might have noticed, I have slightly changed the agenda form, that I'm now the first one to present, to save time for changing the laptop, and so I will now present a draft which we'll send to the mailing list, and to the draft editor, to the draft repository, the AAA generic structure draft.

So, to give you some idea of what this draft is all about, we had an interim meeting, and one of the main things we discussed there was basically this multi domain case.  Given the generic model that we have in our R C 2903.  And this is that detailed view and the notion was that, the block, building block we have there, we have AAA server, which talks with all the AAA generic servers.  We always call it a rule based engine.  But the notion was there, that actually it should have much more internal structure and this internal structure should somehow explicitly be described, in order to later have the built-in architecture to exactly describe what relationships between different AAA servers there would exist.

So, we basically started out by doing no presentation at all at that interim meeting, but just took a white board and just started drawing, and discussing, revising, re drawing and re discussing.  I have here a picture which, in the actual drafts it's already a bit different again.  So look for the differences if you wish.  But we came up with this model.

You can see my point err, I hope.

So, we started to think about and to go through what kind of internal structure should such a generic server have?  And well, what place should it have and how should it be connected?  So we of course came, we came up with a kind of a control module, which would then have the rule based engine where the rules would reside in.  You would -- does somebody have a laser point err?

DAVE SPENCE:  Yes.

CEES DE LAAT:  So, of course, you need to be able to get the protocol, and so we think you have an entrance, in this picture, still we have the exit on the other side.

NEW SPEAKER:  We can't hear you.

CEES DE LAAT:  I was afraid of that.  I, I can do this.

Okay.  You have somewhere, the message is; AAA message is coming in, and you need a protocol, and associated with that security, which should do the security of the message themselves that they cannot be changed.  And also, the relation building with the other AAA server.

That would go to the control module, but as in the generic model, AAA can also send out AAA request to other AAA servers in other domains, so there's also a protocol where I have to go out there, also, again with security module.

From the control module, you would go to, or retrieve your policy from a policy repository, and you should be able to store information in the event log.

There should be some session management, of course, because later, we will hear more about that, in the session I D draft.  And, I don't know if this is still, I do not think that we still have this internal in the current draft, but it was also need for standard protocols to have an entrance into this system.  All the discussion we had, how do we do the application specific modules?  How do we get the connection to the A S Ms, and in this picture, we have, we took the bowled step of F three, for every A model if you wish, for the authorization and the accounting, and A S M interface and the current draft we have combined this again, since that seemed more logical to us.

So, we are still working on the draft, which describes this details of this module, and I would say take a look at it and give me your reactions.

So, are there any questions about this?  Okay.  Then I think we're ahead of schedule and I want to give the floor to the next one.

Which is John.

JOHN VOLLBRECHT:  Okay.  I got elected to talk about session I D, draft, and as I was reviewing, what we would talk about, it got clearer to me that I had a lot of questions about what a session was, and so I guess, so there is a draft, which is actually quite good in a lot of ways.  It has a lot of requirements in it and describes a lot of issues in terms of what should be in a session I D, but I thought it might be more interesting, because, it's a little, because I don't think it's settled yet and I would like to have some discussion, I guess, about this.  And this is actually one of the things that I was hoping we will have time to talk about this evening, and I would like people's input, so, I, after having some discussions with Tanya and Sebastian, the other day, I started trying to document some of our discussions and I decided it was harder than I thought.  And so, I started trying to find a way to represent some of the things we had talked about, and I decided that, I would try to create a data model, which I have never done before for anything, so this is an experiment, but, you know, so we're going to try it.

So, I said, well, okay, what is a session?  A session is from, from a daylight view, is basically a something between user, I don't mean user necessarily as a person, it could be whatever, and an application, is, it could be a network access server or a web server, or basically anything you might want.

But, a user typically has a user I D, some kind of authentication credentials and a profile.  I think, you know, you might argue with that and it might be less profiles, I say profile and I really should say profiles.  The application, actually, I think, looks pretty much like it.  It has an application I D, might have authentication credentials, not all of them have them right now but they clearly could if you wanted to know, to be sure you're talking to the application you think you're talking to, they ought to have authentication credentials.  And sometimes an application profile.  Again, the application might have a lot of different profiles, for different organizations that are using the application, or for different people, or, but, the application profile, and the user profile, are different.

At least that's the theory.

So, then, an interesting thing to imagine is that a session, so, now, on the left side of the bottom over here is pretty much the picture we had in the last slide, now we have a session, a session I D and credentials, and now, imagine that you're hooked up with a session and you want some more resources and the resources want to be part of that session.  At that point, assuming that the session has some authentication credentials, credentials, it can go go out and use the resourcesing to get the questions.  But presumably, you could get them from a user, or through the application.  And, the application might have some authentication credentials already, might already be pre authenticated with some set of applications so that it be would be allowed to, to let you, for example, somebody who is connected to the network, might be allowed to set quality of service parameters on some route err and that might all be set up ahead of time.  And then, be hooked up into the session.  And the session, so now there's a new session, again, there's a session I D, and not necessarily with authentication credentials, because every session might not be allowed to get new resources or need a session authentication credentials to get them.  Same thing with session profile.  And profile basically says the kind of things you want.  So it seems to me, again, and this is all stuff that I have done in the last couple of days, so in terms of its built on some of the things we've done before, but it's, it's, I think it is really powerful.  And I'd like to, I'd like to explore whether this is a valuable way to describe some of the session information and I'd like to, if people are interested in working on this, I'd be very interested in pursuing it.  I'll probably pursue it for a while myself.  But I'd like to work with other people if it's at all possible.

So I just did an example to see if you can put real things in there and here is a local dial with a Q O S, and what that might look like.  If you start filling in some of the attributes.  Any questions about this?  Does it make any sense to anybody?

It doesn't make any sense to anybody.  Somebody has to say something.

Okay.  So I, one of the things I was doing was to contrast session, and session I D's, with transactions and what I'm calling request I D now.  So, a lot of, if you just go through, this is an example of a fairly simple request, user goes to some AAA server and requests authorization for some application, and so he goes to an authorization server, goes to an authentication server and somehow they combine something about the ticket or says okay, or whatever, depending on which model authorization sequences you're doing.

This is pretty much the kind of stuff that the generic AAA server is working on.  Being able to, you know, figure out how to pass policies and combine policies, and so on.

The interesting thing is, it seems to me from a protocol point of view, or between server point of view, there is really not a need for an I D that covers the whole thing.  That each step on the way is pretty much an entity of itself.  That the user, the AAA one is pretty much in one exchange and you need to keep track of it.  But it doesn't have to be mapped to request I D two.  Except in AAA one.  Which of course needs to know those things are all tied together.  But outside of the server, it isn't necessary to, you know, to know that.

This is all so obvious, that it's not interesting.

Okay.  So, well, okay.  So, there's a need -- one of these -- wait a minute.  Okay.  So, I said, all right, how do these things tie in with for instance, auditing or billing or anything else.  So, and here, I get this, and again, I'm not all sure this is the right exact picture, but basically, someplace, there's a usage record of which, which needs to be known by both the session, probably it's associated with the session, and also associated probably with some auditing track customer, might be associated with some billing kind of things.

And again, here, you probably need to, in the usage record, you need to know what the session I D is, and so that you can go back and find out what's in that session ID, and so on.

So, all I've added in this picture is that, just that there are other things that tie into sessions, and each session could have other, you know, things that are tied in, looking at that, at the set of information associated with that.

So, the, one of the things is that a session I D may require some, or probably does require, although the, it may not always require, some binding between the transactions, so the request ID and sessions, so that the, and presumably, the transactions get logged someplace as a separate kind of logging capability.  And those logging, you know, in order to go out for auditing purposes, to the session, the session needs to keep track of or may need to keep track of, if the logging auditing policy requires it, how to find the actual transactions that created, that were part of the session.

And so, I guess, basically, my thing in the end is, it does seem like modeling could be a great tool to get at the details of this, I feel like, that things, as I started to play with this, it seems like it was actually working and being pretty helpful to describe things this way, and that I think it could actually solve a lot of problems if we have a good data model for all of this stuff, to actually tie this together.

So that's really the end of my comments.

NEW SPEAKER:  I do have a comment on the, I've noticed a lot of work groups focus on problem of a session ID or the exchange of using a token to identify resources, between the service, for example, and the SIP work group, and the DCS and the off method and some other work groups have their own individual submissions trying to solve this problem.  And I think this is an important area to get out, articulate and put terminology to.

JOHN VOLLBRECHT:  Thanks, because I actually would love people in other working groups and it would be a focus for everybody to come up with a common way of at least describing what the {proob} problem is.  And people might need different solutions indifferent applications but if you understand the class of solutions, that would be helpful.

NEW SPEAKER:  Okay.  Thanks.
 
 

SEBASTIAN ZANDER:  Okay.  Let's start with an update on the policy based accounting draft.  I think I will be pretty quick, so, just a short overview, actually, this is a very old slide, which was already presented at the last IETF session, but just to give you an overview of what's in the draft.  So we want to refine our policies for defining rules for generation transport, storage and accounting data.  And we want to use this for the configuration of the accounting process and the generic AAA architecture.  And the key features or the features of this are to support a variety of different accounting services, to configure a heterogeneous accounting infrastructure, and to exchange configuration information between different providers.

So what has been changed from version 01 to O two?  We clarified the reference model section, especially some policy translation and the data processing.  We expanded the section on accounting policies, we discuss push versus pull model for policy distribution.  And we added a part which discussions the parameters, using policy condition and policy action.  We fixed some errors, in the accounting message sequences, with respect to the different authorization schemes, defined in R F C 2904.  Then we tried to align our message, it was a draft, our object messaging draft with Dave, and we fixed a couple of pictures, and tried to align that with R C 2903.  So there was missing A and policy repository.  And we did some additional clarifications and more fixes, with the draft.

So just one slide on the policy parameters.  So for the condition, for example, we can have the user parameter, his IP address, the service class, or an accounting type, which is just defined like SIP accounting or detailed

( Simple or detailed. )
         And for the action, we can specify what type of accounting record should be used, for example, letter of detail.

( Level of detail. )
         The destination, the report interval, the storage time and the access list, which means, who is allowed to access certain accounting records.

What needs to be done?  We need to have a closer look on the policy terminology draft and the generic structure draft, which somebody already presented.  And to align our draft with these.  And the second point is, what do we want to do is clarify where accounting policies are stored, and evaluated within the generic AAA architecture.  And, in light of these, we again need to revise the example section.  And I don't know if there are some other issues.  And we plan to release the next version April, may, definitely before the next interim meeting.  So, the question is, are we then ready for working group last call?  This question obviously depends on other issues question.  They just put up the slides, just together as a co-author, to get a perspective, because this draft is already 9 months old, and so, I want to know what's going on.

CEES DE LAAT:  My comment on that would be that, since this draft is quite dependent on the overview architecture drafts, that they probably should go together in last call, and not, if I, I wouldn't put this on the last call, and the generic model would change a bit, then you are in trouble.  So there is a kind of order, I think, in which the drafts need to be going in last call.  So, we have to wait a little bit.

SEBASTIAN ZANDER:  Yes,

CEES DE LAAT:  But it seems to me, that that's the best thing to do.  Other thoughts?

JOHN VOLLBRECHT:  Maybe you ought to think about how soon --

CEES DE LAAT:  Mike.

JOHN VOLLBRECHT:  I think, you know, if the generic model is ready pretty quick, we ought to take a look at the time frames for that.  If it's not going to be a while, I think we ought to think about pushing to get this one actually released.

CEES DE LAAT:  Okay.  Fair enough.  That's all for me.  Are there questions, comments?

NEW SPEAKER:  Could you go back to slide No. 2, please?

I saw an interim provider exchange of configuration information.  What about it to provide exchange off accounting policies?  Is there --

SEBASTIAN ZANDER:  That's what is meant by this point.  That sort of thing.

NEW SPEAKER:  Okay.

CEES DE LAAT:  That's all for this draft.  Next.  Could everybody who is presenting slides, please mail me the slides, so that I can put them on the web.

GUUS SLIEPEN:  Okay.  I will be presenting the policies draft now.  The changes, since the previous draft, are, well, just we re grouped and sorted all the terms.  So we've got it where you can read it more easily.  Spelling fixes, of course.  A number of new terms have been added, which are in the policy, so that there are about, about how our relations and rules are built.

And we looked at the policy terminal draft from the policy framework working group.  And we wanted to align it.  But we noticed that most the definitions that we had, that they had as well, were quite accept able.  And they were some other definitions which are different, but they are, they are very specific to our research group.  So we decided to keep them in.  And I put a note, I'll adopt the document, and state that this draft is for our group specifically.

Okay.  Issues with the current version, there aren't any issues.  Did only thing is that, somebody noted that accounting terms were not quite clear.  There are many things in accounting.  So, if people who do accounting stuff, send me some terms, and include them.

( And I could include them. )
         Well, what we have to do, we have to use this draft, well, we need input from the other drafts, for additional terms, of course.  And we need to re name the draft, because the name is, isn't very sense {yal}.  So, I think draft I R T F, arc terminology would be a better name.  And that's it.

NEW SPEAKER:  Can you give me a couple of examples of where the terminology that the, you know, what, how our use of words is different from what's in the policy framework?

GUUS SLIEPEN:   Let's see.  Well, we had a mention about policy component.  The policy framework working group is working on that QoS specifically.  And their interpretation of policy actions and policy conditions and rules are a bit different from what is here.  To name the specific differences, I would have to show you both versions.

NEW SPEAKER:  I guess what I'm wondering is, whether it would be better to, you know, to put either explicitly put something in there that says, here's what we mean, and here's what they mean, as opposed to saying, you know, be careful, because they're different.  Or something like that.  Because I think it's pretty important to not have policy terminology be different indifferent drafts.  I think that's just, you know, just --

GUUS SLIEPEN:  There are some problems with a few terms, with the rules.  So we have to --

NEW SPEAKER:  In this particular case, I'm just not exactly sure what it would be, but where there is a difference, could we put a, an asterisks and say, the way this is defined, this is different than what's defined in the policy framework definition?  And here's what's in the policy framework definition, or something like that?

GUUS SLIEPEN:  Yes, sure.  We could.

NEW SPEAKER:  I think it would be useful.

GUUS SLIEPEN:  Okay.  Any other questions?  Remarks?

CEES DE LAAT:  You are next.

GUUS SLIEPEN:  Okay.

CEES DE LAAT:  We are ten minutes ahead of schedule.

GUUS SLIEPEN:  Okay.

NEW SPEAKER:  Joe, I have a question, but it was about the previous presentation.  It took me time to process it.

I may speak out of turn here, because I must admit, I am new to this group.  But I was asking about some type of processing, one of the issues that is raised by service providers, is the fact that it's not only processing accounting, but it's some other kind of processing, which is user accounting, and then you generate files and later on you, you process that and you generate something, and it's processing.  In some cases, you may want to go from real time processing, by running some kind of engine, in the way to check if the account is not completed on maybe take some actions due to that.  So a typical example is a quick date applications.  So I was wondering if, in this approach of re architect AAA mechanisms, on the video content, that kind of real time processing that would be accounting, that would generate some feedback, I would say, on the system being enforced,

CEES DE LAAT:  Okay.  Well, do you have anything to say?  Sebastian?  Okay.

SEBASTIAN ZANDER:  Well, I think, I'm real time accounting, or what you mean that we can have accounting records continuously, maybe saying, to the provider or also to the user.  It's explicitly in the policy based accounting, it's an implicit scenario that we would like to support.  So we also have there, in there that, like, the customer itself can specify in what intervals he would like to get an update on how much resources he has.  So this is explicitly one goal in the policy based

NEW SPEAKER:  To be more specific, the real time, to generate accounting records in real time, I meant to do some processing on real time for doing the generation of such accounting records.  Which is like slightly different, so for example, we generate an accounting occur and you want to do some computations, give give something and if it's deleted, then you want to enforce in places, to have the access for this.  That's what I meant by real time

( I didn't understand a lot of what he says, so I didn't write it.   )

NEW SPEAKER:  What I meant is feedback, like for the authorization, this is not in the policy based accounting.  But, of course, I think if you have the position on the accounting data, then, you could also build this and maybe --

NEW SPEAKER:  The ?? group, something?

NEW SPEAKER:  I think it's not yet in part of the architecture, but we just have not --

NEW SPEAKER:  I think it's explicitly part of it.  I think I agree with that.

SEBASTIAN ZANDER:  I think if you have the data, you can use this as a syntax signal and you can use the information that you have thereto put it back to the authorization.  It's possible.  But we have not explicitly put this in our checklist.

NEW SPEAKER:

( In our draft yet.   )

NEW SPEAKER:  I think there's a lot of surprises here or something like that.

GUUS SLIEPEN:  Okay.  Draft AAA architecture.

Okay.  I will state the goal of this draft here, because I think it's changed a bit over time.

What we're trying to do in the draft is to define how to place relationships go.  We have to evaluate across a AAA service.  So you need to have an understanding of the relationship between the AAA servers.

That's one part of the draft.  The other is that, if you send the request policies, that's the main part of the evaluation.  The policies, there are policies in every AAA server, but together, they form the policies in the terminology draft.  So you have to know how these policies look like.

And also, what are the requirements that we have to put on the implementation of policies, whatever you have to do with policies.  And the other part is if you want to push or pull policies.  You have to have representation of policies, which is consistent across policy service.  So one must be able to read the policy:
 
 

NEW SPEAKER:  Now I have a question from a new being.  When you talk about policy, do you anticipate the work being done by the policy working group of the IETF, and the policy working group of the D M T F or is it something unrelated to that?

GUUS SLIEPEN:  It is related.  But if you're trying to have a clear perspective, do not let us be biased by work of the policy framework, because it's, the policy framework group defines policies in a restricted requirements, actually.  There are targeting to us today's current practices.  If you want to make them architecture, it works for everything, from ordering pizza to something else.

ED ELLISSON:  Would it be accurate then to interpret your answers, to say, when you talk about policy, you're not constrained by their work, but you're more broad and you can encompass it?

GUUS SLIEPEN:  Yes.

ED ELLISSON:  But you're not at odds with it either?

GUUS SLIEPEN:  No.  You'll see a lot of our work is also done in the policy framework.

ED ELLESSON:  I'd just like to endorse that position, as a co-chair of the policy framework working group.  I see your work as being broader.  We are constrained to single domain for example, and we are constrained to look at certain examples first.  Trying to make it generic, but we're taking examples as input and feedback as input in particular areas and you're looking broader than that, so I would endorse your view.

GUUS SLIEPEN:  Yes.  We also had a notion of making a cheap and generic policy information model, but, okay.

The changes, since last draft, is that we specified a B N F grammar for policies, explicitly.  It's not meant as something we have to implement, but just to have a base to work from.  So give us your comments, because we want to know what requirements and capabilities of policies are.  Of course, with the grammar, you have representation of that.

We also list some problems that we will now know we will encounter.  And there's conflicting policies which we discussed in the last IETF meeting.  Also, execution of actions, policies and actions, and if you have distributed policies, that, then a lot of AAA servers will evaluate distribute policy and they will will have some action with their policy.  So, and yet, you want to execute actions, but do I do it as a AAA server, to evaluate their part or do you send all the actions back to AAA server, where everything originates from, and that's AAA server executes it?  Do you let these actions be executed in parallel or serialized.  And these are all things you have to think about.  And also if you allow parallel execution for evaluation of policies, then you could have non determine deterministic results.

Okay.  A list of policy requirements which are quite obvious, if you think about it.  You must be able to handle arbitrary Boolean expressions.  I think that's very clear.  But you also have to handle arithmatic or string comparison or workshop, if you are doing some kind of QoS, or perm mutation things and if you want to say, if the this is greater than blah, blah, blah, and for example, for authentication, you want to check if the user name is really the user you want to talk to, so you have to string that comparison.

Well, you have to interact with application specific models, it's pretty clear.  In a distribution requirement, you have to send out requests, and you have to have actions of course.

But there are some problems, with pretty much all these items I just listed.  Except for the Boolean expression.  For example, a arithmetic and string comparison and all that stuff.  How far will you go?  Do you have to implement something like co-sign or square root, string comparison, do you only have plane comparison or do you allow relations?  Also related to this is the interaction of application specific modules.  We had, we were trying to make policy, simple authentication policy.  Using S Q L, as a database, which contains the application data.

And then there was something like a user sends a request, with a user name, and the policy has some information that says, okay, I have to look up the password in the database.  And if it's in an S Q L database, then you have to generate an S Q L query and you have to say something like select buzz word, user, where user name equals, and then you have to substitute the user name, that's user specified in his request.

And so, you have to manipulate the S Q L query.  So you have string placement, and it's hard to do in a simple expression.

It's almost like you are, you have to write a program.

Sending out requests is easy, but you have to push or pull policies, then you have all sorts of trouble.  Like you need the policy language, which is standardized and we're working on that, of course.  You need strong security so nobody can send you policies.

And, actions, they have lots of trouble too.  But I think I mentioned all these problems two slides ago.  Okay.

We looked into several areas for, how to represent policies.  We came with along list, and here are some of them.  You can write policies down in java.  java is nice because it's independent and you can do lots of things with it.  But if you require a device, such as AAA gate poll to have the implementation of a java device, I don't think many implementers will be happy.

But you also said at the last IETF meeting, that smart cards are very light weight and secure implementation, than java.  In AAA requirements.

X M L, if you use that for policy language and policy standards, then X M L is really only a way to describe that, as compares son to most, you can use D D T of course and have stand arrested policies.  But it won't actually evaluate.  So you need to write grammar and write the policy to evaluate it anyway.

And you also have, you also looked into certain other languages.  There are many of them.  And we can take an existing one or we could also try and write our own.

And we are looking into the last thing, because we want to know what your requirements are.  So we have to try to build policies and a policy language before you fully understand which one is best.

Okay.  That's the presentation.
 
 

NEW SPEAKER:  The question is, what's your time frame?

GUUS SLIEPEN:  That's a good question.  We are trying to make a parser now.  Using a bias B I S O N.  And I think we can finish it.  To evaluate execute policies.  We have to decide if this is a real thing, the best thing to do, I don't know.  What do you think?

CEES DE LAAT:  Well, we can try to do a proof of concept, of course, but since this is an I R T F group, we are actually not even allowed to create standards, we can only do experimental things and we should be working group charters to really make the policy language.  But nevertheless, this is,

GUUS SLIEPEN:  Yes.

CEES DE LAAT:  I don't know if you touch this touched this.  But if you have policies that need variables to decide on, and you have actions and the actions change variables, you can get in a big mess.  Can you comment on that?

GUUS SLIEPEN: Yes.

CEES DE LAAT:  So, they are in a distributed environment, of course.

GUUS SLIEPEN:  Same description in the policy framework group, I think.

Well, either you don't allow this or you allow it.  And then you have to take the consequences.

CEES DE LAAT:  Surely I won't allow it.  But we need research on that.  There is a lot of research in mathematics and informal message and agents about this.  But we certainly need to include that and look into it.  I would certainly not want to restrict it.

GUUS SLIEPEN:  No.

CEES DE LAAT:  Okay.  Are there more remarks or questions?

NEW SPEAKER:  We might have spoke about this, but, since it's research, I think a significant component of people worrying about, you know, dealing with policies in real life as understand ability of policies, to policy express sores, and it seems like there is a, there is no doubt, research has already happened and I'm sure a great deal more research needs to be done about, you know, sort of human factors, in this area, and I don't know if you looked into that, or hoping that will be in the scope.

GUUS SLIEPEN:  Yes, we did.  But, we, workshop will be found IBM is working on logic programming, which is a language which allows you to express logical formulates, but normally, you would have conflicts, and then you say, if there is a conflict, then do this instead.  It's just very normal way to say it.  But in the Boolean expression, it's very hard to do.  You have to write all the exceptions and then cord them together.  And this language allows you to specify in a simple way, and then, it translates it into an oral expression.  It does exactly the same.  But we are talking about, well, we are looking at how we should implement this.  Any ideas?  And it's easy to write a folder which allows you to specify policies in a human language and then translate it into something the computer looks at.  I don't think it's a very big issue.  Of course, if you have to look at it.

NEW SPEAKER:  I kind of like to just ask a question.  We can talk about this off line too, but it seems to me that, an awful lot of combining of policies and reasons that you have potential conflicts is because, we are creating, you know, in a theoretical environment, where anything is possible, but in reality, anything is pretty unlikely.  And therefore, we create a lot of complexity, that is not actually necessary to solve most problems.  So it would be nice if we could have something that would be, would solve the easy problems, rather than have, you know, something that solves theoretically all the problems and that's easy to understand and people can basically, you know, deal with.  And I don't know how you make that cut, but it, but it's a real temptation to keep going, when you pass up a certain model, and I don't know whether maybe there should be two sets of things, one, you know, the simple version, and then a sort of a complete version or something like that.  But as a --

GUUS SLIEPEN:  Well, you have a simple implementation, with many complicated or complex implementation, which present vents you from making computations.  So.

NEW SPEAKER:  I'm not sure that's necessarily the case, if you say that you're only attacking a certain class of problems.  You limit the class of problems you're trying to solve and you don't need necessarily as complex of a solution.  And I think maybe that's what you need to do, say, out of all, I'll only tackle this class of problem.

GUUS SLIEPEN:  Where are you starting from?  And trying to do things and later on, we try to look at the progress, and we got there.

CEES DE LAAT:  Okay.

GUUS SLIEPEN:  All right.

CEES DE LAAT:  You have ten minutes.

STEVEN TUECKE:  I'm Steve from argon national laboratory.  And, John and I had some conversations over the last fews months and they asked me to come, to give a quick talk about some of the things we're doing about grid space, because there's a lot of relationship to what's going on here.  So I have got probably 40 minutes worth of material so I'm going to fly and skip through a lot of stuff.  And you'll have complete slides for your slide set.  And I'll fly through stuff.  Unfortunately, I won't be here to night.  But I'll be here for two hours.

Quick overview of grid concepts.  Community authorization problem, which is the big thing we're trying to solve at the moment.  And then some details about our implementation approach.

So, I've got about 8 slides here and I really can only show one or two of them.  The deal on grid computing, basically, we're trying to enable the communities or virtual organizations to come together, across geographical boundaries or organizational boundaries to solve problems.  Some of the issues are absence of central control, absence of Omni science.  And complex trust relationships.  And the purpose is to fundamentally enable applications we can't do currently.

A different way of doing it is, you know, what we're looking at is moving away from a simple client server interaction model of the web, to much more of a full distributed computing model, pulling in all the different resources you need to solve your problems.

A lot of people are doing this, go to our web site, look around.  There's a couple of quick application examples of the sorts of things we're trying to enable.  One is on line instrumentation.  Argon, for example, has a big x-ray source, a community user facility.  And they would like to be able to put it on line and augment it with super computing computational power.

And do this all in collaborative environments and good things.

Large problems.  This is a big one that was solved about six months ago.  Using sort of an almost, or study at home type things, where you consume vast quantities of things on the network.  In this case it was an open problem of optimization, and they consumed basically sustained and something on the order of 800 processors for about a week to solve this process.  Peaks going up and down.  Earthquake engineering, this a big problem.  To essentially re build or go to the next generation of the networks earthquake simulation community.  And put their shape tables and tanks on line, with share hold data, and be able to tie in simulation to this.  Things like that.

This is the grand daddy of all project.  It's the next generation detector and basically, it's it's a heta byte of data a year coming out of this.  Which needs to get out to a few thousand collaborators around the world.  You have huge data coming out one side, and thousands of users on the other side and the users wanted to say, you know, find me this, post queries to find ten teta bytes of data.  and somewhere they have to meet in the middle.

In the commercial state, there's a lot of things cropping up, that are really related to this space.

On a more broadly speaking, there's a lot of overlap with what's going on in the grid space with some things, for example, pure air space.  A S P's, S S P's, things like that.  And the main things, you know, some people think of grid as high end, but really, that's a secondary issue.  The main issue is this one of bringing together people and resources across organizational boundaries to solve the problems.  So it's dealing with the inter domain and inter organizational boundary issues.

The globe bus project, we're an R and D group looking at how do you bring all these different sorts of resources into an environment.  The protocols, services, A P Is, that you need to do this.  And we do this, by part of it, by doing a lot of application works and a lot of deployment work.  So one of the artifacts that we produce, in addition to result results is the tool kit.  What's being used, real ones that we're building at this point.  And this tool kit is the basis for that.

There's a paper, a anatomy of the grid, that's a great place to start, an overview of the grid.  Now you're all experts at the grid.

What is some of the AAA problems that we're trying to solve right now?  Go back to the physics applications.  You've got hundreds of resource providers, spread throughout the world, basically, they're building this teared caption hierarchy for the data, and in addition, researchers have their own resources that they want to sort of bring into this grid space for them and their close collaborators for example.  So you have hundreds of resource providers, and thousands of users spread throughout.  To some extent the trick is how to avoid the end user trust relationship mapping.  You want the get rid of having full trust relationships.

So, some of the takes that we're putting on this, is from the resource provider perspective, what they would like to do is say, I don't care about individual users, what I want to do is give a terra byte of disk space to the atlas community.  That's a particular detector that's on line, and say, give a terra byte to the atlas community and out source all of the authorization decisions to a community representative or community administrator.

At the same time, it's not that they're all pooling resources into one centralized monitor community.  In many cases, individual users have their own users that they also want to bring to bear on on the problem.  So you have a lot of resources contributing into some sort of community wide pool, plus additional resources talking on to the side of that.  Of course there's all sorts of policies about how the community wants to spend the resources.  What projects at the moment have priority, allocations to each of them, what users, you know, belong to each of these groups, things like that.

And, I don't know what that last point is, so we'll go on.

What's the take that we're going at?  What I'm describing right now is something we're on the hook to build and are in the process of building.  So it's all stuff that's happening, and in our project plans over the next year or two.

So, the approach we're taking to this, is basically a capability based model for authorization.  And it's a kin to the push model within the AAA architecture work.

And so basically, the idea is you've got some community service and/or administrator, who maintains the membership of the community, that is, for me to become a part of the community, I have to essentially register into the community service.  It also is the place that maintains the membership of the resources.  For example, a resource provider sets up a particular service level agreement with this, with the atlas community, saying I'm going to contribute a certain amount of disk or a certain amount of cycles into this community.  Effectively, what this thing is doing, is maintaining the community policies, the access controls, between the users and the resources, to be consumed by this community, with all sorts of interesting relationships, groups of users, higher arc keys, all these fun things.

And the basic model is that, in order for a user to gain access to a community resource, that user goes to this service, says what he wants to do, and is issued a capability that he can go present to the resource or resources, to accomplish what he's trying to accomplish.

So, a couple of pictures, just to kind of put some visuals behind this.  You've got a bunch of users, a bunch of resources and the service.  So the simple case, is the user goes to the server and says I want to go do X.  I need to read a file to do my analysis.  Now, you can go off and present to the service, to do your thing.

Of course, that's much simpler than we really want to do.  Even this is simpler.  But the next step is, what a user really wants to do is not do it all themselves but have a service do it on their behalf.  So they want to delegate to a request manager, that can in turn go out to a community service and say, here's all the things I want to do, get the capabilities and go out to the various resources.

But it's more complex than that, there's more delegation.  And, you know, we're not trying to build a monolithic central thing that's in the central of the thing.  Trying to make it components, the various pieces.  And using this authorization service for a variety of different request planners and task managers and things like that.  So the user may say, here's the type of experiment I'm looking for.  All the data from a particular Clyde err run, a with particular energy levels.  Here's the analysis jobs that I want to run against those.  And hand this off to a request planner that will go figure out what the options are, negotiate with the various resources or community services to figure out what it should do.  Create essentially, a task graph or a run plan, and then, hand that off to some task managers, whose job is to persistly and reliably, blah, blah, blah, execute the plan.

So, the upshot is two fundamental issues that are being put together to solve the problems here.  And more than that, but two main ones.  That is the delegation problem, the ability for a user to ask some service to act on his behalf to perform some operations that he wants to perform.  And the second is this ability to delegation, the ability to issue capabilities to Grant access to services.  And you even want to do delegation of capabilities, things like that.

So, the third piece then, is, 20,000 foot overview of how we're actually, the actual tech behind this, that we're using to solve this problem.  So, if you were in the working group session on Tuesday, you saw me give three or four slides describing these badly named person nation certificates,

We submitted two drafts, one indifferent working groups.  Single sign on delegation, by creating these proxy certificates.

And in globe bus, we've been doing this for a long time.  We're just now trying to move this into the standard space.  In effect, what they are, they are X 5 O 9 certificates, signed by the non entity certificate, with various constraints, there's just no way that you can have my sign sign assert for somebody else.

( A certificate. )
         Its purpose is to bind the new identity to a transient key pair, so I can delegate to somebody else, the ability to authenticate instead of me.  It's allowing for I am person nation.

There's all sorts of text and they're motivating all the, why we're doing it and all the issues around it.  Some of the nice features of this approach is the integration issues.  By taking this approach, we can use these proxy credentials directly with SSL and T L S, without requiring changes in the protocol.  All we have to do is change the path validation.  This is what we've been doing at G S I for a long time and it's bought us great mileage towards deploying this stuff in real life.  We don't have to change everything.

Also, if you have authorization systems based on identity, you can continue to use this as your authorization basis, as opposed to, for example, both of these points, as opposed to attribute services which require protocol changes and things.  If you read my draft, you'll see where attribute services and these certificates can play together really nicely.

The other nice feature is, this fact that because you're essentially generating a new key pair, you're able to limit the consequences of compromise key pair.  So effectively, this is almost in your ticket.  Question?

NEW SPEAKER:  Yes, Steve, what you just described as far as the proxy certificate is very similar to what, there's two proposals in the IP S working group, pick and {gib} serve, to at least, based on the description you just gave, the very same concept.

STEVEN TUECKE:  Do you have my e-mail address, if so, can you e-mail me a pointer to those.

NEW SPEAKER:  Sure, Steve.

STEVEN TUECKE:  All right.  So, implementation status, this has been around for about four years.  It's been deployed across the national science foundation, and these other people.  These various other things.  And the European data grid.  So it's getting a lot of use, integrated to a lot of technologies.  Things like that.

So, now how do we take the basis and move it forward so it's actually usable for the more community based, capability model.  The plan here is to essentially extend these proxy certificates with restriction policies, which relates right back to the discussion right before this.  And that is, to allow, you know, what's a proxy saying now?  It's saying the holder of this proxy is allowed to I am person Nate the user to gain access to the resources that the user is allowed to use.  You want to restrict it and only let the user obtain access to some particular subset of the capabilities of that user.  So you effectively have the ability for me to issue to somebody else, a capability inform to use my resources.  That's effectively what's going on.

So, then, to tie this together, what we are developing right now is a community authorization service, which is this community service, takes care of the membership, the groups, the access control lists, and the basically, it has its own identity, within the X 5 O 9, sort of the security space.  And it's that identity that's known to the resources.  So when I as a resource provider, issue or Grant bulk access to a terra byte of space to the community.  What I'm saying is people should come to me as the community, identity, to claim access to that.

So when users want to use one of these resources, they get back one of these restrictive proxies, which is a capability, and then turnaround to use that to provide authenticate to the resources.

Then, in turn, what the resources need to do, is of course, they're seeing the cast identity come in, so one of the goals of this is to put the onus more out in the community, as opposed to the resource providers.  This says you come in as the cast identity, and it maps to a local account, standard UNIX account, quotas, that sort of thing, to draw a box around that community granted resource.

And, one additional thing that this resource provider needs to do is for a given request that comes in then, service request, is to essentially compare that request against the restriction policy that's carried along as part of the capability.  Okay.  And then, last slide, this is sort of glossing over the accounting stuff.  But in effect, the game plan here is to tag these capabilities uniquely so that you can use this information for tracking and you go use that to correlate back with the capabilities that are issued to get, say, user accounting data.  You can, within a resource, if you want to do restrictions on usage, you know, this user only gets a certain amount of disk space, you can also do that on a per capability basis.

So, that is the world wind tour through some of the things we're doing.  Any questions?

BOB MORGAN:  How do you handle differences in trust domains if you have multiple parties which are basically independent of each other?  And essentially, don't trust each other?  Which form part of the grid?

STEVEN TUECKE:  Well, so the no two resources have to know or care about each other in this model.  Basically, the trust relationship is a resource in establishing the agreement with the community service, is establishing a trust relationship with that service.  And then the user, by getting the capability from the service is in hearting that trust relationship.  You're getting back the community credential, which the resource knows about.

BOB MORGAN:  So it's handled by the community?

STEVEN TUECKE:  Yes.  In this case, right.

BOB MORGAN:  Let's see if I understand what you're doing with this.  When I think of my member community, as I will be presenting shortly, you know, I guess I think of it as a more traditional sense as an attribute of a user, and I think you stand representing that, the system as taking on a new identity, of, which I guess I think you're saying that, to some extent, that is easing the task of traditional systems, which know about, you know, sort of accounts, and again

STEVEN TUECKE:  Right.

BOB MORGAN:  And don't know the attributes.

STEVEN TUECKE:  Right.

BOB MORGAN:  I guess, --

STEVEN TUECKE:  So you're asking me why not go attribute certificate route.  I guess,

BOB MORGAN:  I guess.  I haven't gotten to that part of your draft.  But I guess, when I think about attributes, obviously, is a characteristic of attributes, you can have a lot of but you can only have one identity.  So if you, if, you know, being able to restrict something by saying, you know, you are member of this community, and faculty, and you take a bill this month, not part of the authorization mode, or --

STEVEN TUECKE:  Well, that's part.

BOB MORGAN:  Or back up.

STEVEN TUECKE:  That's all part of essentially what's supposed to be enforced by the cap service itself.  The idea is to move the decisions outside of the resources.  So all they care about is put a box around the community as a whole.  And let the community service essentially be the authority effectively, on the community membership.  So I mean, if you're a cast attribute model, you could imagine the cast server the issuer of membership certificates on membership in the groups community privileges.  But instead of propagating the information via attribute certificates, you would instead apply these in user requests access to resource and you issue back a capability for the user to do that.

So maybe we can take this off line, if you want, after this.

JOHN VOLLBRECHT:  Just, two comments, one is, I'm hoping, you know, and I just, that we're going to work this, and take this application and kind of fit it into the model that the AAA R C H group has, and so as you can see how different pieces fit together, at least in terms of the architecture that we're putting on, and we can check the architecture and see if it fits the application.

Another thing I'd like to point out, that Steve and I were pointing about and he didn't mention explicitly, is the idea that, with this, and I'm not sure, this may fit some of the other things Bob is doing too, but that, user be able to actually sort of loan his identity to somebody, to actually, just so if you have a colleague that you want to let use some resources that have actually been assigned to you, you can do that, as opposed to, and you can do it directly, as opposed to going through some central organization.  You might end up having to go through a central organization someplace.  But you can do the loaning more or less directly.  That seemed like a powerful concept.  Something which was beyond at least my way of thinking about things and sort of opened up this thing, this whole process of being a little bit more personal.  I mean, and powerful in a way that I had not understood before.

STEVEN TUECKE:  Some people love that notion and other people, it really scares them.  So, the primary use that we've been using for delegation is not so much for one user to give another user the capability to act on his behalf, but rather, for a user to delegate to processes or agents or something else there, services to act on that user's behalf, to do something.  But you're right, that is a way you can go.

JOHN VOLLBRECHT:  Do you have people using that way?

STEVEN TUECKE:  Today, actually, no.  We really have not had that happen much, as far as I know.

JOHN VOLLBRECHT:  Do you want people to use it that way?

STEVEN TUECKE:  One of the things we are doing is, Dell adding delegations tracing capabilities into the delegation process, so an end party cannot only see that it belongs to this identity but can see where it hoped through.  There's a variety of reasons you might want that.  From audit to control, disallow certain sites that you know have been compromised, but one could imagine using that same facility, to disallow the user delegation and only allow your service.

NEW SPEAKER:  Catch them after they do it.

STEVEN TUECKE:  Right.

CEES DE LAAT:  I would like to cut off the discussion, but if you have a very brief question --

NEW SPEAKER:  I just want to know how you go about aggregating certain authorizations?  Do you have to keep them all separate or put them into, like, an aggregated certificates?  Or how do you go about that?

STEVEN TUECKE:  The open piece in this whole thing in this point is the policy language, in practice, what we expect will happen, a simple version is that one of these capabilities essentially contains a list of access control rights that this thing can be used for, so you can do aggregation capability.  You can imagine much broader aggregation capabilities where you talk about classes of services and things but that's part of the research that we'll solve over the next ten years as this stuff gets used widely.

NEW SPEAKER:  Okay.  Thanks.

CEES DE LAAT:  So while Bob is coming up, it was again, also, John was discussing about security issues, but that's already been covered, so, we had an extra ten minutes, which are gone already.

So, is anybody not sign the blue sheet which are pink?  Okay.

BOB MORGAN:  Okay.  My name is Bob Morgan I'm with the University of Washington and I'm also here today wearing my Internet two hat.  And so I'm going to actually talk about two different things, really, one is project that we're doing within Internet two, to support inter domain access to web resources.  And a different one, that's, that I'm also involved in and do think is related to the first one, is some work, standardization work, different standardization, to standardize that, the protocols and operations in that same kind of space.

So, let me start by just saying a little bit about this middle ware initiative, that's part of Internet two.  You folks may have heard of Internet two as a network, which does exist, in a sublime level, between some hundred class universities in the United States.  There are a number of applications that are trying to take advantage of that.  And research going on and sort of network and a couple other issues of QoS and other stuff.  At some point, it was observed that you know, you have to actually, in order to do interesting applications especially when you have, you need bandwidth, that are attractive to all those people out there who want to run the nano service index, it's attractive to have security infrastructure in this stuff, and that connecting security infrastructure is, between campuses, even doing a reasonable security, in campus is not easy.

There are lots of ways to do it and lots of sites that have done good things and many other sites that have done nothing at all.  Even among the hundred 79 universities, and they're connected together and it has been tried in various ways over the years, and now we have additional motivation to try to do it again.  Because it never worked well before.

So a group of sort of campus level architects was organized a year or two ago and has been working on a variety of things, to deal with those problems, and some of this work, as I mentioned is joined with Ed due cause, which a larger consortium of U.S.  Universities.

So, some of these things, we've been doing best practices, around security infrastructure.  And, we had some use of that in universities, that wanted to actually learn from those of us who claim to be experts.

We have a project that recently, you might know, of a standards and recommendations for a web scheme for a, IRA, and some of the data, from which, would support some of these other projects then.

A project to do L directory integration that is looking at both sort of technical issues and how you index it and hope it can, shortly, to get into some other issues of how you do reasonable searches on a directory.  It's just too big.  And a couple hundred in institutions and has a couple million entries.

And some of that, is, you know, work, has gone on in some other venues already.

I guess, well, there's also some P K I work that's going on, trying to run some standards around P K I, and contributed in our way to the federal P K I, the federal bridge effort and media space.  And there certainly is active discussion now about, of a higher P K I am application.

So, the project that I will say a little bit more about is Shibboleth.  And that is about inter in institution web authentication as it says.  And I think I don't need to really reiterate why inter in institution Al is interesting and important.  And, probably Done have to motivate why a web is important either.  But the observation, maybe just to say something about all this work, that the people involved are not, for the most part, from the academic side, they're more the operational side.  So we're trying to use the infra structures that we have already built on our campuses to do interesting things in the inter campus space.  So, if, you know, this is among the kinds of communities that we want to support, are the researchers on campus, who are taking part in the structure, for example, so we're having ongoing conversations with those folks about how folks want to get this, that are involved in a, in one of these communities and could actually use some inter campus infrastructure if it's there.

So, it's very much trying to work in reality of what's happening today and adding incrementally to it.  So the observation is that most places already have some kind of web authentication system on campus and want to support the usual sorts of am cases, so let's try and leverage that.

There is a lot of different places where this would be attractive, already if we have it.  The library, content provider sort of space.  This is usually on my IP address controls, these days, which so, so that's one of our main target am cases.

There are other sorts of projects in Europe and elsewhere.  That have similar qualities in terms of organizing you know, large scale national infrastructure.

The Oasis work that I'll be talking about is similar, has a similar technological base, so let's us know that we're not totally crazy trying to build this thing.  And lastly, one of the motivations again, is to use what people already have in campus.  One way to solve global security problems is to start with a, with a P K I that, you know, lets you get, be able to go across certificate easily.  And one this is to, one approach, to solve the problems, we're trying to provide capabilities for that and we'll make inter domain security attractive, without saying, first deploy client certificates to your hundred thousand users on campus.  This is not opposed to the goals of P K I, certainly, it will be P K I used to make this thing happen.  But we're not counting on all clients having certificates any time soon.

So, as I said, the main thing is relying on local site authentication, again, this shouldn't be any news to this group.  This is the user domain, which is supplying authentication information to a target domain.  Using standard browsers.

You know, as soon as you try look closely at authentication, you realize that authorization of course, is the point.  And, you know, in practice, authorization varies greatly by application.  Thank you.

And, it rainings from someone sophisticated to the broad base of really primitive access controls.  So, we're trying, just, again, to motivate people using better kinds of authorization that can deal with the, you know, fetching attributes from other places.  Actually, base authentication and authorization, essentially, but also supporting the traditional kind of stuff that people do with ACK A C Ls.  So there are three sort of users, like the course and large site license kind of thing, like Steve was talking about.  Which is very typical in the content provider space.  So we're trying to support all of those with a common system.

Let's see.  I think I won't go into detail on these things.  I will say that, privacy is one of our key items, in fact, you know, a little too key of a an item to some of the people involved.  We're trying to not to to make this into a privacy research group.  But any time you're talking about interior domain stuff, the privacy issues that tend to get ignored in the local situation cannot be ignored, you know, in the idea of automatically sending identity and a bunch attributes about yourself, on a remote site, just because you happen to go there, is traditionally unaccept able.  Where lots of content providers would love to cell computer science key clicks to researchers and that kind of thing.  We are still constrained by federal privacy laws about student information.

Let's see.  I think I talked about some of this stuff already.  The assumption is there will be lots of targets and lots of users coming from wherever you should be able to use your user site authentication service even though you're, you know, you're located somewhere else.

The attribute authority concept is certainly key, I think these days.  So, we're very much wanting to supply attributes, so they can use them to make authorization decisions and hopefully, some of our interesting applications should do that.  Attribute authority, it can implement privacy policies, so we have some ideas about how privacy policies will happen.  The W P three work is interesting and we're hoping to show more about that as we go along.

So, it's happening.  I will proceed, directly to the Oasis security services work.  Of as I mentioned, it started up around this time, and is a different category of activity, and the standard effort in, might happen in IETF but didn't.  The participants are members who have access management products, there's a bunch of them out there.  Those products all bump into each other in the marketplace, and customers that asked, you know, why can't I, if I log in on my integrity server, why can't I access a resource that's protected by the agent?  And when, all these things are very much alike, if you squint, and yet, they're all proprietary, so you can't do that.  So we're trying to make them actually inter operate.  So this is very similar to the sorts of information from our previous project.

The assumption is that this will be X M L based, and as I said, it's a connection between existing security services, and as opposed to in vents new security services, it remains to be seen how little we're able to get away with.

The single sign on scenario is interesting.  Some other ones are random, whatever that means, of connections, sending off purchase orders that get interpreted by non turbo sites, after going through various translating and all sorts of other stuff.

There were some incidents of sort of pre standard specification from a couple of vendors, there's a URL.  For information on the committee.

The structure of this classification is not unlike the sorts of structures that are talked about in the AAA architecture work, and in fact, we have been trying to explicitly rely on some of that work.

The expectation will be that there are several different kinds of assertions which at least in concept are X M L signed blobs, insert indication of application, and assertions about attributes that are associated with security principles.  Assertions about authorization decisions, when a proxy decision point is asked for, to make a policy decision.  And then it returns an authorization decision.  I guess one interesting question for this group is, you know, is there a difference that makes a difference between what people mean by policy and the context of policy decision point.  And what people mean by authorization in terms of authorization server or authorization decision.  So this is a philosophical point is which there is still some dispute.

The question of session management is an interesting one, as yet unresolved, to some kind of session management, how much different targets, and so, protocols, to get this stuff on the list, we'll refer to this picture briefly, which is our current sort of picture model.  With these various authorities that I mentioned before, emitting these various assertions, as the draft picture.

So again, you should be familiar.  I observe that there are -- this is Oasis?  This is a drawing that has been produced by somebody in the Oasis work and it's sort of our current draft on the table for what it is we think we're standardizing and the names of these items.  That's right.

And so, this material, the, let me just say that the Oasis group is a a membership thing, you have to become a member in order to participate, and there are some onus to do that.  But all the work is available, the document repository is available, and mailing lists are available.  Folks you can start from that URL, start from Oasis dash open, dot org and find all this stuff.

So I think I'm about out of time.  So any questions?  Thank you.

CEES DE LAAT:  It seems that we are switching technology.

HENK JONKERS:  I don't have a title page.  What we're trying to do is to come up with a few examples of a particular inter domain name, AAA scenarios, the starting point is more or less accounting and billing but it doesn't mean that I won't pay any attention to the other two As, of course, there is also ought then and authorization that plays an important role.  But accounting is the main purpose.  And we'll show how these examples use authentication and authorization.

I'll start with some very high level pictures.  I tried to assume you'll be more specific, but to just give some impression of the playing field, types of things we can think of.  I'll start with these.  First, in the top left could have corner, it's, well, I think the most complex example you can think of.  Started with service provider and user.  I distinguish two types of relationships, the service delivery, from a provider to user and in the opposite direction a money flow to from the user to the service provider.

Okay.  From this very simple example, you could make a, well, some extension to include more service providers, to out source some of the service provisioning to a second back up service, and then a second delivery from a back up provider.  And the money flows back in this case.  The bottom one is a re iteration of this, and bypass the main service provider, and there's a service delivery from the provider to the user.  But the money flow still goes through a, the front end provider.  So that's two versions of out sourcing of service provisions.  So that's more or less a symmetric case, that's a measure provider and a back up provider.  And you can also consider a more symmetric case, two service providers each with their own user base, both servers use the same users.  And they, but these providers make use of each other's services.

One example, well, maybe you back up service provider, if one is not available, the other could take over.  It's also possible to have some kind of specialization.  One is specialized in one type of service and the other one provides a different type of service, and then they just use each other's services to offer a wider range of services.  So there's basically two directions, back up service provisions and there could be money flowing in two directions.  As always, money from the users to one of the service providers.  So that's already some kind of example of a relationship between these two service providers.

They're at the same level.  They're not really one to the other one.  Of course one can be extended to include more than two service providers.  You get a type of what you keel appear network.

( What you call a peer network. )
         That's not the best to use, because peer does have some connotation of no settlement and so there's no payment.  But here we specifically do include a possible payment to a settle for a differences in service use between the providers.

And then logical next step, where the numbers provides growth, add some type of Eintermediary or service broker to negotiate a broker between the service providers.  And then in the case of money flow, this one is also, maybe to do some kind of clear on the payments, to just reduce just the number of payments needed between these parties.

So, I will try to do is, to pick two typical examples from these classes, by this area, so the client server situation.  And one of them more appealing relationship between service providers, and see what the effect of it is on the AAA scenario.

So the main idea really is to use it as a type of validation and maybe an illustration of several of the issues which are discussed in the open drafts, that being a present err, being produced and research group.

I'll show bit more detail of the client server situation, and another one, an example of peer, which we are taken over now, grid computing, related to what's been presented earlier today, which might be interesting example to just look into some of these items.

So, I think, you know, for the client server setting, similar to the previous one, but important the specific example.  This has been experimented, some demonstrator application which has been implemented in our institute, a bit of a simplified version of this.  It's a streaming video demonstrator, and in which, well, most abstract version, is just a video provider and a user.  But part of this services is out sourced to a second party, which is called the deployment provider.  D P in the picture.  The main provider is a video portal, which is the first point of contact for end users.  And the deployment provider takes care of the streaming and storage of different videos.  The deployment providers offers some services to VP P and user.  But some part of it goes on to the deployment provider.

Another interesting aspect to this is someplace we also decided to out source the accounting and charging and billing.  So there's separate A CCP, which offers services to all of the other parties involved, which is accounting for usage, charging it for it and presenting a bill to the end user.  And some fee goes from the video provider to the A CB P provider.

Now we finally get to some picture, which is more similar to the other ones in this working group.

Here we have the same pattern as the previous picture.  The portal provider, which basically, offers the main service, the portal service to the end user and also takes care of some type of metering, to allow for accounting and charging for usage.

The same is the case for the portal provider, some text is missing.

The streaming service, it takes care of metering of any actual video usage.

And then, the accounting charging and bill provider.  Each of these are located in separate domains, have their own AAA server, communicate with the AAA server through the application specific module.  And the user interacts with all knees all these parties.

And the A S P provider takes care of several things.  We should not in this case be confused with the event log which I think I showed in the AAA server.  This is logging of accounting eees so it's accounting that takes place.  Charging and billing block.  And there may be a separate paper if we decide to pay through a separate file err.  So it doesn't need AAA functionality.  It directly interacts with the end user and with the billing part of the accounting charge being provided.

Okay.  Again, in this picture, we could work out some of the scenarios of AAA using this.  By drawing some types of regressed response to regress.  First, use can make two types of regress.  The first one is basically just a log in to the portal server, which a forwards authentication authorization.  This one only communicates with if portal service AAA server.  If it's appropriate request, and then use, click on video links, which results in a redirect through the deployment service.  The streaming service checks the request, and the policy would have some kind of a reference to AAA server of the portal service, which takes care of the authentication authorization of the user.  So it's forward of service request.

If this one is granted, the admission to its video, at the same time, you have a request for the deployment service.  Because you must meter the usage of the video.

And at the same time, also an accounting request is sent to the A C P provider, to start accounting for this service.  And then at the end to meter records are sent from both the streaming server and the portal server to the accounting charge able server which accounts for service and charge and bill.

So, if you look at session I D in this case, there are two types of sessions.  The main session is just a portal service session, although again, log in and log out, and that's the start and end of the session.  At the lower level, of view and video and accounting and metering for this.

As I said, there's a second example about -- I won't go into this because of time, but it's described in the document.

CEES DE LAAT:  Are there any questions?

HENK JONKERS:  No questions, everybody understood everything, every agrees, it was all clear.  I would also like to discuss, maybe tonight, to see what other people think about this, how this could be linked to other groups.

CEES DE LAAT:  Okay.  So the last topic on, again, on the agenda, is closing remarks by John.  And I have already received while I'm sitting here from at least two precentors, slides, so thanks.  But I want slides from the others.

JOHN VOLLBRECHT:  So, just in closing, first, a couple of things, one is, I'd like to encourage people to come to our session tonight, which is, where is it again?

CEES DE LAAT:  8 o'clock in Rochester room, which is on this floor, on the opposite, in the corner.

JOHN VOLLBRECHT:  So in the Rochester room at 8 o'clock.  And to do some informal talking, a couple of things I'd like to talk about, from me personally, is session management, and I'd like to talk with anybody from other working groups or other projects that are implementing things like that, that we might be able to provide a place for talking about common problems, and may becoming up with some architectures or some descriptions of how, you know, the approaches that different people are taking, to map some kind of architecture.

My view is that that's one of the things that this group could provide, is a service to the community, is just a focus for some of that kind of discussion.  And I guess I want to thank everybody for being here.  And we will have a re chartering discussions tonight, and on the list, so, I guess that's it.  Thank you, everybody.

CEES DE LAAT:  That's it, thanks.

(END OF SESSION.)