From owner-aaa-wg@merit.edu Mon Mar 1 13:11:27 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA28072 for ; Mon, 1 Mar 1999 13:11:27 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id NAA15254 for aaa-wg-outgoing; Mon, 1 Mar 1999 13:09:02 -0500 (EST) X-Authentication-Warning: merit.edu: majordom set sender to owner-aaa-bof@merit.edu using -f Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA15248 for ; Mon, 1 Mar 1999 13:08:57 -0500 (EST) Received: from zrchb213.us.nortel.com (actually 47.100.128.42) by smtprich.nortel.com; Mon, 1 Mar 1999 12:08:27 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2232.9) id ; Mon, 1 Mar 1999 12:08:25 -0600 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5026F50FD@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Pat.Calhoun'" , aaa-wg Subject: RE: AAA Requirements Draft Date: Mon, 1 Mar 1999 12:08:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk A few comments on the requirements suggested in this draft: > From the description and example above, we can identify several > requirements. > > - The local attendants and the local authority have to share > security relationships >From a deployment perspective the local attendant and the local authority may be part of a private network if they are in the same location or maybe a VPN. The need for having a security association between the local attendant (A) and the local authority (AAAL) is debatable. If the local authority is outside the domain of the attendant then I agree that you would require a security association. > - The attendant equipment should be as inexpensive as possible, > since it will be replicated as many times as possible to handle > as many customers as possible. Why is this a AAA requirement? Maybe you can clarify here. > - Capabilities adjustment. Each manufacturer's equipment has > different capabilities. Thus, the AAAL may have to modify the > authorization information from the AAAH. Is the protocol between the manufacturers equipment and the AAAL a part of this WGs requirement consideration? If the protocol between the manufacturers equipment and the AAAL is vendor specific then the modification of the authorization request to suit the equipment should be a part of the protocol between the equipment and AAAL. > - End to End security. The Local Domain and Home Domain must be > able to verify signatures within the message, even though the > message is passed through an intermediate authority server. This > is necessary because the following attacks were identified when > this operation is done using the RADIUS protocol (see [1] for > more information on the individual attacks): > + Message editing > + Attribute editing > + Theft of passwords > + Theft and modification of accounting data > + Replay attacks > + Connection hijacking > + Fraudulent accounting Since the foreign domain shares a security association with the broker (AAAB) and the home domain shares a security association with the broker, the messages traversing from the foreign domain to the home domain via a broker would be secure. The only possible weak link here is the broker himself. Hence why do you see the need for local and home domains to verify signatures within the message. -Basavaraj Patil From owner-aaa-wg@merit.edu Mon Mar 1 13:33:43 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA28311 for ; Mon, 1 Mar 1999 13:33:43 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA15800 for aaa-wg-outgoing; Mon, 1 Mar 1999 13:33:26 -0500 (EST) X-Authentication-Warning: merit.edu: majordom set sender to owner-aaa-bof@merit.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA15792 for ; Mon, 1 Mar 1999 13:33:20 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA17035; Mon, 1 Mar 1999 10:32:46 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.123.47]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id KAA15414; Mon, 1 Mar 1999 10:32:43 -0800 (PST) Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07800; Mon, 1 Mar 1999 10:32:42 -0800 Date: Mon, 1 Mar 1999 10:32:49 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: AAA Requirements Draft To: Basavaraj Patil Cc: "'Pat.Calhoun'" , aaa-wg In-Reply-To: "Your message with ID" <31B1EFDD2CD3D11187710000F805A8D5026F50FD@crchy270.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > A few comments on the requirements suggested in this draft: > > > From the description and example above, we can identify several > > requirements. > > > > - The local attendants and the local authority have to share > > security relationships > > From a deployment perspective the local attendant and the local > authority may be part of a private network if they are in the same > location or maybe a VPN. The need for having a security association > between the local attendant (A) and the local authority (AAAL) is > debatable. If the local authority is outside the domain of the > attendant then I agree that you would require a security > association. Well, the RADIUS protocol *requires* a shared secret between the A and the AAAL because it is too easy to create denial of service attacks. I think that if we are to create a new protocol, we should certainly assume that it would be just as secure. The security between both nodes can be one of the following: - None, assumes IPSec underneath - Shared Secret, at the application layer, similar to RADIUS - PKI, at the application layer, mostly used for brokering > > > - The attendant equipment should be as inexpensive as possible, > > since it will be replicated as many times as possible to handle > > as many customers as possible. > > Why is this a AAA requirement? Maybe you can clarify here. The point here is that a standards based, and easy to implement protocol will ensure that it is relatively inexpesive to produce. This is certainly not the case with protocols such as SS7 or even HLR and VLRs... > > > - Capabilities adjustment. Each manufacturer's equipment has > > different capabilities. Thus, the AAAL may have to modify the > > authorization information from the AAAH. > > Is the protocol between the manufacturers equipment and the AAAL a > part of this WGs requirement consideration? If the protocol between > the manufacturers equipment and the AAAL is vendor specific then the > modification of the authorization request to suit the equipment should > be a part of the protocol between the equipment and AAAL. The protocol between the Attendant and the AAAL AND the protocol between the AAAs is what we should be trying to standardize here. > > > - End to End security. The Local Domain and Home Domain must be > > able to verify signatures within the message, even though the > > message is passed through an intermediate authority server. This > > is necessary because the following attacks were identified when > > this operation is done using the RADIUS protocol (see [1] for > > more information on the individual attacks): > > + Message editing > > + Attribute editing > > + Theft of passwords > > + Theft and modification of accounting data > > + Replay attacks > > + Connection hijacking > > + Fraudulent accounting > > Since the foreign domain shares a security association with the broker > (AAAB) and the home domain shares a security association with the > broker, the messages traversing from the foreign domain to the home > domain via a broker would be secure. The only possible weak link here > is the broker himself. Hence why do you see the need for local > and home domains to verify signatures within the message. Please read the various ROAMOPS documents which clearly describe the known attacks (even inadvertenly) by brokers. We should try to solve the problems which ROAMOPS considers a requirement for brokers. PatC > > -Basavaraj Patil > > From owner-aaa-bof@merit.edu Wed Mar 3 12:33:37 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA00939 for ; Wed, 3 Mar 1999 12:33:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26D5A4441F; Wed, 3 Mar 1999 12:33:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CFA54442F; Wed, 3 Mar 1999 12:33:29 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 07E0E4441F for ; Wed, 3 Mar 1999 12:33:27 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA01362 for ; Wed, 3 Mar 1999 12:33:26 -0500 (EST) Received: from murray (murray.lcp.livingston.com [158.222.8.15]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id JAA05805 for ; Wed, 3 Mar 1999 09:33:16 -0800 (PST) Message-Id: <3.0.6.32.19990303093132.0098ac80@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 03 Mar 1999 09:31:32 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Schedule of AAA sessions at the IETF meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk There will be two AAA WG sessions at the upcoming IETF meeting: Tuesday, Mar 16, 1300-1515 (break in the middle) Wednesday, Mar 17, 1530-1730 I am working on a formal agenda and will post that shortly. The purpose behind having two sessions is to establish work items and the basic makeup of the groups to perform those work items so that we can get something done between the sessions. The groups will then present their assumptions and "plan of attack" during the session on the second day. We need groups to work on authentication, authorization, and accounting separately. We also need groups to divine the requirments of the various candidate applications/services needing AAA services (find out what our "customers" need). The goal is to identify the common areas and unique needs of these candidate services. From this work I hope we will be able to discern the patterns of commonality so we can come up with a structure that is both relatively simple and encompassing. I believe that we need approximately 3-5 people to form each of the groups for A/A/A. We need 1-3 people for each of the application/service area groups. If you want to work in one of these groups you MUST be prepared to put in the necessary time both at the IETF meeting and outside the meeting. We will create separate mailing lists for group discussion and will will hold teleconferences between IETF meetings in order to get things accomplished as quickly as possible. Paul Krumveide and/or I will participate in all of the groups in order try to provide continuity and facilitate the flow of information between groups. Our schedule is aggressive. It is going to take a fair bit of work. If you volunteer, please be prepared to go the distance. If, after all of this, you still want to participate in a group, please let Paul and me know so we can match people up. Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- From owner-aaa-bof@merit.edu Wed Mar 3 13:21:27 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA01388 for ; Wed, 3 Mar 1999 13:21:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 068554447B; Wed, 3 Mar 1999 13:21:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DFEC14447A; Wed, 3 Mar 1999 13:21:16 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id BF1A344478 for ; Wed, 3 Mar 1999 13:21:15 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with SMTP id NAA02247 for ; Wed, 3 Mar 1999 13:21:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA26490; Wed, 3 Mar 1999 10:19:42 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.101.47]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id KAA18126; Wed, 3 Mar 1999 10:19:39 -0800 (PST) Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11482; Wed, 3 Mar 1999 10:19:37 -0800 Date: Wed, 3 Mar 1999 10:19:44 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Schedule of AAA sessions at the IETF meeting To: Brian Lloyd , paul@mci.com Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3.0.6.32.19990303093132.0098ac80@158.222.8.12> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I am willing to volunteer. I would be very interested in working on the Authentication and Accounting piece. I would love to also work on the Authorization part, but if travel is required, I will need to ensure that I am home some of the time :) PatC From owner-aaa-bof@merit.edu Wed Mar 3 13:27:42 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA01440 for ; Wed, 3 Mar 1999 13:27:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 088A244477; Wed, 3 Mar 1999 13:27:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E599244478; Wed, 3 Mar 1999 13:27:36 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 00C9244477 for ; Wed, 3 Mar 1999 13:27:33 -0500 (EST) Received: from smtpgw02.wanmail.net ([149.174.10.62]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA02388 for ; Wed, 3 Mar 1999 13:27:33 -0500 (EST) Received: from wcomexch1.wcom.net (wcomexch1.wcom.net [209.154.236.12]) by smtpgw02.wanmail.net (8.9.1/8.9.1) with ESMTP id NAA03195 for ; Wed, 3 Mar 1999 13:26:20 -0500 (EST) Received: by wcomexch1.wcom.net with Internet Mail Service (5.5.2232.9) id ; Wed, 3 Mar 1999 13:28:32 -0500 Message-ID: <9A74C89D6696D2118E500008C7BA7C5601A81AA5@wcomexch1.wcom.net> From: "Petke, Rich" To: "'aaa-wg@merit.edu'" Subject: Willing to work on teams Date: Wed, 3 Mar 1999 13:28:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian - I'm willing to work on one of the groups. See you in Minn. Rich Petke (rpetke@wcom.net) Product Development MCI WorldCom Advanced Networks (www.wcom.net) 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 Voice: +1-614-723-4157 FAX: +1-614-723-8407 From owner-aaa-bof@merit.edu Mon Mar 8 15:24:22 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA16364 for ; Mon, 8 Mar 1999 15:24:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 254534441D; Mon, 8 Mar 1999 15:24:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0974144421; Mon, 8 Mar 1999 15:24:15 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 108384441D for ; Mon, 8 Mar 1999 15:24:14 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA10857 for ; Mon, 8 Mar 1999 15:24:13 -0500 (EST) Received: from murray (murray.lcp.livingston.com [158.222.8.15]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id MAA07418 for ; Mon, 8 Mar 1999 12:23:58 -0800 (PST) Message-Id: <3.0.6.32.19990308122200.00965ca0@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 08 Mar 1999 12:22:00 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Agenda for upcoming IETF meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk (Please suggest agenda changes to Paul (paul@mci.net) and me if you feel they are critical. Our intention is not to make the agenda so rigid that there is no lattitude for on-the-fly changes so, please, only recommend changes if you think what we have below is missing something really critical. I will be sending the agenda off to the Powers That Be on Wednesday.) Tuesday, Mar 16, 1300 I. Welcome and Warm Fuzzies Agenda bashing II. Discussion of application/service areas requiring AAA services, e.g. remote access, bandwidth broker, etc. Conscription of "volunteers" to work on application/service area requirements and their associated documents. III. Discussion of authentication, authorization, and accouting as separate entities. Conscription of "volunteers" to work on the authentication, authorization, and accounting group documents. Tuesday and Wednesday (between sessions) Various groups go off and work on the direction for their respective work so they can report back at the Wednesday session. Paul Krumveide and Brian Lloyd will make an effort to sit in on the interim discussions either collectively or individually. Wednesday, Mar 17, 1500 I. More Welcome and Warm Fuzzies More Agenda bashing (Remember: no plan of battle ever survives contact with the enemy.) II. Quick and dirty presentations from the applications/services groups. III. Quick and dirty presentations from the A/A/A groups. IV. General discussion (We require that all arms be checked at the door.) V. Plan for interim meetings and teleconferences. Set the schedule (loose) for the various intermediate deliverables. Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax O- From owner-aaa-bof@merit.edu Wed Mar 10 18:01:21 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA13229 for ; Wed, 10 Mar 1999 18:01:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B64D4440B; Wed, 10 Mar 1999 18:01:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 43CCB44415; Wed, 10 Mar 1999 18:01:14 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 1DBF64440B for ; Wed, 10 Mar 1999 18:01:13 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA28998 for ; Wed, 10 Mar 1999 18:01:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22960 for ; Wed, 10 Mar 1999 15:01:11 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.101.47]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id PAA29126 for ; Wed, 10 Mar 1999 15:01:05 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28305; Wed, 10 Mar 1999 15:01:01 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903102301.PAA28305@hsmpka.eng.sun.com> Date: Wed, 10 Mar 1999 15:03:24 -0800 To: Reply-To: Subject: Accounting Requirements.... X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk As most of you know, Accounting consists of multiple message, which I will enumerate: - Accounting Start: An indication that a session has just been established. This message includes information about the session. - Interim Msg: This message can be sent by the system that sent the Accounting Start message, and includes an update on the session. This message includes statistics that can be used for.... network capacity :) - Accounting Stop: This message indicates the end of a session and includes the final statistics. In the RADIUS world, the Interim and Stop messages include cumulative statistics. I have found that there are many services/customers that really want their accounting packets to include cumulative info. However, I have meet some other folks that need their packets to NOT be cumulative and this is necessary due to the fact that they are migrating from existing systems that operate in such a fashion. Therefore, when the accounting session is established, we should allow for either type of accounting information. I would propose that this be sent back in the Accounting Start confirmation message, since the end customer should be the one that determines how they want their accounting data to be fed to them. This, of course, raises an important issue: - In a roaming scenario, where there are multiple accounting server hops, each node in the tree may require a different method. That said, we may want to re-consider the negotiable aspect of this proposal, and require that each service determine their accounting method. PatC From owner-aaa-bof@merit.edu Wed Mar 10 19:41:52 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA14084 for ; Wed, 10 Mar 1999 19:41:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 300AC4441F; Wed, 10 Mar 1999 19:41:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 13F1844415; Wed, 10 Mar 1999 19:41:45 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id E371644415 for ; Wed, 10 Mar 1999 19:41:43 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.9.1a/8.9.1) with ESMTP id TAA00425 for ; Wed, 10 Mar 1999 19:41:42 -0500 (EST) Received: from murray (murray.lcp.livingston.com [158.222.8.15]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id QAA24190 for ; Wed, 10 Mar 1999 16:41:40 -0800 (PST) Message-Id: <3.0.6.32.19990310163934.009b59e0@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 10 Mar 1999 16:39:34 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Re: Accounting Requirements.... In-Reply-To: <199903102301.PAA28305@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 03:03 PM 3/10/99 -0800, Pat.Calhoun@Eng.Sun.COM wrote: > >As most of you know, Accounting consists of multiple message, which I will >enumerate: > - Accounting Start: An indication that a session has just been > established. This message includes information about the session. Not necessarily. Not every application needs this information. > - Interim Msg: This message can be sent by the system that sent the > Accounting Start message, and includes an update on the session. > This message includes statistics that can be used for.... > network capacity :) Again, not necessarily. > - Accounting Stop: This message indicates the end of a session > and includes the final statistics. This seems to be more universal. I am seeing a pretty strong remote access bias here. >In the RADIUS world, the Interim and Stop messages include cumulative >statistics. I have found that there are many services/customers that really >want their accounting packets to include cumulative info. However, I have meet >some other folks that need their packets to NOT be cumulative and this is >necessary due to the fact that they are migrating from existing systems that >operate in such a fashion. This is a nit. If you have cumulative info you can derive intermediate info and vice-versa. We have to be careful not to get lost in the details here yet. It is probably OK to tell people, "well you will have to derive the exact data you need from the accounting stream and here is how you do it." >Therefore, when the accounting session is established, we should allow for >either type of accounting information. I would propose that this be sent >back in the Accounting Start confirmation message, since the end customer >should be the one that determines how they want their accounting data to >be fed to them. This, of course, raises an important issue: > > - In a roaming scenario, where there are multiple accounting server > hops, each node in the tree may require a different method. That > said, we may want to re-consider the negotiable aspect of this > proposal, and require that each service determine their accounting > method. Which means it is all up for grabs. Gotcha. :^) This is interesting but I caution you to try to think more globally insofar as the various applications are concerned. What do bandwidth broker services require? Are they the same as for remote access services? Are the sessions sufficiently similar to warrent the same types of accounting primitives? I don't want to assume anything just yet. Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax O- From owner-aaa-bof@merit.edu Thu Mar 11 06:04:41 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id GAA18790 for ; Thu, 11 Mar 1999 06:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 235B944406; Thu, 11 Mar 1999 06:04:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 084B24440B; Thu, 11 Mar 1999 06:04:35 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id E759544406 for ; Thu, 11 Mar 1999 06:04:29 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by merit.edu (8.9.1a/8.9.1) with ESMTP id GAA06250 for ; Thu, 11 Mar 1999 06:04:28 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA286000; Thu, 11 Mar 1999 11:03:55 GMT Received: from hursley.ibm.com (9-20-29-173.dhcp.hursley.ibm.com [9.20.29.173]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA16254; Thu, 11 Mar 1999 11:03:55 GMT Message-ID: <36E7A2E8.550C3131@hursley.ibm.com> Date: Thu, 11 Mar 1999 11:03:04 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Pat.Calhoun@Eng.Sun.COM Cc: aaa-wg@merit.edu Subject: Re: Accounting Requirements.... References: <199903102301.PAA28305@hsmpka.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I don't understand how this model gives transactional security, which I would have thought was essential for accounting. "Messages" aren't enough to provide transactional properties. Onec the mechanism is fully transactional, it really doesn't matter whether you do cumulative data or not. Brian Patrice Calhoun wrote: > > As most of you know, Accounting consists of multiple message, which I will > enumerate: > - Accounting Start: An indication that a session has just been > established. This message includes information about the session. > - Interim Msg: This message can be sent by the system that sent the > Accounting Start message, and includes an update on the session. > This message includes statistics that can be used for.... > network capacity :) > - Accounting Stop: This message indicates the end of a session > and includes the final statistics. > > In the RADIUS world, the Interim and Stop messages include cumulative > statistics. I have found that there are many services/customers that really > want their accounting packets to include cumulative info. However, I have meet > some other folks that need their packets to NOT be cumulative and this is > necessary due to the fact that they are migrating from existing systems that > operate in such a fashion. > > Therefore, when the accounting session is established, we should allow for > either type of accounting information. I would propose that this be sent > back in the Accounting Start confirmation message, since the end customer > should be the one that determines how they want their accounting data to > be fed to them. This, of course, raises an important issue: > > - In a roaming scenario, where there are multiple accounting server > hops, each node in the tree may require a different method. That > said, we may want to re-consider the negotiable aspect of this > proposal, and require that each service determine their accounting > method. > > PatC From owner-aaa-bof@merit.edu Thu Mar 11 09:05:44 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA20095 for ; Thu, 11 Mar 1999 09:05:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FF7244410; Thu, 11 Mar 1999 09:05:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DE8FF44415; Thu, 11 Mar 1999 09:05:36 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id D56A444410 for ; Thu, 11 Mar 1999 09:05:35 -0500 (EST) Received: from gw3.sprintspectrum.com (gw3.sprintspectrum.com [207.40.70.36]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA08172 for ; Thu, 11 Mar 1999 09:05:35 -0500 (EST) Received: by gw3.sprintspectrum.com; id IAA23297; Thu, 11 Mar 1999 08:04:58 -0600 (CST) Received: from uskmessoa001.sprintspectrum.com(208.10.75.11) by gw3.sprintspectrum.com via smap (V2.0) id xma023211; Thu, 11 Mar 99 08:04:47 -0600 Received: by uskmessoa001.sprintspectrum.com with Internet Mail Service (5.5.2448.0) id ; Thu, 11 Mar 1999 08:04:47 -0600 Message-ID: <5911B2BA1A6DD21198D60060975DA4A4AD3807@uskmessoa028.sprintspectrum.com> From: "Lipford, Mark" To: aaa-wg@merit.edu, "'Pat.Calhoun@Eng.Sun.COM'" Subject: RE: Accounting Requirements.... Date: Thu, 11 Mar 1999 08:04:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, As a wireless carrier we have been working on the assumption that each interim message would be a picture of what had happened since the last message. The reason a wireless carrier would want this is we may identify "triggers" in the wireless network (such as cell changes, bandwidth changes, locations, etc) that we would want to capture the usage as a "snapshot" and not a cumulative amount since start message. This will cause the AAA to be very hard disk intensive, but most carrier (I'm guessing) would not leave this information on the AAA more then 24 hours since we will have a downstream billing and storage system. Thanks ---------- From: Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM] Sent: Wednesday, March 10, 1999 5:03 PM To: aaa-wg@merit.edu Subject: Accounting Requirements.... As most of you know, Accounting consists of multiple message, which I will enumerate: - Accounting Start: An indication that a session has just been established. This message includes information about the session. - Interim Msg: This message can be sent by the system that sent the Accounting Start message, and includes an update on the session. This message includes statistics that can be used for.... network capacity :) - Accounting Stop: This message indicates the end of a session and includes the final statistics. In the RADIUS world, the Interim and Stop messages include cumulative statistics. I have found that there are many services/customers that really want their accounting packets to include cumulative info. However, I have meet some other folks that need their packets to NOT be cumulative and this is necessary due to the fact that they are migrating from existing systems that operate in such a fashion. Therefore, when the accounting session is established, we should allow for either type of accounting information. I would propose that this be sent back in the Accounting Start confirmation message, since the end customer should be the one that determines how they want their accounting data to be fed to them. This, of course, raises an important issue: - In a roaming scenario, where there are multiple accounting server hops, each node in the tree may require a different method. That said, we may want to re-consider the negotiable aspect of this proposal, and require that each service determine their accounting method. PatC From owner-aaa-bof@merit.edu Thu Mar 11 10:44:35 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA21240 for ; Thu, 11 Mar 1999 10:44:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id C54C644413; Thu, 11 Mar 1999 10:44:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A603E44415; Thu, 11 Mar 1999 10:44:25 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id A4D3444413 for ; Thu, 11 Mar 1999 10:44:24 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA10093 for ; Thu, 11 Mar 1999 10:44:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18274 for ; Thu, 11 Mar 1999 07:44:22 -0800 (PST) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.124.37]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id HAA22631 for ; Thu, 11 Mar 1999 07:44:15 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07329; Thu, 11 Mar 1999 07:35:12 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903111535.HAA07329@hsmpka.eng.sun.com> Date: Thu, 11 Mar 1999 07:37:29 -0800 To: Reply-To: Subject: Re: Accounting Requirements.... X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk >At 03:03 PM 3/10/99 -0800, Pat.Calhoun@Eng.Sun.COM wrote: >> >>As most of you know, Accounting consists of multiple message, which I will >>enumerate: >> - Accounting Start: An indication that a session has just been >> established. This message includes information about the session. > >Not necessarily. Not every application needs this information. Perhaps, I was describing it as it is today. I believe that many applications do need this (i.e. telephony, wireless access, ppp), but I cannot pretend that I know *everyones* requirements. I believe that is why we are all here, right? > >> - Interim Msg: This message can be sent by the system that sent the >> Accounting Start message, and includes an update on the session. >> This message includes statistics that can be used for.... >> network capacity :) > >Again, not necessarily. See above. > >> - Accounting Stop: This message indicates the end of a session >> and includes the final statistics. > >This seems to be more universal. > >I am seeing a pretty strong remote access bias here. Well, as I stated above, I know the requirements for the services that I am familiar with. Yes there is a bias, because that's what I use AAA for. I believe that getting input from others (which is our goal here), will help us determine the end result. My mail was just a way to get the ball rolling, if you prefer that I wait until I know what everyone wants, we may be here a long, long, long.... long time :) > >>In the RADIUS world, the Interim and Stop messages include cumulative >>statistics. I have found that there are many services/customers that really >>want their accounting packets to include cumulative info. However, I have >meet >>some other folks that need their packets to NOT be cumulative and this is >>necessary due to the fact that they are migrating from existing systems that >>operate in such a fashion. > >This is a nit. If you have cumulative info you can derive intermediate >info and vice-versa. We have to be careful not to get lost in the details >here yet. It is probably OK to tell people, "well you will have to derive >the exact data you need from the accounting stream and here is how you do it." Well, in the RADIUS WG we discussed this one at length for many many many months, and decided that cumulative was necessary (read: rough concensus). In other services that are looking at AAA, they do *not* wish to change their current model (just the protocol). So, somehow we must support both (this was my point, btw). > >>Therefore, when the accounting session is established, we should allow for >>either type of accounting information. I would propose that this be sent >>back in the Accounting Start confirmation message, since the end customer >>should be the one that determines how they want their accounting data to >>be fed to them. This, of course, raises an important issue: >> >> - In a roaming scenario, where there are multiple accounting server >> hops, each node in the tree may require a different method. That >> said, we may want to re-consider the negotiable aspect of this >> proposal, and require that each service determine their accounting >> method. > >Which means it is all up for grabs. Gotcha. :^) > >This is interesting but I caution you to try to think more globally insofar >as the various applications are concerned. What do bandwidth broker >services require? Are they the same as for remote access services? Are >the sessions sufficiently similar to warrent the same types of accounting >primitives? I don't want to assume anything just yet. > Brian, your response really bothers me. These are *my* requirements, not everyone's. I need *my* requirements to be added to the list of accounting requirements, and matched up against other's requirements. Then we will end up with a list of agreed upon requirements. However, one must start somewhere. That said, I do agree with you. PatC From owner-aaa-bof@merit.edu Thu Mar 11 10:56:02 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA21364 for ; Thu, 11 Mar 1999 10:56:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71CD644415; Thu, 11 Mar 1999 10:55:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 590D04441F; Thu, 11 Mar 1999 10:55:55 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 50E0344415 for ; Thu, 11 Mar 1999 10:55:54 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA10315 for ; Thu, 11 Mar 1999 10:55:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21622; Thu, 11 Mar 1999 07:55:44 -0800 (PST) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.55.37]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id HAA13664; Thu, 11 Mar 1999 07:55:42 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10687; Thu, 11 Mar 1999 07:55:04 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903111555.HAA10687@hsmpka.eng.sun.com> Date: Thu, 11 Mar 1999 07:57:50 -0800 To: "Brian E Carpenter" , Cc: Reply-To: Subject: Re: Accounting Requirements.... X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk >I don't understand how this model gives transactional security, >which I would have thought was essential for accounting. >"Messages" aren't enough to provide transactional properties. > >Onec the mechanism is fully transactional, it really doesn't >matter whether you do cumulative data or not. Brian, I was not discussing transactional security here. I was simply stating that the current RADIUS model does not suffice for other services. That's it. The wireless (read cellular) people do *not* want cumulative, while the PPP access people do. There is still lots of work to do in this area, and security is one of them. Although if you want more info on message security, I would point you to: - draft-calhoun-framework-02.txt is the DIAMETER framework document and describes the need for hop-by-hop and end-to-end security, - draft-calhoun-diameter-07.txt, which discusses simple message security, and - draft-calhoun-diameter-proxy-01.txt, which discusses security across brokers and domains. PatC > > Brian > >Patrice Calhoun wrote: >> >> As most of you know, Accounting consists of multiple message, which I will >> enumerate: >> - Accounting Start: An indication that a session has just been >> established. This message includes information about the session. >> - Interim Msg: This message can be sent by the system that sent the >> Accounting Start message, and includes an update on the session. >> This message includes statistics that can be used for.... >> network capacity :) >> - Accounting Stop: This message indicates the end of a session >> and includes the final statistics. >> >> In the RADIUS world, the Interim and Stop messages include cumulative >> statistics. I have found that there are many services/customers that really >> want their accounting packets to include cumulative info. However, I have >meet >> some other folks that need their packets to NOT be cumulative and this is >> necessary due to the fact that they are migrating from existing systems that >> operate in such a fashion. >> >> Therefore, when the accounting session is established, we should allow for >> either type of accounting information. I would propose that this be sent >> back in the Accounting Start confirmation message, since the end customer >> should be the one that determines how they want their accounting data to >> be fed to them. This, of course, raises an important issue: >> >> - In a roaming scenario, where there are multiple accounting server >> hops, each node in the tree may require a different method. That >> said, we may want to re-consider the negotiable aspect of this >> proposal, and require that each service determine their accounting >> method. >> >> PatC From owner-aaa-bof@merit.edu Thu Mar 11 11:03:54 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21450 for ; Thu, 11 Mar 1999 11:03:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9A6D4441F; Thu, 11 Mar 1999 11:03:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D334044425; Thu, 11 Mar 1999 11:03:46 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 99B0A4441F for ; Thu, 11 Mar 1999 11:03:45 -0500 (EST) Received: from smtpgw02.wanmail.net (smtpgw02.wanmail.net [149.174.10.62]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA10518 for ; Thu, 11 Mar 1999 11:03:45 -0500 (EST) Received: from wcomexch1.wcom.net (wcomexch1.wcom.net [209.154.236.12]) by smtpgw02.wanmail.net (8.9.1/8.9.1) with ESMTP id LAA05961 for ; Thu, 11 Mar 1999 11:03:14 -0500 (EST) Received: by wcomexch1.wcom.net with Internet Mail Service (5.5.2232.9) id ; Thu, 11 Mar 1999 11:05:18 -0500 Message-ID: <9A74C89D6696D2118E500008C7BA7C5601A81AE6@wcomexch1.wcom.net> From: "Petke, Rich" To: "'aaa-wg@merit.edu'" Subject: RE: Accounting Requirements Date: Thu, 11 Mar 1999 11:05:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat - Re-reading your original post as the requirements you know of makes sense. When I first read your post I saw it as a proposed implementation of everyone's requirements. IMO, implementations come AFTER requirement discovery. Sometimes it's hard to take our implementor's hats off when discussing requirements but we need to make sure we stay focused on requirements and not let our discussions be PERCEIVED as drifting into implementations. At this point, I feel that any language of an option being specified in an ACK message is out of scope. Rich Petke (rpetke@wcom.net) Product Development (pd.inhouse.wcom.net) MCI WorldCom Advanced Networks (www.wcom.net) 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 Voice: +1-614-723-4157 FAX: +1-614-723-8407 From owner-aaa-bof@merit.edu Thu Mar 11 11:21:22 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21692 for ; Thu, 11 Mar 1999 11:21:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E75444413; Thu, 11 Mar 1999 11:21:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 69AC84441F; Thu, 11 Mar 1999 11:21:15 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 6B6D944413 for ; Thu, 11 Mar 1999 11:21:14 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA10953 for ; Thu, 11 Mar 1999 11:21:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02929; Thu, 11 Mar 1999 08:20:21 -0800 (PST) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.101.37]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id IAB02437; Thu, 11 Mar 1999 08:20:18 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16077; Thu, 11 Mar 1999 08:20:14 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903111620.IAA16077@hsmpka.eng.sun.com> Date: Thu, 11 Mar 1999 08:22:32 -0800 To: "Petke, Rich" , "'aaa-wg@merit.edu'" Reply-To: Subject: RE: Accounting Requirements X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk >Pat - > > Re-reading your original post as the requirements you know of makes >sense. When I first read your post I saw it as a proposed implementation of >everyone's requirements. IMO, implementations come AFTER requirement >discovery. Sometimes it's hard to take our implementor's hats off when >discussing requirements but we need to make sure we stay focused on >requirements and not let our discussions be PERCEIVED as drifting into >implementations. At this point, I feel that any language of an option being >specified in an ACK message is out of scope. Ok, I will try not to mention any virtual message names :) In any case, if the language sounded like a proposed implementation, my appologies. My intent was simply to state my requirements (hence the subject of the thread). PatC From owner-aaa-bof@merit.edu Thu Mar 11 12:03:12 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA22177 for ; Thu, 11 Mar 1999 12:03:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 175854441F; Thu, 11 Mar 1999 12:03:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F403444425; Thu, 11 Mar 1999 12:03:04 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id C91C94441F for ; Thu, 11 Mar 1999 12:03:03 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA11871 for ; Thu, 11 Mar 1999 12:03:01 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA53876; Thu, 11 Mar 1999 17:02:28 GMT Received: from hursley.ibm.com (9-20-29-173.dhcp.hursley.ibm.com [9.20.29.173]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA17408; Thu, 11 Mar 1999 17:02:28 GMT Message-ID: <36E7F6EF.136DCB7F@hursley.ibm.com> Date: Thu, 11 Mar 1999 17:01:35 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Pat.Calhoun@Eng.Sun.COM Cc: aaa-wg@merit.edu Subject: Re: Accounting Requirements.... References: <199903111555.HAA10687@hsmpka.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Perhaps a slight miscommunication there. What I mean is that accounting transactions need the famous ACID properties of any transaction processing application (unless you are happy to lose data). That's Atomicity, Consistency, Isolation, Durability, and the usual solution is 2 phase commit with rollback. So my question is whether that level of protection is needed, or whether we are happy for accounting records to get lost sometimes. Brian Patrice Calhoun wrote: > > >I don't understand how this model gives transactional security, > >which I would have thought was essential for accounting. > >"Messages" aren't enough to provide transactional properties. > > > >Onec the mechanism is fully transactional, it really doesn't > >matter whether you do cumulative data or not. > > Brian, I was not discussing transactional security here. I was simply stating > that the current RADIUS model does not suffice for other services. That's it. > The wireless (read cellular) people do *not* want cumulative, while the PPP > access people do. > > There is still lots of work to do in this area, and security is one of them. > Although if you want more info on message security, I would point you to: > - draft-calhoun-framework-02.txt is the DIAMETER framework document and > describes the need for hop-by-hop and end-to-end security, > - draft-calhoun-diameter-07.txt, which discusses simple message security, and > - draft-calhoun-diameter-proxy-01.txt, which discusses security across brokers > and domains. > > PatC > > > > Brian > > > >Patrice Calhoun wrote: > >> > >> As most of you know, Accounting consists of multiple message, which I will > >> enumerate: > >> - Accounting Start: An indication that a session has just been > >> established. This message includes information about the session. > >> - Interim Msg: This message can be sent by the system that sent the > >> Accounting Start message, and includes an update on the session. > >> This message includes statistics that can be used for.... > >> network capacity :) > >> - Accounting Stop: This message indicates the end of a session > >> and includes the final statistics. > >> > >> In the RADIUS world, the Interim and Stop messages include cumulative > >> statistics. I have found that there are many services/customers that really > >> want their accounting packets to include cumulative info. However, I have > >meet > >> some other folks that need their packets to NOT be cumulative and this is > >> necessary due to the fact that they are migrating from existing systems that > >> operate in such a fashion. > >> > >> Therefore, when the accounting session is established, we should allow for > >> either type of accounting information. I would propose that this be sent > >> back in the Accounting Start confirmation message, since the end customer > >> should be the one that determines how they want their accounting data to > >> be fed to them. This, of course, raises an important issue: > >> > >> - In a roaming scenario, where there are multiple accounting server > >> hops, each node in the tree may require a different method. That > >> said, we may want to re-consider the negotiable aspect of this > >> proposal, and require that each service determine their accounting > >> method. > >> > >> PatC From owner-aaa-bof@merit.edu Thu Mar 11 12:09:41 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA22266 for ; Thu, 11 Mar 1999 12:09:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40A1B44413; Thu, 11 Mar 1999 12:09:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 28DF644425; Thu, 11 Mar 1999 12:09:35 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 2348944413 for ; Thu, 11 Mar 1999 12:09:34 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA12076 for ; Thu, 11 Mar 1999 12:09:33 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27790; Thu, 11 Mar 1999 09:09:30 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.124.47]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id JAA16946; Thu, 11 Mar 1999 09:09:27 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01378; Thu, 11 Mar 1999 09:09:07 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903111709.JAA01378@hsmpka.eng.sun.com> Date: Thu, 11 Mar 1999 09:11:37 -0800 To: "Brian E Carpenter" , Cc: Reply-To: Subject: Re: Accounting Requirements.... X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Ah, yes I completely misunderstood your statement. Sorry about that. Yes, you are correct that message MUST be reliably delivered to the accounting "server". Loosing messages is not an option, so ACID should be added to the requirements. PatC >Perhaps a slight miscommunication there. > >What I mean is that accounting transactions need the famous ACID >properties of any transaction processing application (unless >you are happy to lose data). That's Atomicity, Consistency, Isolation, >Durability, and the usual solution is 2 phase commit with rollback. >So my question is whether that level of protection is needed, or whether >we are happy for accounting records to get lost sometimes. > > Brian > >Patrice Calhoun wrote: >> >> >I don't understand how this model gives transactional security, >> >which I would have thought was essential for accounting. >> >"Messages" aren't enough to provide transactional properties. >> > >> >Onec the mechanism is fully transactional, it really doesn't >> >matter whether you do cumulative data or not. >> >> Brian, I was not discussing transactional security here. I was simply stating >> that the current RADIUS model does not suffice for other services. That's it. >> The wireless (read cellular) people do *not* want cumulative, while the PPP >> access people do. >> >> There is still lots of work to do in this area, and security is one of them. >> Although if you want more info on message security, I would point you to: >> - draft-calhoun-framework-02.txt is the DIAMETER framework document and >> describes the need for hop-by-hop and end-to-end security, >> - draft-calhoun-diameter-07.txt, which discusses simple message security, and >> - draft-calhoun-diameter-proxy-01.txt, which discusses security across >brokers >> and domains. >> >> PatC >> > >> > Brian >> > >> >Patrice Calhoun wrote: >> >> >> >> As most of you know, Accounting consists of multiple message, which I will >> >> enumerate: >> >> - Accounting Start: An indication that a session has just been >> >> established. This message includes information about the >session. >> >> - Interim Msg: This message can be sent by the system that sent >the >> >> Accounting Start message, and includes an update on the session. >> >> This message includes statistics that can be used for.... >> >> network capacity :) >> >> - Accounting Stop: This message indicates the end of a session >> >> and includes the final statistics. >> >> >> >> In the RADIUS world, the Interim and Stop messages include cumulative >> >> statistics. I have found that there are many services/customers that >really >> >> want their accounting packets to include cumulative info. However, I have >> >meet >> >> some other folks that need their packets to NOT be cumulative and this is >> >> necessary due to the fact that they are migrating from existing systems >that >> >> operate in such a fashion. >> >> >> >> Therefore, when the accounting session is established, we should allow for >> >> either type of accounting information. I would propose that this be sent >> >> back in the Accounting Start confirmation message, since the end customer >> >> should be the one that determines how they want their accounting data to >> >> be fed to them. This, of course, raises an important issue: >> >> >> >> - In a roaming scenario, where there are multiple accounting >server >> >> hops, each node in the tree may require a different method. That >> >> said, we may want to re-consider the negotiable aspect of this >> >> proposal, and require that each service determine their >accounting >> >> method. >> >> >> >> PatC From owner-aaa-bof@merit.edu Thu Mar 11 15:45:19 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA25561 for ; Thu, 11 Mar 1999 15:45:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DE5E44408; Thu, 11 Mar 1999 15:45:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 16BD144405; Thu, 11 Mar 1999 15:45:12 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 0016944402 for ; Thu, 11 Mar 1999 15:45:10 -0500 (EST) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA17621 for ; Thu, 11 Mar 1999 15:45:10 -0500 (EST) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id MAA18178; Thu, 11 Mar 1999 12:44:06 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns5.corpeast.baynetworks.com [132.245.135.108]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id PAA22359; Thu, 11 Mar 1999 15:42:22 -0500 (EST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0.corpeast.baynetworks.com [192.32.72.12]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id PAA25640; Thu, 11 Mar 1999 15:46:12 -0500 for Received: from msquire ([132.245.252.103]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Thu, 11 Mar 1999 15:46:08 -0500 Message-Id: <3.0.32.19990311154412.00ac1b20@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 11 Mar 1999 15:44:13 -0500 To: From: Matt Squire Subject: Re: Accounting Requirements.... Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I've always viewed these 'message types' as just part of the accounting data payload. I don't believe that we need to do anything special for different message types. I think that the real issue here is whether the protocol itself needs to provide for any translation of the data which is being accounted (is that a verb?), or whether this is the responsibility of an application layer above the base accounting protocol. Translation operations could be provided for cumulative vs not (ie addition), for concatenating individual elements into lists of elements, for translating between real time and elapsed time, for translating between different monetary units, and for numerous other operations that could be performed on whatever base data types are accounted. At this point, I don't think it worthwile to make it the protocols responsibility to do any translation. Protocols using AAA should define the data that is being accounted, and should not expect the protocol to do anything except make sure that the data gets to where its supposed to when its supposed to and with whatever security measurements are required for that data. I guess that's the long way of saying that I agree that the services should define the format of their data. - Matt At 03:03 PM 3/10/99 -0800, Patrice Calhoun wrote: > >As most of you know, Accounting consists of multiple message, which I will >enumerate: > - Accounting Start: An indication that a session has just been > established. This message includes information about the session. > - Interim Msg: This message can be sent by the system that sent the > Accounting Start message, and includes an update on the session. > This message includes statistics that can be used for.... > network capacity :) > - Accounting Stop: This message indicates the end of a session > and includes the final statistics. > >In the RADIUS world, the Interim and Stop messages include cumulative >statistics. I have found that there are many services/customers that really >want their accounting packets to include cumulative info. However, I have meet >some other folks that need their packets to NOT be cumulative and this is >necessary due to the fact that they are migrating from existing systems that >operate in such a fashion. > >Therefore, when the accounting session is established, we should allow for >either type of accounting information. I would propose that this be sent >back in the Accounting Start confirmation message, since the end customer >should be the one that determines how they want their accounting data to >be fed to them. This, of course, raises an important issue: > > - In a roaming scenario, where there are multiple accounting server > hops, each node in the tree may require a different method. That > said, we may want to re-consider the negotiable aspect of this > proposal, and require that each service determine their accounting > method. > >PatC > > > From owner-aaa-bof@merit.edu Thu Mar 11 15:48:50 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA25595 for ; Thu, 11 Mar 1999 15:48:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F69544409; Thu, 11 Mar 1999 15:48:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 16C7A44405; Thu, 11 Mar 1999 15:48:44 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 19E8144402 for ; Thu, 11 Mar 1999 15:48:42 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA17702 for ; Thu, 11 Mar 1999 15:48:42 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13254; Thu, 11 Mar 1999 12:48:36 -0800 (PST) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.124.37]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id MAA24358; Thu, 11 Mar 1999 12:48:34 -0800 (PST) Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10821; Thu, 11 Mar 1999 12:48:31 -0800 Date: Thu, 11 Mar 1999 12:48:39 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Accounting Requirements.... To: Matt Squire Cc: Pat.Calhoun@Eng.Sun.COM, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3.0.32.19990311154412.00ac1b20@bl-mail1.corpeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > I've always viewed these 'message types' as just part of the accounting > data payload. I don't believe that we need to do anything special for > different message types. > > I think that the real issue here is whether the protocol itself needs to > provide for any translation of the data which is being accounted (is that a > verb?), or whether this is the responsibility of an application layer above > the base accounting protocol. Translation operations could be provided > for cumulative vs not (ie addition), for concatenating individual elements > into lists of elements, for translating between real time and elapsed time, > for translating between different monetary units, and for numerous other > operations that could be performed on whatever base data types are > accounted. > > At this point, I don't think it worthwile to make it the protocols > responsibility to do any translation. Protocols using AAA should define > the data that is being accounted, and should not expect the protocol to do > anything except make sure that the data gets to where its supposed to when > its supposed to and with whatever security measurements are required for > that data. > > I guess that's the long way of saying that I agree that the services should > define the format of their data. > Matt, I completely agree with you. I think this is a good approach. PatC From owner-aaa-bof@merit.edu Thu Mar 11 16:28:01 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA26281 for ; Thu, 11 Mar 1999 16:28:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E42944417; Thu, 11 Mar 1999 16:27:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C660A44437; Thu, 11 Mar 1999 16:27:50 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id E8FF644417 for ; Thu, 11 Mar 1999 16:26:41 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA18779 for ; Thu, 11 Mar 1999 16:26:39 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8PL2F2C2E8ZDX67@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 11 Mar 1999 16:26:08 EST Date: Thu, 11 Mar 1999 13:26:05 -0800 From: Paul Krumviede Subject: Re: Accounting Requirements.... To: aaa-wg@merit.edu Message-id: <36E834ED.C36F3A0@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199903111709.JAA01378@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Patrice Calhoun wrote: > > Ah, yes I completely misunderstood your statement. Sorry about that. > > Yes, you are correct that message MUST be reliably delivered to the > accounting "server". Loosing messages is not an option, so ACID should > be added to the requirements. Speaking as a a service provider: NO. I'm not sure we're willing to pay the cost of this for, say, micro-payments. For some services, yes. Emphasis on "some." For which services do you think this is a hard requirement. -paul From owner-aaa-bof@merit.edu Thu Mar 11 17:27:05 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA26922 for ; Thu, 11 Mar 1999 17:27:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 413734440C; Thu, 11 Mar 1999 17:26:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C74A44411; Thu, 11 Mar 1999 17:26:59 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 2FCB54440C for ; Thu, 11 Mar 1999 17:26:57 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA20107 for ; Thu, 11 Mar 1999 17:26:56 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8PN65ELK48WVYX5@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 11 Mar 1999 17:26:25 EST Date: Thu, 11 Mar 1999 14:26:22 -0800 From: Paul Krumviede Subject: Re: Accounting Requirements.... To: aaa-wg@merit.edu Message-id: <36E8430E.ED0CA0EF@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-aaa-bof@merit.edu Precedence: bulk "pcalhoun@eng.sun.com" wrote: > > At this point, I don't think it worthwile to make it the protocols > > responsibility to do any translation. Protocols using AAA should define > > the data that is being accounted, and should not expect the protocol to do > > anything except make sure that the data gets to where its supposed to when > > its supposed to and with whatever security measurements are required for > > that data. > > > > I guess that's the long way of saying that I agree that the services should > > define the format of their data. > > > > Matt, > > I completely agree with you. I think this is a good approach. Yes. In the pedantic sense, I'm not sure protocols ever do translation. But given interests in being able to build large scalable systems, I'd rather have something above the protocol layer do what may be required. And since "doing what may be required" is inherently a relative notion, I'm not sure we should do much more than, say, define the properties of the data and transport of it required by services. Having said that, we may have to do something about defining the data element representation. One reason for that may be that if the data needs to be modified, even in the sense of attaching authentication (such as a digital signature of a hash of the data field(s)), then something needs to understand which things to include in such cases. -paul From owner-aaa-bof@merit.edu Fri Mar 12 00:15:37 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id AAA00814 for ; Fri, 12 Mar 1999 00:15:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9915344413; Fri, 12 Mar 1999 00:15:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7500E44417; Fri, 12 Mar 1999 00:15:20 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 1029C44413 for ; Fri, 12 Mar 1999 00:15:18 -0500 (EST) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.9.1a/8.9.1) with ESMTP id AAA25114 for ; Fri, 12 Mar 1999 00:15:18 -0500 (EST) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id VAA12283; Thu, 11 Mar 1999 21:14:17 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns5.corpeast.baynetworks.com [132.245.135.108]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id VAA25857; Thu, 11 Mar 1999 21:14:45 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0.corpeast.baynetworks.com [192.32.72.12]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id AAA19705; Fri, 12 Mar 1999 00:16:23 -0500 for Received: from msquire ([132.245.139.114]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Fri, 12 Mar 1999 00:16:18 -0500 Message-Id: <3.0.32.19990312001409.00acf8f0@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 12 Mar 1999 00:14:12 -0500 To: Paul Krumviede , aaa-wg@merit.edu From: Matt Squire Subject: Re: Accounting Requirements.... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 02:26 PM 3/11/99 -0800, Paul Krumviede wrote: >"pcalhoun@eng.sun.com" wrote: > >> > At this point, I don't think it worthwile to make it the protocols >> > responsibility to do any translation. Protocols using AAA should define >> > the data that is being accounted, and should not expect the protocol to do >> > anything except make sure that the data gets to where its supposed to when >> > its supposed to and with whatever security measurements are required for >> > that data. >> > >> > I guess that's the long way of saying that I agree that the services should >> > define the format of their data. >> > >> >> Matt, >> >> I completely agree with you. I think this is a good approach. > >Yes. In the pedantic sense, I'm not sure protocols ever do >translation. But given interests in being able to build large >scalable systems, I'd rather have something above the protocol >layer do what may be required. > >And since "doing what may be required" is inherently a >relative notion, I'm not sure we should do much more than, >say, define the properties of the data and transport of it >required by services. Having said that, we may have to do >something about defining the data element representation. >One reason for that may be that if the data needs to be >modified, even in the sense of attaching authentication >(such as a digital signature of a hash of the data field(s)), >then something needs to understand which things to include >in such cases. > >-paul > I agree that we need to define the data representation and its properties. A while ago I suggested that we really need to define a SMI/MIB type language so that applications above AAA can define their accounting records and any transport requirements so that the AAA protocol be responsible for transporting these data elements across the network in a way that meets the requirements. I still believe this to be a requirement if we expect to provide a useful accounting protocol for an expandable set of services. - Matt From owner-aaa-bof@merit.edu Fri Mar 12 05:58:01 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id FAA03490 for ; Fri, 12 Mar 1999 05:58:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 686FC44428; Fri, 12 Mar 1999 05:57:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3D4124442A; Fri, 12 Mar 1999 05:57:42 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 3A43C44428 for ; Fri, 12 Mar 1999 05:57:41 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by merit.edu (8.9.1a/8.9.1) with ESMTP id FAA27931 for ; Fri, 12 Mar 1999 05:57:38 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id KAA77162 for ; Fri, 12 Mar 1999 10:57:05 GMT Received: from hursley.ibm.com (9-20-29-173.dhcp.hursley.ibm.com [9.20.29.173]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id KAA16204 for ; Fri, 12 Mar 1999 10:57:04 GMT Message-ID: <36E8F2CE.27F7FD9A@hursley.ibm.com> Date: Fri, 12 Mar 1999 10:56:14 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: Accounting Requirements.... References: <199903111709.JAA01378@hsmpka.eng.sun.com> <36E834ED.C36F3A0@mci.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul Krumviede wrote: > > Patrice Calhoun wrote: > > > > Ah, yes I completely misunderstood your statement. Sorry about that. > > > > Yes, you are correct that message MUST be reliably delivered to the > > accounting "server". Loosing messages is not an option, so ACID should > > be added to the requirements. > > Speaking as a a service provider: NO. I'm not sure we're willing > to pay the cost of this for, say, micro-payments. > > For some services, yes. Emphasis on "some." For which services do you > think this is a hard requirement. That's entirely a question for ISPs to answer. Brian From owner-aaa-bof@merit.edu Fri Mar 12 16:35:22 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA11612 for ; Fri, 12 Mar 1999 16:35:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id CECF544426; Fri, 12 Mar 1999 16:35:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A772944441; Fri, 12 Mar 1999 16:35:06 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id A8EA644426 for ; Fri, 12 Mar 1999 16:35:05 -0500 (EST) Received: from exchange_irvine.rainbow.com (mail.rainbow.com [209.78.195.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA09134 for ; Fri, 12 Mar 1999 16:35:01 -0500 (EST) Received: by exchange_irvine.rainbow.com with Internet Mail Service (5.0.1460.8) id ; Fri, 12 Mar 1999 11:50:26 -0800 Message-ID: From: lelteto To: "'AAA Working Group'" Subject: Authentication using Agents Date: Fri, 12 Mar 1999 11:50:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk Can we consider accomodating Agents in the authentication protocol? That would mean the server can send a piece of code (we definitely need some form of assurance that it came from the correct server as well as code integrity, similar to Java or Authenticode signing) which executes on the client system and generates the response. The current authentication protocols are not suitable to communicate large amount of data (or sending code) so it would be beneficial if the new AAA could do that. I know that in many cases one can install an Agent on the target computer, but our latest system requires to send different agent each time. (To be more precise an agent has a short - 15 minute - lifetime after which it is discarded. This is to protect against analyzing and hacking the code.) At this point the system is connected to the Processor Serial Number feature in Intel's Pentium III processor. (I know the surrounding controversy. Please don't flame me. The feature is very useful in corporate intra/extranets where one wants to authenticate the place - i.e. computer - of the call. In some environments it is necessary to know that you talk with a known locked-down configuration with no malicious Trojen Horses. Consumer applications and privacy is another, debatable question... I don't want to distract this thread with detail. If one is interested go to http://www.rainbow.com and look for the iGuard product or can ask me in private e-mail at lelteto@rainbow.com) So our request is to include mechanism(s) in Authentication where the server sends an Agent to the client which executes there and resturns an authentication value which can be validated at the server. Laszlo Elteto Rainbow Technologies, Inc. From owner-aaa-bof@merit.edu Fri Mar 12 17:39:11 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA12797 for ; Fri, 12 Mar 1999 17:39:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C01B44453; Fri, 12 Mar 1999 17:38:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0A57F4444F; Fri, 12 Mar 1999 17:38:54 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 7835C44458 for ; Fri, 12 Mar 1999 17:38:52 -0500 (EST) Received: from exchange_irvine.rainbow.com (mail.rainbow.com [209.78.195.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA12018 for ; Fri, 12 Mar 1999 17:38:51 -0500 (EST) Received: by exchange_irvine.rainbow.com with Internet Mail Service (5.0.1460.8) id ; Fri, 12 Mar 1999 14:26:28 -0800 Message-ID: From: lelteto To: "'Pat.Calhoun@Eng.Sun.COM'" , "'AAA Working Group'" Subject: RE: Authentication using Agents Date: Fri, 12 Mar 1999 14:26:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk The reason I would like to keep this in mind is that in Susan Hares'Requirements for AAA: A-1b) Transport Req. of Authentication and Authorization" 5. says No bulk data. If the protocol is designed in a way that prevents sending bulk data (in this case actually an agent code) that may be a problem later. I agree that we probably don't want to specify HOW the agent is downloaded but the protocol should allow initiation of a download/upload (depending how you see it) request. It also means the protocol should allow multi-step authentication, not only one pair of challenge/reply. lelteto -----Original Message----- From: Pat.Calhoun@Eng.Sun.COM [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Friday, March 12, 1999 2:14 PM To: lelteto; 'AAA Working Group' Subject: Re: Authentication using Agents What you are describing here sounds very much like Extensible Authentication Protocol (EAP) tied with a AAA protocol (look at draft-calhoun-diameter-eap-02.txt for an example, although the draft needs updating). This allows mutual authentication between the client and the AAA server, allowing the intermediate system (IP Gateway, Mobile IP FA, PPP Server) to simply shuttle the EAP packets back and forth. In your case, it sounds like you want to download something like a Java applet down to the client that contains the EAP authentication module (note, this is an example, I am not specifically recommending the use of EAP here, simply the concept). That said, it sounds like it does make sense, but I am not sure that we need to specify how code gets downloaded to the client, but we can look at the authentication methods that the AAA server needs to worry about. PatC >Can we consider accomodating Agents in the authentication protocol? > >That would mean the server can send a piece of code (we definitely need some >form of assurance that it came from the correct server as well as code >integrity, similar to Java or Authenticode signing) which executes on the >client system and generates the response. >The current authentication protocols are not suitable to communicate large >amount of data (or sending code) so it would be beneficial if the new AAA >could do that. >I know that in many cases one can install an Agent on the target computer, >but our latest system requires to send different agent each time. (To be >more precise an agent has a short - 15 minute - lifetime after which it is >discarded. This is to protect against analyzing and hacking the code.) At >this point the system is connected to the Processor Serial Number feature in >Intel's Pentium III processor. (I know the surrounding controversy. Please >don't flame me. The feature is very useful in corporate intra/extranets >where one wants to authenticate the place - i.e. computer - of the call. In >some environments it is necessary to know that you talk with a known >locked-down configuration with no malicious Trojen Horses. Consumer >applications and privacy is another, debatable question... I don't want to >distract this thread with detail. If one is interested go to >http://www.rainbow.com and look for the iGuard product or can ask me in >private e-mail at lelteto@rainbow.com) > >So our request is to include mechanism(s) in Authentication where the server >sends an Agent to the client which executes there and resturns an >authentication value which can be validated at the server. > >Laszlo Elteto >Rainbow Technologies, Inc. > From owner-aaa-bof@merit.edu Fri Mar 12 17:41:26 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA12908 for ; Fri, 12 Mar 1999 17:41:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45D6F44426; Fri, 12 Mar 1999 17:12:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2154744441; Fri, 12 Mar 1999 17:12:16 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 0831E44426 for ; Fri, 12 Mar 1999 17:12:14 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA09762 for ; Fri, 12 Mar 1999 17:12:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08004; Fri, 12 Mar 1999 14:12:07 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.93.47]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id OAA25004; Fri, 12 Mar 1999 14:12:05 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20424; Fri, 12 Mar 1999 14:11:57 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903122211.OAA20424@hsmpka.eng.sun.com> Date: Fri, 12 Mar 1999 14:14:08 -0800 To: "lelteto" , "'AAA Working Group'" Reply-To: Subject: Re: Authentication using Agents X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk What you are describing here sounds very much like Extensible Authentication Protocol (EAP) tied with a AAA protocol (look at draft-calhoun-diameter-eap-02.txt for an example, although the draft needs updating). This allows mutual authentication between the client and the AAA server, allowing the intermediate system (IP Gateway, Mobile IP FA, PPP Server) to simply shuttle the EAP packets back and forth. In your case, it sounds like you want to download something like a Java applet down to the client that contains the EAP authentication module (note, this is an example, I am not specifically recommending the use of EAP here, simply the concept). That said, it sounds like it does make sense, but I am not sure that we need to specify how code gets downloaded to the client, but we can look at the authentication methods that the AAA server needs to worry about. PatC >Can we consider accomodating Agents in the authentication protocol? > >That would mean the server can send a piece of code (we definitely need some >form of assurance that it came from the correct server as well as code >integrity, similar to Java or Authenticode signing) which executes on the >client system and generates the response. >The current authentication protocols are not suitable to communicate large >amount of data (or sending code) so it would be beneficial if the new AAA >could do that. >I know that in many cases one can install an Agent on the target computer, >but our latest system requires to send different agent each time. (To be >more precise an agent has a short - 15 minute - lifetime after which it is >discarded. This is to protect against analyzing and hacking the code.) At >this point the system is connected to the Processor Serial Number feature in >Intel's Pentium III processor. (I know the surrounding controversy. Please >don't flame me. The feature is very useful in corporate intra/extranets >where one wants to authenticate the place - i.e. computer - of the call. In >some environments it is necessary to know that you talk with a known >locked-down configuration with no malicious Trojen Horses. Consumer >applications and privacy is another, debatable question... I don't want to >distract this thread with detail. If one is interested go to >http://www.rainbow.com and look for the iGuard product or can ask me in >private e-mail at lelteto@rainbow.com) > >So our request is to include mechanism(s) in Authentication where the server >sends an Agent to the client which executes there and resturns an >authentication value which can be validated at the server. > >Laszlo Elteto >Rainbow Technologies, Inc. > From owner-aaa-bof@merit.edu Fri Mar 12 17:49:10 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA12995 for ; Fri, 12 Mar 1999 17:49:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBF974440B; Fri, 12 Mar 1999 17:48:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ABEB144410; Fri, 12 Mar 1999 17:48:55 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id AD62C4440B for ; Fri, 12 Mar 1999 17:48:54 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA13111 for ; Fri, 12 Mar 1999 17:48:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21931; Fri, 12 Mar 1999 14:48:48 -0800 (PST) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.123.37]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8) with SMTP id OAA15201; Fri, 12 Mar 1999 14:48:45 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00858; Fri, 12 Mar 1999 14:48:38 -0800 From: Pat.Calhoun@Eng.Sun.COM (Patrice Calhoun) Message-Id: <199903122248.OAA00858@hsmpka.eng.sun.com> Date: Fri, 12 Mar 1999 14:50:48 -0800 To: "lelteto" , "'AAA Working Group'" Reply-To: Subject: RE: Authentication using Agents X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk >The reason I would like to keep this in mind is that in Susan >Hares'Requirements for AAA: A-1b) Transport Req. of Authentication and >Authorization" 5. says No bulk data. If the protocol is designed in a way >that prevents sending bulk data (in this case actually an agent code) that >may be a problem later. >I agree that we probably don't want to specify HOW the agent is downloaded >but the protocol should allow initiation of a download/upload (depending how >you see it) request. It also means the protocol should allow multi-step >authentication, not only one pair of challenge/reply. Ahh... got it. Yes, it would be possible to download an agent piece down to the PEP, and have the PEP send the agent module (possible a Java applet) down to the client. That would be similar to normal authorization information, I suppose. However, this begs a different question. In order for this code to be downloaded to the client, the AAA server needs to know what the client's identity is first, right? So don't we end up with a chicken and egg problem? Or is the code downloaded only once the user's identity is known? PatC > >lelteto > >-----Original Message----- >From: Pat.Calhoun@Eng.Sun.COM [mailto:Pat.Calhoun@Eng.Sun.COM] >Sent: Friday, March 12, 1999 2:14 PM >To: lelteto; 'AAA Working Group' >Subject: Re: Authentication using Agents > > > >What you are describing here sounds very much like Extensible Authentication >Protocol (EAP) tied with a AAA protocol (look at >draft-calhoun-diameter-eap-02.txt for an example, although the draft needs >updating). > >This allows mutual authentication between the client and the AAA server, >allowing the intermediate system (IP Gateway, Mobile IP FA, PPP Server) >to simply shuttle the EAP packets back and forth. > >In your case, it sounds like you want to download something like a Java >applet down to the client that contains the EAP authentication module (note, >this is an example, I am not specifically recommending the use of EAP here, >simply the concept). > >That said, it sounds like it does make sense, but I am not sure that we need >to specify how code gets downloaded to the client, but we can look at the >authentication methods that the AAA server needs to worry about. > >PatC >>Can we consider accomodating Agents in the authentication protocol? >> >>That would mean the server can send a piece of code (we definitely need >some >>form of assurance that it came from the correct server as well as code >>integrity, similar to Java or Authenticode signing) which executes on the >>client system and generates the response. >>The current authentication protocols are not suitable to communicate large >>amount of data (or sending code) so it would be beneficial if the new AAA >>could do that. >>I know that in many cases one can install an Agent on the target computer, >>but our latest system requires to send different agent each time. (To be >>more precise an agent has a short - 15 minute - lifetime after which it is >>discarded. This is to protect against analyzing and hacking the code.) At >>this point the system is connected to the Processor Serial Number feature >in >>Intel's Pentium III processor. (I know the surrounding controversy. Please >>don't flame me. The feature is very useful in corporate intra/extranets >>where one wants to authenticate the place - i.e. computer - of the call. In >>some environments it is necessary to know that you talk with a known >>locked-down configuration with no malicious Trojen Horses. Consumer >>applications and privacy is another, debatable question... I don't want to >>distract this thread with detail. If one is interested go to >>http://www.rainbow.com and look for the iGuard product or can ask me in >>private e-mail at lelteto@rainbow.com) >> >>So our request is to include mechanism(s) in Authentication where the >server >>sends an Agent to the client which executes there and resturns an >>authentication value which can be validated at the server. >> >>Laszlo Elteto >>Rainbow Technologies, Inc. >> > > From owner-aaa-bof@merit.edu Fri Mar 12 18:18:44 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA13204 for ; Fri, 12 Mar 1999 18:18:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B83A44410; Fri, 12 Mar 1999 18:18:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 29C0544413; Fri, 12 Mar 1999 18:18:31 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 2D2FC44410 for ; Fri, 12 Mar 1999 18:18:30 -0500 (EST) Received: from exchange_irvine.rainbow.com (mail.rainbow.com [209.78.195.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA13651 for ; Fri, 12 Mar 1999 18:18:29 -0500 (EST) Received: by exchange_irvine.rainbow.com with Internet Mail Service (5.0.1460.8) id ; Fri, 12 Mar 1999 15:06:08 -0800 Message-ID: From: lelteto To: "'Pat.Calhoun@Eng.Sun.COM'" , "'AAA Working Group'" Subject: RE: Authentication using Agents Date: Fri, 12 Mar 1999 15:06:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk In the CURRENT implementation the server knows the username (and possibly pasword) before sending the agent; however, it is not necessary. (The server sends the same agent - in a given time slot - no matter what the user is.) In fact, in some environments the server might want to authenticate the computer (e.g. using the Processor Serial Number - think about network node authentication where there is no user at all) without any user information. We are interesting in allowing downloading an agent to an unknown computer. The agent suppose to authenticate that environment (with or without user). So I don't think it's a chicken-and-egg problem (although you can make that with some work ). Our basic goal just extending the authentication to accomodate agents (or more precisely, making sure the final protocol's limitation(s) will not prevent it. lelteto -----Original Message----- From: Pat.Calhoun@Eng.Sun.COM [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Friday, March 12, 1999 2:51 PM To: lelteto; 'AAA Working Group' Subject: RE: Authentication using Agents >The reason I would like to keep this in mind is that in Susan >Hares'Requirements for AAA: A-1b) Transport Req. of Authentication and >Authorization" 5. says No bulk data. If the protocol is designed in a way >that prevents sending bulk data (in this case actually an agent code) that >may be a problem later. >I agree that we probably don't want to specify HOW the agent is downloaded >but the protocol should allow initiation of a download/upload (depending how >you see it) request. It also means the protocol should allow multi-step >authentication, not only one pair of challenge/reply. Ahh... got it. Yes, it would be possible to download an agent piece down to the PEP, and have the PEP send the agent module (possible a Java applet) down to the client. That would be similar to normal authorization information, I suppose. However, this begs a different question. In order for this code to be downloaded to the client, the AAA server needs to know what the client's identity is first, right? So don't we end up with a chicken and egg problem? Or is the code downloaded only once the user's identity is known? PatC > >lelteto > >-----Original Message----- >From: Pat.Calhoun@Eng.Sun.COM [mailto:Pat.Calhoun@Eng.Sun.COM] >Sent: Friday, March 12, 1999 2:14 PM >To: lelteto; 'AAA Working Group' >Subject: Re: Authentication using Agents > > > >What you are describing here sounds very much like Extensible Authentication >Protocol (EAP) tied with a AAA protocol (look at >draft-calhoun-diameter-eap-02.txt for an example, although the draft needs >updating). > >This allows mutual authentication between the client and the AAA server, >allowing the intermediate system (IP Gateway, Mobile IP FA, PPP Server) >to simply shuttle the EAP packets back and forth. > >In your case, it sounds like you want to download something like a Java >applet down to the client that contains the EAP authentication module (note, >this is an example, I am not specifically recommending the use of EAP here, >simply the concept). > >That said, it sounds like it does make sense, but I am not sure that we need >to specify how code gets downloaded to the client, but we can look at the >authentication methods that the AAA server needs to worry about. > >PatC >>Can we consider accomodating Agents in the authentication protocol? >> >>That would mean the server can send a piece of code (we definitely need >some >>form of assurance that it came from the correct server as well as code >>integrity, similar to Java or Authenticode signing) which executes on the >>client system and generates the response. >>The current authentication protocols are not suitable to communicate large >>amount of data (or sending code) so it would be beneficial if the new AAA >>could do that. >>I know that in many cases one can install an Agent on the target computer, >>but our latest system requires to send different agent each time. (To be >>more precise an agent has a short - 15 minute - lifetime after which it is >>discarded. This is to protect against analyzing and hacking the code.) At >>this point the system is connected to the Processor Serial Number feature >in >>Intel's Pentium III processor. (I know the surrounding controversy. Please >>don't flame me. The feature is very useful in corporate intra/extranets >>where one wants to authenticate the place - i.e. computer - of the call. In >>some environments it is necessary to know that you talk with a known >>locked-down configuration with no malicious Trojen Horses. Consumer >>applications and privacy is another, debatable question... I don't want to >>distract this thread with detail. If one is interested go to >>http://www.rainbow.com and look for the iGuard product or can ask me in >>private e-mail at lelteto@rainbow.com) >> >>So our request is to include mechanism(s) in Authentication where the >server >>sends an Agent to the client which executes there and resturns an >>authentication value which can be validated at the server. >> >>Laszlo Elteto >>Rainbow Technologies, Inc. >> > > From owner-aaa-bof@merit.edu Sat Mar 13 19:17:01 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA24638 for ; Sat, 13 Mar 1999 19:17:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F29B4444A; Sat, 13 Mar 1999 19:16:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F1B9A4444C; Sat, 13 Mar 1999 19:16:44 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 7A8534444A for ; Sat, 13 Mar 1999 19:16:42 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by merit.edu (8.9.1a/8.9.1) with ESMTP id TAA28331 for ; Sat, 13 Mar 1999 19:16:41 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8SJKWXWEW8WVZ03@shoe.reston.mci.net> for aaa-wg@merit.edu; Sat, 13 Mar 1999 19:16:10 EST Date: Sat, 13 Mar 1999 16:16:07 -0800 From: Paul Krumviede Subject: Re: Accounting Requirements.... To: Brian E Carpenter , aaa-wg@merit.edu Message-id: <36EAFFC7.2566D4C5@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199903111709.JAA01378@hsmpka.eng.sun.com> <36E834ED.C36F3A0@mci.net> <36E8F2CE.27F7FD9A@hursley.ibm.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian E Carpenter wrote: > > Paul Krumviede wrote: > > > > Patrice Calhoun wrote: > > > Yes, you are correct that message MUST be reliably delivered to the > > > accounting "server". Loosing messages is not an option, so ACID should > > > be added to the requirements. > > > > Speaking as a a service provider: NO. I'm not sure we're willing > > to pay the cost of this for, say, micro-payments. > > > > For some services, yes. Emphasis on "some." For which services do you > > think this is a hard requirement. > > That's entirely a question for ISPs to answer. True. My negative reaction was due to the prospect of a heavy-weight transactional modem for all accounting, while in some micro-payment schemes rare, for some value of rare, packet loss may be acceptable. Perhaps I was reacting to the "MUST" be reliably delivered. Perhaps "MUST be capable" for those services the operator wants that level of assurance. So I guess I'm saying that I want some way to indicate that some packets in the accounting stream MUST be reliably delivered, while other may not have to meet such a stringent requirement. Does this make any sense? -paul From owner-aaa-bof@merit.edu Sun Mar 14 20:30:20 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA09329 for ; Sun, 14 Mar 1999 20:30:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 584EE44480; Sun, 14 Mar 1999 20:30:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F09C44481; Sun, 14 Mar 1999 20:30:06 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 02BF344480 for ; Sun, 14 Mar 1999 20:30:04 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA12819 for ; Sun, 14 Mar 1999 20:30:03 -0500 (EST) Received: from murray (hal.lcp.livingston.com [158.222.8.12]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id RAA18552; Sun, 14 Mar 1999 17:29:50 -0800 (PST) Message-Id: <3.0.6.32.19990314172735.00998100@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sun, 14 Mar 1999 17:27:35 -0800 To: Paul Krumviede From: Brian Lloyd Subject: Re: Accounting Requirements.... Cc: Brian E Carpenter , aaa-wg@merit.edu In-Reply-To: <36EAFFC7.2566D4C5@mci.net> References: <199903111709.JAA01378@hsmpka.eng.sun.com> <36E834ED.C36F3A0@mci.net> <36E8F2CE.27F7FD9A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 04:16 PM 3/13/99 -0800, Paul Krumviede wrote: >True. My negative reaction was due to the prospect of a heavy-weight >transactional modem for all accounting, while in some micro-payment >schemes rare, for some value of rare, packet loss may be acceptable. >Perhaps I was reacting to the "MUST" be reliably delivered. Perhaps >"MUST be capable" for those services the operator wants that level >of assurance. So I guess I'm saying that I want some way to indicate >that some packets in the accounting stream MUST be reliably delivered, >while other may not have to meet such a stringent requirement. Does >this make any sense? Yes. Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax O- From owner-aaa-bof@merit.edu Wed Mar 17 18:22:45 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA21037 for ; Wed, 17 Mar 1999 18:22:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 57CCA44518; Wed, 17 Mar 1999 18:14:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AF829448A9; Wed, 17 Mar 1999 18:12:14 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 6F85B444A6 for ; Wed, 17 Mar 1999 17:54:38 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA03699 for ; Wed, 17 Mar 1999 17:54:36 -0500 (EST) Received: from alden (host022.44IETF.MR.Net [209.32.92.22]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id XAA04822; Wed, 17 Mar 1999 23:53:58 +0100 Message-Id: <4.1.19990317155337.018dd610@dokka.maxware.no> Message-Id: <4.1.19990317155337.018dd610@dokka.maxware.no> X-Sender: hta@dokka.maxware.no (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Mar 1999 16:00:47 -0600 To: , From: Harald Tveit Alvestrand Subject: Re: Accounting Requirements.... In-Reply-To: <199903102301.PAA28305@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Trying to abstract Pat's messages into what I understand as requirements: Given a "client" (user of services) and a "server" (part of the management infrastructure for that service): - Some applications need to know when the client starts using the service. This information is often useful, sometimes critical, sometimes useless. - Some applications need to know, at some points in time between the start and the end of the usage, how much of the resource the client has used. In many cases, this does not need to be reliably delivered. - All applications that use accounting at all need to know how much of the resources the client has consumed when he stops using the service. The cost of losing this information is so high that it's often useful to spend resources in making sure it's delivered. Mapped to messages provided by the protocol: - Accounting-start is a MUST be in protocol, MAY be used by apps (and will be in most cases), and MUST be capable of reasonably reliable delivery. - Accounting-Interim SHOULD be in the protocol, MAY (sometimes) be used by apps, and delivery is not critical. - Accounting-Stop MUST be in protocol, MUST be used, and MUST have ACID properties. if we deploy a protocol where Accounting-Interim is sometimes lost, then Accouting-Stop MUST have cumulative statistics, not incremental. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-aaa-bof@merit.edu Thu Mar 18 01:33:35 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id BAA24013 for ; Thu, 18 Mar 1999 01:33:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA47944404; Thu, 18 Mar 1999 01:33:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F3E644406; Thu, 18 Mar 1999 01:33:29 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by segue.merit.edu (Postfix) with ESMTP id 706BE44404 for ; Thu, 18 Mar 1999 01:33:28 -0500 (EST) Received: from mx-1e-a.omnipoint.com (1cust019.tnt3.dfw2.gmbpt.com [204.132.199.19] (may be forged)) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA16982 for ; Thu, 18 Mar 1999 01:33:26 -0500 (EST) From: MBilgic@omnipoint.com Message-ID: <81F84374BF62D1118E6900805FBECF9C77303C@omnipoint.com> To: Harald@Alvestrand.no, Pat.Calhoun@Eng.Sun.COM, aaa-wg@merit.edu Subject: RE: Accounting Requirements.... Date: Wed, 17 Mar 1999 23:33:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk A comment about the reliability of the delivery of usage information to the "application" during the usage: For some applications this needs to be extremely reliable. A typical example is the pay-phone service where the phone gets measurement pulses from the switch. So I would slightly rephrase Harald's relevant statement: "- Accounting-Interim MUST be in the protocol, MAY (sometimes) be used by apps." Murat Bilgic Principal Engineer email: mbilgic@omnipoint.com Omnipoint Technologies Inc. Phone: 719-548-1201 x 1292 Colorado Springs, CO 80907 Fax: 719-548-1393 --- Any personal opinions expressed herein do not necessarily represent those of Omnipoint Technologies, Inc. From owner-aaa-bof@merit.edu Thu Mar 18 11:41:21 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA29267 for ; Thu, 18 Mar 1999 11:41:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D83144427; Thu, 18 Mar 1999 11:40:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 841CA44436; Thu, 18 Mar 1999 11:40:59 -0500 (EST) Received: from exchange_irvine.rainbow.com (mail.rainbow.com [209.78.195.3]) by segue.merit.edu (Postfix) with ESMTP id 47ACD44427 for ; Thu, 18 Mar 1999 11:40:57 -0500 (EST) Received: by exchange_irvine.rainbow.com with Internet Mail Service (5.0.1460.8) id ; Thu, 18 Mar 1999 08:29:10 -0800 Message-ID: From: lelteto To: "'MBilgic@omnipoint.com'" , Harald@Alvestrand.no, Pat.Calhoun@Eng.Sun.COM, aaa-wg@merit.edu Subject: RE: Accounting Requirements.... Date: Thu, 18 Mar 1999 08:29:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree. If interim is not in the protocol what happens if the stop message never delivered (e.g. total connection lost, system crash/reboot etc.)? Some protocol (possibly based on business decision) may accept the risk and ignore the interim messages but many applications will need that. So for this reason, too, the Accounting-Interim MUST be in the protocol. Laszlo Elteto Rainbow Technologies, Inc. -----Original Message----- From: MBilgic@omnipoint.com [mailto:MBilgic@omnipoint.com] Sent: Wednesday, March 17, 1999 10:33 PM To: Harald@Alvestrand.no; Pat.Calhoun@Eng.Sun.COM; aaa-wg@merit.edu Subject: RE: Accounting Requirements.... A comment about the reliability of the delivery of usage information to the "application" during the usage: For some applications this needs to be extremely reliable. A typical example is the pay-phone service where the phone gets measurement pulses from the switch. So I would slightly rephrase Harald's relevant statement: "- Accounting-Interim MUST be in the protocol, MAY (sometimes) be used by apps." Murat Bilgic Principal Engineer email: mbilgic@omnipoint.com Omnipoint Technologies Inc. Phone: 719-548-1201 x 1292 Colorado Springs, CO 80907 Fax: 719-548-1393 --- Any personal opinions expressed herein do not necessarily represent those of Omnipoint Technologies, Inc. From owner-aaa-bof@merit.edu Thu Mar 18 15:09:55 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA01089 for ; Thu, 18 Mar 1999 15:09:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4BFC44440D; Thu, 18 Mar 1999 15:09:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A76644418; Thu, 18 Mar 1999 15:09:36 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id 1871A4440D for ; Thu, 18 Mar 1999 15:09:34 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8ZAFTT0WU8Y4XZI@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 18 Mar 1999 15:09:29 EST Date: Thu, 18 Mar 1999 14:09:28 -0600 From: Paul Krumviede Subject: Re: Accounting Requirements.... To: aaa-wg@merit.edu Message-id: <36F15D78.AA831E46@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <4.1.19990317155337.018dd610@dokka.maxware.no> Sender: owner-aaa-bof@merit.edu Precedence: bulk Harald Tveit Alvestrand wrote: > > Trying to abstract Pat's messages into what I understand as requirements: > Given a "client" (user of services) and a "server" (part of the management > infrastructure for that service): > - All applications that use accounting at all need to know how much of > the resources the client has consumed when he stops using the service. > The cost of losing this information is so high that it's often useful to > spend resources in making sure it's delivered. I'm not sure I believe this is true, depending on one's definition of an "application" here. If one is doing flat rate billing, but using "accounting" for network engineering, then I may be willing to lost a lot of data rather than spend a lot of resources to ensure it gets delivered. Bernard made a few useful distinctions today, such as the purpose for which the data is intended. > Mapped to messages provided by the protocol: > - Accounting-Stop MUST be in protocol, MUST be used, and MUST have > ACID properties. I'm not sure it MUST be used or have ACID properties. > if we deploy a protocol where Accounting-Interim is sometimes lost, then > Accouting-Stop MUST have cumulative statistics, not incremental. This I can agree with. Perhaps it should always have cumulative statistics, and may have incremental as well? -paul From owner-aaa-bof@merit.edu Thu Mar 18 17:02:43 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA02436 for ; Thu, 18 Mar 1999 17:02:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF4244441A; Thu, 18 Mar 1999 17:02:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CCA364441D; Thu, 18 Mar 1999 17:02:24 -0500 (EST) Received: from ntserver1.redstonecom.com (ntserver1.redstonecom.com [199.105.223.130]) by segue.merit.edu (Postfix) with ESMTP id 2F5AF4441A for ; Thu, 18 Mar 1999 17:02:14 -0500 (EST) Received: by NTSERVER1 with Internet Mail Service (5.0.1457.3) id ; Thu, 18 Mar 1999 17:02:43 -0500 Message-ID: From: Paul Raison To: aaa-wg@merit.edu Subject: RE: Accounting Requirements.... Date: Thu, 18 Mar 1999 17:02:41 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk With the high speed interfaces that are (or may) be up always (cable modems, dsl, etc), has the discussion of rolling over the accounting numbers and the appropriate server behavior ever come up? If yes, can you point me to the references. Also, in consideration of the interim accounting message, how does the client know when the server is down, verses, when the server just does not support the interim accounting, or is interim accounting just best effort? Thanks, Paul From owner-aaa-bof@merit.edu Thu Mar 18 17:09:11 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA02472 for ; Thu, 18 Mar 1999 17:09:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1A8044493; Thu, 18 Mar 1999 17:08:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 64404444E7; Thu, 18 Mar 1999 17:08:20 -0500 (EST) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by segue.merit.edu (Postfix) with ESMTP id D7D1E4448C for ; Thu, 18 Mar 1999 17:08:13 -0500 (EST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.168.5]) by bootstrap.agcs.com (8.9.1/8.9.1) with ESMTP id PAA25900 for ; Thu, 18 Mar 1999 15:06:23 -0700 (MST) Posted-Date: Thu, 18 Mar 1999 15:06:23 -0700 (MST) Received: from agcs.com ([130.131.59.151]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with ESMTP id AAA6D83 for ; Thu, 18 Mar 1999 15:08:13 -0700 Message-ID: <36F17951.174DDE0D@agcs.com> Date: Thu, 18 Mar 1999 15:08:17 -0700 From: "Brian Hagar" Organization: AG Communication Systems X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "aaa-wg@merit.edu" Subject: Query Content-Type: multipart/mixed; boundary="------------F2364F2D7F9999ECB9AF96FD" Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------F2364F2D7F9999ECB9AF96FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings, I have not come across where I can get the current soft copy of the "Requirements for a General Authentication, Authorization, and Accounting Protocol" draft document . The copy that I have is from December 1998. It was given to me by a colleague and I do no see it under the IETF web page. Can I get a copy on the net? I am also subscribing to the WG mailing list and have missed some of the earlier e-mails. Is there an archive of this working group? Thank You, Brian Hagar --------------F2364F2D7F9999ECB9AF96FD Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Hagar Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Brian Hagar n: Hagar;Brian org: AG Communication Systems email;internet: hagarb@agcs.com title: Systems Engineer x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------F2364F2D7F9999ECB9AF96FD-- From owner-aaa-bof@merit.edu Thu Mar 18 17:21:32 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA02659 for ; Thu, 18 Mar 1999 17:21:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B5704441D; Thu, 18 Mar 1999 17:21:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1922C4441E; Thu, 18 Mar 1999 17:21:06 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id E59B44441D for ; Thu, 18 Mar 1999 17:21:03 -0500 (EST) Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id XAA18357; Thu, 18 Mar 1999 23:21:01 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id XAA23732; Thu, 18 Mar 1999 23:20:59 +0100 Date: Thu, 18 Mar 1999 23:20:59 +0100 Message-Id: <199903182220.XAA23732@dumbo.fokus.gmd.de > To: hagarb@agcs.com Subject: Re: Query Cc: aaa-wg@merit.edu X-Sun-Charset: US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Brian, you wrote: > I do no see it under the IETF web page. Can I get a copy > on the net? > > I am also subscribing to the WG mailing list and have missed some of > the earlier e-mails. Is there an archive of this working group? have a look at http://www.merit.edu/working.groups/aaa-bof/index.html or at European site at http://www.fokus.gmd.de/research/cc/glone/ietf/aaa/ and as a single file from Jan98 up to your mail as http://www.fokus.gmd.de/research/cc/glone/ietf/mail-archive/aaa/current regards Michael From owner-aaa-bof@merit.edu Thu Mar 18 17:22:04 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA02673 for ; Thu, 18 Mar 1999 17:22:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69DBD4441E; Thu, 18 Mar 1999 17:21:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4856944422; Thu, 18 Mar 1999 17:21:44 -0500 (EST) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id 51B184441E for ; Thu, 18 Mar 1999 17:21:43 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8ZF1NK2A08WVZB1@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 18 Mar 1999 17:21:37 EST Date: Thu, 18 Mar 1999 16:21:36 -0600 From: Paul Krumviede Subject: Re: Query To: Brian Hagar Cc: "aaa-wg@merit.edu" Message-id: <36F17C70.AD4D89C3@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <36F17951.174DDE0D@agcs.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian Hagar wrote: > > Greetings, > > I have not come across where I can get the current soft copy of the > "Requirements for a General Authentication, Authorization, and > Accounting Protocol" draft document . The > copy that I have is from December 1998. It was given to me by a > colleague and I do no see it under the IETF web page. Can I get a copy > on the net? > > I am also subscribing to the WG mailing list and have missed some of > the earlier e-mails. Is there an archive of this working group? The slightly dated URL for the archive and pointers to earlier documents is http://www.merit.edu/working.groups/aaa-bof. I say "slightly dated" since the URL refers to "bof" and perhaps we should see about having this changed to minimize (?) confusion. But I think all the docs to date, the BOF mailing list archive, and the WG mailing list archive are all there. -paul From owner-aaa-bof@merit.edu Thu Mar 18 18:24:06 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA03540 for ; Thu, 18 Mar 1999 18:24:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C03844423; Thu, 18 Mar 1999 18:23:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4894844424; Thu, 18 Mar 1999 18:23:48 -0500 (EST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by segue.merit.edu (Postfix) with ESMTP id 8AB5E44423 for ; Thu, 18 Mar 1999 18:23:45 -0500 (EST) Received: from alden (host022.44IETF.MR.Net [209.32.92.22]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id AAA23405; Fri, 19 Mar 1999 00:23:29 +0100 Message-Id: <4.1.19990318071537.026d9bc0@dokka.maxware.no> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 18 Mar 1999 07:18:02 -0600 To: MBilgic@omnipoint.com, Pat.Calhoun@Eng.Sun.COM, aaa-wg@merit.edu From: Harald Alvestrand Subject: RE: Accounting Requirements.... In-Reply-To: <81F84374BF62D1118E6900805FBECF9C77303C@omnipoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 23:33 17.03.99 -0700, MBilgic@omnipoint.com wrote: >A comment about the reliability of the delivery of usage information to the >"application" during the usage: > >For some applications this needs to be extremely reliable. A typical example >is the pay-phone service where the phone gets measurement pulses from the >switch. This is one example of a case where current technology (foolishly, I think) depends on getting delta information (a single pulse) rather than cumulative information (info on how much time has passed since the start of the call). If you don't do accumulated stats in the account-stop, the deltas all have to be reliable; I regard that as unnecessary overhead, easily fixed by a small piece of code at the sender end, which has state memory anyway; however, not all device makers agree with me. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From owner-aaa-bof@merit.edu Thu Mar 18 19:15:32 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA03953 for ; Thu, 18 Mar 1999 19:15:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 080184442C; Thu, 18 Mar 1999 19:15:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CA4614442E; Thu, 18 Mar 1999 19:15:10 -0500 (EST) Received: from atlas.xylogics.com (h2107.s84f5.BayNetworks.COM [132.245.33.7]) by segue.merit.edu (Postfix) with ESMTP id CC5814442C for ; Thu, 18 Mar 1999 19:15:08 -0500 (EST) Received: from vulcan.xylogics.com (vulcan.xylogics.com [132.245.33.8]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id TAA04759; Thu, 18 Mar 1999 19:10:11 -0500 (EST) Received: from mitton11 ([132.245.135.86]) by vulcan.xylogics.com id AA26266 (4.1/UK-doug-951219); Thu, 18 Mar 99 19:10:10 EST Message-Id: <3.0.5.32.19990318181440.00aa75a0@127.0.0.1> X-Sender: mitton@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 18 Mar 1999 18:14:40 -0600 To: Paul Raison , aaa-wg@merit.edu From: Dave Mitton Subject: RE: Accounting Requirements.... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Paul, If your question is in respect to the exact behavior of the RADIUS Accounting statistics, it would be better posted to the RADIUS WG list, Look at draft-ietf-radius-ext-03.txt for Interim Accounting support and Acct-*-Gigawords counter. If you are trying to make a generic requirement on accounting for AAA, then I aggree that this is a suitable niche requirement to get right in the statistics requirements. I should probably work it into NASREQ too. Dave. At 05:02 PM 3/18/99 -0500, Paul Raison wrote: > >With the high speed interfaces that are (or may) be up >always (cable modems, dsl, etc), has the discussion of rolling >over the accounting numbers and the appropriate server behavior >ever come up? If yes, can you point me to the references. > >Also, in consideration of the interim accounting message, how >does the client know when the server is down, verses, when >the server just does not support the interim accounting, >or is interim accounting just best effort? > >Thanks, >Paul > > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, IP Services 978-916-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Fri Mar 19 11:01:33 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA13236 for ; Fri, 19 Mar 1999 11:01:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id D14D544430; Fri, 19 Mar 1999 10:59:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B0FB94444C; Fri, 19 Mar 1999 10:59:51 -0500 (EST) Received: from idrp.merit.edu (idrp.merit.edu [198.108.60.89]) by segue.merit.edu (Postfix) with ESMTP id 23B1B44430; Fri, 19 Mar 1999 10:59:50 -0500 (EST) Received: from localhost (skh@localhost) by idrp.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA10428; Fri, 19 Mar 1999 10:59:49 -0500 (EST) X-Authentication-Warning: idrp.merit.edu: skh owned process doing -bs Date: Fri, 19 Mar 1999 10:59:49 -0500 (EST) From: Susan Hares To: aaa-wg@merit.edu Cc: skh@merit.edu Subject: Query (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------F2364F2D7F9999ECB9AF96FD Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------F2364F2D7F9999ECB9AF96FD Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: www.merit.edu/working.group/aaa-bof will give you 1) archive of the bof messages 2) slides 3) interim documents 4) Related draft jump off page. Coming by Monday morning, this will give a link to www.meit.edu/working.groups/aaa-wg. this location wil give you: 1) aaa-wg archive 2) Any draft documents 3) Anything people want to link to or post as working documents. I'll post the internet2 bandwidth broker link. Sue Hares ---------- Forwarded message ---------- Date: Thu, 18 Mar 1999 15:08:17 -0700 From: Brian Hagar To: "aaa-wg@merit.edu" Subject: Query Greetings, I have not come across where I can get the current soft copy of the "Requirements for a General Authentication, Authorization, and Accounting Protocol" draft document . The copy that I have is from December 1998. It was given to me by a colleague and I do no see it under the IETF web page. Can I get a copy on the net? I am also subscribing to the WG mailing list and have missed some of the earlier e-mails. Is there an archive of this working group? Thank You, Brian Hagar --------------F2364F2D7F9999ECB9AF96FD Content-Type: TEXT/X-VCARD; CHARSET=us-ascii; NAME="vcard.vcf" Content-ID: Content-Description: Card for Brian Hagar Content-Disposition: ATTACHMENT; FILENAME="vcard.vcf" begin: vcard fn: Brian Hagar n: Hagar;Brian org: AG Communication Systems email;internet: hagarb@agcs.com title: Systems Engineer x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------F2364F2D7F9999ECB9AF96FD-- From owner-aaa-bof@merit.edu Fri Mar 19 14:42:56 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA19146 for ; Fri, 19 Mar 1999 14:42:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id E37F944441; Fri, 19 Mar 1999 14:39:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C174144442; Fri, 19 Mar 1999 14:39:54 -0500 (EST) Received: from docws002.shl.com (docws002.shl.com [159.249.56.2]) by segue.merit.edu (Postfix) with ESMTP id 02F7044441 for ; Fri, 19 Mar 1999 14:39:52 -0500 (EST) Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws002.shl.com (8.9.1/8.9.1) with ESMTP id NAA23632 for ; Fri, 19 Mar 1999 13:19:45 -0700 (MST) Received: by dalmsdoc01.shl.com with Internet Mail Service (5.5.2232.9) id ; Fri, 19 Mar 1999 13:40:03 -0600 Message-ID: From: "PACHL, Jan" To: aaa-wg@merit.edu Subject: accounting and network (+system) management Date: Fri, 19 Mar 1999 13:39:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk In the interest of clarifying the scope and content of the Accounting piece of the AAA WG, let's relate it to network and system management. Bernard Aboba touched on that in his presentation, when he asked "Why not use SNMP?". One common approach to network and system management uses the F-C-A-P-S classification: Fault (+problem) management, Configuration management, Accounting management, Performance management, and Security management. (Security management includes authentication and authorization.) That suggests that fault, configuration and performance management are out of scope of the AAA work. If they are in the scope, or partly are, let's state that explicitly, so we avoid hidden scope creep. Jan Pachl SHL Systemhouse From owner-aaa-bof@merit.edu Mon Mar 22 10:37:21 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA21234 for ; Mon, 22 Mar 1999 10:37:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 576F24443B; Mon, 22 Mar 1999 10:37:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 40F764443C; Mon, 22 Mar 1999 10:37:12 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 459694443B for ; Mon, 22 Mar 1999 10:37:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28158 for ; Mon, 22 Mar 1999 07:37:12 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.63.47]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id HAA17336 for ; Mon, 22 Mar 1999 07:37:06 -0800 (PST) Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA24362; Mon, 22 Mar 1999 07:37:06 -0800 Date: Mon, 22 Mar 1999 07:37:14 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: ROAMOPS Authentication/Authorization Requirements ID To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2157795331R-6A-922117034=:26810NCE.IlHAFeR" Sender: owner-aaa-bof@merit.edu Precedence: bulk ---LA_F2157795331R-6A-922117034=:26810NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII All, I am attaching the Internet Draft that Glen and I have put together. This reflects the requirements for ROAMOPS for both Authentication and Authorization, based on several Internet Drafts and RFCs that ROAMOPS have produced. I am also sending this to the secretariat, but knowing that they will be in over their heads coming in after the IETF, I thought I would send it to the list. PatC ---LA_F2157795331R-6A-922117034=:26810NCE.IlHAFeR Content-Type: TEXT/plain; name="draft-ietf-aaa-roamops-aa-reqs-00.txt"; charset=us-ascii Content-Description: default INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-ietf-aaa-roamops-auth-req-00.txt Glen Zorn Date: March 1999 Microsoft Corporation Roamops Authentication/Authorization Requirements Status of this Memo This document is a submission by the AAA Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the aaa-wg@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The AAA Working Group is currently looking at defining the requirements for Authentication and Authorization. This document contains the requirements for Roaming Operations. 1.0 Introduction Calhoun, Zorn expires August 1999 [Page 1] INTERNET DRAFT March 1999 In non-roamops environments, a typical AAA deployment would consist of a Policy Enforcement Point (PEP), and a Policy Decision Point (PDP). The PEP receives a request for service from a user or device, and in turn issues an Authentication/Authorization request to the PDP. +------+ +-----+ +-----+ | user | | PEP | | PDP | +------+ +-----+ +-----+ --------> Request for service ---------------------> Authentication/Authorization (AA) <--------------------- Reply w/ authorization info <-------- Service is offered The PDP authenticates the user, makes some authorization decisions based on the user or device's profile, and issues a reply. The reply MAY include additional authorization information, which the PEP uses to perform additional authorization decisions before offering the service to the user/device. Much of the work in progress within ROAMOPS allows the AAA server to take a much more active role in the authentication phase. This is intended to increase the security, especially in roaming environments, where replay of previous authentication sessions is very easy. The unfortunate side-effect of this feature is that it requires more exchanges between the PEP and the PDP, as shown below. Calhoun, Zorn expires August 1999 [Page 2] INTERNET DRAFT March 1999 +------+ +-----+ +-----+ | user | | PEP | | PDP | +------+ +-----+ +-----+ --------> Request for service ---------------------> AA Req w/ identity <--------------------- AA Reply w/ Challenge <-------- Challenge --------> Response ---------------------> AA Req w/ Response <--------------------- Reply w/ authorization info <-------- Service is offered In the above example, when the PEP issues the initial AA request to the PDP, it includes the user's identity (ideally in the format defined by the Network Access Identifier (NAI) specification [1]). The PDP issues some challenge to the PEP, which is then forwarded to the user/device. This challenge could in fact be encapsulated within an EAP [2] or SASL [3] envelope, which would allow for user/device to PDP authentication using existing authentication frameworks. Once the PDP determines that the user/device has satisfactorily authenticated itself, access is granted which includes authorization information. There have been some discussions in the AAA working group to logically split the authentication and authorization phase, possibly into two different protocols. The resulting protocol would look like the following figure: Calhoun, Zorn expires August 1999 [Page 3] INTERNET DRAFT March 1999 +------+ +-----+ +-----+ | user | | PEP | | PDP | +------+ +-----+ +-----+ --------> Request for service ---------------------> Authen. Req w/ identity <--------------------- Authen. Reply w/ Challenge <-------- Challenge --------> Response ---------------------> Authen. Req w/ Response <--------------------- Authen. Reply w/ token ---------------------> Authorization Req w/ token <--------------------- Reply w/ authorization info <-------- Service is offered In this instance, the PEP initially sends the authentication request to the PDP. Upon successful authentication, the PDP returns some form of signed token back in the reply. The PEP would then issue the authorization request to the PDP, which would look at the token (to ensure that authentication had already occured), authorize the user/device, and return a reply that contains the additional authorization information. Since it is very possible for the authentication and authorization to be performed by two different PDPs, each specializing in their own area, the above example does allow for such a logical split in functionality. The Authentication PDP could support a specific manufacturer's token card, or biometric authentication. In the roamops model, it is assumed that the user/device cannot be authenticated and authorized locally. This means that the user/device requests service from a provider that is not its "home" provider. Therefore, the visited domain must forward the request to the user's home domain in order to perform the Authentication and Authorization. A reply from the home domain may be construed as "willingness to pay" for the service provided to the requesting user/device. Calhoun, Zorn expires August 1999 [Page 4] INTERNET DRAFT March 1999 Visited Home +------+ +-----+ +-----+ +-----+ | user | | PEP | | PDP | | PDP | +------+ +-----+ +-----+ +-----+ --------> Request for service ---------------------> Authen. Req Req (includes identity) -------------> Authen. Req w/ identity <------------- Authen. Rep. w/ Challenge <--------------------- Authen. Reply w/ Challenge <-------- Challenge --------> Response ---------------------> Authen. Req w/ Response -------------> Authen. Req w/ Response <------------- Authen. Reply w/ token <--------------------- Authen. Reply w/ token ---------------------> Autho. Req w/ token -------------> Autho. Req w/ token <------------- Reply w/ authorization info <--------------------- Reply w/ authorization info <-------- Service is offered In the above diagram, the Visited PDP forwards the request to the home PDP. The Home PDP is known using the identity, which is some cases is the NAI. It is equally possible for the visited PDP to simply forward the request to a broker, which it shares a trust relationship with, which in turn forwards the request to the home PDP. Calhoun, Zorn expires August 1999 [Page 5] INTERNET DRAFT March 1999 Visited Broker Home +------+ +-----+ +-----+ +-----+ +-----+ | user | | PEP | | PDP | | PDP | | PDP | +------+ +-----+ +-----+ +-----+ +-----+ Here each message will traverse the internet, possibly twice for each message if a broker is involved. Many of the services which will be using AAA stated that one of their requirement was to be able to use AAA and not impose an additional long latency. Therefore, it is paramount that we attempt to limit the number of messages required for the authentication and authorization phase. Ideally, the authentication request *should* include a request for authorization. This also has the advantange of reducing the Inter-Domain trust relationships to one (instead of one for authentication and one for authorization). When brokers are involved, it is necessary that a end-to-end (Visited to Home PDP) trust relationship be established in order to prevent from fraudulent broker activity. Otherwise, it would be possible for the broker to modify authorization information that was returned by the home domain's PDP. It should therefore be possible for the broker to return a forwarding address to the visited network's PDP, and allow the local PDP to contact the "home" PDP directly, using the end-to-end trust relationship for authentication and authorization. However, accounting messages MUST flow through the broker. This decision is up to the broker's policy on whether a forwarding address is returned, or the request is proxied to the home domain. Note that the PDP can still interface with a specialized authentication server for support of token cards or biometrics, as shown below. In this case, the interface between the PDP and the specialized Authentication server MAY use the AAA protocol, or may use a proprietary protocol. However, this is clearly outside this scope of this document. If the Authentication server is required, this should exist within the home domain, and should not be exposed to the visited domain, especially if the interface to the authentiation server is proprietary. +------+ +-----+ +-----+ +------+ | user | | PEP | | PDP | | Auth | +------+ +-----+ +-----+ +------+ 3.0 Conclusion The ROAMOPS working group has the following requirements: - Allow existing Authentication Frameworks (EAP, SASL) to be Calhoun, Zorn expires August 1999 [Page 6] INTERNET DRAFT March 1999 transported over the AAA protocol for user/device authentication. - Allow for separate authorization when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization. - The AAA protocol MUST be "proxyable", meaning that a PDP MUST be able to forward the request to another PDP, which may or may not be within the same administrative domain. - The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response. - When a broker is involved, the protocol MUST provide end to end security. - The broker MUST be able to return a forwarding address to a requestor, allowing two nodes to communicate together. Furthermore, the protocol MUST provide the following features (per user session): - One Authentication, One Authorization - One Authentication, Multiple Authorization - Multiple Authentication, Multiple Authorization 4.0 References [1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [2] B. Aboba, M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [3] J. Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. Calhoun, Zorn expires August 1999 [Page 7] INTERNET DRAFT March 1999 5.0 Author's Address Questions about this memo can be directed to: Pat R. Calhoun Network and Security Research Center Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pat.calhoun@eng.sun.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052 Phone: +1 425 703 1559 E-Mail: glennz@microsoft.com Calhoun, Zorn expires August 1999 [Page 8] ---LA_F2157795331R-6A-922117034=:26810NCE.IlHAFeR-- From owner-aaa-bof@merit.edu Mon Mar 22 10:58:33 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA21581 for ; Mon, 22 Mar 1999 10:58:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FD734443C; Mon, 22 Mar 1999 10:58:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6937B44441; Mon, 22 Mar 1999 10:58:25 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id B88A34443C for ; Mon, 22 Mar 1999 10:58:23 -0500 (EST) Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id QAA21898; Mon, 22 Mar 1999 16:51:02 +0100 (MET) From: Mikhail Smirnov Received: (mis@localhost) by dumbo.fokus.gmd.de (SMI-8.6/8.6.12) id QAA26264; Mon, 22 Mar 1999 16:50:59 +0100 Date: Mon, 22 Mar 1999 16:50:59 +0100 Message-Id: <199903221550.QAA26264@dumbo.fokus.gmd.de > To: aaa-wg@merit.edu, Pat.Calhoun@Eng.Sun.COM Subject: Re: ROAMOPS Authentication/Authorization Requirements ID Cc: smirnow@fokus.gmd.de X-Sun-Charset: US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon Mar 22 16:37:40 1999 Pat Calhoun wrote: > I am attaching the Internet Draft that Glen and I have put together. This > reflects the requirements for ROAMOPS for both Authentication and > Authorization, based on several Internet Drafts and RFCs that ROAMOPS have > produced. one of the requirements reads: - The AAA protocol MUST be "proxyable", meaning that a PDP MUST be able to forward the request to another PDP, which may or may not be within the same administrative domain. which might be too fuzzy (imho, almost any client server protocol is proxyable in soime sense). Do you mean that like in SIP 3 entities of AAA should be specified (client, server _and_ proxy) with explicit behaviour defined for each entity? Thanks Michael From owner-aaa-bof@merit.edu Mon Mar 22 11:37:57 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA22107 for ; Mon, 22 Mar 1999 11:37:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 75FA044441; Mon, 22 Mar 1999 11:37:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E59C44442; Mon, 22 Mar 1999 11:37:49 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0D2D644441 for ; Mon, 22 Mar 1999 11:37:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25814; Mon, 22 Mar 1999 08:37:39 -0800 (PST) Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.51.37]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with SMTP id IAA10374; Mon, 22 Mar 1999 08:37:33 -0800 (PST) Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06606; Mon, 22 Mar 1999 08:37:32 -0800 Date: Mon, 22 Mar 1999 08:37:39 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: ROAMOPS Authentication/Authorization Requirements ID To: Mikhail Smirnov Cc: aaa-wg@merit.edu, Pat.Calhoun@Eng.Sun.COM In-Reply-To: "Your message with ID" <199903221550.QAA26264@dumbo.fokus.gmd.de > Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > On Mon Mar 22 16:37:40 1999 Pat Calhoun wrote: > > > I am attaching the Internet Draft that Glen and I have put together. This > > reflects the requirements for ROAMOPS for both Authentication and > > Authorization, based on several Internet Drafts and RFCs that ROAMOPS have > > produced. > > one of the requirements reads: > > - The AAA protocol MUST be "proxyable", meaning that a PDP > MUST be able to forward the request to another PDP, which > may or may not be within the same administrative domain. > > which might be too fuzzy (imho, almost any client server protocol > is proxyable in soime sense). Do you mean that like in SIP 3 entities > of AAA should be specified (client, server _and_ proxy) with explicit > behaviour defined for each entity? Yes, that is correct. A proxy MAY perform additional authorization decisions, but I do not need to define those within the requirements specification. PatC From owner-aaa-bof@merit.edu Wed Mar 24 17:00:49 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA23681 for ; Wed, 24 Mar 1999 17:00:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D48F44435; Wed, 24 Mar 1999 17:00:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 82FF644434; Wed, 24 Mar 1999 17:00:32 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 29A2744430 for ; Wed, 24 Mar 1999 17:00:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00927; Wed, 24 Mar 1999 17:00:26 -0500 (EST) Message-Id: <199903242200.RAA00927@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-roamops-auth-req-00.txt Date: Wed, 24 Mar 1999 17:00:26 -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Roamops Authentication/Authorization Requirements Author(s) : P. Calhoun, G. Zorn Filename : draft-ietf-aaa-roamops-auth-req-00.txt Pages : 8 Date : 23-Mar-99 The AAA Working Group is currently looking at defining the requirements for Authentication and Authorization. This document contains the requirements for Roaming Operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-roamops-auth-req-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-roamops-auth-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-roamops-auth-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990323104408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-aaa-roamops-auth-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-aaa-roamops-auth-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990323104408.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Fri Mar 26 15:41:21 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA21741 for ; Fri, 26 Mar 1999 15:41:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A5B744460; Fri, 26 Mar 1999 15:41:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7FB9744458; Fri, 26 Mar 1999 15:41:05 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by segue.merit.edu (Postfix) with ESMTP id CE06144460 for ; Fri, 26 Mar 1999 15:39:46 -0500 (EST) Received: from murray (murray.lcp.livingston.com [158.222.8.15]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id MAA01921 for ; Fri, 26 Mar 1999 12:38:56 -0800 (PST) Message-Id: <3.0.6.32.19990326123621.00972100@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 26 Mar 1999 12:36:21 -0800 To: aaa-wg@merit.edu From: Brian Lloyd (by way of Brian Lloyd ) Subject: AAA subgroups Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul and I have been under the weather so we haven't gotten the minutes out as quickly as I would have liked. Our appologies. I did try to get the names and email addresses of the people for the various subgroups but the info came faster than I could enter it. I apologize profusely if I missed your name/address or if I got you in the wrong place. Here is the list I have. Please send me corrections and additions. Authentication: Michael Jeronimo Mark L. Stevens Stuart Jacobs Glen Zorn Accounting: Bernard Aboba Jari Arkko I. Gopal Iyengar Nenad Trifunovic Nevil Brownlee Authorization: John Volbrecht Bernard Aboba Pat Calhoun Francis Reichmeyer George Gross Lisa Lippert Stephen Farrell David Durham Shai Herzog Mark Beadles Bengt Ackzell ing. L.H.M. Gommans Sam Hartman Mobile IP: Stuart Jacobs Login Support and Content Services: Alex Latzko Siggy Maier Bandwidth Broker: Sue Hares David Durham Shai Herzog Remote Access: Dave Mitton Glenn Zorn Voice over IP: Pat Calhoun Ping Pan J. Rosenberg (get email address) Directory Services: Ellen Stokes From owner-aaa-bof@merit.edu Fri Mar 26 16:22:05 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA22084 for ; Fri, 26 Mar 1999 16:22:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 157AA44467; Fri, 26 Mar 1999 16:21:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EEC6544465; Fri, 26 Mar 1999 16:21:48 -0500 (EST) Received: from smtpott1.nortel.ca (smtpott1.NortelNetworks.com [192.58.194.78]) by segue.merit.edu (Postfix) with ESMTP id F0DF244463 for ; Fri, 26 Mar 1999 16:21:47 -0500 (EST) Received: from zcard00m.ca.nortel.com by smtpott1.nortel.ca; Fri, 26 Mar 1999 16:21:00 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 26 Mar 1999 16:20:01 -0500 Message-ID: <81D861463C3CD11185F30000F890796602B6AF75@nbdci472.ca.nortel.com> From: "Siggy Maier" To: "'aaa-wg@merit.edu'" Subject: add to mail list Date: Fri, 26 Mar 1999 16:20:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk From owner-aaa-bof@merit.edu Sat Mar 27 04:28:16 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id EAA27672 for ; Sat, 27 Mar 1999 04:28:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FAB24447A; Sat, 27 Mar 1999 04:26:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57AD74447C; Sat, 27 Mar 1999 04:26:26 -0500 (EST) Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by segue.merit.edu (Postfix) with ESMTP id 48D664447A for ; Sat, 27 Mar 1999 04:26:23 -0500 (EST) Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id BAA02919; Sat, 27 Mar 1999 01:26:14 -0800 (PST) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Sat, 27 Mar 1999 01:25:11 -0800 Message-ID: <81529AC9939FD211AC3F00A0C98938EB11A71F@orsmsx90.jf.intel.com> From: "Yavatkar, Raj" To: "'Brian Lloyd'" , aaa-wg@merit.edu Subject: RE: AAA subgroups Date: Fri, 26 Mar 1999 13:18:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I volunteered for Bandwidth Broker, but have not seen any email Raj -----Original Message----- From: Brian Lloyd [mailto:brian@lloyd.com] Sent: Friday, March 26, 1999 12:36 PM To: aaa-wg@merit.edu Subject: AAA subgroups Paul and I have been under the weather so we haven't gotten the minutes out as quickly as I would have liked. Our appologies. I did try to get the names and email addresses of the people for the various subgroups but the info came faster than I could enter it. I apologize profusely if I missed your name/address or if I got you in the wrong place. Here is the list I have. Please send me corrections and additions. Authentication: Michael Jeronimo Mark L. Stevens Stuart Jacobs Glen Zorn Accounting: Bernard Aboba Jari Arkko I. Gopal Iyengar Nenad Trifunovic Nevil Brownlee Authorization: John Volbrecht Bernard Aboba Pat Calhoun Francis Reichmeyer George Gross Lisa Lippert Stephen Farrell David Durham Shai Herzog Mark Beadles Bengt Ackzell ing. L.H.M. Gommans Sam Hartman Mobile IP: Stuart Jacobs Login Support and Content Services: Alex Latzko Siggy Maier Bandwidth Broker: Sue Hares David Durham Shai Herzog Remote Access: Dave Mitton Glenn Zorn Voice over IP: Pat Calhoun Ping Pan J. Rosenberg (get email address) Directory Services: Ellen Stokes From owner-aaa-bof@merit.edu Sun Mar 28 14:10:24 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA14474 for ; Sun, 28 Mar 1999 14:10:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2801844483; Sun, 28 Mar 1999 14:10:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC5F244482; Sun, 28 Mar 1999 14:10:10 -0500 (EST) Received: from idrp.merit.edu (idrp.merit.edu [198.108.60.89]) by segue.merit.edu (Postfix) with ESMTP id B518044480; Sun, 28 Mar 1999 14:10:09 -0500 (EST) Received: from localhost (skh@localhost) by idrp.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA03702; Sun, 28 Mar 1999 14:10:09 -0500 (EST) X-Authentication-Warning: idrp.merit.edu: skh owned process doing -bs Date: Sun, 28 Mar 1999 14:10:09 -0500 (EST) From: Susan Hares To: "Yavatkar, Raj" Cc: "'Brian Lloyd'" , aaa-wg@merit.edu Subject: RE: AAA subgroups In-Reply-To: <81529AC9939FD211AC3F00A0C98938EB11A71F@orsmsx90.jf.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Raj: I'm a bit behind in the email. I hope to get this out by next Thursday. Sue On Fri, 26 Mar 1999, Yavatkar, Raj wrote: > I volunteered for Bandwidth Broker, but have not seen any email > > Raj > > -----Original Message----- > From: Brian Lloyd [mailto:brian@lloyd.com] > Sent: Friday, March 26, 1999 12:36 PM > To: aaa-wg@merit.edu > Subject: AAA subgroups > > > Paul and I have been under the weather so we haven't gotten the minutes out > as quickly as I would have liked. Our appologies. > > I did try to get the names and email addresses of the people for the > various subgroups but the info came faster than I could enter it. I > apologize profusely if I missed your name/address or if I got you in the > wrong place. Here is the list I have. Please send me corrections and > additions. > > Authentication: > > Michael Jeronimo > Mark L. Stevens > Stuart Jacobs > Glen Zorn > > Accounting: > > Bernard Aboba > Jari Arkko > I. Gopal Iyengar > Nenad Trifunovic > Nevil Brownlee > > > Authorization: > > John Volbrecht > Bernard Aboba > Pat Calhoun > Francis Reichmeyer > George Gross > Lisa Lippert > Stephen Farrell > David Durham > Shai Herzog > Mark Beadles > Bengt Ackzell > ing. L.H.M. Gommans > Sam Hartman > > Mobile IP: > > Stuart Jacobs > > Login Support and Content Services: > > Alex Latzko > Siggy Maier > > Bandwidth Broker: > > Sue Hares > David Durham > Shai Herzog > > Remote Access: > > Dave Mitton > Glenn Zorn > > Voice over IP: > > Pat Calhoun > Ping Pan > J. Rosenberg (get email address) > > > Directory Services: > > Ellen Stokes > > > From owner-aaa-bof@merit.edu Wed Mar 31 10:30:07 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA08292 for ; Wed, 31 Mar 1999 10:30:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 774354443D; Tue, 30 Mar 1999 14:09:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5CFE144439; Tue, 30 Mar 1999 14:09:39 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by segue.merit.edu (Postfix) with ESMTP id 702D84443B for ; Tue, 30 Mar 1999 14:09:30 -0500 (EST) Received: from murray (murray.lcp.livingston.com [158.222.8.15]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id LAA29992 for ; Tue, 30 Mar 1999 11:09:29 -0800 (PST) Message-Id: <3.0.6.32.19990330110514.0094bb20@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 30 Mar 1999 11:05:14 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: AAA subgroups Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Below is an update to the subgroup lists. I have incorporated all the comments and requests I have received so far. I am somewhat concerned about the number of people in each group. When you get too many people there is often too much discussion and not enough writing. We need to narrow down to a small cadre of actual document writers for each of the subgroups. Remember, the first drafts are due in one month. It is better to write a straw-man document by the end of April that is partially incorrect than to wait for one that is 100% correct. Paul and I also want to know who will be the document authors/editors for each subgroup so that we know whose neck(s) to breathe down. Lastly, Paul and I would like to keep documents and their discussion within our group(s) for now and not submit them to the IETF for publication as drafts for now. The goal is to move quickly and limiting the number of people tends to make things move more quickly. We know that this is not the normal way of doing things but we have so much to get done that efficiency is very important. ------------------- Subgroups and Subgroup Participants: Authentication: Michael Jeronimo Mark L. Stevens Stuart Jacobs Glen Zorn Sudhakar Ramakrishna Thomas Hardjono Accounting: Bernard Aboba Jari Arkko Gopal Iyengar Nenad Trifunovic Nevil Brownlee Bob Natale Sudhakar Ramakrishna Matt Squire Carter Bullard Authorization: John Volbrecht Bernard Aboba Pat Calhoun Francis Reichmeyer George Gross Lisa Lippert Stephen Farrell David Durham Shai Herzog Mark Beadles Bengt Ackzell ing. L.H.M. Gommans Sam Hartman Matt Holdrege Thomas Hardjono Mobile IP: Stuart Jacobs Steven Glass Charles Perkins Tom Hiller Gopal Dommety Basavaraj Patil Sam Hartman Lance Olson Alex Latzko Siggy Maier Steve Hanna David Durham Shai Herzog Remote Access: Dave Mitton Glenn Zorn Matt Holdrege Voice over IP: Pat Calhoun Ping Pan J. Rosenberg (get email address) Leonid Yegoshin Sudhakar Ramakrishna Matt Holdrege Melinda Shore Directory Services: Ellen Stokes Jatinder Bali Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax O- From owner-aaa-bof@merit.edu Wed Mar 31 13:31:50 1999 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA10800 for ; Wed, 31 Mar 1999 13:31:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CC6944406; Wed, 31 Mar 1999 13:31:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5991744408; Wed, 31 Mar 1999 13:31:32 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by segue.merit.edu (Postfix) with ESMTP id 85C8944406 for ; Wed, 31 Mar 1999 13:31:24 -0500 (EST) Received: from murray (murray.lcp.livingston.com [158.222.8.15]) by hal.lcp.livingston.com (8.8.7/8.8.4) with SMTP id KAA09297 for ; Wed, 31 Mar 1999 10:29:04 -0800 (PST) Message-Id: <3.0.6.32.19990331101759.00995100@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 31 Mar 1999 10:17:59 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: AAA subgroups (another update) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Subgroups and Subgroup Participants: Authentication: Michael Jeronimo Mark L. Stevens Stuart Jacobs Glen Zorn Sudhakar Ramakrishna Thomas Hardjono Accounting: Bernard Aboba Jari Arkko Gopal Iyengar Nenad Trifunovic Nevil Brownlee Bob Natale Sudhakar Ramakrishna Matt Squire Carter Bullard Authorization: John Volbrecht Bernard Aboba Pat Calhoun Francis Reichmeyer George Gross Lisa Lippert Stephen Farrell David Durham Shai Herzog Mark Beadles Bengt Ackzell ing. L.H.M. Gommans Sam Hartman Matt Holdrege Thomas Hardjono Mobile IP: Stuart Jacobs Steven Glass Charles Perkins Tom Hiller Gopal Dommety Basavaraj Patil Sam Hartman Lance Olson Alex Latzko Siggy Maier Steve Hanna David Durham Shai Herzog Francis Reichmeyer Yavatkar, Raj Remote Access: Dave Mitton Glenn Zorn Matt Holdrege Yavatkar, Raj Voice over IP: Pat Calhoun Ping Pan J. Rosenberg (get email address) Leonid Yegoshin Sudhakar Ramakrishna Matt Holdrege Melinda Shore Directory Services: Ellen Stokes Jatinder Bali Brian Lloyd Lucent Technologies brian@lloyd.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6513 - voice +1.530.676.3442 - fax O-