From owner-aaa-wg@merit.edu Mon Feb 1 08:55:30 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id IAA13031 for ; Mon, 1 Feb 1999 08:55:30 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id IAA20358 for aaa-wg-outgoing; Mon, 1 Feb 1999 08:52:51 -0500 (EST) Received: from idrp.merit.edu (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.9.1a/8.9.1) with ESMTP id IAA20346; Mon, 1 Feb 1999 08:52:43 -0500 (EST) Received: from localhost by idrp.merit.edu (8.9.1a/8.9.1) with SMTP id IAA24056; Mon, 1 Feb 1999 08:52:42 -0500 (EST) X-Authentication-Warning: idrp.merit.edu: skh owned process doing -bs Date: Mon, 1 Feb 1999 08:52:42 -0500 (EST) From: Susan Hares To: "Yavatkar, Raj" cc: Basavaraj Patil , "'aaa-wg@merit.edu'" Subject: RE: Straw-person charter In-Reply-To: <7DAA70BEB463D211AC3E00A0C96B7AB2A64DDC@ORSMSX41> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Raj: Thank-you for the good feedback on the dates. As to the Requirement's document - We did some work as a BOF, and we have some text (drafty, draft text that I worked up with Fred.). I'm hoping with a "sub-group" that focus on the document we can get 2-3 revisions in prior to March. At that meeting, if it looks like we are not getting consensus, we have 6 weeks to obtain consensus on the mailing group prior to the end of April. As to the applications document, we had considerable presentations at the Aug IETF. I'm hoping we can capture that work. Other than existing work, I don't have pre-conceived notions. I hope we will have lively mail group discussion prior to IETF, and a strong meeting there. We'll can adjust the schedule if we really fall behind. Did I understand your concern. Sue Hares On Sun, 31 Jan 1999, Yavatkar, Raj wrote: > Hi Susan: > > Looking at your schedule for documents, I am really surprised. Given that WG > will meet for the first time in March, is it really realistic to have > documents done by April and still ensure a chance for everyone to > participate, contribute, and then reach decisions. I hope we are not coming > in with a pre-conceived notions on any of the documents. > > Please clarify > > Thanks > Raj > > -----Original Message----- > From: Susan Hares [mailto:skh@merit.edu] > Sent: Friday, January 29, 1999 3:59 PM > To: Basavaraj Patil > Cc: 'aaa-wg@merit.edu' > Subject: Re: Straw-person charter > > > > Do you have suggestions for rewording that sentence. Any help > gratefully accepted. > > Sue > > On Fri, 29 Jan 1999, Basavaraj Patil wrote: > > > > > > > > >From: skh@merit.edu > > >Sent: Thursday, January 28, 1999 10:42 AM > > >To: aaa-wg@merit.edu > > >Cc: skh@merit.edu > > >Subject: Straw-person charter > > > > > > > --- Snip Snip--- > > > > > >-------------- > > > > > > > > >AAA working group charter > > > > > >The Authentication, Authorization and Accounting working group will > > >focus on the specification of a general Authentication, > > >Authorization, and Accounting protocol for the Internet. > > >The purpose behind creating a general AAA protocol for the Internet is to > > create > > >a common base protocol for a number of specific AAA protocols which > include > > >IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server > AAA. > > > > >By creating a general base Protocol, the amount of work to create a > > >specific AAA protocols will be reduced. > > > > Mentioning the above applications as examples for supporting the need > > for a commmon base AAA protocol is good, but we do not want to > > necessarily limit the scope to just a few. Starting with the ones > > mentioned above will give a good and common set of requirements for > > the WG to focus on. The AAA protocol needs to be generic enough to > > support new and future applications. > > It's just a matter of how you say it in the charter and nothing more. > > > > -Basavaraj Patil > > > > > > > >The problem space for a general AAA working group contains > > >work in: > > > - determining the current set of specific applications > > > that the AAA will service, > > > - documenting requirements for a base AAA protocol, > > > - selecting a transport protocol or set of transport protocol to > > > be used by a general AAA protocol based on the requirements, > > > - selecting the framework for the AAA protocols, > > > - specifying the base AAA protocol, > > > - specifying the data formats for information contained > > > in the AAA protocol information for authentication, > > > authorization, and accounting. > > > > > > > Basavaraj Patil > > Wireless Technology Labs - Dept IP10 > > Nortel Networks, Richardson > > > * 972-684-1489 > > > > > > From owner-aaa-wg@merit.edu Mon Feb 1 12:31:01 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA15471 for ; Mon, 1 Feb 1999 12:31:01 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id MAA26123 for aaa-wg-outgoing; Mon, 1 Feb 1999 12:29:39 -0500 (EST) Received: from smtpott2.nortel.ca (smtpott2.NortelNetworks.com [192.58.194.80]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA26118; Mon, 1 Feb 1999 12:29:33 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtpott2.nortel.ca; Mon, 1 Feb 1999 12:28:54 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id ; Mon, 1 Feb 1999 12:28:48 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E52@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Susan Hares'" Cc: "'aaa-wg@merit.edu'" Subject: RE: Straw-person charter Date: Mon, 1 Feb 1999 12:28:37 -0500 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 Here's one suggestion: The Authentication, Authorization and Accounting (AAA) working group will focus on the specification of a general Authentication, Authorization, and Accounting protocol for the Internet. Most applications require some form or the other of Authentication, Authorization and, Accounting. Defining a general/common base protocol, which can be extended to meet the specific needs of an application, would reduce the effort to create specific protocols for new and existing applications. A common base protocol would also enhance interoperability. -Basavaraj Patil > -----Original Message----- > From: Susan Hares [SMTP:skh@merit.edu] > Sent: Friday, January 29, 1999 5:59 PM > To: Patil, Basavaraj [RICH2:IP10:EXCH] > Cc: 'aaa-wg@merit.edu' > Subject: Re: Straw-person charter > > > Do you have suggestions for rewording that sentence. Any help > gratefully accepted. > > Sue > > On Fri, 29 Jan 1999, Basavaraj Patil wrote: > > > > > > > > >From: skh@merit.edu > > >Sent: Thursday, January 28, 1999 10:42 AM > > >To: aaa-wg@merit.edu > > >Cc: skh@merit.edu > > >Subject: Straw-person charter > > > > > > > --- Snip Snip--- > > > > > >-------------- > > > > > > > > >AAA working group charter > > > > > >The Authentication, Authorization and Accounting working group will > > >focus on the specification of a general Authentication, > > >Authorization, and Accounting protocol for the Internet. > > >The purpose behind creating a general AAA protocol for the Internet is > to > > create > > >a common base protocol for a number of specific AAA protocols which > include > > >IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server > AAA. > > > > >By creating a general base Protocol, the amount of work to create a > > >specific AAA protocols will be reduced. > > > > Mentioning the above applications as examples for supporting the need > > for a commmon base AAA protocol is good, but we do not want to > > necessarily limit the scope to just a few. Starting with the ones > > mentioned above will give a good and common set of requirements for > > the WG to focus on. The AAA protocol needs to be generic enough to > > support new and future applications. > > It's just a matter of how you say it in the charter and nothing more. > > > > -Basavaraj Patil > > > > > > > >The problem space for a general AAA working group contains > > >work in: > > > - determining the current set of specific applications > > > that the AAA will service, > > > - documenting requirements for a base AAA protocol, > > > - selecting a transport protocol or set of transport protocol to > > > be used by a general AAA protocol based on the requirements, > > > - selecting the framework for the AAA protocols, > > > - specifying the base AAA protocol, > > > - specifying the data formats for information contained > > > in the AAA protocol information for authentication, > > > authorization, and accounting. > > > > > > > Basavaraj Patil > > Wireless Technology Labs - Dept IP10 > > Nortel Networks, Richardson > > > * 972-684-1489 > > > > > From owner-aaa-wg@merit.edu Mon Feb 1 18:06:58 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA21070 for ; Mon, 1 Feb 1999 18:06:56 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA05158 for aaa-wg-outgoing; Mon, 1 Feb 1999 18:04:57 -0500 (EST) Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA05148 for ; Mon, 1 Feb 1999 18:04:48 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by jindo.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA28970 for ; Mon, 1 Feb 1999 15:04:12 -0800 (PST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA26399 for ; Mon, 1 Feb 1999 15:04:30 -0800 (PST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id PAA19428 for ; Mon, 1 Feb 1999 15:04:11 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA26390 for ; Mon, 1 Feb 1999 15:04:28 -0800 (PST) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id PAA24178 for ; Mon, 1 Feb 1999 15:04:08 -0800 (PST) Received: from hal.lcp.livingston.com(158.222.8.12) by proxy3.cisco.com via smap (V2.0) id xma009886; Mon, 1 Feb 99 22:33:26 GMT X-SMAP-Received-From: outside 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 OAA07689 for ; Mon, 1 Feb 1999 14:04:42 -0800 (PST) Message-Id: <3.0.6.32.19990201135851.009288c0@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 01 Feb 1999 13:58:51 -0800 To: ietf-aaa@external.cisco.com From: Brian Lloyd Subject: back to basics Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk There is so much flying around about AAA protocols, transport protocols, etc., that I am having trouble getting focused on the problem. The one thing that became very clear to me at the end of the BOF (when Sue got pelted with apparently irrelevant questions out of left field) is that nothing is very clear to me, and probably not clear to a lot of people. I think that, at least for me, the problem is that some of us are talking about specific protocol solutions for a subset of known problems, some of us are talking about the underlying schema for the metadata, and some of us are talking about transport. The latter is getting a LOT of discussion because, hey, we don't know jack about triple-A but we sure as heck know a lot about transport protocols. :^) I *really* want to go back to ground-zero and talk about the *problem* we are trying to solve. I don't even want to start talking about the requirements or the solution until there is some consensus that we understand the problem and can share a common (and meaningful) lexicon. I plan to write the equivalent of a white paper that attempts to define the problem space. My missive will probably be incomplete and, in places, incoherent because it will represent, to some extent, my own stream-of-conciousness as I think about the problem. On the other hand, comments and input from the rest of you will greatly help to focus things with the end goal being a global understanding of the problem and of previous and current approaches to solving some or all of the problem before us. I. The Authorization/Configuration "Big Picture" As I examine what I belive to be the "big picture" I see lots of overlap with other areas. First, we have somthing that is defining "services" (for want of a more specific word) that may be delivered by the network to a device or a user. Examples of services include but are not limited to: * dial-up remote access to the network; * access to and configuration of a mail server; * access to and configuration of a web server; * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; * setting up tunnels for security (IPSEC); * FTP server access; * TELNET server access; * combinations of the above. I could probably think of more if I spent any time at it. The key question here is: how do we desribe these services to the network devices so that they can deliver these services. This strikes me as falling into the catagories of service provisioning and policy. I can see our AAA protocols delivering session configuration for each instance of service. (Yes, I said "protocol*s*" plural since we already have a couple in regular use and I don't think they are going to go away. Think RADIUS, Diameter, COPS, LDAP, etc.) So I think we need to spend a little time determining how configuration information is to be delivered to multiple systems possibly using multiple protocols. As I see it, a service instance might not be viewed as an atomic transaction as far as authorization/configuration is concerned. If we don't think about this up front, whatever we cook up might not prove to be a general solution. This means to me that we need to talk about universal internal data representation for directories and databases so that we can agree on the sematics of the data stored there. II. Authentication This part of what we are doing is probably the best understood. We want some way of verifying that an entity is the entity it claims to be. We have a number of methods of doing this. So where is authentication WG in this? What is the story with CAT? Where does it fit in here? Should we even do anything besides figuring out how to integrate other authentication protocols with the authorization protocols? III. Accounting Frankly I don't think we are going to end up with a single protocol here either. There are two types of "accounting" data that comes immediately to my mind as I write this. The first is very timely and is used to propagate session state information in real time so that we can use it to make authorization decisions on the fly. The second is used to produce reports for billing and settlement purposes. The latter need not propagate in real-time. Collect it up and send it out in batches when convenient. These two types of data might not propagate using the same protocols but then again, they might. IV. What we don't need to talk about The discussion of TCP vs. UDP is a waste of time right now. I believe that, once we figure out what data is getting pushed around and when, the proper underlying transport layer for a particular application will become fairly obvious. So, please throw rocks at my comments above. I certainly don't claim omniscience. 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-wg@merit.edu Mon Feb 1 20:24:19 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA22197 for ; Mon, 1 Feb 1999 20:24:18 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA08678 for aaa-wg-outgoing; Mon, 1 Feb 1999 20:23:33 -0500 (EST) Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA08674 for ; Mon, 1 Feb 1999 20:23:28 -0500 (EST) Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) 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 BAA08603; Tue, 2 Feb 1999 01:19:34 GMT Received: by FMSMSX27 with Internet Mail Service (5.5.2232.9) id <1DMBSBGQ>; Mon, 1 Feb 1999 17:19:34 -0800 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B513301B0F3FD@FMSMSX37> From: "Durham, David" To: "'Brian Lloyd'" , ietf-aaa@external.cisco.com Cc: aaa-wg@merit.edu Subject: RE: back to basics Date: Mon, 1 Feb 1999 17:19:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I absolutely agree that we must first figure out what we are talking about (in AAA) and then move onto the details. It is a waste of time to dive into protocols this soon, so I am looking forward to reading Brian's white paper. BTW, given the confusion surrounding AAA right now, the current charter seems far too aggressive in its goals. I would like to see the first 2 WG sessions & drafts to be devoted to clearly explaining the problem set. Once this known, we can start mixing and matching protocols, schemas, Directories, MIBs and what have you. Why are we looking for a solution before we have even clearly defined the problem? my 2 cents, -Dave PS. We should start by getting the mail server right, I'm still counting 2 AAA lists! > -----Original Message----- > From: Brian Lloyd [SMTP:brian@lloyd.com] > Sent: Monday, February 01, 1999 1:59 PM > To: ietf-aaa@external.cisco.com > Subject: back to basics > > There is so much flying around about AAA protocols, transport protocols, > etc., that I am having trouble getting focused on the problem. The one > thing that became very clear to me at the end of the BOF (when Sue got > pelted with apparently irrelevant questions out of left field) is that > nothing is very clear to me, and probably not clear to a lot of people. > > I think that, at least for me, the problem is that some of us are talking > about specific protocol solutions for a subset of known problems, some of > us are talking about the underlying schema for the metadata, and some of > us > are talking about transport. The latter is getting a LOT of discussion > because, hey, we don't know jack about triple-A but we sure as heck know a > lot about transport protocols. :^) > > I *really* want to go back to ground-zero and talk about the *problem* we > are trying to solve. I don't even want to start talking about the > requirements or the solution until there is some consensus that we > understand the problem and can share a common (and meaningful) lexicon. > > I plan to write the equivalent of a white paper that attempts to define > the > problem space. My missive will probably be incomplete and, in places, > incoherent because it will represent, to some extent, my own > stream-of-conciousness as I think about the problem. On the other hand, > comments and input from the rest of you will greatly help to focus things > with the end goal being a global understanding of the problem and of > previous and current approaches to solving some or all of the problem > before us. > > I. The Authorization/Configuration "Big Picture" > > As I examine what I belive to be the "big picture" I see lots of overlap > with other areas. First, we have somthing that is defining "services" > (for > want of a more specific word) that may be delivered by the network to a > device or a user. Examples of services include but are not limited to: > > * dial-up remote access to the network; > * access to and configuration of a mail server; > * access to and configuration of a web server; > * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; > * setting up tunnels for security (IPSEC); > * FTP server access; > * TELNET server access; > * combinations of the above. > > I could probably think of more if I spent any time at it. The key > question > here is: how do we desribe these services to the network devices so that > they can deliver these services. This strikes me as falling into the > catagories of service provisioning and policy. I can see our AAA > protocols > delivering session configuration for each instance of service. (Yes, I > said "protocol*s*" plural since we already have a couple in regular use > and > I don't think they are going to go away. Think RADIUS, Diameter, COPS, > LDAP, etc.) So I think we need to spend a little time determining how > configuration information is to be delivered to multiple systems possibly > using multiple protocols. As I see it, a service instance might not be > viewed as an atomic transaction as far as authorization/configuration is > concerned. If we don't think about this up front, whatever we cook up > might not prove to be a general solution. This means to me that we need > to > talk about universal internal data representation for directories and > databases so that we can agree on the sematics of the data stored there. > > II. Authentication > > This part of what we are doing is probably the best understood. We want > some way of verifying that an entity is the entity it claims to be. We > have a number of methods of doing this. > > So where is authentication WG in this? What is the story with CAT? Where > does it fit in here? Should we even do anything besides figuring out how > to integrate other authentication protocols with the authorization > protocols? > > III. Accounting > > Frankly I don't think we are going to end up with a single protocol here > either. There are two types of "accounting" data that comes immediately > to > my mind as I write this. The first is very timely and is used to > propagate > session state information in real time so that we can use it to make > authorization decisions on the fly. The second is used to produce reports > for billing and settlement purposes. The latter need not propagate in > real-time. Collect it up and send it out in batches when convenient. > > These two types of data might not propagate using the same protocols but > then again, they might. > > IV. What we don't need to talk about > > The discussion of TCP vs. UDP is a waste of time right now. I believe > that, once we figure out what data is getting pushed around and when, the > proper underlying transport layer for a particular application will become > fairly obvious. > > So, please throw rocks at my comments above. I certainly don't claim > omniscience. > > > 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-wg@merit.edu Mon Feb 1 20:35:41 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA22359 for ; Mon, 1 Feb 1999 20:35:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA08797 for aaa-wg-outgoing; Mon, 1 Feb 1999 20:35:31 -0500 (EST) Received: from quisp.cisco.com (quisp.cisco.com [171.69.95.82]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA08793 for ; Mon, 1 Feb 1999 20:35:26 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by quisp.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id RAA15100 for ; Mon, 1 Feb 1999 17:34:53 -0800 (PST) Received: from beasley.cisco.com (beasley.cisco.com [171.69.11.49]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA26260 for ; Mon, 1 Feb 1999 17:35:12 -0800 (PST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by beasley.cisco.com (8.8.8/2.6/Cisco List Logging/CISCO.GATE.1.1) with ESMTP id RAA23500 for ; Mon, 1 Feb 1999 17:34:52 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA16677 for ; Mon, 1 Feb 1999 18:03:18 -0800 (PST) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id RAA05775 for ; Mon, 1 Feb 1999 17:34:44 -0800 (PST) Received: from calliope1.fm.intel.com(132.233.247.10) by proxy3.cisco.com via smap (V2.0) id xma029915; Tue, 2 Feb 99 01:23:26 GMT X-SMAP-Received-From: outside Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) 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 BAA08603; Tue, 2 Feb 1999 01:19:34 GMT Received: by FMSMSX27 with Internet Mail Service (5.5.2232.9) id <1DMBSBGQ>; Mon, 1 Feb 1999 17:19:34 -0800 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B513301B0F3FD@FMSMSX37> From: "Durham, David" To: "'Brian Lloyd'" , ietf-aaa@external.cisco.com Cc: aaa-wg@merit.edu Subject: RE: back to basics Date: Mon, 1 Feb 1999 17:19:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I absolutely agree that we must first figure out what we are talking about (in AAA) and then move onto the details. It is a waste of time to dive into protocols this soon, so I am looking forward to reading Brian's white paper. BTW, given the confusion surrounding AAA right now, the current charter seems far too aggressive in its goals. I would like to see the first 2 WG sessions & drafts to be devoted to clearly explaining the problem set. Once this known, we can start mixing and matching protocols, schemas, Directories, MIBs and what have you. Why are we looking for a solution before we have even clearly defined the problem? my 2 cents, -Dave PS. We should start by getting the mail server right, I'm still counting 2 AAA lists! > -----Original Message----- > From: Brian Lloyd [SMTP:brian@lloyd.com] > Sent: Monday, February 01, 1999 1:59 PM > To: ietf-aaa@external.cisco.com > Subject: back to basics > > There is so much flying around about AAA protocols, transport protocols, > etc., that I am having trouble getting focused on the problem. The one > thing that became very clear to me at the end of the BOF (when Sue got > pelted with apparently irrelevant questions out of left field) is that > nothing is very clear to me, and probably not clear to a lot of people. > > I think that, at least for me, the problem is that some of us are talking > about specific protocol solutions for a subset of known problems, some of > us are talking about the underlying schema for the metadata, and some of > us > are talking about transport. The latter is getting a LOT of discussion > because, hey, we don't know jack about triple-A but we sure as heck know a > lot about transport protocols. :^) > > I *really* want to go back to ground-zero and talk about the *problem* we > are trying to solve. I don't even want to start talking about the > requirements or the solution until there is some consensus that we > understand the problem and can share a common (and meaningful) lexicon. > > I plan to write the equivalent of a white paper that attempts to define > the > problem space. My missive will probably be incomplete and, in places, > incoherent because it will represent, to some extent, my own > stream-of-conciousness as I think about the problem. On the other hand, > comments and input from the rest of you will greatly help to focus things > with the end goal being a global understanding of the problem and of > previous and current approaches to solving some or all of the problem > before us. > > I. The Authorization/Configuration "Big Picture" > > As I examine what I belive to be the "big picture" I see lots of overlap > with other areas. First, we have somthing that is defining "services" > (for > want of a more specific word) that may be delivered by the network to a > device or a user. Examples of services include but are not limited to: > > * dial-up remote access to the network; > * access to and configuration of a mail server; > * access to and configuration of a web server; > * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; > * setting up tunnels for security (IPSEC); > * FTP server access; > * TELNET server access; > * combinations of the above. > > I could probably think of more if I spent any time at it. The key > question > here is: how do we desribe these services to the network devices so that > they can deliver these services. This strikes me as falling into the > catagories of service provisioning and policy. I can see our AAA > protocols > delivering session configuration for each instance of service. (Yes, I > said "protocol*s*" plural since we already have a couple in regular use > and > I don't think they are going to go away. Think RADIUS, Diameter, COPS, > LDAP, etc.) So I think we need to spend a little time determining how > configuration information is to be delivered to multiple systems possibly > using multiple protocols. As I see it, a service instance might not be > viewed as an atomic transaction as far as authorization/configuration is > concerned. If we don't think about this up front, whatever we cook up > might not prove to be a general solution. This means to me that we need > to > talk about universal internal data representation for directories and > databases so that we can agree on the sematics of the data stored there. > > II. Authentication > > This part of what we are doing is probably the best understood. We want > some way of verifying that an entity is the entity it claims to be. We > have a number of methods of doing this. > > So where is authentication WG in this? What is the story with CAT? Where > does it fit in here? Should we even do anything besides figuring out how > to integrate other authentication protocols with the authorization > protocols? > > III. Accounting > > Frankly I don't think we are going to end up with a single protocol here > either. There are two types of "accounting" data that comes immediately > to > my mind as I write this. The first is very timely and is used to > propagate > session state information in real time so that we can use it to make > authorization decisions on the fly. The second is used to produce reports > for billing and settlement purposes. The latter need not propagate in > real-time. Collect it up and send it out in batches when convenient. > > These two types of data might not propagate using the same protocols but > then again, they might. > > IV. What we don't need to talk about > > The discussion of TCP vs. UDP is a waste of time right now. I believe > that, once we figure out what data is getting pushed around and when, the > proper underlying transport layer for a particular application will become > fairly obvious. > > So, please throw rocks at my comments above. I certainly don't claim > omniscience. > > > 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-wg@merit.edu Mon Feb 1 22:16:11 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id WAA23176 for ; Mon, 1 Feb 1999 22:16:11 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id WAA09947 for aaa-wg-outgoing; Mon, 1 Feb 1999 22:15:52 -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 WAA09943 for ; Mon, 1 Feb 1999 22:15:47 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA20487; Mon, 1 Feb 1999 19:04:46 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpkb.Eng.Sun.COM [129.146.65.38]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA09365; Mon, 1 Feb 1999 19:04:46 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA22795; Mon, 1 Feb 1999 19:04:30 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902020304.TAA22795@hsmpka.eng.sun.com> Date: Mon, 1 Feb 1999 19:01:43 -0800 To: "Durham, David" , , "'Brian Lloyd'" Cc: Reply-To: Subject: RE: back to basics 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 absolutely agree that we must first figure out what we are >talking about (in AAA) and then move onto the details. It is >a waste of time to dive into protocols this soon, so I am >looking forward to reading Brian's white paper. > >BTW, given the confusion surrounding AAA >right now, the current charter seems far too aggressive in >its goals. I would like to see the first 2 WG sessions & drafts >to be devoted to clearly explaining the problem set. Once >this known, we can start mixing and matching protocols, >schemas, Directories, MIBs and what have you. Why are we >looking for a solution before we have even clearly defined >the problem? The correct one for the (soon-to-be) WG is aaa-wg@merit.edu. PatC > >my 2 cents, > >-Dave > >PS. We should start by getting the mail server right, I'm still >counting 2 AAA lists! > >> -----Original Message----- >> From: Brian Lloyd [SMTP:brian@lloyd.com] >> Sent: Monday, February 01, 1999 1:59 PM >> To: ietf-aaa@external.cisco.com >> Subject: back to basics >> >> There is so much flying around about AAA protocols, transport protocols, >> etc., that I am having trouble getting focused on the problem. The one >> thing that became very clear to me at the end of the BOF (when Sue got >> pelted with apparently irrelevant questions out of left field) is that >> nothing is very clear to me, and probably not clear to a lot of people. >> >> I think that, at least for me, the problem is that some of us are talking >> about specific protocol solutions for a subset of known problems, some of >> us are talking about the underlying schema for the metadata, and some of >> us >> are talking about transport. The latter is getting a LOT of discussion >> because, hey, we don't know jack about triple-A but we sure as heck know a >> lot about transport protocols. :^) >> >> I *really* want to go back to ground-zero and talk about the *problem* we >> are trying to solve. I don't even want to start talking about the >> requirements or the solution until there is some consensus that we >> understand the problem and can share a common (and meaningful) lexicon. >> >> I plan to write the equivalent of a white paper that attempts to define >> the >> problem space. My missive will probably be incomplete and, in places, >> incoherent because it will represent, to some extent, my own >> stream-of-conciousness as I think about the problem. On the other hand, >> comments and input from the rest of you will greatly help to focus things >> with the end goal being a global understanding of the problem and of >> previous and current approaches to solving some or all of the problem >> before us. >> >> I. The Authorization/Configuration "Big Picture" >> >> As I examine what I belive to be the "big picture" I see lots of overlap >> with other areas. First, we have somthing that is defining "services" >> (for >> want of a more specific word) that may be delivered by the network to a >> device or a user. Examples of services include but are not limited to: >> >> * dial-up remote access to the network; >> * access to and configuration of a mail server; >> * access to and configuration of a web server; >> * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >> * setting up tunnels for security (IPSEC); >> * FTP server access; >> * TELNET server access; >> * combinations of the above. >> >> I could probably think of more if I spent any time at it. The key >> question >> here is: how do we desribe these services to the network devices so that >> they can deliver these services. This strikes me as falling into the >> catagories of service provisioning and policy. I can see our AAA >> protocols >> delivering session configuration for each instance of service. (Yes, I >> said "protocol*s*" plural since we already have a couple in regular use >> and >> I don't think they are going to go away. Think RADIUS, Diameter, COPS, >> LDAP, etc.) So I think we need to spend a little time determining how >> configuration information is to be delivered to multiple systems possibly >> using multiple protocols. As I see it, a service instance might not be >> viewed as an atomic transaction as far as authorization/configuration is >> concerned. If we don't think about this up front, whatever we cook up >> might not prove to be a general solution. This means to me that we need >> to >> talk about universal internal data representation for directories and >> databases so that we can agree on the sematics of the data stored there. >> >> II. Authentication >> >> This part of what we are doing is probably the best understood. We want >> some way of verifying that an entity is the entity it claims to be. We >> have a number of methods of doing this. >> >> So where is authentication WG in this? What is the story with CAT? Where >> does it fit in here? Should we even do anything besides figuring out how >> to integrate other authentication protocols with the authorization >> protocols? >> >> III. Accounting >> >> Frankly I don't think we are going to end up with a single protocol here >> either. There are two types of "accounting" data that comes immediately >> to >> my mind as I write this. The first is very timely and is used to >> propagate >> session state information in real time so that we can use it to make >> authorization decisions on the fly. The second is used to produce reports >> for billing and settlement purposes. The latter need not propagate in >> real-time. Collect it up and send it out in batches when convenient. >> >> These two types of data might not propagate using the same protocols but >> then again, they might. >> >> IV. What we don't need to talk about >> >> The discussion of TCP vs. UDP is a waste of time right now. I believe >> that, once we figure out what data is getting pushed around and when, the >> proper underlying transport layer for a particular application will become >> fairly obvious. >> >> So, please throw rocks at my comments above. I certainly don't claim >> omniscience. >> >> >> 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-wg@merit.edu Mon Feb 1 22:16:20 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id WAA23182 for ; Mon, 1 Feb 1999 22:16:20 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id WAA09941 for aaa-wg-outgoing; Mon, 1 Feb 1999 22:15:29 -0500 (EST) Received: from stars.cisco.com (stars.cisco.com [171.71.112.28]) by merit.edu (8.9.1a/8.9.1) with ESMTP id WAA09937 for ; Mon, 1 Feb 1999 22:15:24 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by stars.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id TAA24246 for ; Mon, 1 Feb 1999 19:14:52 -0800 (PST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA08680 for ; Mon, 1 Feb 1999 19:15:11 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id TAA00222 for ; Mon, 1 Feb 1999 19:14:51 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA04868 for ; Mon, 1 Feb 1999 19:15:02 -0800 (PST) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id TAA13506 for ; Mon, 1 Feb 1999 19:14:50 -0800 (PST) Received: from mercury.sun.com(192.9.25.1) by proxy2.cisco.com via smap (V2.0) id xma013488; Tue, 2 Feb 99 03:14:44 GMT X-SMAP-Received-From: outside Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA20487; Mon, 1 Feb 1999 19:04:46 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpkb.Eng.Sun.COM [129.146.65.38]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA09365; Mon, 1 Feb 1999 19:04:46 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA22795; Mon, 1 Feb 1999 19:04:30 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902020304.TAA22795@hsmpka.eng.sun.com> Date: Mon, 1 Feb 1999 19:01:43 -0800 To: "Durham, David" , , "'Brian Lloyd'" Cc: Reply-To: Subject: RE: back to basics 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 absolutely agree that we must first figure out what we are >talking about (in AAA) and then move onto the details. It is >a waste of time to dive into protocols this soon, so I am >looking forward to reading Brian's white paper. > >BTW, given the confusion surrounding AAA >right now, the current charter seems far too aggressive in >its goals. I would like to see the first 2 WG sessions & drafts >to be devoted to clearly explaining the problem set. Once >this known, we can start mixing and matching protocols, >schemas, Directories, MIBs and what have you. Why are we >looking for a solution before we have even clearly defined >the problem? The correct one for the (soon-to-be) WG is aaa-wg@merit.edu. PatC > >my 2 cents, > >-Dave > >PS. We should start by getting the mail server right, I'm still >counting 2 AAA lists! > >> -----Original Message----- >> From: Brian Lloyd [SMTP:brian@lloyd.com] >> Sent: Monday, February 01, 1999 1:59 PM >> To: ietf-aaa@external.cisco.com >> Subject: back to basics >> >> There is so much flying around about AAA protocols, transport protocols, >> etc., that I am having trouble getting focused on the problem. The one >> thing that became very clear to me at the end of the BOF (when Sue got >> pelted with apparently irrelevant questions out of left field) is that >> nothing is very clear to me, and probably not clear to a lot of people. >> >> I think that, at least for me, the problem is that some of us are talking >> about specific protocol solutions for a subset of known problems, some of >> us are talking about the underlying schema for the metadata, and some of >> us >> are talking about transport. The latter is getting a LOT of discussion >> because, hey, we don't know jack about triple-A but we sure as heck know a >> lot about transport protocols. :^) >> >> I *really* want to go back to ground-zero and talk about the *problem* we >> are trying to solve. I don't even want to start talking about the >> requirements or the solution until there is some consensus that we >> understand the problem and can share a common (and meaningful) lexicon. >> >> I plan to write the equivalent of a white paper that attempts to define >> the >> problem space. My missive will probably be incomplete and, in places, >> incoherent because it will represent, to some extent, my own >> stream-of-conciousness as I think about the problem. On the other hand, >> comments and input from the rest of you will greatly help to focus things >> with the end goal being a global understanding of the problem and of >> previous and current approaches to solving some or all of the problem >> before us. >> >> I. The Authorization/Configuration "Big Picture" >> >> As I examine what I belive to be the "big picture" I see lots of overlap >> with other areas. First, we have somthing that is defining "services" >> (for >> want of a more specific word) that may be delivered by the network to a >> device or a user. Examples of services include but are not limited to: >> >> * dial-up remote access to the network; >> * access to and configuration of a mail server; >> * access to and configuration of a web server; >> * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >> * setting up tunnels for security (IPSEC); >> * FTP server access; >> * TELNET server access; >> * combinations of the above. >> >> I could probably think of more if I spent any time at it. The key >> question >> here is: how do we desribe these services to the network devices so that >> they can deliver these services. This strikes me as falling into the >> catagories of service provisioning and policy. I can see our AAA >> protocols >> delivering session configuration for each instance of service. (Yes, I >> said "protocol*s*" plural since we already have a couple in regular use >> and >> I don't think they are going to go away. Think RADIUS, Diameter, COPS, >> LDAP, etc.) So I think we need to spend a little time determining how >> configuration information is to be delivered to multiple systems possibly >> using multiple protocols. As I see it, a service instance might not be >> viewed as an atomic transaction as far as authorization/configuration is >> concerned. If we don't think about this up front, whatever we cook up >> might not prove to be a general solution. This means to me that we need >> to >> talk about universal internal data representation for directories and >> databases so that we can agree on the sematics of the data stored there. >> >> II. Authentication >> >> This part of what we are doing is probably the best understood. We want >> some way of verifying that an entity is the entity it claims to be. We >> have a number of methods of doing this. >> >> So where is authentication WG in this? What is the story with CAT? Where >> does it fit in here? Should we even do anything besides figuring out how >> to integrate other authentication protocols with the authorization >> protocols? >> >> III. Accounting >> >> Frankly I don't think we are going to end up with a single protocol here >> either. There are two types of "accounting" data that comes immediately >> to >> my mind as I write this. The first is very timely and is used to >> propagate >> session state information in real time so that we can use it to make >> authorization decisions on the fly. The second is used to produce reports >> for billing and settlement purposes. The latter need not propagate in >> real-time. Collect it up and send it out in batches when convenient. >> >> These two types of data might not propagate using the same protocols but >> then again, they might. >> >> IV. What we don't need to talk about >> >> The discussion of TCP vs. UDP is a waste of time right now. I believe >> that, once we figure out what data is getting pushed around and when, the >> proper underlying transport layer for a particular application will become >> fairly obvious. >> >> So, please throw rocks at my comments above. I certainly don't claim >> omniscience. >> >> >> 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-wg@merit.edu Tue Feb 2 01:26:12 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id BAA24512 for ; Tue, 2 Feb 1999 01:26:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA12409 for aaa-wg-outgoing; Tue, 2 Feb 1999 01:25:46 -0500 (EST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA12405 for ; Tue, 2 Feb 1999 01:25:42 -0500 (EST) Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.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 GAA01572; Tue, 2 Feb 1999 06:21:36 GMT Received: by ORSMSX28 with Internet Mail Service (5.5.2232.9) id <1C1YHKKT>; Mon, 1 Feb 1999 22:21:35 -0800 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB2A8F6DA@ORSMSX41> From: "Yavatkar, Raj" To: "'Pat.Calhoun@eng.sun.com'" , "Durham, David" , ietf-aaa@external.cisco.com, "'Brian Lloyd'" Cc: aaa-wg@merit.edu Subject: RE: back to basics Date: Mon, 1 Feb 1999 22:21:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree with Brian. I sent a similar message to the "right address" last week, but haven't seen it reflected. I think some people seem to have made up their mind about what docs to produce by April, etc. However, in a true IETF spirit, we should have an open process with problem space and framework first defined and agreed upon before jumping to conclusions Fred, Sue, comments? Raj -----Original Message----- From: Pat.Calhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] Sent: Monday, February 01, 1999 7:02 PM To: Durham, David; ietf-aaa@external.cisco.com; 'Brian Lloyd' Cc: aaa-wg@merit.edu Subject: RE: back to basics >I absolutely agree that we must first figure out what we are >talking about (in AAA) and then move onto the details. It is >a waste of time to dive into protocols this soon, so I am >looking forward to reading Brian's white paper. > >BTW, given the confusion surrounding AAA >right now, the current charter seems far too aggressive in >its goals. I would like to see the first 2 WG sessions & drafts >to be devoted to clearly explaining the problem set. Once >this known, we can start mixing and matching protocols, >schemas, Directories, MIBs and what have you. Why are we >looking for a solution before we have even clearly defined >the problem? The correct one for the (soon-to-be) WG is aaa-wg@merit.edu. PatC > >my 2 cents, > >-Dave > >PS. We should start by getting the mail server right, I'm still >counting 2 AAA lists! > >> -----Original Message----- >> From: Brian Lloyd [SMTP:brian@lloyd.com] >> Sent: Monday, February 01, 1999 1:59 PM >> To: ietf-aaa@external.cisco.com >> Subject: back to basics >> >> There is so much flying around about AAA protocols, transport protocols, >> etc., that I am having trouble getting focused on the problem. The one >> thing that became very clear to me at the end of the BOF (when Sue got >> pelted with apparently irrelevant questions out of left field) is that >> nothing is very clear to me, and probably not clear to a lot of people. >> >> I think that, at least for me, the problem is that some of us are talking >> about specific protocol solutions for a subset of known problems, some of >> us are talking about the underlying schema for the metadata, and some of >> us >> are talking about transport. The latter is getting a LOT of discussion >> because, hey, we don't know jack about triple-A but we sure as heck know a >> lot about transport protocols. :^) >> >> I *really* want to go back to ground-zero and talk about the *problem* we >> are trying to solve. I don't even want to start talking about the >> requirements or the solution until there is some consensus that we >> understand the problem and can share a common (and meaningful) lexicon. >> >> I plan to write the equivalent of a white paper that attempts to define >> the >> problem space. My missive will probably be incomplete and, in places, >> incoherent because it will represent, to some extent, my own >> stream-of-conciousness as I think about the problem. On the other hand, >> comments and input from the rest of you will greatly help to focus things >> with the end goal being a global understanding of the problem and of >> previous and current approaches to solving some or all of the problem >> before us. >> >> I. The Authorization/Configuration "Big Picture" >> >> As I examine what I belive to be the "big picture" I see lots of overlap >> with other areas. First, we have somthing that is defining "services" >> (for >> want of a more specific word) that may be delivered by the network to a >> device or a user. Examples of services include but are not limited to: >> >> * dial-up remote access to the network; >> * access to and configuration of a mail server; >> * access to and configuration of a web server; >> * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >> * setting up tunnels for security (IPSEC); >> * FTP server access; >> * TELNET server access; >> * combinations of the above. >> >> I could probably think of more if I spent any time at it. The key >> question >> here is: how do we desribe these services to the network devices so that >> they can deliver these services. This strikes me as falling into the >> catagories of service provisioning and policy. I can see our AAA >> protocols >> delivering session configuration for each instance of service. (Yes, I >> said "protocol*s*" plural since we already have a couple in regular use >> and >> I don't think they are going to go away. Think RADIUS, Diameter, COPS, >> LDAP, etc.) So I think we need to spend a little time determining how >> configuration information is to be delivered to multiple systems possibly >> using multiple protocols. As I see it, a service instance might not be >> viewed as an atomic transaction as far as authorization/configuration is >> concerned. If we don't think about this up front, whatever we cook up >> might not prove to be a general solution. This means to me that we need >> to >> talk about universal internal data representation for directories and >> databases so that we can agree on the sematics of the data stored there. >> >> II. Authentication >> >> This part of what we are doing is probably the best understood. We want >> some way of verifying that an entity is the entity it claims to be. We >> have a number of methods of doing this. >> >> So where is authentication WG in this? What is the story with CAT? Where >> does it fit in here? Should we even do anything besides figuring out how >> to integrate other authentication protocols with the authorization >> protocols? >> >> III. Accounting >> >> Frankly I don't think we are going to end up with a single protocol here >> either. There are two types of "accounting" data that comes immediately >> to >> my mind as I write this. The first is very timely and is used to >> propagate >> session state information in real time so that we can use it to make >> authorization decisions on the fly. The second is used to produce reports >> for billing and settlement purposes. The latter need not propagate in >> real-time. Collect it up and send it out in batches when convenient. >> >> These two types of data might not propagate using the same protocols but >> then again, they might. >> >> IV. What we don't need to talk about >> >> The discussion of TCP vs. UDP is a waste of time right now. I believe >> that, once we figure out what data is getting pushed around and when, the >> proper underlying transport layer for a particular application will become >> fairly obvious. >> >> So, please throw rocks at my comments above. I certainly don't claim >> omniscience. >> >> >> 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-wg@merit.edu Tue Feb 2 01:26:14 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id BAA24519 for ; Tue, 2 Feb 1999 01:26:14 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA12414 for aaa-wg-outgoing; Tue, 2 Feb 1999 01:26:07 -0500 (EST) Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22]) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA12410 for ; Tue, 2 Feb 1999 01:26:01 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by jindo.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA15308 for ; Mon, 1 Feb 1999 22:25:29 -0800 (PST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id WAA28711 for ; Mon, 1 Feb 1999 22:25:48 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id WAA03118 for ; Mon, 1 Feb 1999 22:25:28 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id WAA25188 for ; Mon, 1 Feb 1999 22:25:38 -0800 (PST) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id WAA24299 for ; Mon, 1 Feb 1999 22:25:24 -0800 (PST) Received: from ganymede.or.intel.com(134.134.248.3) by proxy3.cisco.com via smap (V2.0) id xma024283; Tue, 2 Feb 99 06:25:23 GMT X-SMAP-Received-From: outside Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28]) by ganymede.or.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 GAA01572; Tue, 2 Feb 1999 06:21:36 GMT Received: by ORSMSX28 with Internet Mail Service (5.5.2232.9) id <1C1YHKKT>; Mon, 1 Feb 1999 22:21:35 -0800 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB2A8F6DA@ORSMSX41> From: "Yavatkar, Raj" To: "'Pat.Calhoun@eng.sun.com'" , "Durham, David" , ietf-aaa@external.cisco.com, "'Brian Lloyd'" Cc: aaa-wg@merit.edu Subject: RE: back to basics Date: Mon, 1 Feb 1999 22:21:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree with Brian. I sent a similar message to the "right address" last week, but haven't seen it reflected. I think some people seem to have made up their mind about what docs to produce by April, etc. However, in a true IETF spirit, we should have an open process with problem space and framework first defined and agreed upon before jumping to conclusions Fred, Sue, comments? Raj -----Original Message----- From: Pat.Calhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] Sent: Monday, February 01, 1999 7:02 PM To: Durham, David; ietf-aaa@external.cisco.com; 'Brian Lloyd' Cc: aaa-wg@merit.edu Subject: RE: back to basics >I absolutely agree that we must first figure out what we are >talking about (in AAA) and then move onto the details. It is >a waste of time to dive into protocols this soon, so I am >looking forward to reading Brian's white paper. > >BTW, given the confusion surrounding AAA >right now, the current charter seems far too aggressive in >its goals. I would like to see the first 2 WG sessions & drafts >to be devoted to clearly explaining the problem set. Once >this known, we can start mixing and matching protocols, >schemas, Directories, MIBs and what have you. Why are we >looking for a solution before we have even clearly defined >the problem? The correct one for the (soon-to-be) WG is aaa-wg@merit.edu. PatC > >my 2 cents, > >-Dave > >PS. We should start by getting the mail server right, I'm still >counting 2 AAA lists! > >> -----Original Message----- >> From: Brian Lloyd [SMTP:brian@lloyd.com] >> Sent: Monday, February 01, 1999 1:59 PM >> To: ietf-aaa@external.cisco.com >> Subject: back to basics >> >> There is so much flying around about AAA protocols, transport protocols, >> etc., that I am having trouble getting focused on the problem. The one >> thing that became very clear to me at the end of the BOF (when Sue got >> pelted with apparently irrelevant questions out of left field) is that >> nothing is very clear to me, and probably not clear to a lot of people. >> >> I think that, at least for me, the problem is that some of us are talking >> about specific protocol solutions for a subset of known problems, some of >> us are talking about the underlying schema for the metadata, and some of >> us >> are talking about transport. The latter is getting a LOT of discussion >> because, hey, we don't know jack about triple-A but we sure as heck know a >> lot about transport protocols. :^) >> >> I *really* want to go back to ground-zero and talk about the *problem* we >> are trying to solve. I don't even want to start talking about the >> requirements or the solution until there is some consensus that we >> understand the problem and can share a common (and meaningful) lexicon. >> >> I plan to write the equivalent of a white paper that attempts to define >> the >> problem space. My missive will probably be incomplete and, in places, >> incoherent because it will represent, to some extent, my own >> stream-of-conciousness as I think about the problem. On the other hand, >> comments and input from the rest of you will greatly help to focus things >> with the end goal being a global understanding of the problem and of >> previous and current approaches to solving some or all of the problem >> before us. >> >> I. The Authorization/Configuration "Big Picture" >> >> As I examine what I belive to be the "big picture" I see lots of overlap >> with other areas. First, we have somthing that is defining "services" >> (for >> want of a more specific word) that may be delivered by the network to a >> device or a user. Examples of services include but are not limited to: >> >> * dial-up remote access to the network; >> * access to and configuration of a mail server; >> * access to and configuration of a web server; >> * setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >> * setting up tunnels for security (IPSEC); >> * FTP server access; >> * TELNET server access; >> * combinations of the above. >> >> I could probably think of more if I spent any time at it. The key >> question >> here is: how do we desribe these services to the network devices so that >> they can deliver these services. This strikes me as falling into the >> catagories of service provisioning and policy. I can see our AAA >> protocols >> delivering session configuration for each instance of service. (Yes, I >> said "protocol*s*" plural since we already have a couple in regular use >> and >> I don't think they are going to go away. Think RADIUS, Diameter, COPS, >> LDAP, etc.) So I think we need to spend a little time determining how >> configuration information is to be delivered to multiple systems possibly >> using multiple protocols. As I see it, a service instance might not be >> viewed as an atomic transaction as far as authorization/configuration is >> concerned. If we don't think about this up front, whatever we cook up >> might not prove to be a general solution. This means to me that we need >> to >> talk about universal internal data representation for directories and >> databases so that we can agree on the sematics of the data stored there. >> >> II. Authentication >> >> This part of what we are doing is probably the best understood. We want >> some way of verifying that an entity is the entity it claims to be. We >> have a number of methods of doing this. >> >> So where is authentication WG in this? What is the story with CAT? Where >> does it fit in here? Should we even do anything besides figuring out how >> to integrate other authentication protocols with the authorization >> protocols? >> >> III. Accounting >> >> Frankly I don't think we are going to end up with a single protocol here >> either. There are two types of "accounting" data that comes immediately >> to >> my mind as I write this. The first is very timely and is used to >> propagate >> session state information in real time so that we can use it to make >> authorization decisions on the fly. The second is used to produce reports >> for billing and settlement purposes. The latter need not propagate in >> real-time. Collect it up and send it out in batches when convenient. >> >> These two types of data might not propagate using the same protocols but >> then again, they might. >> >> IV. What we don't need to talk about >> >> The discussion of TCP vs. UDP is a waste of time right now. I believe >> that, once we figure out what data is getting pushed around and when, the >> proper underlying transport layer for a particular application will become >> fairly obvious. >> >> So, please throw rocks at my comments above. I certainly don't claim >> omniscience. >> >> >> 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-wg@merit.edu Tue Feb 2 08:08:23 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id IAA28180 for ; Tue, 2 Feb 1999 08:08:23 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id IAA16096 for aaa-wg-outgoing; Tue, 2 Feb 1999 08:06:16 -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 IAA16092 for ; Tue, 2 Feb 1999 08:06:11 -0500 (EST) Received: from mailhost.BayNetworks.COM ([141.251.211.49]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id FAA24324; Tue, 2 Feb 1999 05:04:12 -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 OAA13251; Tue, 2 Feb 1999 14:04:31 +0100 (MET) 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 IAA10215; Tue, 2 Feb 1999 08:05:15 -0500 for Received: from msquire ([132.245.112.50]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Tue, 2 Feb 1999 08:05:16 -0500 Message-Id: <3.0.32.19990202075547.007cdec0@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 02 Feb 1999 07:55:48 -0500 To: Brian Lloyd , aaa-wg@merit.edu From: Matt Squire Subject: Re: back to basics Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I'm in agreement with Brian here. The existing protocols aren't going to disappear. The work done in this WG has to live in an environment where differnet protocols are used to perform AAA for various functions. IMHO, one of the most important contributions of this WG would be in the area of common data representations (internal and external) for new and existing protocols. Included in this would be a a way of describing new authentication methods, new accounting records, etc, in some kind of mib/schema format. I'd also like to second the opinion that the proposed schedule for April consensus seems far to aggressive. A one month turnaround between a requirements doc and a base protocol seems a bit short. - Matt > >I. The Authorization/Configuration "Big Picture" > >As I examine what I belive to be the "big picture" I see lots of overlap >with other areas. First, we have somthing that is defining "services" (for >want of a more specific word) that may be delivered by the network to a >device or a user. Examples of services include but are not limited to: > >* dial-up remote access to the network; >* access to and configuration of a mail server; >* access to and configuration of a web server; >* setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >* setting up tunnels for security (IPSEC); >* FTP server access; >* TELNET server access; >* combinations of the above. > >I could probably think of more if I spent any time at it. The key question >here is: how do we desribe these services to the network devices so that >they can deliver these services. This strikes me as falling into the >catagories of service provisioning and policy. I can see our AAA protocols >delivering session configuration for each instance of service. (Yes, I >said "protocol*s*" plural since we already have a couple in regular use and >I don't think they are going to go away. Think RADIUS, Diameter, COPS, >LDAP, etc.) So I think we need to spend a little time determining how >configuration information is to be delivered to multiple systems possibly >using multiple protocols. As I see it, a service instance might not be >viewed as an atomic transaction as far as authorization/configuration is >concerned. If we don't think about this up front, whatever we cook up >might not prove to be a general solution. This means to me that we need to >talk about universal internal data representation for directories and >databases so that we can agree on the sematics of the data stored there. > >II. Authentication > >This part of what we are doing is probably the best understood. We want >some way of verifying that an entity is the entity it claims to be. We >have a number of methods of doing this. > >So where is authentication WG in this? What is the story with CAT? Where >does it fit in here? Should we even do anything besides figuring out how >to integrate other authentication protocols with the authorization protocols? > >III. Accounting > >Frankly I don't think we are going to end up with a single protocol here >either. There are two types of "accounting" data that comes immediately to >my mind as I write this. The first is very timely and is used to propagate >session state information in real time so that we can use it to make >authorization decisions on the fly. The second is used to produce reports >for billing and settlement purposes. The latter need not propagate in >real-time. Collect it up and send it out in batches when convenient. > >These two types of data might not propagate using the same protocols but >then again, they might. > >IV. What we don't need to talk about > >The discussion of TCP vs. UDP is a waste of time right now. I believe >that, once we figure out what data is getting pushed around and when, the >proper underlying transport layer for a particular application will become >fairly obvious. > >So, please throw rocks at my comments above. I certainly don't claim >omniscience. > > >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-wg@merit.edu Tue Feb 2 11:09:16 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA00123 for ; Tue, 2 Feb 1999 11:09:16 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA19178 for aaa-wg-outgoing; Tue, 2 Feb 1999 11:08:38 -0500 (EST) Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA19168 for ; Tue, 2 Feb 1999 11:08:31 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by rhine.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24366 for ; Tue, 2 Feb 1999 08:07:58 -0800 (PST) Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA11705 for ; Tue, 2 Feb 1999 08:08:18 -0800 (PST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id IAA12991 for ; Tue, 2 Feb 1999 08:07:56 -0800 (PST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA11698 for ; Tue, 2 Feb 1999 08:08:16 -0800 (PST) Received: (from smap@localhost) by proxy2.cisco.com (8.8.7/8.8.5) id IAA27786 for ; Tue, 2 Feb 1999 08:07:54 -0800 (PST) Received: from mercury.sun.com(192.9.25.1) by proxy2.cisco.com via smap (V2.0) id xma027744; Tue, 2 Feb 99 16:07:46 GMT X-SMAP-Received-From: outside Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA10803; Tue, 2 Feb 1999 07:57:19 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.123.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA19112; Tue, 2 Feb 1999 07:57:17 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04726; Tue, 2 Feb 1999 07:57:11 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902021557.HAA04726@hsmpka.eng.sun.com> Date: Tue, 2 Feb 1999 07:54:10 -0800 To: "Brian Lloyd" , Reply-To: Subject: Re: back to basics 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 > [snip.] > >I *really* want to go back to ground-zero and talk about the *problem* we >are trying to solve. I don't even want to start talking about the >requirements or the solution until there is some consensus that we >understand the problem and can share a common (and meaningful) lexicon. Let me try. As embedded (access) routers become more complex, and support many new services, it is advantageous to be able to retrieve authentication and authorization information for a particular user using a single protocol. In the embedded world, less is better, as the risk and the cost of changing code is high. For the service provider, there is a demand to be able to have a centralized database, where a user's profile contains information for many services. Although this can be used by multiple processes, each using different software and protocols, the cost of deployment and maintenance is *very* high. Therefore, it is advantageous for them to have a single process (hence protocol) that can handle these. This would also allow for easier debugging (one log file), etc. So, the services that we are looking at are; - PPP Remote Dial-In - IP Telephony - Mobile IP - Terminal Server (telnet, etc). - IP Fax - Others I am sure. Note that we should not restrict the services to the above, however you will find a good mix to start with that should allow us to create a truly extensible protocol. Now we need to look at roaming services. This is *key* to the new AAA protocol. We need to create a protocol that can allow users to roam from their home network to foreign networks. In order for this to work, we need to create a protocol that allows secure proxying. In addition, the said protocol must be able to support brokers, since this will allow roaming to scale at first. Now when the service providers sign their agreement, either with another ISP or a broker, we should try to limit interaction to a few components, or the AAA servers. This is where a limited number of AAA servers, as opposed to one per service, eases management and reduces the cost of equipment and maintenance for the broker (hence better service). I would urge you to look at draft-calhoun-diameter-framework-02.txt. Although it is probably not as complete as I would like it, it does get into some of these details. There is another draft that discusses secure proxy, etc. Yes these drafts do discuss a specific protocol, but I believe that they also describe a problem set that we are trying to solve. Is this a reasonable goal? > >I plan to write the equivalent of a white paper that attempts to define the >problem space. My missive will probably be incomplete and, in places, >incoherent because it will represent, to some extent, my own >stream-of-conciousness as I think about the problem. On the other hand, >comments and input from the rest of you will greatly help to focus things >with the end goal being a global understanding of the problem and of >previous and current approaches to solving some or all of the problem >before us. I would love to help. > >I. The Authorization/Configuration "Big Picture" > >As I examine what I belive to be the "big picture" I see lots of overlap >with other areas. First, we have somthing that is defining "services" (for >want of a more specific word) that may be delivered by the network to a >device or a user. Examples of services include but are not limited to: > >* dial-up remote access to the network; >* access to and configuration of a mail server; >* access to and configuration of a web server; >* setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >* setting up tunnels for security (IPSEC); >* FTP server access; >* TELNET server access; >* combinations of the above. And... * IP Telephony * IP Fax * Mobile IP > > [ SNIP ] > If we don't think about this up front, whatever we cook up >might not prove to be a general solution. We will never be able to think about everthing that will happen in the future. However, if we can solve the problem for the services above, we should have something that is quite extensible. > This means to me that we need to >talk about universal internal data representation for directories and >databases so that we can agree on the sematics of the data stored there. I think that the Policy WG is looking at the internal data reprensentation (in an LDAP format). We should try to leverage from their work as much as we can. > >II. Authentication > >This part of what we are doing is probably the best understood. We want >some way of verifying that an entity is the entity it claims to be. We >have a number of methods of doing this. > >So where is authentication WG in this? What is the story with CAT? Where >does it fit in here? Should we even do anything besides figuring out how >to integrate other authentication protocols with the authorization protocols? > GSSAPI does fit within a specific set of services, where EAP fit others, and IKE's xauth fits others. There is unfortunately not one size fits all, and we need to be able to support them all (as far as I can tell). If you look at draft-calhoun-diameter-framework-02.txt, it describes how authentication using a variety of auth types could be tied to authorization. >III. Accounting > >Frankly I don't think we are going to end up with a single protocol here >either. There are two types of "accounting" data that comes immediately to >my mind as I write this. The first is very timely and is used to propagate >session state information in real time so that we can use it to make >authorization decisions on the fly. The second is used to produce reports >for billing and settlement purposes. The latter need not propagate in >real-time. Collect it up and send it out in batches when convenient. > >These two types of data might not propagate using the same protocols but >then again, they might. I believe that we should be looking at the real-time format. Once we understand this, we can then apply this to batch processing, and possibly recommend a couple of transports for batch (i.e. ftp, smime, etc). > >IV. What we don't need to talk about > >The discussion of TCP vs. UDP is a waste of time right now. I believe >that, once we figure out what data is getting pushed around and when, the >proper underlying transport layer for a particular application will become >fairly obvious. Yes, I agree. PatC From owner-aaa-wg@merit.edu Tue Feb 2 11:31: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 LAA00302 for ; Tue, 2 Feb 1999 11:31:43 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA19919 for aaa-wg-outgoing; Tue, 2 Feb 1999 11:31:29 -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 LAA19915 for ; Tue, 2 Feb 1999 11:31:24 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21962 for ; Tue, 2 Feb 1999 08:30:53 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.61.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA12504 for ; Tue, 2 Feb 1999 08:30:52 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12330; Tue, 2 Feb 1999 08:30:31 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902021630.IAA12330@hsmpka.eng.sun.com> Date: Tue, 2 Feb 1999 08:27:44 -0800 To: Reply-To: Subject: Back to basics 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 In replying to Brian's e-mail, I had not noticed that the original message was sent to the wrong mailing list. Please reply to this one, as opposed to the old ietf-aaa@external.cisco.com. PatC ---- > [snip.] > >I *really* want to go back to ground-zero and talk about the *problem* we >are trying to solve. I don't even want to start talking about the >requirements or the solution until there is some consensus that we >understand the problem and can share a common (and meaningful) lexicon. Let me try. As embedded (access) routers become more complex, and support many new services, it is advantageous to be able to retrieve authentication and authorization information for a particular user using a single protocol. In the embedded world, less is better, as the risk and the cost of changing code is high. For the service provider, there is a demand to be able to have a centralized database, where a user's profile contains information for many services. Although this can be used by multiple processes, each using different software and protocols, the cost of deployment and maintenance is *very* high. Therefore, it is advantageous for them to have a single process (hence protocol) that can handle these. This would also allow for easier debugging (one log file), etc. So, the services that we are looking at are; - PPP Remote Dial-In - IP Telephony - Mobile IP - Terminal Server (telnet, etc). - IP Fax - Others I am sure. Note that we should not restrict the services to the above, however you will find a good mix to start with that should allow us to create a truly extensible protocol. Now we need to look at roaming services. This is *key* to the new AAA protocol. We need to create a protocol that can allow users to roam from their home network to foreign networks. In order for this to work, we need to create a protocol that allows secure proxying. In addition, the said protocol must be able to support brokers, since this will allow roaming to scale at first. Now when the service providers sign their agreement, either with another ISP or a broker, we should try to limit interaction to a few components, or the AAA servers. This is where a limited number of AAA servers, as opposed to one per service, eases management and reduces the cost of equipment and maintenance for the broker (hence better service). I would urge you to look at draft-calhoun-diameter-framework-02.txt. Although it is probably not as complete as I would like it, it does get into some of these details. There is another draft that discusses secure proxy, etc. Yes these drafts do discuss a specific protocol, but I believe that they also describe a problem set that we are trying to solve. Is this a reasonable goal? > >I plan to write the equivalent of a white paper that attempts to define the >problem space. My missive will probably be incomplete and, in places, >incoherent because it will represent, to some extent, my own >stream-of-conciousness as I think about the problem. On the other hand, >comments and input from the rest of you will greatly help to focus things >with the end goal being a global understanding of the problem and of >previous and current approaches to solving some or all of the problem >before us. I would love to help. > >I. The Authorization/Configuration "Big Picture" > >As I examine what I belive to be the "big picture" I see lots of overlap >with other areas. First, we have somthing that is defining "services" (for >want of a more specific word) that may be delivered by the network to a >device or a user. Examples of services include but are not limited to: > >* dial-up remote access to the network; >* access to and configuration of a mail server; >* access to and configuration of a web server; >* setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; >* setting up tunnels for security (IPSEC); >* FTP server access; >* TELNET server access; >* combinations of the above. And... * IP Telephony * IP Fax * Mobile IP > > [ SNIP ] > If we don't think about this up front, whatever we cook up >might not prove to be a general solution. We will never be able to think about everthing that will happen in the future. However, if we can solve the problem for the services above, we should have something that is quite extensible. > This means to me that we need to >talk about universal internal data representation for directories and >databases so that we can agree on the sematics of the data stored there. I think that the Policy WG is looking at the internal data reprensentation (in an LDAP format). We should try to leverage from their work as much as we can. > >II. Authentication > >This part of what we are doing is probably the best understood. We want >some way of verifying that an entity is the entity it claims to be. We >have a number of methods of doing this. > >So where is authentication WG in this? What is the story with CAT? Where >does it fit in here? Should we even do anything besides figuring out how >to integrate other authentication protocols with the authorization protocols? > GSSAPI does fit within a specific set of services, where EAP fit others, and IKE's xauth fits others. There is unfortunately not one size fits all, and we need to be able to support them all (as far as I can tell). If you look at draft-calhoun-diameter-framework-02.txt, it describes how authentication using a variety of auth types could be tied to authorization. >III. Accounting > >Frankly I don't think we are going to end up with a single protocol here >either. There are two types of "accounting" data that comes immediately to >my mind as I write this. The first is very timely and is used to propagate >session state information in real time so that we can use it to make >authorization decisions on the fly. The second is used to produce reports >for billing and settlement purposes. The latter need not propagate in >real-time. Collect it up and send it out in batches when convenient. > >These two types of data might not propagate using the same protocols but >then again, they might. I believe that we should be looking at the real-time format. Once we understand this, we can then apply this to batch processing, and possibly recommend a couple of transports for batch (i.e. ftp, smime, etc). > >IV. What we don't need to talk about > >The discussion of TCP vs. UDP is a waste of time right now. I believe >that, once we figure out what data is getting pushed around and when, the >proper underlying transport layer for a particular application will become >fairly obvious. Yes, I agree. PatC From owner-aaa-wg@merit.edu Tue Feb 2 13:29:00 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA02662 for ; Tue, 2 Feb 1999 13:28:59 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA22794 for aaa-wg-outgoing; Tue, 2 Feb 1999 13:28:01 -0500 (EST) Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2] (may be forged)) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA22787 for ; Tue, 2 Feb 1999 13:27:54 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2232.9) id ; Tue, 2 Feb 1999 10:27:50 -0800 Message-ID: From: Andrew Smith To: "'aaa'" , "'Brian Lloyd'" , "'Pat.Calhoun@eng.sun.com'" Subject: RE: back to basics Date: Tue, 2 Feb 1999 10:27:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Brian, One important difference between the problems spaces that you each describe is the lookup key for the information that the protocol interaction conveys. Pat seems to focus exclusively on things keyed by "user" whereas Brian seems to have more emphasis on "devices" or more networky sorts of things like tunnels and servers. Are "users" really just a special case of "networky things" or is this pointing to a basic difference that might indicate that we perhaps shouldn't try to force them all through the same shaped hole? Andrew **************************************************************** Andrew Smith tel: +1 (408) 863-2821 Extreme Networks fax: +1 (408) 342-0990 10460 Bandley Drive http://www.extremenetworks.com Cupertino CA 95014 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Pat.Calhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] > Sent: Tuesday, February 02, 1999 7:54 AM > To: Brian Lloyd; ietf-aaa@external.cisco.com > Subject: Re: back to basics > > > > > [snip.] > > > >I *really* want to go back to ground-zero and talk about the > *problem* we > >are trying to solve. I don't even want to start talking about the > >requirements or the solution until there is some consensus that we > >understand the problem and can share a common (and > meaningful) lexicon. > > Let me try. > > As embedded (access) routers become more complex, and support many new > services, it is advantageous to be able to retrieve authentication and > authorization information for a particular user using a > single protocol. > > In the embedded world, less is better, as the risk and the > cost of changing > code is high. > > For the service provider, there is a demand to be able to > have a centralized > database, where a user's profile contains information for > many services. > Although this can be used by multiple processes, each using different > software and protocols, the cost of deployment and > maintenance is *very* > high. Therefore, it is advantageous for them to have a single process > (hence protocol) that can handle these. This would also allow > for easier > debugging (one log file), etc. > > So, the services that we are looking at are; > - PPP Remote Dial-In > - IP Telephony > - Mobile IP > - Terminal Server (telnet, etc). > - IP Fax > - Others I am sure. > > Note that we should not restrict the services to the above, > however you > will find a good mix to start with that should allow us to create a > truly extensible protocol. > > Now we need to look at roaming services. This is *key* to the new AAA > protocol. We need to create a protocol that can allow users > to roam from > their home network to foreign networks. In order for this to > work, we need > to create a protocol that allows secure proxying. In > addition, the said > protocol must be able to support brokers, since this will > allow roaming to > scale at first. > > Now when the service providers sign their agreement, either > with another > ISP or a broker, we should try to limit interaction to a few > components, > or the AAA servers. This is where a limited number of AAA > servers, as opposed > to one per service, eases management and reduces the cost of > equipment and > maintenance for the broker (hence better service). > > I would urge you to look at > draft-calhoun-diameter-framework-02.txt. Although > it is probably not as complete as I would like it, it does > get into some > of these details. There is another draft that discusses > secure proxy, etc. Yes > these drafts do discuss a specific protocol, but I believe > that they also > describe a problem set that we are trying to solve. > > Is this a reasonable goal? > > > > >I plan to write the equivalent of a white paper that > attempts to define the > >problem space. My missive will probably be incomplete and, > in places, > >incoherent because it will represent, to some extent, my own > >stream-of-conciousness as I think about the problem. On the > other hand, > >comments and input from the rest of you will greatly help to > focus things > >with the end goal being a global understanding of the problem and of > >previous and current approaches to solving some or all of the problem > >before us. > > I would love to help. > > > > >I. The Authorization/Configuration "Big Picture" > > > >As I examine what I belive to be the "big picture" I see > lots of overlap > >with other areas. First, we have somthing that is defining > "services" (for > >want of a more specific word) that may be delivered by the > network to a > >device or a user. Examples of services include but are not > limited to: > > > >* dial-up remote access to the network; > >* access to and configuration of a mail server; > >* access to and configuration of a web server; > >* setting up tunnels to guarantee QoS; e.g. bandwidth, latency, etc.; > >* setting up tunnels for security (IPSEC); > >* FTP server access; > >* TELNET server access; > >* combinations of the above. > > And... > * IP Telephony > * IP Fax > * Mobile IP > > > > > [ SNIP ] > > If we don't think about this up front, whatever we cook up > >might not prove to be a general solution. > > We will never be able to think about everthing that will happen in the > future. However, if we can solve the problem for the services > above, we > should have something that is quite extensible. > > > This means to me that we need to > >talk about universal internal data representation for directories and > >databases so that we can agree on the sematics of the data > stored there. > > I think that the Policy WG is looking at the internal data > reprensentation > (in an LDAP format). We should try to leverage from their > work as much as we > can. > > > > >II. Authentication > > > >This part of what we are doing is probably the best > understood. We want > >some way of verifying that an entity is the entity it claims > to be. We > >have a number of methods of doing this. > > > >So where is authentication WG in this? What is the story > with CAT? Where > >does it fit in here? Should we even do anything besides > figuring out how > >to integrate other authentication protocols with the > authorization protocols? > > > > GSSAPI does fit within a specific set of services, where EAP > fit others, and > IKE's xauth fits others. There is unfortunately not one size > fits all, and we > need to be able to support them all (as far as I can tell). > > If you look at draft-calhoun-diameter-framework-02.txt, it > describes how > authentication using a variety of auth types could be tied to > authorization. > > >III. Accounting > > > >Frankly I don't think we are going to end up with a single > protocol here > >either. There are two types of "accounting" data that comes > immediately to > >my mind as I write this. The first is very timely and is > used to propagate > >session state information in real time so that we can use it to make > >authorization decisions on the fly. The second is used to > produce reports > >for billing and settlement purposes. The latter need not > propagate in > >real-time. Collect it up and send it out in batches when > convenient. > > > >These two types of data might not propagate using the same > protocols but > >then again, they might. > > I believe that we should be looking at the real-time format. > Once we understand > this, we can then apply this to batch processing, and > possibly recommend a > couple of transports for batch (i.e. ftp, smime, etc). > > > > >IV. What we don't need to talk about > > > >The discussion of TCP vs. UDP is a waste of time right now. > I believe > >that, once we figure out what data is getting pushed around > and when, the > >proper underlying transport layer for a particular > application will become > >fairly obvious. > > Yes, I agree. > > PatC > From owner-aaa-wg@merit.edu Tue Feb 2 13:39:48 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA02797 for ; Tue, 2 Feb 1999 13:39:47 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA23112 for aaa-wg-outgoing; Tue, 2 Feb 1999 13:39:40 -0500 (EST) Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA23108 for ; Tue, 2 Feb 1999 13:39:36 -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 SAA21047; Tue, 2 Feb 1999 18:39:01 GMT Received: by FMSMSX19 with Internet Mail Service (5.5.2232.9) id ; Tue, 2 Feb 1999 10:39:00 -0800 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B513301B0F404@FMSMSX37> From: "Durham, David" To: "'Pat.Calhoun@eng.sun.com'" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Tue, 2 Feb 1999 10:38:59 -0800 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 [Snip] > So, the services that we are looking at are; > - PPP Remote Dial-In > - IP Telephony > - Mobile IP > - Terminal Server (telnet, etc). > - IP Fax > - Others I am sure. > > Note that we should not restrict the services to the above, however you > will find a good mix to start with that should allow us to create a > truly extensible protocol. > [Durham, David] A truly extensible protocol? A truly extensible protocol is hardly a protocol at all. UDP is a very extensible protocol (in that you can use it for almost anything, with enough additions), but we need a protocol (or better yet, a set of existing protocolS, schemas, etc.) that do something to achieve AAA. Right?!? This is exactly the issue, we aren't defining a solution because we apparently don't have a specific problem to solve. Therefore, there is this talk of a completely generic protocol that can "do everything." I know we all love to design protocols, but let's first determine the specific functionality all these services require and design a specific protocol only if needed. But, please, don't say we are designing a truly extensible protocol, it makes it sound like we are punting on the key issue, AAA! (whatever that is:) ). > Now we need to look at roaming services. This is *key* to the new AAA > protocol. We need to create a protocol that can allow users to roam from > their home network to foreign networks. In order for this to work, we need > to create a protocol that allows secure proxying. In addition, the said > protocol must be able to support brokers, since this will allow roaming to > scale at first. > > Now when the service providers sign their agreement, either with another > ISP or a broker, we should try to limit interaction to a few components, > or the AAA servers. This is where a limited number of AAA servers, as > opposed > to one per service, eases management and reduces the cost of equipment and > maintenance for the broker (hence better service). > > I would urge you to look at draft-calhoun-diameter-framework-02.txt. > Although > it is probably not as complete as I would like it, it does get into some > of these details. There is another draft that discusses secure proxy, etc. > Yes > these drafts do discuss a specific protocol, but I believe that they also > describe a problem set that we are trying to solve. > > Is this a reasonable goal? > [Durham, David] Why not use CAT &&/|| global directory services to achieve this goal. Surely, having global certificates is a less lofty goal than inventing a new protocol that itself must become ubiquitous in support of roaming? From owner-aaa-wg@merit.edu Tue Feb 2 15:34:23 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA04099 for ; Tue, 2 Feb 1999 15:34:23 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA26249 for aaa-wg-outgoing; Tue, 2 Feb 1999 15:33:30 -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 PAA26245 for ; Tue, 2 Feb 1999 15:33:24 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA26187 for ; Tue, 2 Feb 1999 12:32:52 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.65.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16372 for ; Tue, 2 Feb 1999 12:32:51 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24485; Tue, 2 Feb 1999 12:32:51 -0800 Date: Tue, 2 Feb 1999 12:32:58 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Back to basics To: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <4A043A1FE4B2D111AC3F00A0C96B513301B0F404@FMSMSX37> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk David Durham states: > [Snip] > > So, the services that we are looking at are; > > - PPP Remote Dial-In > > - IP Telephony > > - Mobile IP > > - Terminal Server (telnet, etc). > > - IP Fax > > - Others I am sure. > > > > Note that we should not restrict the services to the above, however you > > will find a good mix to start with that should allow us to create a > > truly extensible protocol. > > > [Durham, David] A truly extensible protocol? A truly > extensible protocol is hardly a protocol at all. UDP is > a very extensible protocol (in that you can use it for > almost anything, with enough additions), but we need a > protocol (or better yet, a set of existing protocolS, > schemas, etc.) that do something to achieve AAA. Right?!? > > This is exactly the issue, we aren't defining a solution > because we apparently don't have a specific problem to solve. > Therefore, there is this talk of a completely generic > protocol that can "do everything." I know we all love to > design protocols, but let's first determine the specific > functionality all these services require and design a > specific protocol only if needed. But, please, don't say > we are designing a truly extensible protocol, it makes it > sound like we are punting on the key issue, AAA! (whatever > that is:) ). Ok, truly may have been too strong a word, but nevertheless what we *want* to focus on is the base protocol and let each individual WG handle the AA (authentication and authorization) for the service. We already know that some WG use GSSAPI, while others use EAP. Therefore, it is really impossible for this AAA group to force all users of the AAA base to use a specific authentication scheme. Furthermore, the authorization information for each service will be different, and the expertise of the specific service belongs is not in the AAA wg. That said, what we need to do is create a method for AAA policy decisions to be exchanged for multiple services, and not look too much into a specific service, with the exception that ensuring that the base protocol would work for all known services. Once this is done, there is other work that this WG needs to focus on, namely: - Accounting (could belong in another WG) - Resource Management - Proxy (probably belongs in ROAMOPS) > > > Now we need to look at roaming services. This is *key* to the new AAA > > protocol. We need to create a protocol that can allow users to roam from > > their home network to foreign networks. In order for this to work, we need > > to create a protocol that allows secure proxying. In addition, the said > > protocol must be able to support brokers, since this will allow roaming to > > scale at first. > > > > Now when the service providers sign their agreement, either with another > > ISP or a broker, we should try to limit interaction to a few components, > > or the AAA servers. This is where a limited number of AAA servers, as > > opposed > > to one per service, eases management and reduces the cost of equipment and > > maintenance for the broker (hence better service). > > > > I would urge you to look at draft-calhoun-diameter-framework-02.txt. > > Although > > it is probably not as complete as I would like it, it does get into some > > of these details. There is another draft that discusses secure proxy, etc. > > Yes > > these drafts do discuss a specific protocol, but I believe that they also > > describe a problem set that we are trying to solve. > > > > Is this a reasonable goal? > > > [Durham, David] Why not use CAT &&/|| global directory services > to achieve this goal. Surely, having global certificates is a > less lofty goal than inventing a new protocol that itself must > become ubiquitous in support of roaming? > Although certificates provide you with good authentication, it hardly provides you with authorization information. Furthermore, a service provider will want to make sure that the user (or device's) home provider will be willing to pay for the service offered to the user. PatC From owner-aaa-wg@merit.edu Tue Feb 2 15:35: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 PAA04115 for ; Tue, 2 Feb 1999 15:35:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA26308 for aaa-wg-outgoing; Tue, 2 Feb 1999 15:35:20 -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 PAA26304 for ; Tue, 2 Feb 1999 15:35:15 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA26649; Tue, 2 Feb 1999 12:34:42 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.101.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA23508; Tue, 2 Feb 1999 12:34:40 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24825; Tue, 2 Feb 1999 12:34:21 -0800 Date: Tue, 2 Feb 1999 12:34:28 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: back to basics To: Andrew Smith Cc: "'aaa'" , "'Brian Lloyd'" , "'Pat.Calhoun@eng.sun.com'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Pat, Brian, > > One important difference between the problems spaces that you each describe > is the lookup key for the information that the protocol interaction conveys. > Pat seems to focus exclusively on things keyed by "user" whereas Brian seems > to have more emphasis on "devices" or more networky sorts of things like > tunnels and servers. Are "users" really just a special case of "networky > things" or is this pointing to a basic difference that might indicate that > we perhaps shouldn't try to force them all through the same shaped hole? > You are correct. I use the term user very loosely, and perhaps I should have chosen a different term. In fact as far as MObile IP is concerned, it deals with both devices (a phone) and users (a smart card used within a phone). PatC From owner-aaa-wg@merit.edu Tue Feb 2 18:39:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA06382 for ; Tue, 2 Feb 1999 18:39:42 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA29394 for aaa-wg-outgoing; Tue, 2 Feb 1999 18:37:35 -0500 (EST) Received: from harlequin.MorningStar.Com (harlequin.MorningStar.Com [137.175.80.154]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA29389 for ; Tue, 2 Feb 1999 18:37:27 -0500 (EST) Received: (from edguer@localhost) by harlequin.MorningStar.Com (8.9.0/8.9.0) id SAA22266 for aaa-wg@merit.edu; Tue, 2 Feb 1999 18:36:55 -0500 (EST) From: Aydin Edguer Message-Id: <199902022336.SAA22266@harlequin.MorningStar.Com> Subject: Re: Back to basics To: aaa-wg@merit.edu Date: Tue, 2 Feb 1999 14:31:08 -0500 (EST) In-Reply-To: <4A043A1FE4B2D111AC3F00A0C96B513301B0F404@FMSMSX37> from "Durham, David" at Feb 2, 99 10:38:59 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk > [Durham, David] A truly extensible protocol? A truly extensible protocol > is hardly a protocol at all. UDP is a very extensible protocol (in that > you can use it for almost anything, with enough additions), but we need a > protocol (or better yet, a set of existing protocolS, schemas, etc.) that > do something to achieve AAA. Right?!? No. You are wrong. A "truly extensible protocol" is very much a protocol. PPP is "truly extensible" and I think it is very much a collection of protocols (CHAP, EAP, IPCP, IPXCP, MP) that work and that are built around a base protocol (LCP) and formats (HDLC, etc). Yes, the protocol, needs to take into account existing mechanisms to which it will be interfacing but it seems likely that a problem will be that existing protocols either do not meet the current needs or are too specific to a particular domain of use. But if you will read the "Straw-person charter" that is the basis for the future of working group, you will see that the detailing of the particular needs is part of what the WG will do (if the charter is approved) and that nothing will be decided about the protocol until after that step. > This is exactly the issue, we aren't defining a solution because we > apparently don't have a specific problem to solve. No. You are wrong. There are a number of very specific problems which this working group is trying to solve. The problems were detailed as part of the process of creating the working group. The WG will now formalize those details and list of problems as part of the first task: Documents for March presentation (draft finished by February) Document 1 - List of applications that use AAA Document 2 - AAA requirements > Therefore, there is this talk of a completely generic protocol that can > "do everything." No, there is not 'talk of a completely generic protocol that can do everything'. There is talk about a base protocol that all units must understand and can communicate using (like UDP/IP or LCP/PPP) and which the units use to agree upon other layers (like RPC or NCP) or other extensions to the base protocol. This is because after the BOF had detailed the different problems that the WG would try to solve there appeared to be a number of shared characteristics. > [Durham, David] Why not use CAT &&/|| global directory services to > achieve this goal. Surely, having global certificates is a less lofty > goal than inventing a new protocol that itself must become ubiquitous > in support of roaming? We would not necessarily use global directory services because global information does not necessarily help in achieving the goal of roaming services. This is because the objective is not to find the end user, but to follow the chain of authority back to the person the end user has an agreement with. This is similar to the routing of IP packets. You look in you local database to see who you have a contract with and try to determine if the user has a contract with any of them. If not, then you need to choose the "best" choice and ask them if they have a contract with the user, etc. We would not necessarily use global directory services because other than the Domain Name Service, there are few if any global directories that really exist. Yes, it is true that we hope to have a global PKI in the future, but we are not there yet and global certificates is a mighty lofty goal that does not really address some of the needs that have already been expressed (example: for event notification aka accounting). From owner-aaa-wg@merit.edu Tue Feb 2 18:46:44 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA06439 for ; Tue, 2 Feb 1999 18:46:43 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA29510 for aaa-wg-outgoing; Tue, 2 Feb 1999 18:45:12 -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 SAA29506 for ; Tue, 2 Feb 1999 18:45:07 -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 PAA14856; Tue, 2 Feb 1999 15:44:00 -0800 (PST) Message-Id: <3.0.6.32.19990202154009.0091db80@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 02 Feb 1999 15:40:09 -0800 To: Andrew Smith From: Brian Lloyd Subject: RE: back to basics Cc: "'aaa'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 10:27 AM 2/2/99 -0800, Andrew Smith wrote: > >Pat, Brian, > >One important difference between the problems spaces that you each describe >is the lookup key for the information that the protocol interaction conveys. >Pat seems to focus exclusively on things keyed by "user" whereas Brian seems >to have more emphasis on "devices" or more networky sorts of things like >tunnels and servers. Are "users" really just a special case of "networky >things" or is this pointing to a basic difference that might indicate that >we perhaps shouldn't try to force them all through the same shaped hole? This is an area where I think it will be very easy to get off on the wrong track. My thinking, and probably Pat's as well, has been shaped by our close association with remote access. Here you always have a user and it is very easy to think that you have to have a user for all services. Maybe you do but I am not ready to concede that without some discussion. I can see a user requesting a service and I can see a device requesting a service so, from that point of view, they seem the same to me. This also implies that we need some sort of method of creating universal and unique entity IDs for purposes of looking things up. But I can also see an entity requesting services that involve configuration information being sent to more than one entity, not just the device requesting the authorization. Also, you might or might not grant the authorization based on other events and configuration operations that must take place before the requested authorization may be granted. Here we have an interaction that does not necessarily fall into the simple request/grant transaction model with which I believe we have all been working. I beg everyone's pardon if I am stating the patently obvious. 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-wg@merit.edu Tue Feb 2 23:14:13 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id XAA08542 for ; Tue, 2 Feb 1999 23:14:13 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id XAA03502 for aaa-wg-outgoing; Tue, 2 Feb 1999 23:13:34 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by merit.edu (8.9.1a/8.9.1) with ESMTP id XAA03498; Tue, 2 Feb 1999 23:13:28 -0500 (EST) Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.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 EAA23090; Wed, 3 Feb 1999 04:13:27 GMT Received: by FMSMSX29 with Internet Mail Service (5.5.2232.9) id <1DMDDKRN>; Tue, 2 Feb 1999 20:13:26 -0800 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB2A6519C@ORSMSX41> From: "Yavatkar, Raj" To: Susan Hares , "Yavatkar, Raj" Cc: Basavaraj Patil , "'aaa-wg@merit.edu'" Subject: RE: Straw-person charter Date: Tue, 2 Feb 1999 20:13:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Yes, you addressed my concern and thanks for the clarification. Raj -----Original Message----- From: Susan Hares [mailto:skh@merit.edu] Sent: Monday, February 01, 1999 5:53 AM To: Yavatkar, Raj Cc: Basavaraj Patil; 'aaa-wg@merit.edu' Subject: RE: Straw-person charter Raj: Thank-you for the good feedback on the dates. As to the Requirement's document - We did some work as a BOF, and we have some text (drafty, draft text that I worked up with Fred.). I'm hoping with a "sub-group" that focus on the document we can get 2-3 revisions in prior to March. At that meeting, if it looks like we are not getting consensus, we have 6 weeks to obtain consensus on the mailing group prior to the end of April. As to the applications document, we had considerable presentations at the Aug IETF. I'm hoping we can capture that work. Other than existing work, I don't have pre-conceived notions. I hope we will have lively mail group discussion prior to IETF, and a strong meeting there. We'll can adjust the schedule if we really fall behind. Did I understand your concern. Sue Hares On Sun, 31 Jan 1999, Yavatkar, Raj wrote: > Hi Susan: > > Looking at your schedule for documents, I am really surprised. Given that WG > will meet for the first time in March, is it really realistic to have > documents done by April and still ensure a chance for everyone to > participate, contribute, and then reach decisions. I hope we are not coming > in with a pre-conceived notions on any of the documents. > > Please clarify > > Thanks > Raj > > -----Original Message----- > From: Susan Hares [mailto:skh@merit.edu] > Sent: Friday, January 29, 1999 3:59 PM > To: Basavaraj Patil > Cc: 'aaa-wg@merit.edu' > Subject: Re: Straw-person charter > > > > Do you have suggestions for rewording that sentence. Any help > gratefully accepted. > > Sue > > On Fri, 29 Jan 1999, Basavaraj Patil wrote: > > > > > > > > >From: skh@merit.edu > > >Sent: Thursday, January 28, 1999 10:42 AM > > >To: aaa-wg@merit.edu > > >Cc: skh@merit.edu > > >Subject: Straw-person charter > > > > > > > --- Snip Snip--- > > > > > >-------------- > > > > > > > > >AAA working group charter > > > > > >The Authentication, Authorization and Accounting working group will > > >focus on the specification of a general Authentication, > > >Authorization, and Accounting protocol for the Internet. > > >The purpose behind creating a general AAA protocol for the Internet is to > > create > > >a common base protocol for a number of specific AAA protocols which > include > > >IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server > AAA. > > > > >By creating a general base Protocol, the amount of work to create a > > >specific AAA protocols will be reduced. > > > > Mentioning the above applications as examples for supporting the need > > for a commmon base AAA protocol is good, but we do not want to > > necessarily limit the scope to just a few. Starting with the ones > > mentioned above will give a good and common set of requirements for > > the WG to focus on. The AAA protocol needs to be generic enough to > > support new and future applications. > > It's just a matter of how you say it in the charter and nothing more. > > > > -Basavaraj Patil > > > > > > > >The problem space for a general AAA working group contains > > >work in: > > > - determining the current set of specific applications > > > that the AAA will service, > > > - documenting requirements for a base AAA protocol, > > > - selecting a transport protocol or set of transport protocol to > > > be used by a general AAA protocol based on the requirements, > > > - selecting the framework for the AAA protocols, > > > - specifying the base AAA protocol, > > > - specifying the data formats for information contained > > > in the AAA protocol information for authentication, > > > authorization, and accounting. > > > > > > > Basavaraj Patil > > Wireless Technology Labs - Dept IP10 > > Nortel Networks, Richardson > > > * 972-684-1489 > > > > > > From owner-aaa-wg@merit.edu Wed Feb 3 13:17:28 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA17303 for ; Wed, 3 Feb 1999 13:17:28 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id NAA17416 for aaa-wg-outgoing; Wed, 3 Feb 1999 13:10:18 -0500 (EST) Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA17405 for ; Wed, 3 Feb 1999 13:10:07 -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 SAA09651; Wed, 3 Feb 1999 18:10:05 GMT Received: by FMSMSX19 with Internet Mail Service (5.5.2232.9) id ; Wed, 3 Feb 1999 10:10:04 -0800 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B513301B0F409@FMSMSX37> From: "Durham, David" To: "'pcalhoun@eng.sun.com'" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Wed, 3 Feb 1999 10:10:02 -0800 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 > Ok, truly may have been too strong a word, but nevertheless what we *want* > to focus on is the base protocol and let each individual WG handle the > AA (authentication and authorization) for the service. We already know > that > some WG use GSSAPI, while others use EAP. Therefore, it is really > impossible > for this AAA group to force all users of the AAA base to use a specific > authentication scheme. Furthermore, the authorization information for each > service will be different, and the expertise of the specific service > belongs is > not in the AAA wg. > > That said, what we need to do is create a method for AAA policy decisions > to be > exchanged for multiple services, and not look too much into a specific > service, > with the exception that ensuring that the base protocol would work for all > known services. > [Durham, David] Okay, thanks for qualifying "truly" :) I can understand other WGs using a common base protocol, but the base protocol should still be doing something. I don't agree with completely extending the base protocol (essentially into a new protocol) for each variation. Can't we contain this to simply say that the base protocol provides the common operations (and perhaps even data representation, namespace, etc.) for all uses, and then just leave the specific data TBD? (Essentially this is the SNMP and LDAP model et al). I understand that everyone uses a different authentication mechanism, but these are basically data differences and not protocol issues (unless AAA intends to support challenge/ response authentication mechanisms too). So, minus challenge/ response, the protocol isn't actually doing authentication, but simply carrying authentication tickets/certificates and communicating error notifications, right? Other than that, can't the all-encompassing base protocol be simplified to allowing events to occur and then being able to asynchronously stop such events at an appropriate time in the future (aka. Authorization)? It seems to me like there should be some commonality on this theme across WGs. As you say, there are data differences, but what is similar? [Snip] > > > > > [Durham, David] Why not use CAT &&/|| global directory services > > to achieve this goal. Surely, having global certificates is a > > less lofty goal than inventing a new protocol that itself must > > become ubiquitous in support of roaming? > > > Although certificates provide you with good authentication, it hardly > provides > you with authorization information. Furthermore, a service provider will > want > to make sure that the user (or device's) home provider will be willing to > pay > for the service offered to the user. > [Durham, David] Okay, authorization (in the sense above) does not come with global certificates, true. So is it safe to say what this WG is looking for is a generalized asynchronous authorization protocol that can pass around a variety of authentication information? (or am I being overly simplistic?) > PatC > From owner-aaa-wg@merit.edu Wed Feb 3 13:25:01 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA17400 for ; Wed, 3 Feb 1999 13:25:01 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA18099 for aaa-wg-outgoing; Wed, 3 Feb 1999 13:24:49 -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 NAA18092 for ; Wed, 3 Feb 1999 13:24:44 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00732; Wed, 3 Feb 1999 10:24:11 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.122.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA07496; Wed, 3 Feb 1999 10:24:09 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05531; Wed, 3 Feb 1999 10:24:02 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902031824.KAA05531@hsmpka.eng.sun.com> Date: Wed, 3 Feb 1999 10:20:55 -0800 To: "Durham, David" , , "'pcalhoun@eng.sun.com'" Reply-To: Subject: RE: Back to basics 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 > > >> Ok, truly may have been too strong a word, but nevertheless what we *want* >> to focus on is the base protocol and let each individual WG handle the >> AA (authentication and authorization) for the service. We already know >> that >> some WG use GSSAPI, while others use EAP. Therefore, it is really >> impossible >> for this AAA group to force all users of the AAA base to use a specific >> authentication scheme. Furthermore, the authorization information for each >> service will be different, and the expertise of the specific service >> belongs is >> not in the AAA wg. >> >> That said, what we need to do is create a method for AAA policy decisions >> to be >> exchanged for multiple services, and not look too much into a specific >> service, >> with the exception that ensuring that the base protocol would work for all >> known services. >> > [Durham, David] Okay, thanks for qualifying "truly" :) > I can understand other WGs using a common base protocol, > but the base protocol should still be doing something. > I don't agree with completely extending the base protocol > (essentially into a new protocol) for each variation. Can't > we contain this to simply say that the base protocol provides > the common operations (and perhaps even data representation, > namespace, etc.) for all uses, and then just leave the specific > data TBD? (Essentially this is the SNMP and LDAP model et al). This is precisely what DIAMETER does. One base protocol, many applications (or extensions). > > I understand that everyone uses a different authentication > mechanism, but these are basically data differences and not > protocol issues (unless AAA intends to support challenge/ > response authentication mechanisms too). So, minus challenge/ > response, the protocol isn't actually doing authentication, but > simply carrying authentication tickets/certificates and > communicating error notifications, right? Yes that is correct, up to a certain point. The protocol will have to carry authentication (that is AAA protocol authentication) in some cases. Essentially, I believe we have three different types of AAA protocol authentication: 1. None (this is where you use IPSec underneath AAA) 2. Shared Secrets (intended to work with existing RADIUS deployments) 3. PKI (The protocol must support some form of PKI to allow secure communication through a set of proxies, such as brokers). > > Other than that, can't the all-encompassing base protocol be > simplified to allowing events to occur and then being able to > asynchronously stop such events at an appropriate time in > the future (aka. Authorization)? It seems to me like there > should be some commonality on this theme across WGs. As you say, > there are data differences, but what is similar? Yes, this sounds about right. You also want the server to be able to keep some AAA session state information, so there are some additional stuff there as well. > > [Snip] >> > > >> > [Durham, David] Why not use CAT &&/|| global directory services >> > to achieve this goal. Surely, having global certificates is a >> > less lofty goal than inventing a new protocol that itself must >> > become ubiquitous in support of roaming? >> > >> Although certificates provide you with good authentication, it hardly >> provides >> you with authorization information. Furthermore, a service provider will >> want >> to make sure that the user (or device's) home provider will be willing to >> pay >> for the service offered to the user. >> > [Durham, David] Okay, authorization (in the sense above) > does not come with global certificates, true. So is it safe to > say what this WG is looking for is a generalized asynchronous > authorization protocol that can pass around a variety of > authentication information? (or am I being overly simplistic?) I believe there is more to is than that (see above). We need to be able to handle cross-domain auth, both directly and through brokers (similar to the EDI model). There is possibly some session state information that must be maintained. PatC > >> PatC >> From owner-aaa-wg@merit.edu Wed Feb 3 14:03:18 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA17868 for ; Wed, 3 Feb 1999 14:03:18 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA18931 for aaa-wg-outgoing; Wed, 3 Feb 1999 14:03:01 -0500 (EST) Received: from harlequin.MorningStar.Com (harlequin.MorningStar.Com [137.175.80.154]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA18918 for ; Wed, 3 Feb 1999 14:02:54 -0500 (EST) Received: (from edguer@localhost) by harlequin.MorningStar.Com (8.9.0/8.9.0) id OAA22310 for aaa-wg@merit.edu; Wed, 3 Feb 1999 14:02:21 -0500 (EST) From: Aydin Edguer Message-Id: <199902031902.OAA22310@harlequin.MorningStar.Com> Subject: Re: Back to basics To: aaa-wg@merit.edu Date: Wed, 3 Feb 1999 14:02:20 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk > [Durham, David] I understand that everyone uses a different authentication > mechanism, but these are basically data differences and not protocol issues > (unless AAA intends to support challenge/response authentication mechanisms > too). Yes, the AAA protocol that is designed must provide support for challenge- response (C-R) authentication mechanisms. This is required for both two factor authentication products (Axent Omniguard/Defender, Cryptocard RB-1, etc) and authentication protocols such as EAP or RADIUS's Access-Challenge. From owner-aaa-wg@merit.edu Wed Feb 3 20:19:02 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA23660 for ; Wed, 3 Feb 1999 20:19:02 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA01985 for aaa-wg-outgoing; Wed, 3 Feb 1999 20:18:29 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA01981 for ; Wed, 3 Feb 1999 20:18:24 -0500 (EST) Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.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 BAA07978 for ; Thu, 4 Feb 1999 01:18:23 GMT Received: by fmsmsx28-4.fm.intel.com with Internet Mail Service (5.5.2232.9) id <1DXM7LP1>; Wed, 3 Feb 1999 17:18:23 -0800 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B513301B0F40E@FMSMSX37> From: "Durham, David" To: aaa-wg@merit.edu Subject: RE: Back to basics Date: Wed, 3 Feb 1999 17:18:21 -0800 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 [Durham, David] Pat says: > > protocol issues (unless AAA intends to support challenge/ > > response authentication mechanisms too). So, minus challenge/ > > response, the protocol isn't actually doing authentication, but > > simply carrying authentication tickets/certificates and > > communicating error notifications, right? > Yes that is correct, up to a certain point. The protocol will have to > carry authentication (that is AAA protocol authentication) in some cases. > Essentially, I believe we have three different types of AAA protocol > authentication: > 1. None (this is where you use IPSec underneath AAA) > 2. Shared Secrets (intended to work with existing RADIUS deployments) > 3. PKI (The protocol must support some form of PKI to allow secure > communication through a set of proxies, such as brokers). > [Durham, David] Aydin Edguer says: > > [Durham, David] I understand that everyone uses a different > authentication > > mechanism, but these are basically data differences and not protocol > issues > > (unless AAA intends to support challenge/response authentication > mechanisms > > too). > > Yes, the AAA protocol that is designed must provide support for challenge- > response (C-R) authentication mechanisms. This is required for both two > factor authentication products (Axent Omniguard/Defender, Cryptocard RB-1, > etc) and authentication protocols such as EAP or RADIUS's > Access-Challenge. > [Durham, David] So, which is it, C-R yea or nay? Won't it add complexity to the base protocol to support such diverse (and some legacy) authentication mechanisms? The base protocol will essentially have to become a challenge-response protocol. From owner-aaa-wg@merit.edu Wed Feb 3 20:36:26 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA23761 for ; Wed, 3 Feb 1999 20:36:26 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id UAA02436 for aaa-wg-outgoing; Wed, 3 Feb 1999 20:36:15 -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 UAA02429 for ; Wed, 3 Feb 1999 20:36:06 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7BJA4GECE8ZG01S@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 3 Feb 1999 20:35:33 EST Date: Wed, 03 Feb 1999 14:51:01 -0800 From: Paul Krumviede Subject: Re: Straw-person charter To: AAA wg Reply-to: paul@mci.net Message-id: <36B8D2CC.1687B44A@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199901281642.LAA07036@idrp.merit.edu> Sender: owner-aaa-bof@merit.edu Precedence: bulk skh@merit.edu wrote: > - selecting the framework for the AAA protocols, and > After setting our requirements, we will use the requirements to > select a transport protocol and set the framework for the AAA protocols. > After having done all the background work for specifying the base AAA protocol, > The working group will select a base protocol for AAA functions. What does it mean to "select" a framework? Does this mean pick one from an existing list, or something different? -paul From owner-aaa-wg@merit.edu Wed Feb 3 20:36: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 UAA23769 for ; Wed, 3 Feb 1999 20:36:27 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id UAA02426 for aaa-wg-outgoing; Wed, 3 Feb 1999 20:36:03 -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 UAA02414 for ; Wed, 3 Feb 1999 20:35:55 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7BJ9TXBX48ZG01S@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 3 Feb 1999 20:35:24 EST Date: Wed, 03 Feb 1999 14:44:33 -0800 From: Paul Krumviede Subject: Re: Back to basics To: AAA wg Reply-to: paul@mci.net Message-id: <36B8D149.D7D71CD9@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199902021630.IAA12330@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Patrice Calhoun wrote: > > [snip.] > > > >I *really* want to go back to ground-zero and talk about the *problem* we > >are trying to solve. I don't even want to start talking about the > >requirements or the solution until there is some consensus that we > >understand the problem and can share a common (and meaningful) lexicon. > > Let me try. > > As embedded (access) routers become more complex, and support many new > services, it is advantageous to be able to retrieve authentication and > authorization information for a particular user using a single protocol. But this in itself is a simplification. Ideally I want to be able to use an AAA solution on more than "embedded (access) routers" and for more than single users. And differences in authentication mechanisms require either flexible protocols or multiple protocols (to the extent that, say, CHAP is different than SKEME). > For the service provider, there is a demand to be able to have a centralized > database, where a user's profile contains information for many services. > Although this can be used by multiple processes, each using different > software and protocols, the cost of deployment and maintenance is *very* > high. Therefore, it is advantageous for them to have a single process > (hence protocol) that can handle these. This would also allow for easier > debugging (one log file), etc. I'm not sure about this. As a service provider, I want a single *interface* but I'm willing to have a bunch of databases. In part this is because I need to support existing systems, and migrating information from them into a new system is expensive. In part I may have different databases of record for different aspects of a customer's service. > So, the services that we are looking at are; > - PPP Remote Dial-In > - IP Telephony > - Mobile IP > - Terminal Server (telnet, etc). > - IP Fax > - Others I am sure. > > Note that we should not restrict the services to the above, however you > will find a good mix to start with that should allow us to create a > truly extensible protocol. I'm not sure that solving this set of problems will adequately generalize to solve other facets of AAA problems (even if we leave out accounting). > Now we need to look at roaming services. This is *key* to the new AAA > protocol. We need to create a protocol that can allow users to roam from > their home network to foreign networks. In order for this to work, we need > to create a protocol that allows secure proxying. In addition, the said > protocol must be able to support brokers, since this will allow roaming to > scale at first. But this is only true for network access. If I'm trying to implement an authentication and authorization framework for users requesting QoS, particularly for (say) web-hosting. There is no roaming in that scenario. -paul From owner-aaa-wg@merit.edu Wed Feb 3 20:36: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 UAA23770 for ; Wed, 3 Feb 1999 20:36:27 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id UAA02391 for aaa-wg-outgoing; Wed, 3 Feb 1999 20:35:34 -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 UAA02384 for ; Wed, 3 Feb 1999 20:35:28 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7BJ9CQ7Y28ZG01S@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 3 Feb 1999 20:34:55 EST Date: Wed, 03 Feb 1999 14:03:31 -0800 From: Paul Krumviede Subject: Re: back to basics To: AAA wg Reply-to: paul@mci.net Message-id: <36B8C7AF.FDA9508F@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3.0.6.32.19990202154009.0091db80@158.222.8.12> Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian Lloyd wrote: > But I can also see an entity requesting services that involve configuration > information being sent to more than one entity, not just the device > requesting the authorization. Also, you might or might not grant the > authorization based on other events and configuration operations that must > take place before the requested authorization may be granted. Here we have > an interaction that does not necessarily fall into the simple request/grant > transaction model with which I believe we have all been working. I'm also thinking of things like possible multicast distribution of policy information (flooding). An inverse case might be something like aggregation of requests (such as in a bandwidth broker scenario). Neither of these seem to be handled well by a simple request/grant model. -paul From owner-aaa-wg@merit.edu Wed Feb 3 20:36:28 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA23775 for ; Wed, 3 Feb 1999 20:36:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA02407 for aaa-wg-outgoing; Wed, 3 Feb 1999 20:35:49 -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 UAA02395 for ; Wed, 3 Feb 1999 20:35:41 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7BJ9OE1NK8ZG01S@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 3 Feb 1999 20:35:08 EST Date: Wed, 03 Feb 1999 14:28:41 -0800 From: Paul Krumviede Subject: Re: back to basics To: AAA wg Reply-to: paul@mci.net Message-id: <36B8CD90.9F972807@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3.0.6.32.19990201135851.009288c0@158.222.8.12> Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian Lloyd wrote: > II. Authentication > > This part of what we are doing is probably the best understood. We want > some way of verifying that an entity is the entity it claims to be. We > have a number of methods of doing this. There are a few layers of authentication here: not only authentication of the users of a service, but also authentication of the components of the service (in particular, authentication of the AAA system components themselves). Perhaps one thing we need is a way to describe and agree on one or more authentication mechanisms (perhaps per service or instance) and then making sure that the message(s) required to implement these mechanisms can be exchanged. > So where is authentication WG in this? What is the story with CAT? Where > does it fit in here? Should we even do anything besides figuring out how > to integrate other authentication protocols with the authorization protocols? Maybe simply convey policy and then figure out how to invoke the mechanisms/protocols. > III. Accounting > > Frankly I don't think we are going to end up with a single protocol here > either. There are two types of "accounting" data that comes immediately to > my mind as I write this. The first is very timely and is used to propagate > session state information in real time so that we can use it to make > authorization decisions on the fly. The second is used to produce reports > for billing and settlement purposes. The latter need not propagate in > real-time. Collect it up and send it out in batches when convenient. So we may want a way to express and convey the desired properties (for service A I want near real time periodic updates, while for service D I only want summary data at the end of the service instance). I think the one thing that is important is that "accounting" data, or resource usage data, should be syntactically self descriptive, so if somebody adds a new data type or field then other systems can parse the data it understands. This does have the risk that new fields may have to be marked critical, indicating that lack of understanding of the semantics of this field means the whole message can't be correctly interpreted. > These two types of data might not propagate using the same protocols but > then again, they might. > > IV. What we don't need to talk about > > The discussion of TCP vs. UDP is a waste of time right now. I believe > that, once we figure out what data is getting pushed around and when, the > proper underlying transport layer for a particular application will become > fairly obvious. I believe that we need to enumerate the service requirements, but attempting to solve them is premature (and I'd prefer to fold it into something like RUTS rather than solve it ourselves). -paul From owner-aaa-wg@merit.edu Wed Feb 3 21:33:32 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id VAA24396 for ; Wed, 3 Feb 1999 21:33:31 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA03395 for aaa-wg-outgoing; Wed, 3 Feb 1999 21:32:56 -0500 (EST) Received: from ndcrelay2.mcit.com (ndcrelay2.mcit.com [166.37.172.6]) by merit.edu (8.9.1a/8.9.1) with ESMTP id VAA03385 for ; Wed, 3 Feb 1999 21:32:51 -0500 (EST) Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id CAA19159; Thu, 4 Feb 1999 02:29:32 GMT Received: from sinnreich2 ([166.44.130.195]) by omss5.mcit.com (InterMail v03.02.05 118 120) with SMTP id <19990204023220.HHIM28868@[166.44.130.195]>; Wed, 3 Feb 1999 20:32:20 -0600 From: "Henry Sinnreich" To: , "AAA wg" Subject: RE: Back to basics Date: Wed, 3 Feb 1999 20:31:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) In-reply-to: <36B8D149.D7D71CD9@mci.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul Krumviede sums it up quite nicely > As a service provider, I want a single > *interface* > but I'm willing to have a bunch of databases. In part this is because I > need to support existing systems, and migrating information from them > into a new system is expensive. In part I may have different databases > of record for different aspects of a customer's service. > > > So, the services that we are looking at are; > > - PPP Remote Dial-In > > - IP Telephony > > - Mobile IP > > - Terminal Server (telnet, etc). > > - IP Fax There is a strong case for this interface to be XML, unless there are good reasons not to use it, like performance under peak traffic load. Would be interested in the pros/cons for the single XML interface. Thanks, Henry Sinnreich > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Paul Krumviede > Sent: Wednesday, February 03, 1999 5:45 PM > To: AAA wg > Subject: Re: Back to basics > > > Patrice Calhoun wrote: > > > > [snip.] > > > > > >I *really* want to go back to ground-zero and talk about the > *problem* we > > >are trying to solve. I don't even want to start talking about the > > >requirements or the solution until there is some consensus that we > > >understand the problem and can share a common (and meaningful) lexicon. > > > > Let me try. > > > > As embedded (access) routers become more complex, and support many new > > services, it is advantageous to be able to retrieve authentication and > > authorization information for a particular user using a single protocol. > > But this in itself is a simplification. Ideally I want to be able to > use an AAA solution on more than "embedded (access) routers" and for > more than single users. > > And differences in authentication mechanisms require either flexible > protocols or multiple protocols (to the extent that, say, CHAP is > different than SKEME). > > > For the service provider, there is a demand to be able to have > a centralized > > database, where a user's profile contains information for many services. > > Although this can be used by multiple processes, each using different > > software and protocols, the cost of deployment and maintenance is *very* > > high. Therefore, it is advantageous for them to have a single process > > (hence protocol) that can handle these. This would also allow for easier > > debugging (one log file), etc. > > I'm not sure about this. As a service provider, I want a single > *interface* > but I'm willing to have a bunch of databases. In part this is because I > need to support existing systems, and migrating information from them > into a new system is expensive. In part I may have different databases > of record for different aspects of a customer's service. > > > So, the services that we are looking at are; > > - PPP Remote Dial-In > > - IP Telephony > > - Mobile IP > > - Terminal Server (telnet, etc). > > - IP Fax > > - Others I am sure. > > > > Note that we should not restrict the services to the above, however you > > will find a good mix to start with that should allow us to create a > > truly extensible protocol. > > I'm not sure that solving this set of problems will adequately generalize > to solve other facets of AAA problems (even if we leave out accounting). > > > Now we need to look at roaming services. This is *key* to the new AAA > > protocol. We need to create a protocol that can allow users to roam from > > their home network to foreign networks. In order for this to > work, we need > > to create a protocol that allows secure proxying. In addition, the said > > protocol must be able to support brokers, since this will allow > roaming to > > scale at first. > > But this is only true for network access. If I'm trying to implement an > authentication and authorization framework for users requesting QoS, > particularly for (say) web-hosting. There is no roaming in that scenario. > > -paul > > From owner-aaa-wg@merit.edu Thu Feb 4 10:23:58 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA00657 for ; Thu, 4 Feb 1999 10:23:58 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA13256 for aaa-wg-outgoing; Thu, 4 Feb 1999 10:19: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 SMTP id KAA13252 for ; Thu, 4 Feb 1999 10:19:19 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26164; Thu, 4 Feb 1999 07:18:47 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.55.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29232; Thu, 4 Feb 1999 07:18:46 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA08680; Thu, 4 Feb 1999 07:18:40 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902041518.HAA08680@hsmpka.eng.sun.com> Date: Thu, 4 Feb 1999 07:15:26 -0800 To: "Durham, David" , Reply-To: Subject: RE: Back to basics 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 > > > [Durham, David] Pat says: >> > protocol issues (unless AAA intends to support challenge/ >> > response authentication mechanisms too). So, minus challenge/ >> > response, the protocol isn't actually doing authentication, but >> > simply carrying authentication tickets/certificates and >> > communicating error notifications, right? >> Yes that is correct, up to a certain point. The protocol will have to >> carry authentication (that is AAA protocol authentication) in some cases. >> Essentially, I believe we have three different types of AAA protocol >> authentication: >> 1. None (this is where you use IPSec underneath AAA) >> 2. Shared Secrets (intended to work with existing RADIUS deployments) >> 3. PKI (The protocol must support some form of PKI to allow secure >> communication through a set of proxies, such as brokers). >> > [Durham, David] Aydin Edguer says: >> > [Durham, David] I understand that everyone uses a different >> authentication >> > mechanism, but these are basically data differences and not protocol >> issues >> > (unless AAA intends to support challenge/response authentication >> mechanisms >> > too). >> >> Yes, the AAA protocol that is designed must provide support for challenge- >> response (C-R) authentication mechanisms. This is required for both two >> factor authentication products (Axent Omniguard/Defender, Cryptocard RB-1, >> etc) and authentication protocols such as EAP or RADIUS's >> Access-Challenge. >> > [Durham, David] So, which is it, C-R yea or nay? Won't it > add complexity to the base protocol to support such diverse > (and some legacy) authentication mechanisms? The base > protocol will essentially have to become a challenge-response > protocol. I believe that you are confusing the "user/device" authentication mechanism from the base protocol authentication mechanism. Two peers must communicate, using the said base protocol, in a secure fashion. This is what I was referring to, while Aydin was referring to the "user/device" authentication. PatC From owner-aaa-wg@merit.edu Thu Feb 4 10:27:54 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA00684 for ; Thu, 4 Feb 1999 10:27:53 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA13370 for aaa-wg-outgoing; Thu, 4 Feb 1999 10:26:23 -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 KAA13366 for ; Thu, 4 Feb 1999 10:26:18 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA27903; Thu, 4 Feb 1999 07:25:46 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.124.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA15553; Thu, 4 Feb 1999 07:25:44 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA09720; Thu, 4 Feb 1999 07:25:31 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902041525.HAA09720@hsmpka.eng.sun.com> Date: Thu, 4 Feb 1999 07:22:23 -0800 To: , "AAA wg" Reply-To: Subject: Re: Back to basics 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 >Patrice Calhoun wrote: > >> > [snip.] >> > >> >I *really* want to go back to ground-zero and talk about the *problem* we >> >are trying to solve. I don't even want to start talking about the >> >requirements or the solution until there is some consensus that we >> >understand the problem and can share a common (and meaningful) lexicon. >> >> Let me try. >> >> As embedded (access) routers become more complex, and support many new >> services, it is advantageous to be able to retrieve authentication and >> authorization information for a particular user using a single protocol. > >But this in itself is a simplification. Ideally I want to be able to >use an AAA solution on more than "embedded (access) routers" and for >more than single users. Yes you are correct, and now that I build things other than Access Routers, I also have an interest in these devices :) > >And differences in authentication mechanisms require either flexible >protocols or multiple protocols (to the extent that, say, CHAP is >different than SKEME). > >> For the service provider, there is a demand to be able to have a centralized >> database, where a user's profile contains information for many services. >> Although this can be used by multiple processes, each using different >> software and protocols, the cost of deployment and maintenance is *very* >> high. Therefore, it is advantageous for them to have a single process >> (hence protocol) that can handle these. This would also allow for easier >> debugging (one log file), etc. > >I'm not sure about this. As a service provider, I want a single *interface* >but I'm willing to have a bunch of databases. In part this is because I >need to support existing systems, and migrating information from them >into a new system is expensive. In part I may have different databases >of record for different aspects of a customer's service. > >> So, the services that we are looking at are; >> - PPP Remote Dial-In >> - IP Telephony >> - Mobile IP >> - Terminal Server (telnet, etc). >> - IP Fax >> - Others I am sure. >> >> Note that we should not restrict the services to the above, however you >> will find a good mix to start with that should allow us to create a >> truly extensible protocol. > >I'm not sure that solving this set of problems will adequately generalize >to solve other facets of AAA problems (even if we leave out accounting). Paul, as much as we cannot predict the future, I believe that we can. If we can agree on a small set of primitives, and allow for the extension (or application) to handle most of the AAA work (within guidelines which we setup), then we can create an extensible protocol. > >> Now we need to look at roaming services. This is *key* to the new AAA >> protocol. We need to create a protocol that can allow users to roam from >> their home network to foreign networks. In order for this to work, we need >> to create a protocol that allows secure proxying. In addition, the said >> protocol must be able to support brokers, since this will allow roaming to >> scale at first. > >But this is only true for network access. If I'm trying to implement an >authentication and authorization framework for users requesting QoS, >particularly for (say) web-hosting. There is no roaming in that scenario. Is this true? As I user I happen to be at the airport and use a web kiosk. I would, ideally, not have to worry about who owns the kiosk, use the service and receive a single bill from my home provider. This is no different than how my calling card works. PatC From owner-aaa-wg@merit.edu Thu Feb 4 11:47:29 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA01665 for ; Thu, 4 Feb 1999 11:47:28 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA15263 for aaa-wg-outgoing; Thu, 4 Feb 1999 11:45:23 -0500 (EST) Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA15257 for ; Thu, 4 Feb 1999 11:45:18 -0500 (EST) Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca; Thu, 4 Feb 1999 11:44:42 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id <1HKYJ1QT>; Thu, 4 Feb 1999 11:44:38 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E62@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Durham, David'" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Thu, 4 Feb 1999 11:44:30 -0500 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 [Durham, David] Pat says: >> > protocol issues (unless AAA intends to support challenge/ >> > response authentication mechanisms too). So, minus challenge/ >> > response, the protocol isn't actually doing authentication, but >> > simply carrying authentication tickets/certificates and >> > communicating error notifications, right? >> Yes that is correct, up to a certain point. The protocol will have to >> carry authentication (that is AAA protocol authentication) in some cases. >> Essentially, I believe we have three different types of AAA protocol >> authentication: >> 1. None (this is where you use IPSec underneath AAA) >> 2. Shared Secrets (intended to work with existing RADIUS deployments) >> 3. PKI (The protocol must support some form of PKI to allow secure >> communication through a set of proxies, such as brokers). >> > [Durham, David] Aydin Edguer says: >> > [Durham, David] I understand that everyone uses a different >> authentication >> > mechanism, but these are basically data differences and not protocol >> issues >> > (unless AAA intends to support challenge/response authentication >> mechanisms >> > too). >> >> Yes, the AAA protocol that is designed must provide support for challenge- >> response (C-R) authentication mechanisms. This is required for both two >> factor authentication products (Axent Omniguard/Defender, Cryptocard RB-1, >> etc) and authentication protocols such as EAP or RADIUS's >> Access-Challenge. >> > [Durham, David] So, which is it, C-R yea or nay? Won't it > add complexity to the base protocol to support such diverse > (and some legacy) authentication mechanisms? The base > protocol will essentially have to become a challenge-response > protocol. So far what I gather from the discussion is that Triple-A needs to support multiple authentication schemes. So if there is some application that uses a Challenge-Response authentication scheme, then AAA ought to be able to support that. So C-R is just another authentication scheme that ought to be supported by AAA. The AAA base protocol itself will not necessarily have any specific authentication schemes as you suggest. It only provides the means to do whatever authentication scheme required by the application. -Basavaraj Patil -Emad Qaddoura From owner-aaa-wg@merit.edu Thu Feb 4 12:23:06 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA02029 for ; Thu, 4 Feb 1999 12:23:05 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA16116 for aaa-wg-outgoing; Thu, 4 Feb 1999 12:21:34 -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 MAA16107 for ; Thu, 4 Feb 1999 12:21:25 -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 JAA26244 for ; Thu, 4 Feb 1999 09:21:22 -0800 (PST) Message-Id: <3.0.6.32.19990204092025.0094f600@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 09:20:25 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Re: Back to basics In-Reply-To: <199902041525.HAA09720@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:22 AM 2/4/99 -0800, Patrice Calhoun wrote: >>But this is only true for network access. If I'm trying to implement an >>authentication and authorization framework for users requesting QoS, >>particularly for (say) web-hosting. There is no roaming in that scenario. > >Is this true? As I user I happen to be at the airport and use a web kiosk. >I would, ideally, not have to worry about who owns the kiosk, use the service >and receive a single bill from my home provider. This is no different than >how my calling card works. The authentication takes place between the user and the web server. As I see it, the web kiosk isn't involved therefore there is no roming involved. Am I confused here? 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-wg@merit.edu Thu Feb 4 12:23:13 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA02035 for ; Thu, 4 Feb 1999 12:23:13 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA16100 for aaa-wg-outgoing; Thu, 4 Feb 1999 12:21:12 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA16093; Thu, 4 Feb 1999 12:21:06 -0500 (EST) Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprtp.nortel.com; Thu, 4 Feb 1999 12:19:51 -0500 Received: by zrtpd00m.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HH5ZB82>; Thu, 4 Feb 1999 12:19:41 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E63@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Brian Lloyd'" , "'aaa-wg@merit.edu'" Cc: "Susan Hares (E-mail)" Subject: RE: back to basics Date: Thu, 4 Feb 1999 12:13:22 -0500 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 Brian Lloyd wrote: >IV. What we don't need to talk about > >The discussion of TCP vs. UDP is a waste of time right now. I believe >that, once we figure out what data is getting pushed around and when, the >proper underlying transport layer for a particular application will become >fairly obvious. > The transport mechanisms for different aspects of AAA will probably vary. I agree with Brian that we should not try to solve the transport layer problems in this WG. Rather I think we can at least come up with a set of requirements or specifications that AAA expects from the transport layer. Somebody else (RUTS maybe???) can then go ahead and use these as input in defining a protocol(s) that can be used by AAA. -Basavaraj Patil -Emad Qaddoura From owner-aaa-wg@merit.edu Thu Feb 4 12:23:16 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA02041 for ; Thu, 4 Feb 1999 12:23:16 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA16114 for aaa-wg-outgoing; Thu, 4 Feb 1999 12:21:32 -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 MAA16106 for ; Thu, 4 Feb 1999 12:21:24 -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 JAA26241 for ; Thu, 4 Feb 1999 09:21:21 -0800 (PST) Message-Id: <3.0.6.32.19990204091544.00971920@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 09:15:44 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: RE: Back to basics In-Reply-To: <199902041518.HAA08680@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 07:15 AM 2/4/99 -0800, Patrice Calhoun wrote: >I believe that you are confusing the "user/device" authentication mechanism >from the base protocol authentication mechanism. Two peers must communicate, >using the said base protocol, in a secure fashion. This is what I was referring >to, while Aydin was referring to the "user/device" authentication. IMHO, they are different manifestations of the same problem. The authorization server needs to be able to authorize the authorization client. Think of it as the situation where the client says, "hi, I am a NAS and I want to be able to authenticate my users with you. How do I do that?" Granted, some of this transaction is implied but the semantics are still there. This is why I feel we need to put authentication at a bit more of an arms length from authorization. To me, authorization is just, "entity 'p' wants to do action 'x'," to which the server replies, "yes and here is how." There is no authentication involved in this process. The authentication process is just that we want to somehow improve our confidence that the original requesting entity is really 'p'. Just because we have spent so much time in the remote access world where authentication tends to be tightly tied to authorization doesn't mean that they are intrinsicly linked. There may be applications where the authorization takes place without authentication. 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-wg@merit.edu Thu Feb 4 12:55:29 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA02301 for ; Thu, 4 Feb 1999 12:55:29 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA17010 for aaa-wg-outgoing; Thu, 4 Feb 1999 12:52:49 -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 MAA17006 for ; Thu, 4 Feb 1999 12:52:42 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA16805; Thu, 4 Feb 1999 09:51:33 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.63.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA12580; Thu, 4 Feb 1999 09:51:32 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16217; Thu, 4 Feb 1999 09:51:21 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902041751.JAA16217@hsmpka.eng.sun.com> Date: Thu, 4 Feb 1999 09:48:09 -0800 To: "Brian Lloyd" , Reply-To: Subject: RE: Back to basics 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 07:15 AM 2/4/99 -0800, Patrice Calhoun wrote: >>I believe that you are confusing the "user/device" authentication mechanism >>from the base protocol authentication mechanism. Two peers must communicate, >>using the said base protocol, in a secure fashion. This is what I was >referring >>to, while Aydin was referring to the "user/device" authentication. > >IMHO, they are different manifestations of the same problem. The >authorization server needs to be able to authorize the authorization >client. Think of it as the situation where the client says, "hi, I am a >NAS and I want to be able to authenticate my users with you. How do I do >that?" Granted, some of this transaction is implied but the semantics are >still there. This is why I feel we need to put authentication at a bit >more of an arms length from authorization. > >To me, authorization is just, "entity 'p' wants to do action 'x'," to which >the server replies, "yes and here is how." There is no authentication >involved in this process. The authentication process is just that we want >to somehow improve our confidence that the original requesting entity is >really 'p'. Just because we have spent so much time in the remote access >world where authentication tends to be tightly tied to authorization >doesn't mean that they are intrinsicly linked. There may be applications >where the authorization takes place without authentication. Obviously you mis-understood my statement. Two "base protocol" peers must be able to exchange packets. These packets must be authenticated, and perhaps encrypted. This is completely outside of the authetication of the user or device. Agreed? PatC > > >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-wg@merit.edu Thu Feb 4 12:59:11 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA02334 for ; Thu, 4 Feb 1999 12:59:11 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA17162 for aaa-wg-outgoing; Thu, 4 Feb 1999 12:57:40 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA17158 for ; Thu, 4 Feb 1999 12:57:35 -0500 (EST) Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprtp.nortel.com; Thu, 4 Feb 1999 12:56:10 -0500 Received: by zrtpd00m.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HH5ZDHA>; Thu, 4 Feb 1999 12:54:45 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E65@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Brian Lloyd'" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Thu, 4 Feb 1999 12:51:25 -0500 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 Brian Lloyd wrote: >IMHO, they are different manifestations of the same problem. The >authorization server needs to be able to authorize the authorization >client. Think of it as the situation where the client says, "hi, I am a >NAS and I want to be able to authenticate my users with you. How do I do >that?" Granted, some of this transaction is implied but the semantics are >still there. This is why I feel we need to put authentication at a bit >more of an arms length from authorization. > >To me, authorization is just, "entity 'p' wants to do action 'x'," to which >the server replies, "yes and here is how." There is no authentication >involved in this process. The authentication process is just that we want >to somehow improve our confidence that the original requesting entity is >really 'p'. Just because we have spent so much time in the remote access >world where authentication tends to be tightly tied to authorization >doesn't mean that they are intrinsicly linked. There may be applications >where the authorization takes place without authentication. > Brian, I think you are putting the authorization (the least understood so far) aspect of AAA in a better perspective now with your example. Just to extrapolate on what you suggested I believe when "entity p" wants to do action 'x', some entity needs to figure out what are the resources that would be required to accomplish task 'x'. The responsibility of the authorization server would be to verify if 'entity p' has the privileges to do action 'x' and if he does then to authorize the use of those resources. To accomplish a task 'x' multiple resources in the network may need to be authorized and this aspect needs to be considered within the AAA discussions. When I look at the NAS the only authorization that happens in this case is the allocation of a modem and this is probably an implicit result of the user being authenticated. Is there an authorization request that is sent out by the NAS subsequent to authentication for allocation of a modem? (somebody can educate me here). It may be possible to trigger an authentication request as a result of an authorization request to some resource in certain applications. -Basavaraj Patil -Emad Qaddoura Nortel Networks > -----Original Message----- > From: Brian Lloyd [SMTP:brian@lloyd.com] > Sent: Thursday, February 04, 1999 11:16 AM > To: aaa-wg@merit.edu > Subject: RE: Back to basics > > At 07:15 AM 2/4/99 -0800, Patrice Calhoun wrote: > >I believe that you are confusing the "user/device" authentication > mechanism > >from the base protocol authentication mechanism. Two peers must > communicate, > >using the said base protocol, in a secure fashion. This is what I was > referring > >to, while Aydin was referring to the "user/device" authentication. > > IMHO, they are different manifestations of the same problem. The > authorization server needs to be able to authorize the authorization > client. Think of it as the situation where the client says, "hi, I am a > NAS and I want to be able to authenticate my users with you. How do I do > that?" Granted, some of this transaction is implied but the semantics are > still there. This is why I feel we need to put authentication at a bit > more of an arms length from authorization. > > To me, authorization is just, "entity 'p' wants to do action 'x'," to > which > the server replies, "yes and here is how." There is no authentication > involved in this process. The authentication process is just that we want > to somehow improve our confidence that the original requesting entity is > really 'p'. Just because we have spent so much time in the remote access > world where authentication tends to be tightly tied to authorization > doesn't mean that they are intrinsicly linked. There may be applications > where the authorization takes place without authentication. > > > 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-wg@merit.edu Thu Feb 4 13:10:28 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA02475 for ; Thu, 4 Feb 1999 13:10:28 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA17432 for aaa-wg-outgoing; Thu, 4 Feb 1999 13:08:14 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA17427 for ; Thu, 4 Feb 1999 13:08:09 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.nortel.com; Thu, 4 Feb 1999 13:07:35 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HHZAGGX>; Thu, 4 Feb 1999 13:07:37 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E67@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Brian Lloyd'" , aaa-wg@merit.edu Cc: "'pat.calhoun@eng.sun.com'" Subject: RE: Back to basics Date: Thu, 4 Feb 1999 13:07:31 -0500 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 >At 07:22 AM 2/4/99 -0800, Patrice Calhoun wrote: >>>But this is only true for network access. If I'm trying to implement an >>>authentication and authorization framework for users requesting QoS, >>>particularly for (say) web-hosting. There is no roaming in that scenario. >> >>Is this true? As I user I happen to be at the airport and use a web kiosk. >>I would, ideally, not have to worry about who owns the kiosk, use the service >>and receive a single bill from my home provider. This is no different than >>how my calling card works. > Brian Lloyd wrote: >The authentication takes place between the user and the web server. As I >see it, the web kiosk isn't involved therefore there is no roming involved. > Am I confused here? > > The kiosk may be owned by a service provider'A' who is not necessarily your service provider 'B'. The usage of the kiosk by you is authenticated by your service provider 'B' and you receive a bill for that from 'B'. The kiosk service provider 'A' is not the one who would bill you. Some settlement happens between the service providers. The roaming aspect in this scenario is from a user/service perspective, which in this case is access to some service from a device (kiosk). -Basavaraj Patil -Emad Qaddoura Nortel Networks From owner-aaa-wg@merit.edu Thu Feb 4 13:46: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 NAA02907 for ; Thu, 4 Feb 1999 13:46:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA18047 for aaa-wg-outgoing; Thu, 4 Feb 1999 13:44:21 -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 NAA18043 for ; Thu, 4 Feb 1999 13:44:17 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10319; Thu, 4 Feb 1999 10:43:10 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.63.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA16246; Thu, 4 Feb 1999 10:43:09 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA02686; Thu, 4 Feb 1999 10:42:42 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902041842.KAA02686@hsmpka.eng.sun.com> Date: Thu, 4 Feb 1999 10:39:43 -0800 To: "Brian Lloyd" , Reply-To: Subject: Re: Back to basics 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 07:22 AM 2/4/99 -0800, Patrice Calhoun wrote: >>>But this is only true for network access. If I'm trying to implement an >>>authentication and authorization framework for users requesting QoS, >>>particularly for (say) web-hosting. There is no roaming in that scenario. >> >>Is this true? As I user I happen to be at the airport and use a web kiosk. >>I would, ideally, not have to worry about who owns the kiosk, use the service >>and receive a single bill from my home provider. This is no different than >>how my calling card works. > >The authentication takes place between the user and the web server. As I >see it, the web kiosk isn't involved therefore there is no roming involved. > Am I confused here? Trust exists between the web kiosk and the foreign provider's AAA Server. Trust exists between the foreign provider's AAA Server and the user's home AAA server. Further, trust exists between the user and the home AAA Server. The AAA protocol is initiated (on behalf of the user) to the foreign AAA server, which proxies the request to the home AAA server. The AAA communication between all three devices must be secure, and may require non-repudiation. The user does get authenticated, but this is outside the scope of this thread. My point is that is you have created a secure roaming AAA protocol, it can be applied to many services, but this requires that the AAA protocol is secure. PatC > > >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-wg@merit.edu Thu Feb 4 13:49:38 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA02943 for ; Thu, 4 Feb 1999 13:49:37 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA18123 for aaa-wg-outgoing; Thu, 4 Feb 1999 13:47:52 -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 NAA18119 for ; Thu, 4 Feb 1999 13:47:47 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA11297; Thu, 4 Feb 1999 10:45:45 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.63.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA05863; Thu, 4 Feb 1999 10:45:40 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03773; Thu, 4 Feb 1999 10:45:17 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902041845.KAA03773@hsmpka.eng.sun.com> Date: Thu, 4 Feb 1999 10:42:18 -0800 To: "Basavaraj Patil" , , "'Brian Lloyd'" Reply-To: Subject: RE: Back to basics 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 >Brian Lloyd wrote: >>IMHO, they are different manifestations of the same problem. The >>authorization server needs to be able to authorize the authorization >>client. Think of it as the situation where the client says, "hi, I am a >>NAS and I want to be able to authenticate my users with you. How do I do >>that?" Granted, some of this transaction is implied but the semantics are >>still there. This is why I feel we need to put authentication at a bit >>more of an arms length from authorization. >> >>To me, authorization is just, "entity 'p' wants to do action 'x'," to which >>the server replies, "yes and here is how." There is no authentication >>involved in this process. The authentication process is just that we want >>to somehow improve our confidence that the original requesting entity is >>really 'p'. Just because we have spent so much time in the remote access >>world where authentication tends to be tightly tied to authorization >>doesn't mean that they are intrinsicly linked. There may be applications >>where the authorization takes place without authentication. >> > >Brian, > >I think you are putting the authorization (the least understood so >far) aspect of AAA in a better perspective now with your example. Just >to extrapolate on what you suggested I believe when "entity p" wants >to do action 'x', some entity needs to figure out what are the >resources that would be required to accomplish task 'x'. The >responsibility of the authorization server would be to verify if >'entity p' has the privileges to do action 'x' and if he does then to >authorize the use of those resources. To accomplish a task 'x' >multiple resources in the network may need to be authorized and this >aspect needs to be considered within the AAA discussions. When I look >at the NAS the only authorization that happens in this case is the >allocation of a modem and this is probably an implicit result of the >user being authenticated. Is there an authorization request that is >sent out by the NAS subsequent to authentication for allocation of a >modem? (somebody can educate me here). > >It may be possible to trigger an authentication request as a result of >an authorization request to some resource in certain applications. I believe that one way of achieving this is for the AAA server to create a session token when the user is authenticated. This token is used in subsequent authorization requests. The token would be signed by the AAA server, which then means that if the provider has many AAA servers, they would have to share a single private key (I think - but if someone has a better method, please let me know). The token would have a lifetime, and would have to be periodically refreshed. PatC > >-Basavaraj Patil >-Emad Qaddoura >Nortel Networks > >> -----Original Message----- >> From: Brian Lloyd [SMTP:brian@lloyd.com] >> Sent: Thursday, February 04, 1999 11:16 AM >> To: aaa-wg@merit.edu >> Subject: RE: Back to basics >> >> At 07:15 AM 2/4/99 -0800, Patrice Calhoun wrote: >> >I believe that you are confusing the "user/device" authentication >> mechanism >> >from the base protocol authentication mechanism. Two peers must >> communicate, >> >using the said base protocol, in a secure fashion. This is what I was >> referring >> >to, while Aydin was referring to the "user/device" authentication. >> >> IMHO, they are different manifestations of the same problem. The >> authorization server needs to be able to authorize the authorization >> client. Think of it as the situation where the client says, "hi, I am a >> NAS and I want to be able to authenticate my users with you. How do I do >> that?" Granted, some of this transaction is implied but the semantics are >> still there. This is why I feel we need to put authentication at a bit >> more of an arms length from authorization. >> >> To me, authorization is just, "entity 'p' wants to do action 'x'," to >> which >> the server replies, "yes and here is how." There is no authentication >> involved in this process. The authentication process is just that we want >> to somehow improve our confidence that the original requesting entity is >> really 'p'. Just because we have spent so much time in the remote access >> world where authentication tends to be tightly tied to authorization >> doesn't mean that they are intrinsicly linked. There may be applications >> where the authorization takes place without authentication. >> >> >> 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-wg@merit.edu Thu Feb 4 13:59:03 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA03025 for ; Thu, 4 Feb 1999 13:59:03 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA18267 for aaa-wg-outgoing; Thu, 4 Feb 1999 13:58:23 -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 NAA18263 for ; Thu, 4 Feb 1999 13:58:08 -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 KAA26957; Thu, 4 Feb 1999 10:57:50 -0800 (PST) Message-Id: <3.0.6.32.19990204103323.008f7ea0@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 10:33:23 -0800 To: From: Brian Lloyd Subject: RE: Back to basics Cc: In-Reply-To: <199902041751.JAA16217@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 09:48 AM 2/4/99 -0800, Patrice Calhoun wrote: >Obviously you mis-understood my statement. Two "base protocol" peers must >be able to exchange packets. These packets must be authenticated, and perhaps >encrypted. This is completely outside of the authetication of the user or >device. > >Agreed? Perhaps I am being intentionally obtuse. IMHO, what you have is two peers who must authenticate and authorize each other. This strikes me as a special case of the general "authenticate and authorize a user" case. The service request is implied by virtue of knowing that these two entities are "peers doing AAA", but somewhere, someone has to make the decision to authorize this. It seems conceivable to me that, at some point in the future, we might centrally authorize the peers and they must AA each other with the central server. Now this looks more like the general case. So maybe we are agreeing violently but I really want to examine all our assumptions. Frankly, I am operating under the assumption that "properly viewed everything looks like remote access" has yet to be proven. There is a chance you are correct but please humor me. :^) 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-wg@merit.edu Thu Feb 4 14:00:03 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA03043 for ; Thu, 4 Feb 1999 14:00:03 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA18298 for aaa-wg-outgoing; Thu, 4 Feb 1999 13:59:54 -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 NAA18294 for ; Thu, 4 Feb 1999 13:59:49 -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 KAA26963; Thu, 4 Feb 1999 10:57:54 -0800 (PST) Message-Id: <3.0.6.32.19990204105655.009492e0@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 10:56:55 -0800 To: "Basavaraj Patil" From: Brian Lloyd Subject: RE: Back to basics Cc: aaa-wg@merit.edu In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5022D5E65@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 12:51 PM 2/4/99 -0500, Basavaraj Patil wrote: >Brian, > >I think you are putting the authorization (the least understood so >far) aspect of AAA in a better perspective now with your example. Just >to extrapolate on what you suggested I believe when "entity p" wants >to do action 'x', some entity needs to figure out what are the >resources that would be required to accomplish task 'x'. The >responsibility of the authorization server would be to verify if >'entity p' has the privileges to do action 'x' and if he does then to >authorize the use of those resources. To accomplish a task 'x' >multiple resources in the network may need to be authorized and this >aspect needs to be considered within the AAA discussions. Absolutely! You stated it much better than I. >When I look >at the NAS the only authorization that happens in this case is the >allocation of a modem and this is probably an implicit result of the >user being authenticated. Is there an authorization request that is >sent out by the NAS subsequent to authentication for allocation of a >modem? (somebody can educate me here). Well, you authorize the use of a modem but you also return configuration information about how to establish the session with the network. That is why I keep mentioning the word "configuration" in conjunction with "authorization." This takes the exhchange from: C: May 'p' do 'x'? S: Yes. to: C: May 'p' do 'x'? S: Yes, and here is how ... These things may involve setting up tunnels, verifying that the user isn't logged on too many times, etc. This we already understand as a result of doing RADIUS for so many years. Now we need to perform this analysis for other types of applications. >It may be possible to trigger an authentication request as a result of >an authorization request to some resource in certain applications. Also true in my opinion but I am not yet prepared to conceed that you MUST peform an authentication request in conjunction with an authorization request. Likewise I am not prepared to conceed that you MUST peform an authorization request in conjunction with an authentication request although I am far less comfortable making this assertion. Example: I walk up to a teller in a bank to request a transaction. The teller wants me to authenticate using something stronger than my pretty face (it is quite common to have the tellers now request that I use my bank card to authenticate) before even asking me what my transaction is. This is an authentication without an authorization. But, the teller, by virtue of being the teller, is allowed to verify if I am authorized to transfer funds out of a particular account without having to authenticate as me. This is an authorization without an authentication. OK, so this is not precisely like transactions we are working on in the net but our AAA algorithms should work regardless of the actual transactions being discussed. We also need to think about the problem of which entities are allowed to do authentication requests and which are allowed to do authorization requests. Recursively speaking, this sounds like an authorization request to me. Is this sufficiently confusing or do I need to work harder at this? ;^) 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-wg@merit.edu Thu Feb 4 14:02:01 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA03068 for ; Thu, 4 Feb 1999 14:02:01 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id OAA18327 for aaa-wg-outgoing; Thu, 4 Feb 1999 14:01:50 -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 OAA18320 for ; Thu, 4 Feb 1999 14:01:43 -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 KAA26960; Thu, 4 Feb 1999 10:57:52 -0800 (PST) Message-Id: <3.0.6.32.19990204103658.00955740@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 10:36:58 -0800 To: "Basavaraj Patil" From: Brian Lloyd Subject: RE: Back to basics Cc: aaa-wg@merit.edu In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5022D5E67@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 01:07 PM 2/4/99 -0500, Basavaraj Patil wrote: >Brian Lloyd wrote: >>The authentication takes place between the user and the web server. As I >>see it, the web kiosk isn't involved therefore there is no roming involved. >> Am I confused here? > >The kiosk may be owned by a service provider'A' who is not necessarily >your service provider 'B'. The usage of the kiosk by you is authenticated >by your service provider 'B' and you receive a bill for that from 'B'. The >kiosk service provider 'A' is not the one who would bill you. Some >settlement happens between the service providers. The roaming aspect >in this scenario is from a user/service perspective, which in this case is >access to some service from a device (kiosk). Thank you. I stand corrected. 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-wg@merit.edu Thu Feb 4 14:10:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA03189 for ; Thu, 4 Feb 1999 14:10:42 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id OAA18544 for aaa-wg-outgoing; Thu, 4 Feb 1999 14:10:26 -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 OAA18537 for ; Thu, 4 Feb 1999 14:10:17 -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 LAA27066; Thu, 4 Feb 1999 11:09:52 -0800 (PST) Message-Id: <3.0.6.32.19990204110851.00924e40@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 11:08:51 -0800 To: From: Brian Lloyd Subject: RE: Back to basics Cc: aaa-wg@merit.edu In-Reply-To: <199902041845.KAA03773@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 10:42 AM 2/4/99 -0800, Patrice Calhoun wrote: >>It may be possible to trigger an authentication request as a result of >>an authorization request to some resource in certain applications. > >I believe that one way of achieving this is for the AAA server to create a >session token when the user is authenticated. This token is used in subsequent >authorization requests. The token would be signed by the AAA server, which >then means that if the provider has many AAA servers, they would have to share >a single private key (I think - but if someone has a better method, please let >me know). > >The token would have a lifetime, and would have to be periodically refreshed. Sounds like you are reinventing Kerberos. Actually I would like to leave these kinds of details to a later discussion. I want to be sure we all agree on the forest before we start describing the individual trees. Metaissue: do we need several discussion threads here? I think we have beaten the subject line "Back to basics" to death. 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-wg@merit.edu Thu Feb 4 15:47:41 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA04449 for ; Thu, 4 Feb 1999 15:47:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA21005 for aaa-wg-outgoing; Thu, 4 Feb 1999 15:45:31 -0500 (EST) Received: from mail.iphighway.com ([209.3.6.75]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA20993 for ; Thu, 4 Feb 1999 15:45:23 -0500 (EST) Received: from shai-notebook (SHAI_NOTEBOOK [209.3.6.105]) by mail.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1JD2SM0Z; Thu, 4 Feb 1999 15:43:54 -0500 Message-Id: <4.1.19990204151335.03d6ccb0@mail.iphighway.com> X-Sender: herzog@mail.iphighway.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Feb 1999 15:33:36 -0500 To: "Basavaraj Patil" , "'Durham, David'" , aaa-wg@merit.edu From: Shai Herzog Subject: RE: Back to basics In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5022D5E62@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 11:44 AM 2/4/99, Basavaraj Patil wrote: > The AAA base protocol itself >will not necessarily have any specific authentication schemes as you >suggest. It only provides the means to do whatever authentication >scheme required by the application. I don't think I know how to design a protocol to do "whatever"; if I could program it once, sell it to everyone, and make millions ;-) Seriously, I agree with Brian about the need to define the problem we are trying to solve first, then go to requirements, and only then discuss protocol. I understand that this may be a long road, and some of us would like to see a quicker short-cut. This is where "less is more" comes to mind: If we had a well defined, specific problem at hand, we could have gone quickly through problem definition and requirements and reach a protocol decision (See RAP) but one cannot have the cake and eat it to. I don't have any illusions about it. When we go down the generic direction we are making a decision to take the long and winding road. The main problem is that when people say "whatever" they actually means "the problem I have in my mind" which tend to be quite different from someone elses. (Brian's vs. PatC). (it may just be my impression but it seem that protocols that do "whatever" tend to fail later on when faced with real requirements). So, I guess I am saying that we must choose whether to take the long road to define a very generic mechanism, or take the faster road and define a unified solution for N AAA problems we already know. I (obviously) vote toward the later. Things would become much clearer if we list N specific AAA problems the WG is trying to solve and completely put aside the "whatever" clause. Further more, the N may be reduced even more if we find out some of the previously thought of problems have different requirements. Sorry for the long note... Shai __________________________________________________________ Shai Herzog Founder & CTO, IPHighway Inc. Cell: (408) 390-3045 http://www.iphighway.com/herzog Tel : (201) 585-0800 Fax : (212) 656-1006 From owner-aaa-wg@merit.edu Thu Feb 4 16:56:11 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA05191 for ; Thu, 4 Feb 1999 16:56:11 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA22530 for aaa-wg-outgoing; Thu, 4 Feb 1999 16:55: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 SMTP id QAA22526 for ; Thu, 4 Feb 1999 16:55:09 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA09932; Thu, 4 Feb 1999 13:54:00 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.123.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA18314; Thu, 4 Feb 1999 13:53:58 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00495; Thu, 4 Feb 1999 13:53:44 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902042153.NAA00495@hsmpka.eng.sun.com> Date: Thu, 4 Feb 1999 13:50:32 -0800 To: "Brian Lloyd" , "Basavaraj Patil" Cc: Reply-To: Subject: Split Authentication and Authorization 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 12:51 PM 2/4/99 -0500, Basavaraj Patil wrote: >>Brian, >> >>I think you are putting the authorization (the least understood so >>far) aspect of AAA in a better perspective now with your example. Just >>to extrapolate on what you suggested I believe when "entity p" wants >>to do action 'x', some entity needs to figure out what are the >>resources that would be required to accomplish task 'x'. The >>responsibility of the authorization server would be to verify if >>'entity p' has the privileges to do action 'x' and if he does then to >>authorize the use of those resources. To accomplish a task 'x' >>multiple resources in the network may need to be authorized and this >>aspect needs to be considered within the AAA discussions. > >Absolutely! You stated it much better than I. > >>When I look >>at the NAS the only authorization that happens in this case is the >>allocation of a modem and this is probably an implicit result of the >>user being authenticated. Is there an authorization request that is >>sent out by the NAS subsequent to authentication for allocation of a >>modem? (somebody can educate me here). > >Well, you authorize the use of a modem but you also return configuration >information about how to establish the session with the network. That is >why I keep mentioning the word "configuration" in conjunction with >"authorization." This takes the exhchange from: > > C: May 'p' do 'x'? > S: Yes. > >to: > > C: May 'p' do 'x'? > S: Yes, and here is how ... > >These things may involve setting up tunnels, verifying that the user isn't >logged on too many times, etc. This we already understand as a result of >doing RADIUS for so many years. Now we need to perform this analysis for >other types of applications. > >>It may be possible to trigger an authentication request as a result of >>an authorization request to some resource in certain applications. > >Also true in my opinion but I am not yet prepared to conceed that you MUST >peform an authentication request in conjunction with an authorization >request. > >Likewise I am not prepared to conceed that you MUST peform an authorization >request in conjunction with an authentication request although I am far >less comfortable making this assertion. > >Example: I walk up to a teller in a bank to request a transaction. The >teller wants me to authenticate using something stronger than my pretty >face (it is quite common to have the tellers now request that I use my bank >card to authenticate) before even asking me what my transaction is. This >is an authentication without an authorization. But, the teller, by virtue >of being the teller, is allowed to verify if I am authorized to transfer >funds out of a particular account without having to authenticate as me. >This is an authorization without an authentication. > >OK, so this is not precisely like transactions we are working on in the net >but our AAA algorithms should work regardless of the actual transactions >being discussed. > >We also need to think about the problem of which entities are allowed to do >authentication requests and which are allowed to do authorization requests. > Recursively speaking, this sounds like an authorization request to me. > >Is this sufficiently confusing or do I need to work harder at this? ;^) > You are correct. This was part of the DIAMETER design to allow this type of functionality. However, just because the functionality exists does not mean that it should always be used. Case in point, TACACS+. The people responsible for it agree that always having a separate exchange is not necessarily a good idea. So, what we should strive for is a method to authenticate, and optionally authorize ( and the other way around). PatC From owner-aaa-wg@merit.edu Thu Feb 4 17:55:45 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA06199 for ; Thu, 4 Feb 1999 17:55:45 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA23493 for aaa-wg-outgoing; Thu, 4 Feb 1999 17:54:57 -0500 (EST) Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA23489; Thu, 4 Feb 1999 17:54:50 -0500 (EST) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id LAA27137; Fri, 5 Feb 1999 11:54:45 +1300 (NZDT) From: Nevil Brownlee To: aaa-wg@merit.edu Cc: skh@merit.edu Subject: A structure for Accounting (?) In-Reply-To: <199901301509.KAA16542@idrp.merit.edu> Message-ID: Date: Fri, 5 Feb 1999 12:05:22 +1300 (New Zealand Daylight Time) X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello all: Back in November we had a brief discussion on the AAA and RTFM lists about RTFM requirements for AAA. Looking back, the outcome of that discussion was that Accounting - as viewed by AAA - seems to mean something like "making it possible for accounting data to be gathered by an 'aggregation agent.'" An aggregation agent would be a process which an interested party (e.g. an ISP) runs, and which gathers together usage data for all that party's customers. Examples of data sources for aggregation include Network Access Servers (association of user ids with IP addresses, including session start/stop times), RTFM meters (traffic flow usage data associated with IP adresses) and so on. Note that I assume an NAS will authenticate the user, and verify the user is authorised to start an IP session before actually allocating the IP address). Does this seem a reasonable view of a structure to support generalised usage accounting? Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From owner-aaa-wg@merit.edu Thu Feb 4 18:14:54 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA06336 for ; Thu, 4 Feb 1999 18:14:53 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA23930 for aaa-wg-outgoing; Thu, 4 Feb 1999 18:14:17 -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 SAA23924 for ; Thu, 4 Feb 1999 18:14:10 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7CSMHOPKW8ZG1LP@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 4 Feb 1999 18:13:36 EST Date: Thu, 04 Feb 1999 15:13:25 -0800 From: Paul Krumviede Subject: Re: Split Authentication and Authorization To: AAA wg Reply-to: paul@mci.net Message-id: <36BA2998.F4CEA006@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199902042153.NAA00495@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Patrice Calhoun wrote: > > >At 12:51 PM 2/4/99 -0500, Basavaraj Patil wrote: > >>Brian, > >> > >>I think you are putting the authorization (the least understood so > >>far) aspect of AAA in a better perspective now with your example. Just > >>to extrapolate on what you suggested I believe when "entity p" wants > >>to do action 'x', some entity needs to figure out what are the > >>resources that would be required to accomplish task 'x'. The > >>responsibility of the authorization server would be to verify if > >>'entity p' has the privileges to do action 'x' and if he does then to > >>authorize the use of those resources. To accomplish a task 'x' > >>multiple resources in the network may need to be authorized and this > >>aspect needs to be considered within the AAA discussions. > > > >Absolutely! You stated it much better than I. The fundamental problem is that at time T user U authenticates, and maybe some authorization is done then, maybe not. Now at time T+n, something makes an authorization request, claiming to U or acting on behalf of U. Why should I believe this latter claim? The need, as I see it, is that there be established some binding between an authentication and a subsequent authorization request. This can take the form of something that can be evaluated later, so the binding does not need to be instantaneous in time (Kerberos tickets are an example). For some services, such as those that are providing cryptographic services, there are strong technical reasons to want to authenticate parties, negotiate algorithms, and do key agreement in a tightly coupled fashion, preventing a whole range of cryptographic attacks. For other types of services, this tight coupling may not be necessary. > >>When I look > >>at the NAS the only authorization that happens in this case is the > >>allocation of a modem and this is probably an implicit result of the > >>user being authenticated. Is there an authorization request that is > >>sent out by the NAS subsequent to authentication for allocation of a > >>modem? (somebody can educate me here). > > > >Well, you authorize the use of a modem but you also return configuration > >information about how to establish the session with the network. That is > >why I keep mentioning the word "configuration" in conjunction with > >"authorization." This takes the exhchange from: > > > > C: May 'p' do 'x'? > > S: Yes. > > > >to: > > > > C: May 'p' do 'x'? > > S: Yes, and here is how ... > > > >These things may involve setting up tunnels, verifying that the user isn't > >logged on too many times, etc. This we already understand as a result of > >doing RADIUS for so many years. Now we need to perform this analysis for > >other types of applications. In one sense, this isn't really true. In most cases, a user can't come back and ask for a new service (lets say a new tunnel, or maybe now some QoS). Choosing to authorize such a request in the absence of some proof of the user requires something like trusting the requesting equipment (to the extent that a user who denies making that request can be convincingly show to have made that request, perhaps in court), or another authentication exchange, or something similar (in function) to a Kerberos ticket to convince the authorizing party that the requesting party is correctly representing the requesting entity. > >>It may be possible to trigger an authentication request as a result of > >>an authorization request to some resource in certain applications. > > > >Also true in my opinion but I am not yet prepared to conceed that you MUST > >peform an authentication request in conjunction with an authorization > >request. Other than for some specific, very constrained situations, I don't think one MUST do this. > >Likewise I am not prepared to conceed that you MUST peform an authorization > >request in conjunction with an authentication request although I am far > >less comfortable making this assertion. Again, other than some stringent crypto cases, this is also correct (as far as I can tell, at least :-). > >Example: I walk up to a teller in a bank to request a transaction. The > >teller wants me to authenticate using something stronger than my pretty > >face (it is quite common to have the tellers now request that I use my bank > >card to authenticate) before even asking me what my transaction is. This > >is an authentication without an authorization. But, the teller, by virtue > >of being the teller, is allowed to verify if I am authorized to transfer > >funds out of a particular account without having to authenticate as me. > >This is an authorization without an authentication. > > > >OK, so this is not precisely like transactions we are working on in the net > >but our AAA algorithms should work regardless of the actual transactions > >being discussed. But we're trying to design protocols that will allow algorithms to work, not to design algorithms (or are we doing the latter as well?). > >We also need to think about the problem of which entities are allowed to do > >authentication requests and which are allowed to do authorization requests. > > Recursively speaking, this sounds like an authorization request to me. > > > >Is this sufficiently confusing or do I need to work harder at this? ;^) > > > You are correct. This was part of the DIAMETER design to allow this type of > functionality. However, just because the functionality exists does not mean > that it should always be used. Case in point, TACACS+. The people responsible > for it agree that always having a separate exchange is not necessarily a > good idea. So, what we should strive for is a method to authenticate, and > optionally authorize ( and the other way around). Other than denial of service issues, I think any entity can make either type of request. The recipient of such a request gets to decide if they wish to respond at all, and may then get to decide if given the nature of the request and the supporting info, it wants to grant it (attempt to authenticate something, and/or attempt to authorize it). This may involve some recursion. -paul From owner-aaa-wg@merit.edu Thu Feb 4 18:21:51 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA06372 for ; Thu, 4 Feb 1999 18:21:51 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA24095 for aaa-wg-outgoing; Thu, 4 Feb 1999 18:21:40 -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 SAA24086 for ; Thu, 4 Feb 1999 18:21:32 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7CSVLW4DW8ZG21A@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 4 Feb 1999 18:20:54 EST Date: Thu, 04 Feb 1999 15:20:46 -0800 From: Paul Krumviede Subject: authentication keys for multiple aaa servers To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36BA2B50.FD7245A4@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199902041845.KAA03773@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Patrice Calhoun wrote: [I lost an attribution in here.] > >It may be possible to trigger an authentication request as a result of > >an authorization request to some resource in certain applications. > > I believe that one way of achieving this is for the AAA server to create a > session token when the user is authenticated. This token is used in subsequent > authorization requests. The token would be signed by the AAA server, which > then means that if the provider has many AAA servers, they would have to share > a single private key (I think - but if someone has a better method, please let > me know). If we're talking a public key type service, than each server can have its own key pair and certificate, signed by the service provider in some form of hierarchy. Then would be relying parties only need the service provider's root CA key(s) (if maybe they have lots of roots, like AT&T). Scales, you only have to check CRL's, I can add a new server with a new key and cert without having to tell everybody in the world, etc. Gets messy if the root CA key is compromised. -paul From owner-aaa-wg@merit.edu Thu Feb 4 18:30:53 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA06440 for ; Thu, 4 Feb 1999 18:30:53 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA24233 for aaa-wg-outgoing; Thu, 4 Feb 1999 18:30:31 -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 SAA24229 for ; Thu, 4 Feb 1999 18:30:26 -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 PAA29375; Thu, 4 Feb 1999 15:30:13 -0800 (PST) Message-Id: <3.0.6.32.19990204152303.0094ca10@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 15:23:03 -0800 To: Shai Herzog From: Brian Lloyd Subject: RE: Back to basics Cc: aaa-wg@merit.edu In-Reply-To: <4.1.19990204151335.03d6ccb0@mail.iphighway.com> References: <31B1EFDD2CD3D11187710000F805A8D5022D5E62@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 03:33 PM 2/4/99 -0500, Shai Herzog wrote: > >Seriously, I agree with Brian about the need to define the problem we >are trying to solve first, then go to requirements, and only then discuss >protocol. Thank you for your support. >So, I guess I am saying that we must choose whether to take the long >road to define a very generic mechanism, or take the faster road and >define a unified solution for N AAA problems we already know. I (obviously) >vote toward the later. Things would become much clearer if we list N >specific AAA problems the WG is trying to solve and completely put >aside the "whatever" clause. Further more, the N may be reduced even more >if we find out some of the previously thought of problems have >different requirements. This is something that I am hoping to accomplish here. We need to get the set of AAA applications on the table and then go through the AAA process and data requirements for each one in hopes of seeing the commonality and insuring that we actually come up with something more universal. 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-wg@merit.edu Thu Feb 4 19:05:14 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA06805 for ; Thu, 4 Feb 1999 19:05:14 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id TAA24671 for aaa-wg-outgoing; Thu, 4 Feb 1999 19:04:56 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id TAA24667 for ; Thu, 4 Feb 1999 19:04:50 -0500 (EST) Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprtp.nortel.com; Thu, 4 Feb 1999 19:04:27 -0500 Received: by zrtpd00m.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HH5Z44F>; Thu, 4 Feb 1999 19:04:25 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5023C5A95@crchy270.us.nortel.com> From: "Emad Qaddoura" To: "'Shai Herzog'" Cc: "'Durham, David'" , "Basavaraj Patil" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Thu, 4 Feb 1999 18:49:26 -0500 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 Shai, > "So, I guess I am saying that we must choose whether to take the long >road to define a very generic mechanism, or take the faster road and >define a unified solution for N AAA problems we already know. I (obviously) >vote toward the later. Things would become much clearer if we list N >specific AAA problems the WG is trying to solve and completely put >aside the "whatever" clause. Further more, the N may be reduced even more >if we find out some of the previously thought of problems have >different requirements" Or is there something in the middle? The risk of solving the problem for the N AAA problems of today and not plan for the future may allow the later solutions which did not focus on the generic aspect to be totally new solution, we just don't know at this time. However, from todays' N list, there may be enough experience to define the generic aspect which Raj referred to as "Whatever". > -----Original Message----- > From: Shai Herzog [SMTP:herzog@iphighway.com] > Sent: Thursday, February 04, 1999 2:34 PM > To: Patil, Basavaraj [RICH2:IP10:EXCH]; 'Durham, David'; > aaa-wg@merit.edu > Subject: RE: Back to basics > > > > > At 11:44 AM 2/4/99, Basavaraj Patil wrote: > > The AAA base protocol itself > >will not necessarily have any specific authentication schemes as you > >suggest. It only provides the means to do whatever authentication > >scheme required by the application. > > I don't think I know how to design a protocol to do "whatever"; if > I could program it once, sell it to everyone, and make millions ;-) > > Seriously, I agree with Brian about the need to define the problem we > are trying to solve first, then go to requirements, and only then discuss > protocol. > > I understand that this may be a long road, and some of us would like to > see a quicker short-cut. This is where "less is more" comes to mind: > If we had a well defined, specific problem at hand, we could have gone > quickly through problem definition and requirements and reach a protocol > decision (See RAP) but one cannot have the cake and eat it to. > > I don't have any illusions about it. When we go down the generic direction > we are making a decision to take the long and winding road. > > The main problem is that when people say "whatever" they actually > means "the problem I have in my mind" which tend to be quite different > from someone elses. (Brian's vs. PatC). (it may just be my impression > but it seem that protocols that do "whatever" tend to fail > later on when faced with real requirements). > > So, I guess I am saying that we must choose whether to take the long > road to define a very generic mechanism, or take the faster road and > define a unified solution for N AAA problems we already know. I > (obviously) > vote toward the later. Things would become much clearer if we list N > specific AAA problems the WG is trying to solve and completely put > aside the "whatever" clause. Further more, the N may be reduced even more > if we find out some of the previously thought of problems have > different requirements. > > Sorry for the long note... > > Shai > > > __________________________________________________________ > Shai Herzog Founder & CTO, IPHighway Inc. > Cell: (408) 390-3045 http://www.iphighway.com/herzog > Tel : (201) 585-0800 Fax : (212) 656-1006 From owner-aaa-wg@merit.edu Thu Feb 4 21:07: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 VAA07821 for ; Thu, 4 Feb 1999 21:07:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA26220 for aaa-wg-outgoing; Thu, 4 Feb 1999 21:06:35 -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 VAA26215 for ; Thu, 4 Feb 1999 21:06:31 -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 SAA00534; Thu, 4 Feb 1999 18:06:11 -0800 (PST) Message-Id: <3.0.6.32.19990204180353.00953260@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 04 Feb 1999 18:03:53 -0800 To: paul@mci.net From: Brian Lloyd Subject: Re: Split Authentication and Authorization Cc: AAA wg In-Reply-To: <36BA2998.F4CEA006@mci.net> References: <199902042153.NAA00495@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:13 PM 2/4/99 -0800, Paul Krumviede wrote: >The fundamental problem is that at time T user U authenticates, and maybe >some authorization is done then, maybe not. Now at time T+n, something >makes an authorization request, claiming to U or acting on behalf of U. >Why should I believe this latter claim? I am not asking you to connect the two events at all. They are separate. I was just stating that you can make an authorization request without ever authenticating. The question is, "is U allowed to do X." The answer is, "yes, and here is how." This has nothing to do with the question, "is this entity that purports to be U really U?" >The need, as I see it, is that there be established some binding between >an authentication and a subsequent authorization request. This can take >the form of something that can be evaluated later, so the binding does >not need to be instantaneous in time (Kerberos tickets are an example). > >For some services, such as those that are providing cryptographic >services, there are strong technical reasons to want to authenticate >parties, negotiate algorithms, and do key agreement in a tightly >coupled fashion, preventing a whole range of cryptographic attacks. >For other types of services, this tight coupling may not be necessary. OK, we appear to be in sync here. I am not advocating that *all* authentications must be separate from all authorizations, only that they may be and that any AA protocol we adopt should accommodate both decoupled and coupled authentications/authorizations. >> >These things may involve setting up tunnels, verifying that the user isn't >> >logged on too many times, etc. This we already understand as a result of >> >doing RADIUS for so many years. Now we need to perform this analysis for >> >other types of applications. > >In one sense, this isn't really true. In most cases, a user can't come >back and ask for a new service (lets say a new tunnel, or maybe now some >QoS). Choosing to authorize such a request in the absence of some proof >of the user requires something like trusting the requesting equipment (to >the extent that a user who denies making that request can be convincingly >shown to have made that request, perhaps in court), or another authentication >exchange, or something similar (in function) to a Kerberos ticket to convince >the authorizing party that the requesting party is correctly representing >the requesting entity. It is up to the requesting party to ensure that it is properly representing the originally requesting entity. (I was going to make an example using a dial up user and a NAS but I want to get away from that model for awhile. We have used it so much that I think we tend to accept that as the generic model.) >> >Also true in my opinion but I am not yet prepared to conceed that you MUST >> >peform an authentication request in conjunction with an authorization >> >request. > >Other than for some specific, very constrained situations, I don't think >one MUST do this. Thank you. >> >Likewise I am not prepared to conceed that you MUST peform an authorization >> >request in conjunction with an authentication request although I am far >> >less comfortable making this assertion. > >Again, other than some stringent crypto cases, this is also correct (as >far as I can tell, at least :-). Are we agreeing violently yet? :^) >But we're trying to design protocols that will allow algorithms to work, >not to design algorithms (or are we doing the latter as well?). Can you really separate them? The protocol has to allow me to perform the tasks I wish to perform, therefore we at least need to know something about the algorithms. 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-wg@merit.edu Thu Feb 4 21:43:47 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id VAA08058 for ; Thu, 4 Feb 1999 21:43:47 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA26663 for aaa-wg-outgoing; Thu, 4 Feb 1999 21:43:31 -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 VAA26655 for ; Thu, 4 Feb 1999 21:43:26 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7CZX1GOV68ZG1V6@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 4 Feb 1999 21:42:54 EST Date: Thu, 04 Feb 1999 18:42:46 -0800 From: Paul Krumviede Subject: Re: Split Authentication and Authorization To: AAA wg Reply-to: paul@mci.net Message-id: <36BA5A7B.D7D73A13@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199902042153.NAA00495@hsmpka.eng.sun.com> <3.0.6.32.19990204180353.00953260@127.0.0.1> Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian Lloyd wrote: > > At 03:13 PM 2/4/99 -0800, Paul Krumviede wrote: > >The fundamental problem is that at time T user U authenticates, and maybe > >some authorization is done then, maybe not. Now at time T+n, something > >makes an authorization request, claiming to U or acting on behalf of U. > >Why should I believe this latter claim? > > I am not asking you to connect the two events at all. They are separate. > I was just stating that you can make an authorization request without ever > authenticating. The question is, "is U allowed to do X." The answer is, > "yes, and here is how." This has nothing to do with the question, "is this > entity that purports to be U really U?" I'm saying that one has to be able to do this connection. One may choose not to do it for certain cases, but any authorization request for a service for which I can do a discrete billing transaction may require some such coupling. Otherwise I'm going to flood the service provider with requests for a service purporting to be you, and attempt to drive you into bankruptcy. Or I'm going to issue a lot of (expensive) requests, get the service, and deny having requested it, and we can fight it out in court. The inability to verify the identity (and associated permissions and billing relationships) would render such a protocol framework extremely risky, and probably of insufficient interest to me and my employer. Note that I am not saying I want to do this on every, or even many, authorization requests, but the capability is, I think, mandatory. > >The need, as I see it, is that there be established some binding between > >an authentication and a subsequent authorization request. This can take > >the form of something that can be evaluated later, so the binding does > >not need to be instantaneous in time (Kerberos tickets are an example). > > > >For some services, such as those that are providing cryptographic > >services, there are strong technical reasons to want to authenticate > >parties, negotiate algorithms, and do key agreement in a tightly > >coupled fashion, preventing a whole range of cryptographic attacks. > >For other types of services, this tight coupling may not be necessary. > > OK, we appear to be in sync here. I am not advocating that *all* > authentications must be separate from all authorizations, only that they > may be and that any AA protocol we adopt should accommodate both decoupled > and coupled authentications/authorizations. Yes, where they may be all sorts of possible bindings, on different time scales, etc. I agree that it should support both. > >> >These things may involve setting up tunnels, verifying that the user isn't > >> >logged on too many times, etc. This we already understand as a result of > >> >doing RADIUS for so many years. Now we need to perform this analysis for > >> >other types of applications. > > > >In one sense, this isn't really true. In most cases, a user can't come > >back and ask for a new service (lets say a new tunnel, or maybe now some > >QoS). Choosing to authorize such a request in the absence of some proof > >of the user requires something like trusting the requesting equipment (to > >the extent that a user who denies making that request can be convincingly > >shown to have made that request, perhaps in court), or another authentication > >exchange, or something similar (in function) to a Kerberos ticket to convince > >the authorizing party that the requesting party is correctly representing > >the requesting entity. > > It is up to the requesting party to ensure that it is properly representing > the originally requesting entity. (I was going to make an example using a > dial up user and a NAS but I want to get away from that model for awhile. > We have used it so much that I think we tend to accept that as the generic > model.) Yes, but there are some interesting questions as to transitivity of this. > >> >Also true in my opinion but I am not yet prepared to conceed that you MUST > >> >peform an authentication request in conjunction with an authorization > >> >request. > > > >Other than for some specific, very constrained situations, I don't think > >one MUST do this. > > Thank you. > > >> >Likewise I am not prepared to conceed that you MUST peform an > authorization > >> >request in conjunction with an authentication request although I am far > >> >less comfortable making this assertion. > > > >Again, other than some stringent crypto cases, this is also correct (as > >far as I can tell, at least :-). > > Are we agreeing violently yet? :^) Probably :-) > >But we're trying to design protocols that will allow algorithms to work, > >not to design algorithms (or are we doing the latter as well?). > > Can you really separate them? The protocol has to allow me to perform the > tasks I wish to perform, therefore we at least need to know something about > the algorithms. Knowing about the algorithm(s) to support is one thing, and I agree that is necessary, but I'm not sure we want to design new algorithms (e.g. we can say that we should support a few variants of challenge response, EKE, variants of Diffie-Hellman key agreement with different numbers of rounds to authenticate the participants, etc. but not define a new algorithm). And by now I've lost track of why I was trying to make the distinction :-( -paul From owner-aaa-wg@merit.edu Fri Feb 5 01:30:44 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id BAA09485 for ; Fri, 5 Feb 1999 01:30:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA28711 for aaa-wg-outgoing; Fri, 5 Feb 1999 01:30:13 -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 BAA28705 for ; Fri, 5 Feb 1999 01:30:08 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7D7TU1F008ZG1JN@shoe.reston.mci.net> for aaa-wg@merit.edu; Fri, 5 Feb 1999 01:29:37 EST Date: Thu, 04 Feb 1999 12:16:17 -0800 From: Paul Krumviede Subject: Re: Back to basics To: AAA wg Reply-to: paul@mci.net Message-id: <36BA000F.783C883B@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <199902041525.HAA09720@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Patrice Calhoun wrote: > >But this is only true for network access. If I'm trying to implement an > >authentication and authorization framework for users requesting QoS, > >particularly for (say) web-hosting. There is no roaming in that scenario. > > Is this true? As I user I happen to be at the airport and use a web kiosk. > I would, ideally, not have to worry about who owns the kiosk, use the service > and receive a single bill from my home provider. This is no different than > how my calling card works. Yes. The "user" requesting the QoS service is the web server that I'm hosting, not the other end. While that service may move to another provider, it isn't likely to happen quickly. I'm not saying that your example is not going to happen, but I view it as a variant of the remote access issue (since it is effectively additional parameters on the access, although it may be finer grained). -paul From owner-aaa-wg@merit.edu Fri Feb 5 01:30:47 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id BAA09492 for ; Fri, 5 Feb 1999 01:30:47 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id BAA28725 for aaa-wg-outgoing; Fri, 5 Feb 1999 01:30:32 -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 BAA28718 for ; Fri, 5 Feb 1999 01:30:27 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7D7UIHWBA8ZG1JN@shoe.reston.mci.net> for aaa-wg@merit.edu; Fri, 5 Feb 1999 01:29:56 EST Date: Thu, 04 Feb 1999 22:10:43 -0800 From: Paul Krumviede Subject: Re: A structure for Accounting (?) To: Nevil Brownlee Cc: AAA wg Reply-to: paul@mci.net Message-id: <36BA8B5B.52E5A00B@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-aaa-bof@merit.edu Precedence: bulk Nevil Brownlee wrote: > > Hello all: > > Back in November we had a brief discussion on the AAA and RTFM lists > about RTFM requirements for AAA. Looking back, the outcome of that > discussion was that Accounting - as viewed by AAA - seems to mean > something like "making it possible for accounting data to be gathered by > an 'aggregation agent.'" > > An aggregation agent would be a process which an interested party (e.g. > an ISP) runs, and which gathers together usage data for all that party's > customers. > > Examples of data sources for aggregation include Network Access Servers > (association of user ids with IP addresses, including session start/stop > times), RTFM meters (traffic flow usage data associated with IP > adresses) and so on. Note that I assume an NAS will authenticate the > user, and verify the user is authorised to start an IP session before > actually allocating the IP address). > > Does this seem a reasonable view of a structure to support generalised > usage accounting? I think we came to realize that people meant a few different things, implicitly or explicitly, when they said "accounting." Let me call it resource utilization data. There are at least 2 distinct uses for such data: network engineering (capacity planning, service provisioning, what have you) and rating and billing. A related use is in a service that is implemented using hard state information maintained in service elements (a simple example is IP addresses allocated to a dial-up user, a complex example being QoS resources for a multicast group), where I may need to unwind such resource allocation over time (as a multicast group member joins or is dropped, as a call terminates). The time scale over which I want such information to be delivered, and acted upon, seems to depend on the use to which I am putting that information. For capacity planning, I don't need that data in anything near real-time. I may need it for resource management, although that could depend on how I'm allocating and managing resources internally. Use of the data for billing (where I get to rate/price it and somehow convert it into a bill) may be the trickiest case of all (simple if a pre-paid calling card model, tricky if there is a tiered pricing structure based on volume, where the eventual price of this service instance depends on your future utilization). So this is perhaps a lengthy way of saying I think we need a more nuanced, or perhaps context sensitive, view of "accounting" and the necessary support for it. For example, I'm willing to consider having the same information sent multiple times, perhaps on different time scales, if that turns out to be easier to handle than saying "pass all the usage data through an aggregation point which gets to redistribute, and possibly replicate, the data to all the other things that might want to look at it now or in the future." -paul From owner-aaa-wg@merit.edu Fri Feb 5 07:40:30 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id HAA12542 for ; Fri, 5 Feb 1999 07:40:29 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id HAA02829 for aaa-wg-outgoing; Fri, 5 Feb 1999 07:37:02 -0500 (EST) Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49]) by merit.edu (8.9.1a/8.9.1) with ESMTP id HAA02825 for ; Fri, 5 Feb 1999 07:36:58 -0500 (EST) Received: from omss5.mcit.com (omss5-fddi.mcit.com [166.37.204.27]) by omzrelay.mcit.com (8.8.7/) with ESMTP id LAA01903; Fri, 5 Feb 1999 11:35:21 GMT Received: from sinnreich2 ([166.44.130.195]) by omss5.mcit.com (InterMail v03.02.05 118 120) with SMTP id <19990205123553.FSWZ28868@[166.44.130.195]>; Fri, 5 Feb 1999 06:35:53 -0600 From: "Henry Sinnreich" To: , "Nevil Brownlee" Cc: "AAA wg" Subject: RE: A structure for Accounting (?) Date: Fri, 5 Feb 1999 06:35:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal In-Reply-To: <36BA8B5B.52E5A00B@mci.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Need to be able to show the running meter during a phone call, as already provided in the IP telephony industry. Thanks, Henry > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Paul Krumviede > Sent: Friday, February 05, 1999 1:11 AM > To: Nevil Brownlee > Cc: AAA wg > Subject: Re: A structure for Accounting (?) > > > Nevil Brownlee wrote: > > > > Hello all: > > > > Back in November we had a brief discussion on the AAA and RTFM lists > > about RTFM requirements for AAA. Looking back, the outcome of that > > discussion was that Accounting - as viewed by AAA - seems to mean > > something like "making it possible for accounting data to be gathered by > > an 'aggregation agent.'" > > > > An aggregation agent would be a process which an interested party (e.g. > > an ISP) runs, and which gathers together usage data for all that party's > > customers. > > > > Examples of data sources for aggregation include Network Access Servers > > (association of user ids with IP addresses, including session start/stop > > times), RTFM meters (traffic flow usage data associated with IP > > adresses) and so on. Note that I assume an NAS will authenticate the > > user, and verify the user is authorised to start an IP session before > > actually allocating the IP address). > > > > Does this seem a reasonable view of a structure to support generalised > > usage accounting? > > I think we came to realize that people meant a few different things, > implicitly or explicitly, when they said "accounting." Let me call > it resource utilization data. There are at least 2 distinct uses for > such data: network engineering (capacity planning, service provisioning, > what have you) and rating and billing. A related use is in a service > that is implemented using hard state information maintained in service > elements (a simple example is IP addresses allocated to a dial-up > user, a complex example being QoS resources for a multicast group), > where I may need to unwind such resource allocation over time (as > a multicast group member joins or is dropped, as a call terminates). > > The time scale over which I want such information to be delivered, > and acted upon, seems to depend on the use to which I am putting > that information. For capacity planning, I don't need that data > in anything near real-time. I may need it for resource management, > although that could depend on how I'm allocating and managing > resources internally. Use of the data for billing (where I get > to rate/price it and somehow convert it into a bill) may be > the trickiest case of all (simple if a pre-paid calling card > model, tricky if there is a tiered pricing structure based > on volume, where the eventual price of this service instance > depends on your future utilization). > > So this is perhaps a lengthy way of saying I think we need a > more nuanced, or perhaps context sensitive, view of "accounting" > and the necessary support for it. For example, I'm willing to > consider having the same information sent multiple times, perhaps > on different time scales, if that turns out to be easier to handle > than saying "pass all the usage data through an aggregation point > which gets to redistribute, and possibly replicate, the data to > all the other things that might want to look at it now or in the > future." > > -paul > > From owner-aaa-wg@merit.edu Fri Feb 5 08:58:21 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id IAA13166 for ; Fri, 5 Feb 1999 08:58:21 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id IAA04277 for aaa-wg-outgoing; Fri, 5 Feb 1999 08:58:03 -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 IAA04273 for ; Fri, 5 Feb 1999 08:57:58 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA10195; Fri, 5 Feb 1999 05:57:26 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.103.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA12789; Fri, 5 Feb 1999 05:57:25 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA12851; Fri, 5 Feb 1999 05:57:24 -0800 Date: Fri, 5 Feb 1999 05:57:32 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Back to basics To: paul@mci.net Cc: AAA wg In-Reply-To: "Your message with ID" <36BA000F.783C883B@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Patrice Calhoun wrote: > > > >But this is only true for network access. If I'm trying to implement an > > >authentication and authorization framework for users requesting QoS, > > >particularly for (say) web-hosting. There is no roaming in that scenario. > > > > Is this true? As I user I happen to be at the airport and use a web kiosk. > > I would, ideally, not have to worry about who owns the kiosk, use the service > > and receive a single bill from my home provider. This is no different than > > how my calling card works. > > Yes. The "user" requesting the QoS service is the web server that I'm > hosting, not the other end. While that service may move to another > provider, it isn't likely to happen quickly. Agreed. The kiosk is the one that initiates the request, but on behalf of the user. > > I'm not saying that your example is not going to happen, but I view it > as a variant of the remote access issue (since it is effectively additional > parameters on the access, although it may be finer grained). Yes this is actually another version of remote access, but instead of simply AA for dial-in, we are also requesting QOS. This would result in an additional charge to the user, not the kiosk operator. no? PatC > > -paul > > From owner-aaa-wg@merit.edu Fri Feb 5 09:05:14 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA13255 for ; Fri, 5 Feb 1999 09:05:14 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA04434 for aaa-wg-outgoing; Fri, 5 Feb 1999 09:05:03 -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 JAA04430 for ; Fri, 5 Feb 1999 09:04:58 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA11423; Fri, 5 Feb 1999 06:03:49 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.51.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA13138; Fri, 5 Feb 1999 06:03:48 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14343; Fri, 5 Feb 1999 06:03:47 -0800 Date: Fri, 5 Feb 1999 06:03:55 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: A structure for Accounting (?) To: Henry Sinnreich Cc: Paul.Krumviede@mci.com, Nevil Brownlee , AAA wg In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Need to be able to show the running meter during a phone call, as already > provided in the IP telephony industry. Pardon the possibly stupid question Henry, but is this meter not a function of the SIP Client or Server? Does the user need to interact with the provider's accounting system in order to get a meter? PatC > > Thanks, Henry > > > -----Original Message----- > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > Of Paul Krumviede > > Sent: Friday, February 05, 1999 1:11 AM > > To: Nevil Brownlee > > Cc: AAA wg > > Subject: Re: A structure for Accounting (?) > > > > > > Nevil Brownlee wrote: > > > > > > Hello all: > > > > > > Back in November we had a brief discussion on the AAA and RTFM lists > > > about RTFM requirements for AAA. Looking back, the outcome of that > > > discussion was that Accounting - as viewed by AAA - seems to mean > > > something like "making it possible for accounting data to be gathered by > > > an 'aggregation agent.'" > > > > > > An aggregation agent would be a process which an interested party (e.g. > > > an ISP) runs, and which gathers together usage data for all that party's > > > customers. > > > > > > Examples of data sources for aggregation include Network Access Servers > > > (association of user ids with IP addresses, including session start/stop > > > times), RTFM meters (traffic flow usage data associated with IP > > > adresses) and so on. Note that I assume an NAS will authenticate the > > > user, and verify the user is authorised to start an IP session before > > > actually allocating the IP address). > > > > > > Does this seem a reasonable view of a structure to support generalised > > > usage accounting? > > > > I think we came to realize that people meant a few different things, > > implicitly or explicitly, when they said "accounting." Let me call > > it resource utilization data. There are at least 2 distinct uses for > > such data: network engineering (capacity planning, service provisioning, > > what have you) and rating and billing. A related use is in a service > > that is implemented using hard state information maintained in service > > elements (a simple example is IP addresses allocated to a dial-up > > user, a complex example being QoS resources for a multicast group), > > where I may need to unwind such resource allocation over time (as > > a multicast group member joins or is dropped, as a call terminates). > > > > The time scale over which I want such information to be delivered, > > and acted upon, seems to depend on the use to which I am putting > > that information. For capacity planning, I don't need that data > > in anything near real-time. I may need it for resource management, > > although that could depend on how I'm allocating and managing > > resources internally. Use of the data for billing (where I get > > to rate/price it and somehow convert it into a bill) may be > > the trickiest case of all (simple if a pre-paid calling card > > model, tricky if there is a tiered pricing structure based > > on volume, where the eventual price of this service instance > > depends on your future utilization). > > > > So this is perhaps a lengthy way of saying I think we need a > > more nuanced, or perhaps context sensitive, view of "accounting" > > and the necessary support for it. For example, I'm willing to > > consider having the same information sent multiple times, perhaps > > on different time scales, if that turns out to be easier to handle > > than saying "pass all the usage data through an aggregation point > > which gets to redistribute, and possibly replicate, the data to > > all the other things that might want to look at it now or in the > > future." > > > > -paul > > > > > From owner-aaa-wg@merit.edu Fri Feb 5 10:49:41 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA14339 for ; Fri, 5 Feb 1999 10:49:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA06644 for aaa-wg-outgoing; Fri, 5 Feb 1999 10:49:05 -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 KAA06640 for ; Fri, 5 Feb 1999 10:49:01 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7DRD1WF3G8WW4J4@shoe.reston.mci.net> for aaa-wg@merit.edu; Fri, 5 Feb 1999 10:48:30 EST Date: Fri, 05 Feb 1999 07:48:27 -0800 From: Paul Krumviede Subject: Re: Back to basics To: AAA wg Reply-to: paul@mci.net Message-id: <36BB12C5.52533663@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) 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: > > > Patrice Calhoun wrote: > > > > > >But this is only true for network access. If I'm trying to implement an > > > >authentication and authorization framework for users requesting QoS, > > > >particularly for (say) web-hosting. There is no roaming in that scenario. > > > > > > Is this true? As I user I happen to be at the airport and use a web kiosk. > > > I would, ideally, not have to worry about who owns the kiosk, use the service > > > and receive a single bill from my home provider. This is no different than > > > how my calling card works. > > > > Yes. The "user" requesting the QoS service is the web server that I'm > > hosting, not the other end. While that service may move to another > > provider, it isn't likely to happen quickly. > > Agreed. The kiosk is the one that initiates the request, but on behalf of the > user. No. QoS could be requested by either end, asymmetrically. So in some instances, I have a (corporate) customer, who wants me to host his web service, and provide some form of QoS from the server towards the end-user, and the server "owner" is going to pay for the QoS, not the HTTP requestor. > > I'm not saying that your example is not going to happen, but I view it > > as a variant of the remote access issue (since it is effectively additional > > parameters on the access, although it may be finer grained). > > Yes this is actually another version of remote access, but instead of simply > AA for dial-in, we are also requesting QOS. This would result in an additional > charge to the user, not the kiosk operator. no? In your case, yes. In my case (see above), no. Of course, both cases can exist (the intersection of some user population hitting a particular web service, say). -paul From owner-aaa-wg@merit.edu Fri Feb 5 11:08:01 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA14480 for ; Fri, 5 Feb 1999 11:08:01 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id LAA06999 for aaa-wg-outgoing; Fri, 5 Feb 1999 11:07:40 -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 LAA06994 for ; Fri, 5 Feb 1999 11:07:33 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA12322; Fri, 5 Feb 1999 08:06:40 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.55.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA01375; Fri, 5 Feb 1999 08:06:39 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06705; Fri, 5 Feb 1999 08:06:38 -0800 Date: Fri, 5 Feb 1999 08:06:46 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Back to basics To: paul@mci.net Cc: AAA wg In-Reply-To: "Your message with ID" <36BB12C5.52533663@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > > > Patrice Calhoun wrote: > > > > > > > >But this is only true for network access. If I'm trying to implement an > > > > >authentication and authorization framework for users requesting QoS, > > > > >particularly for (say) web-hosting. There is no roaming in that scenario. > > > > > > > > Is this true? As I user I happen to be at the airport and use a web kiosk. > > > > I would, ideally, not have to worry about who owns the kiosk, use the service > > > > and receive a single bill from my home provider. This is no different than > > > > how my calling card works. > > > > > > Yes. The "user" requesting the QoS service is the web server that I'm > > > hosting, not the other end. While that service may move to another > > > provider, it isn't likely to happen quickly. > > > > Agreed. The kiosk is the one that initiates the request, but on behalf of the > > user. > > No. QoS could be requested by either end, asymmetrically. So in some > instances, I have a (corporate) customer, who wants me to host his web > service, and provide some form of QoS from the server towards the end-user, > and the server "owner" is going to pay for the QoS, not the HTTP requestor. OK, here I agree with you. > > > > I'm not saying that your example is not going to happen, but I view it > > > as a variant of the remote access issue (since it is effectively additional > > > parameters on the access, although it may be finer grained). > > > > Yes this is actually another version of remote access, but instead of simply > > AA for dial-in, we are also requesting QOS. This would result in an additional > > charge to the user, not the kiosk operator. no? > > In your case, yes. In my case (see above), no. Of course, both cases can > exist (the intersection of some user population hitting a particular web > service, say). Yes, it looks like we are in agreement. PatC > > -paul From owner-aaa-wg@merit.edu Fri Feb 5 11:08:03 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA14486 for ; Fri, 5 Feb 1999 11:08:03 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id LAA06998 for aaa-wg-outgoing; Fri, 5 Feb 1999 11:07:38 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA06990 for ; Fri, 5 Feb 1999 11:07:29 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.nortel.com; Fri, 5 Feb 1999 10:54:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HHZC1MW>; Fri, 5 Feb 1999 10:54:32 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E77@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Pat.Calhoun'" , aaa-wg , "'Brian Lloyd'" Subject: RE: Back to basics Date: Fri, 5 Feb 1999 10:54:23 -0500 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 Pat Calhoun wrote: >I believe that one way of achieving this is for the AAA server to create a >session token when the user is authenticated. This token is used in subsequent >authorization requests. The token would be signed by the AAA server, which >then means that if the provider has many AAA servers, they would have to share >a single private key (I think - but if someone has a better method, please let >me know). > >The token would have a lifetime, and would have to be periodically refreshed. Yes. That's one way of doing it. Just a couple of thoughts though... 1. Who would actually keep the token? The user or the AAA server? Either solution has implications that merit discussion but maybe not at this time. 2. The thought of multiple AAA servers sharing a single private key, even though they are owned by the same service provider, seems unlikely and not a feasible solution. I'm not sure if we want to start discussing solutions at this point yet. Maybe we ought to just discuss the requirements initially. -Basavaraj Patil From owner-aaa-wg@merit.edu Fri Feb 5 11:15:38 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA14531 for ; Fri, 5 Feb 1999 11:15:38 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA07227 for aaa-wg-outgoing; Fri, 5 Feb 1999 11:15:31 -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 LAA07222 for ; Fri, 5 Feb 1999 11:15:25 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA14747; Fri, 5 Feb 1999 08:14:52 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.61.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23901; Fri, 5 Feb 1999 08:14:51 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08546; Fri, 5 Feb 1999 08:14:50 -0800 Date: Fri, 5 Feb 1999 08:14:57 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Back to basics To: Basavaraj Patil Cc: "'Pat.Calhoun'" , aaa-wg , "'Brian Lloyd'" In-Reply-To: "Your message with ID" <31B1EFDD2CD3D11187710000F805A8D5022D5E77@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 > > Pat Calhoun wrote: > >I believe that one way of achieving this is for the AAA server to create a > >session token when the user is authenticated. This token is used in > subsequent > >authorization requests. The token would be signed by the AAA server, which > >then means that if the provider has many AAA servers, they would have to > share > >a single private key (I think - but if someone has a better method, please > let > >me know). > > > >The token would have a lifetime, and would have to be periodically > refreshed. > > Yes. That's one way of doing it. Just a couple of thoughts > though... > 1. Who would actually keep the token? The user or the AAA server? > Either solution has implications that merit discussion but maybe not > at this time. Both. This is the basis of Resource Management (as defined by the DIAMETER protocol). > 2. The thought of multiple AAA servers sharing a single private key, > even though they are owned by the same service provider, seems > unlikely and not a feasible solution. I am not sure why I said this. The only reason why the AAA servers would have to share such a key would be if the token was encrypted. For verifying signatures they can all have different keys. > > I'm not sure if we want to start discussing solutions at this point > yet. Maybe we ought to just discuss the requirements initially. I agree. However, there are requirements already written down. What we should be doing at this point is bashing (and cleaning up) Sue and Fred's requirements spec. PatC > > -Basavaraj Patil > > From owner-aaa-wg@merit.edu Fri Feb 5 12:16:35 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA15235 for ; Fri, 5 Feb 1999 12:16:35 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA12969 for aaa-wg-outgoing; Fri, 5 Feb 1999 12:15:52 -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 MAA12963 for ; Fri, 5 Feb 1999 12:15:47 -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 JAA04520; Fri, 5 Feb 1999 09:15:41 -0800 (PST) Message-Id: <3.0.6.32.19990205090609.0096e8d0@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 05 Feb 1999 09:06:09 -0800 To: paul@mci.net From: Brian Lloyd Subject: Re: Split Authentication and Authorization Cc: AAA wg In-Reply-To: <36BA5A7B.D7D73A13@mci.net> References: <199902042153.NAA00495@hsmpka.eng.sun.com> <3.0.6.32.19990204180353.00953260@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 06:42 PM 2/4/99 -0800, Paul Krumviede wrote: >I'm saying that one has to be able to do this connection. One may choose >not to do it for certain cases, but any authorization request for a service >for which I can do a discrete billing transaction may require some such >coupling. Otherwise I'm going to flood the service provider with requests >for a service purporting to be you, and attempt to drive you into >bankruptcy. Or I'm going to issue a lot of (expensive) requests, get >the service, and deny having requested it, and we can fight it out >in court. > >The inability to verify the identity (and associated permissions >and billing relationships) would render such a protocol framework >extremely risky, and probably of insufficient interest to me and >my employer. Note that I am not saying I want to do this on >every, or even many, authorization requests, but the capability >is, I think, mandatory. I think we are agreeing violently here. I agree and recognize the need to bind authentication and authorization together for some classes of service. All I am trying to point out is that there may be cases where we want to authenticate without authorizing and vice-versa. I am not trying to say that they must always be separate. >> OK, we appear to be in sync here. I am not advocating that *all* >> authentications must be separate from all authorizations, only that they >> may be and that any AA protocol we adopt should accommodate both decoupled >> and coupled authentications/authorizations. > >Yes, where they may be all sorts of possible bindings, on different >time scales, etc. I agree that it should support both. Then we are indeed in agreement. >> It is up to the requesting party to ensure that it is properly representing >> the originally requesting entity. (I was going to make an example using a >> dial up user and a NAS but I want to get away from that model for awhile. >> We have used it so much that I think we tend to accept that as the generic >> model.) > >Yes, but there are some interesting questions as to transitivity of >this. That is why we are having this discussion instead of trying to hammer out details of a protocol right now. >> >But we're trying to design protocols that will allow algorithms to work, >> >not to design algorithms (or are we doing the latter as well?). >> >> Can you really separate them? The protocol has to allow me to perform the >> tasks I wish to perform, therefore we at least need to know something about >> the algorithms. > >Knowing about the algorithm(s) to support is one thing, and I agree that >is necessary, but I'm not sure we want to design new algorithms (e.g. >we can say that we should support a few variants of challenge response, >EKE, variants of Diffie-Hellman key agreement with different numbers of >rounds to authenticate the participants, etc. but not define a new >algorithm). I agree with that. > >And by now I've lost track of why I was trying to make the distinction :-( Your brain is full? OK, you may go home now. Maybe it was all that wine you had at dinner. :^) 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-wg@merit.edu Fri Feb 5 14:01:51 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA16309 for ; Fri, 5 Feb 1999 14:01:51 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA15385 for aaa-wg-outgoing; Fri, 5 Feb 1999 13:59:53 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA15372 for ; Fri, 5 Feb 1999 13:59:46 -0500 (EST) Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprtp.nortel.com; Fri, 5 Feb 1999 13:59:26 -0500 Received: by zrtpd00m.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HH55KGP>; Fri, 5 Feb 1999 11:43:03 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E78@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'paul@mci.net'" , AAA wg Subject: RE: Split Authentication and Authorization Date: Fri, 5 Feb 1999 11:36:03 -0500 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 Paul Krumviede wrote: > >The fundamental problem is that at time T user U authenticates, and maybe >some authorization is done then, maybe not. Now at time T+n, something >makes an authorization request, claiming to U or acting on behalf of U. >Why should I believe this latter claim? Depending on the resource that authorization is being requested for may have different responses. It is upto the resource manager to decide how to handle the authorization request. Maybe some policy associated with that resource requires the verification of the identity of the requesting entity or maybe not. There are many scenarios and ways that a request for authorization to the same resource can be handled. I think it's a policy associated with that resource issue and not AA. > >The need, as I see it, is that there be established some binding between >an authentication and a subsequent authorization request. This can take >the form of something that can be evaluated later, so the binding does >not need to be instantaneous in time (Kerberos tickets are an >example). Would you really want a binding between the initial authentication request and subsequent authorization request(s)? The framework needs to partition authentication and authorization clearly. If there is a need for authentication information to be a part of an authorization request then the requesting entity can combine them together. Having that flexibility would make it more useful for multiple applications. > >For some services, such as those that are providing cryptographic >services, there are strong technical reasons to want to authenticate >parties, negotiate algorithms, and do key agreement in a tightly >coupled fashion, preventing a whole range of cryptographic attacks. >For other types of services, this tight coupling may not be necessary. Completely agree. The very nature of the task (using cryptographic services) would require authentication, algorithm negotiation, key exchanges, etc.. > >Brian Lloyd wrote: > >Well, you authorize the use of a modem but you also return configuration > >information about how to establish the session with the network. That is > >why I keep mentioning the word "configuration" in conjunction with > >"authorization." This takes the exhchange from: > > > > C: May 'p' do 'x'? > > S: Yes. > > > >to: > > > > C: May 'p' do 'x'? > > S: Yes, and here is how ... > > I'm still not sure or convinced that configuration information needs to be returned as a result of an authorization request. I agree that this can be quite useful information and would probably prevent another set of message exchanges, but maybe all applications do not need this information. If 'p' knows how to do 'x' then the information on how to do it that is returned as a response to an authorization request is redundant. Maybe all you need is a flag in the request message that can indicate to the authorizing entity if configuration information is required. >In one sense, this isn't really true. In most cases, a user can't come >back and ask for a new service (lets say a new tunnel, or maybe now some >QoS). Why can a user not ask for a new service? If a user has been allocated 'x' amount of bandwidth and wants more (read : is willing to pay) then why can he not request for 'x+y' amount of bandwidth? Can a user not go from being a Gold User to a Platinum user if he is willing to pay for it? > >>Basavaraj Patil wrote: > >>It may be possible to trigger an authentication request as a result of > >>an authorization request to some resource in certain applications. > >Brian Lloyd wrote: > >Also true in my opinion but I am not yet prepared to conceed that you MUST > >peform an authentication request in conjunction with an authorization > >request. >Paul Krumviede wote: >Other than for some specific, very constrained situations, I don't think >one MUST do this. I agree. I did not mean to imply that an authentication is a MUST for an authorization. I just meant to say it MAY in the case above and below. > >Likewise I am not prepared to conceed that you MUST peform an authorization > >request in conjunction with an authentication request although I am far > >less comfortable making this assertion. >Again, other than some stringent crypto cases, this is also correct (as >far as I can tell, at least :-). >But we're trying to design protocols that will allow algorithms to work, >not to design algorithms (or are we doing the latter as well?). That's what I believe is the charter of this WG. Let's just design a protocol that will allow different algorithms to work. -Basavaraj Patil From owner-aaa-wg@merit.edu Fri Feb 5 14:33:36 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA16575 for ; Fri, 5 Feb 1999 14:33:36 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id OAA16225 for aaa-wg-outgoing; Fri, 5 Feb 1999 14:31:42 -0500 (EST) Received: from mail.iphighway.com ([209.3.6.75]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA16215 for ; Fri, 5 Feb 1999 14:31:29 -0500 (EST) Received: from shai-notebook (SHAI_NOTEBOOK [209.3.6.105]) by mail.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1JD2SNK3; Fri, 5 Feb 1999 14:30:00 -0500 Message-Id: <4.1.19990205142346.00aa1100@mail.iphighway.com> X-Sender: herzog@mail.iphighway.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 05 Feb 1999 14:27:54 -0500 To: "Emad Qaddoura" From: Shai Herzog Subject: RE: Back to basics Cc: "'Durham, David'" , "Basavaraj Patil" , aaa-wg@merit.edu In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5023C5A95@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 06:49 PM 2/4/99, Emad Qaddoura wrote: >Shai, > >> "So, I guess I am saying that we must choose whether to take the >long >>road to define a very generic mechanism, or take the faster road and >>define a unified solution for N AAA problems we already know. I (obviously) >>vote toward the later. Things would become much clearer if we list N >>specific AAA problems the WG is trying to solve and completely put >>aside the "whatever" clause. Further more, the N may be reduced even more >>if we find out some of the previously thought of problems have >>different requirements" > > > Or is there something in the middle? You can increase or decrease the N value ;-) It is fine to try to keep a protocol "OPEN" or "GENERIC" as long as we all understand that (1) it is designed for N applications and (2) it does not contain things that cannot be justified for these N applications (future use stuff) and (3) that is not artificially gluing very different applications just to force a single protocol (e.g., one can design a TCP/UDP protocol that does both, but we rather have them separate since their functionality is very different). Shai __________________________________________________________ Shai Herzog Founder & CTO, IPHighway Inc. Cell: (408) 390-3045 http://www.iphighway.com/herzog Tel : (201) 585-0800 Fax : (212) 656-1006 From owner-aaa-wg@merit.edu Fri Feb 5 15:21:24 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA17104 for ; Fri, 5 Feb 1999 15:21:23 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA17755 for aaa-wg-outgoing; Fri, 5 Feb 1999 15:19:07 -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 PAA17747 for ; Fri, 5 Feb 1999 15:19:00 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA10908; Fri, 5 Feb 1999 12:14:26 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.61.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA27036; Fri, 5 Feb 1999 12:14:25 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA20741; Fri, 5 Feb 1999 12:14:20 -0800 Date: Fri, 5 Feb 1999 12:14:18 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Split Authentication and Authorization To: Basavaraj Patil Cc: "'paul@mci.net'" , AAA wg In-Reply-To: "Your message with ID" <31B1EFDD2CD3D11187710000F805A8D5022D5E78@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 > > Paul Krumviede wrote: > > > >The fundamental problem is that at time T user U authenticates, and maybe > >some authorization is done then, maybe not. Now at time T+n, something > >makes an authorization request, claiming to U or acting on behalf of U. > >Why should I believe this latter claim? > > Depending on the resource that authorization is being requested for > may have different responses. It is upto the resource manager to decide > how to handle the authorization request. Maybe some policy associated > with that resource requires the verification of the identity of the > requesting entity or maybe not. There are many scenarios and ways that > a request for authorization to the same resource can be handled. I > think it's a policy associated with that resource issue and not AA. > > > > > >The need, as I see it, is that there be established some binding between > >an authentication and a subsequent authorization request. This can take > >the form of something that can be evaluated later, so the binding does > >not need to be instantaneous in time (Kerberos tickets are an > >example). > > Would you really want a binding between the initial authentication > request and subsequent authorization request(s)? The framework needs > to partition authentication and authorization clearly. If there is a > need for authentication information to be a part of an authorization > request then the requesting entity can combine them together. Having > that flexibility would make it more useful for multiple applications. > > > > >For some services, such as those that are providing cryptographic > >services, there are strong technical reasons to want to authenticate > >parties, negotiate algorithms, and do key agreement in a tightly > >coupled fashion, preventing a whole range of cryptographic attacks. > >For other types of services, this tight coupling may not be necessary. > > Completely agree. The very nature of the task (using cryptographic > services) would require authentication, algorithm negotiation, key > exchanges, etc.. > > > >Brian Lloyd wrote: > > >Well, you authorize the use of a modem but you also return configuration > > >information about how to establish the session with the network. That is > > >why I keep mentioning the word "configuration" in conjunction with > > >"authorization." This takes the exhchange from: > > > > > > C: May 'p' do 'x'? > > > S: Yes. > > > > > >to: > > > > > > C: May 'p' do 'x'? > > > S: Yes, and here is how ... > > > > > I'm still not sure or convinced that configuration information needs > to be returned as a result of an authorization request. I agree that > this can be quite useful information and would probably prevent > another set of message exchanges, but maybe all applications do not > need this information. If 'p' knows how to do 'x' then the information > on how to do it that is returned as a response to an authorization > request is redundant. Maybe all you need is a flag in the request > message that can indicate to the authorizing entity if configuration > information is required. An example here is that a user has requested to be tunneled. The tunnel information may come back from the AAA server. This information is known as authorization info. If we want to do any form of resource management, the AAA client must maintain this information, such as a token. The DIAMETER Resource Management document provides more info on this. > > > >In one sense, this isn't really true. In most cases, a user can't come > >back and ask for a new service (lets say a new tunnel, or maybe now some > >QoS). > > Why can a user not ask for a new service? If a user has been allocated > 'x' amount of bandwidth and wants more (read : is willing to pay) then > why can he not request for 'x+y' amount of bandwidth? Can a user not > go from being a Gold User to a Platinum user if he is willing to pay > for it? > > > >>Basavaraj Patil wrote: > > >>It may be possible to trigger an authentication request as a result of > > >>an authorization request to some resource in certain applications. > > > >Brian Lloyd wrote: > > >Also true in my opinion but I am not yet prepared to conceed that you > MUST > > >peform an authentication request in conjunction with an authorization > > >request. > > >Paul Krumviede wote: > >Other than for some specific, very constrained situations, I don't think > >one MUST do this. > > I agree. I did not mean to imply that an authentication is a MUST for > an authorization. I just meant to say it MAY in the case above and below. > > > >Likewise I am not prepared to conceed that you MUST peform an > authorization > > >request in conjunction with an authentication request although I am far > > >less comfortable making this assertion. > > >Again, other than some stringent crypto cases, this is also correct (as > >far as I can tell, at least :-). > > >But we're trying to design protocols that will allow algorithms to work, > >not to design algorithms (or are we doing the latter as well?). > > That's what I believe is the charter of this WG. Let's just design a > protocol that will allow different algorithms to work. This should be our end goal. > > -Basavaraj Patil > From owner-aaa-wg@merit.edu Fri Feb 5 17:51:58 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA18980 for ; Fri, 5 Feb 1999 17:51:58 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA20530 for aaa-wg-outgoing; Fri, 5 Feb 1999 17:51:29 -0500 (EST) Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA20525 for ; Fri, 5 Feb 1999 17:51:24 -0500 (EST) Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca; Fri, 5 Feb 1999 17:43:36 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id <1HKYKBPR>; Fri, 5 Feb 1999 15:49:35 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E7A@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'aaa-wg@merit.edu'" Cc: "Emad Qaddoura" Subject: Applications using AAA Date: Fri, 5 Feb 1999 15:49:30 -0500 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 Part of the straw-person charter issued by Sue included : "The first step in this working group is to determine the requirements for the AAA protocol. To accomplish this, we must document the current set of applications that we will use to set our requirements. To set the requirements, we will collect requirements and then cull out any requirements which are specific to a particular instantiation of AAA." Applications identified so far include : -IP Telephony -PPP Remote Dial-in (NAS) -Terminal Server (telnet etc.) -Bandwidth Broker -Mobile IP -IP Fax What other applications, in use today, can we use and add to this list which can serve as the basis for gathering/refining the requirements? Basavaraj Patil Nortel Networks From owner-aaa-wg@merit.edu Fri Feb 5 17:54:57 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA18997 for ; Fri, 5 Feb 1999 17:54:57 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA20588 for aaa-wg-outgoing; Fri, 5 Feb 1999 17:54:48 -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 RAA20583 for ; Fri, 5 Feb 1999 17:54:43 -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 OAA07136; Fri, 5 Feb 1999 14:51:18 -0800 (PST) Message-Id: <3.0.6.32.19990205145029.00966100@127.0.0.1> X-Sender: brian@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 05 Feb 1999 14:50:29 -0800 To: "Basavaraj Patil" From: Brian Lloyd Subject: RE: Split Authentication and Authorization Cc: AAA wg In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5022D5E78@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 11:36 AM 2/5/99 -0500, Basavaraj Patil wrote: >I'm still not sure or convinced that configuration information needs >to be returned as a result of an authorization request. I agree that >this can be quite useful information and would probably prevent >another set of message exchanges, but maybe all applications do not >need this information. If 'p' knows how to do 'x' then the information >on how to do it that is returned as a response to an authorization >request is redundant. Maybe all you need is a flag in the request >message that can indicate to the authorizing entity if configuration >information is required. You just don't return the config info. The empty set is a valid subset of the possible configuration set. Again, this comes from my RADIUS bias but I believe it to be generally true. >>But we're trying to design protocols that will allow algorithms to work, >>not to design algorithms (or are we doing the latter as well?). > >That's what I believe is the charter of this WG. Let's just design a >protocol that will allow different algorithms to work. That is how I view it. Sue Hares is working on an update to the charter which she will be getting back to me on Monday. I will bleed on it and then post it for discussion. 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-wg@merit.edu Fri Feb 5 18:15:29 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA19375 for ; Fri, 5 Feb 1999 18:15:28 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA20913 for aaa-wg-outgoing; Fri, 5 Feb 1999 18:15:22 -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 SAA20909 for ; Fri, 5 Feb 1999 18:15:17 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA00202; Fri, 5 Feb 1999 15:14:39 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.61.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA07192; Fri, 5 Feb 1999 15:14:38 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10426; Fri, 5 Feb 1999 15:14:18 -0800 Date: Fri, 5 Feb 1999 15:14:24 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Applications using AAA To: Basavaraj Patil Cc: "'aaa-wg@merit.edu'" , Emad Qaddoura In-Reply-To: "Your message with ID" <31B1EFDD2CD3D11187710000F805A8D5022D5E7A@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 > > Part of the straw-person charter issued by Sue included : > > "The first step in this working group is to determine the requirements for > the > AAA protocol. To accomplish this, we must document the current set of > applications that we will use to set our requirements. To set the > requirements, we will collect requirements and then cull out any > requirements > which are specific to a particular instantiation of AAA." > > Applications identified so far include : > -IP Telephony > -PPP Remote Dial-in (NAS) > -Terminal Server (telnet etc.) > -Bandwidth Broker > -Mobile IP > -IP Fax For now I would add ROAMOPS. Although ROAMOPS is not an application, it will make sure that Cross-Domain AAA works well. PatC > > What other applications, in use today, can we use and add to this list which > can serve as the basis for gathering/refining the requirements? > > Basavaraj Patil > Nortel Networks From owner-aaa-wg@merit.edu Fri Feb 5 22:49:48 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id WAA21278 for ; Fri, 5 Feb 1999 22:49:48 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id WAA23451 for aaa-wg-outgoing; Fri, 5 Feb 1999 22:49:14 -0500 (EST) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by merit.edu (8.9.1a/8.9.1) with ESMTP id WAA23446 for ; Fri, 5 Feb 1999 22:49:03 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id TAA08001; Fri, 5 Feb 1999 19:35:08 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id WAA17931; Fri, 5 Feb 1999 22:37:29 -0500 (EST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-hme0.corpeast.baynetworks.com [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id WAA25333; Fri, 5 Feb 1999 22:37:28 -0500 for Received: from thardjon.engeast.baynetworks.com ([132.245.134.76]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Fri, 5 Feb 1999 22:38:52 -0500 Message-Id: <3.0.5.32.19990205223623.007935a0@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 05 Feb 1999 22:36:23 -0500 To: Brian Lloyd , ietf-aaa@external.cisco.com From: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) Subject: Re: back to basics Cc: aaa-wg@merit.edu, thardjono@baynetworks.com In-Reply-To: <3.0.6.32.19990201135851.009288c0@158.222.8.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 01:58 PM 2/1/99 -0800, you wrote: >I *really* want to go back to ground-zero and talk about the *problem* we >are trying to solve. I don't even want to start talking about the >requirements or the solution until there is some consensus that we >understand the problem and can share a common (and meaningful) lexicon. Thanks, Brian. This is very useful input. For a while there I thought AAA was only interested in a suitable "AAA-transport protocol" (PS. excuse my blatancy :-) ). Glad to hear there are other issues :-) I think some amount of time should be devoted to getting everybody agreeing on the problem areas(s) and items to be resolved. cheers, Thomas ------ ---------------------------------------------------------------------- Thomas Hardjono 3 Federal Street, BL3-03 Bay Architecture Lab Billerica, MA 01821, USA Nortel Networks Tel: 978-916-4538 email: thardjono@baynetworks.com Fax: 978-916-0620 ---------------------------------------------------------------------- From owner-aaa-wg@merit.edu Fri Feb 5 22:54:21 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id WAA21302 for ; Fri, 5 Feb 1999 22:54:21 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id WAA23508 for aaa-wg-outgoing; Fri, 5 Feb 1999 22:54:06 -0500 (EST) Received: from stars.cisco.com (stars.cisco.com [171.71.112.28]) by merit.edu (8.9.1a/8.9.1) with ESMTP id WAA23504 for ; Fri, 5 Feb 1999 22:53:46 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by stars.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id TAA11406 for ; Fri, 5 Feb 1999 19:51:20 -0800 (PST) Received: from beasley.cisco.com (beasley.cisco.com [171.69.11.49]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA28057 for ; Fri, 5 Feb 1999 19:51:51 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by beasley.cisco.com (8.8.8/2.6/Cisco List Logging/CISCO.GATE.1.1) with ESMTP id TAA01173 for ; Fri, 5 Feb 1999 19:51:19 -0800 (PST) Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA29529 for ; Fri, 5 Feb 1999 19:51:17 -0800 (PST) Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id TAA04201 for ; Fri, 5 Feb 1999 19:49:32 -0800 (PST) Received: from ns2.baynetworks.com(134.177.3.16) by proxy1.cisco.com via smap (V2.0) id xma004053; Sat, 6 Feb 99 03:48:31 GMT X-SMAP-Received-From: outside Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id TAA08001; Fri, 5 Feb 1999 19:35:08 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id WAA17931; Fri, 5 Feb 1999 22:37:29 -0500 (EST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-hme0.corpeast.baynetworks.com [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id WAA25333; Fri, 5 Feb 1999 22:37:28 -0500 for Received: from thardjon.engeast.baynetworks.com ([132.245.134.76]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Fri, 5 Feb 1999 22:38:52 -0500 Message-Id: <3.0.5.32.19990205223623.007935a0@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 05 Feb 1999 22:36:23 -0500 To: Brian Lloyd , ietf-aaa@external.cisco.com From: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) Subject: Re: back to basics Cc: aaa-wg@merit.edu, thardjono@baynetworks.com In-Reply-To: <3.0.6.32.19990201135851.009288c0@158.222.8.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 01:58 PM 2/1/99 -0800, you wrote: >I *really* want to go back to ground-zero and talk about the *problem* we >are trying to solve. I don't even want to start talking about the >requirements or the solution until there is some consensus that we >understand the problem and can share a common (and meaningful) lexicon. Thanks, Brian. This is very useful input. For a while there I thought AAA was only interested in a suitable "AAA-transport protocol" (PS. excuse my blatancy :-) ). Glad to hear there are other issues :-) I think some amount of time should be devoted to getting everybody agreeing on the problem areas(s) and items to be resolved. cheers, Thomas ------ ---------------------------------------------------------------------- Thomas Hardjono 3 Federal Street, BL3-03 Bay Architecture Lab Billerica, MA 01821, USA Nortel Networks Tel: 978-916-4538 email: thardjono@baynetworks.com Fax: 978-916-0620 ---------------------------------------------------------------------- From owner-aaa-wg@merit.edu Sat Feb 6 00:43:39 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id AAA21912 for ; Sat, 6 Feb 1999 00:43:39 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id AAA24472 for aaa-wg-outgoing; Sat, 6 Feb 1999 00:43:25 -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 AAA24468 for ; Sat, 6 Feb 1999 00:43:20 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7EKIDEOBW8ZG2G0@shoe.reston.mci.net> for aaa-wg@merit.edu; Sat, 6 Feb 1999 00:42:49 EST Date: Fri, 05 Feb 1999 15:43:39 -0800 From: Paul Krumviede Subject: Re: Split Authentication and Authorization Cc: AAA wg Reply-to: paul@mci.net Message-id: <36BB8221.FB212E2B@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <31B1EFDD2CD3D11187710000F805A8D5022D5E78@crchy270.us.nortel.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Basavaraj Patil wrote: > > Paul Krumviede wrote: > > > >The fundamental problem is that at time T user U authenticates, and maybe > >some authorization is done then, maybe not. Now at time T+n, something > >makes an authorization request, claiming to U or acting on behalf of U. > >Why should I believe this latter claim? > > Depending on the resource that authorization is being requested for > may have different responses. It is upto the resource manager to decide > how to handle the authorization request. Maybe some policy associated > with that resource requires the verification of the identity of the > requesting entity or maybe not. There are many scenarios and ways that > a request for authorization to the same resource can be handled. I > think it's a policy associated with that resource issue and not AA. On balance, I think we are agreeing, but the wording is hiding that. I'm not concerned about "a request for authorization to the same resource," I'm concerned with request for a different service. And I would assert that the AA framework must be able to support it, not that it must be used in all cases. In the sense of "must support it" I think it is an AA issue, or we need to have a more explicit sense of what people mean by "AA." > > > >The need, as I see it, is that there be established some binding between > >an authentication and a subsequent authorization request. This can take > >the form of something that can be evaluated later, so the binding does > >not need to be instantaneous in time (Kerberos tickets are an > >example). > > Would you really want a binding between the initial authentication > request and subsequent authorization request(s)? The framework needs > to partition authentication and authorization clearly. If there is a > need for authentication information to be a part of an authorization > request then the requesting entity can combine them together. Having > that flexibility would make it more useful for multiple applications. But partitioning them will make some things either impossible within the framework, leading me (as MCI WorldCom) to go do something else, or make it quite messy, probably making me go do something else. I do not, in all cases, want such a binding. But for some cases, it will be necessary. > > > >For some services, such as those that are providing cryptographic > >services, there are strong technical reasons to want to authenticate > >parties, negotiate algorithms, and do key agreement in a tightly > >coupled fashion, preventing a whole range of cryptographic attacks. > >For other types of services, this tight coupling may not be necessary. > > Completely agree. The very nature of the task (using cryptographic > services) would require authentication, algorithm negotiation, key > exchanges, etc.. It requires that those things be bound together, and that is the point. Doing them in isolation leaves all sorts of cryptographic holes. > > >Brian Lloyd wrote: > > >Well, you authorize the use of a modem but you also return configuration > > >information about how to establish the session with the network. That is > > >why I keep mentioning the word "configuration" in conjunction with > > >"authorization." This takes the exhchange from: > > > > > > C: May 'p' do 'x'? > > > S: Yes. > > > > > >to: > > > > > > C: May 'p' do 'x'? > > > S: Yes, and here is how ... > > > > > I'm still not sure or convinced that configuration information needs > to be returned as a result of an authorization request. I agree that > this can be quite useful information and would probably prevent > another set of message exchanges, but maybe all applications do not > need this information. If 'p' knows how to do 'x' then the information > on how to do it that is returned as a response to an authorization > request is redundant. Maybe all you need is a flag in the request > message that can indicate to the authorizing entity if configuration > information is required. > > >In one sense, this isn't really true. In most cases, a user can't come > >back and ask for a new service (lets say a new tunnel, or maybe now some > >QoS). > > Why can a user not ask for a new service? If a user has been allocated > 'x' amount of bandwidth and wants more (read : is willing to pay) then > why can he not request for 'x+y' amount of bandwidth? Can a user not > go from being a Gold User to a Platinum user if he is willing to pay > for it? I think the full original suggestion was that this could be done in RADIUS on existing network access servers. Given those constraints, there is no syntax or mechanism for doing so, and it would be hard, but not impossible, for a RADIUS server could return, as part of the initial RADIUS authentication request/response, return enough authorization info to allow the NAS to subsequently decide if a user should be granted a request for a new, more expensive, service. Particularly if the user authenticated with the equivalent of a prepaid calling card, and requests a service for which the NAS has no idea of what the charging might be. So the NAS can ask for the pricing info, and the AA server simply needs to decide if the NAS is to be trusted with such info (one doesn't want to allow a competitor to probe one's systems for customer account and service pricing issues), or it can actually pretend to be stateless and do a combined authentication and authorization. Perhaps it will be an implementation choice. > > >>Basavaraj Patil wrote: > > >>It may be possible to trigger an authentication request as a result of > > >>an authorization request to some resource in certain applications. > > > >Brian Lloyd wrote: > > >Also true in my opinion but I am not yet prepared to conceed that you > MUST > > >peform an authentication request in conjunction with an authorization > > >request. > > >Paul Krumviede wote: > >Other than for some specific, very constrained situations, I don't think > >one MUST do this. > > I agree. I did not mean to imply that an authentication is a MUST for > an authorization. I just meant to say it MAY in the case above and below. > > > >Likewise I am not prepared to conceed that you MUST peform an > authorization > > >request in conjunction with an authentication request although I am far > > >less comfortable making this assertion. > > >Again, other than some stringent crypto cases, this is also correct (as > >far as I can tell, at least :-). > > >But we're trying to design protocols that will allow algorithms to work, > >not to design algorithms (or are we doing the latter as well?). > > That's what I believe is the charter of this WG. Let's just design a > protocol that will allow different algorithms to work. This part at least seems not to cause confusion or dissent. Maybe I should be contrary :-) -paul From owner-aaa-wg@merit.edu Sat Feb 6 23:28:28 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id XAA02295 for ; Sat, 6 Feb 1999 23:28:28 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id XAA07024 for aaa-wg-outgoing; Sat, 6 Feb 1999 23:25:39 -0500 (EST) Received: from ligarius-fe0.ultra.net (ligarius-fe0.ultra.net [146.115.8.189]) by merit.edu (8.9.1a/8.9.1) with ESMTP id XAA07020 for ; Sat, 6 Feb 1999 23:25:34 -0500 (EST) Received: from pavilion (207-172-216-143.s143.tnt1.sbo.erols.com [207.172.216.143]) by ligarius-fe0.ultra.net (8.8.8/ult/n20340/mtc.v2) with SMTP id XAA32493; Sat, 6 Feb 1999 23:25:26 -0500 (EST) Message-Id: <3.0.5.32.19990206233204.007ba100@pop.ma.ultranet.com> X-Sender: dlb237@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 06 Feb 1999 23:32:04 -0500 To: Brian Lloyd From: "David L. Black" Subject: Authorization without Authentication? Cc: aaa-wg@merit.edu In-Reply-To: <3.0.6.32.19990204105655.009492e0@127.0.0.1> References: <31B1EFDD2CD3D11187710000F805A8D5022D5E65@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Back to the original example that kicked off this discussion. >Example: I walk up to a teller in a bank to request a transaction. The >teller wants me to authenticate using something stronger than my pretty >face (it is quite common to have the tellers now request that I use my bank >card to authenticate) before even asking me what my transaction is. This >is an authentication without an authorization. But, the teller, by virtue >of being the teller, is allowed to verify if I am authorized to transfer >funds out of a particular account without having to authenticate as me. >This is an authorization without an authentication. Not exactly. I doubt Brian wants his ability to transfer funds from an account available as public information to anyone who asks. The key phrase in the above example is "by virtue of being the teller" -- in other words the teller is authorized to check Brian's ability to transfer funds out of the account by virtue of a previous authentication of him/her as a teller to the bank's account management system. > I was just stating that you can make an authorization request without ever > authenticating. The question is, "is U allowed to do X." The answer is, > "yes, and here is how." This has nothing to do with the question, "is this > entity that purports to be U really U?" This assumes that the answer to "is U allowed to do X" is public information available to all comers. In the bank example (and many others), it isn't and hence a prior authentication is necessary to read this information (even if the request is not to actually do X). IMHO, authorization without either authentication or reference to a prior authentication is not something that serious amounts of time should be invested in supporting. An authorization system without authentication operates on the voluntary good will of its users -- if I tell it that I'm the Prime Minister, it has no way of questioning that statement or my ability to do things the Prime Minister is allowed to do. This is not a wise move when one would like to charge for the authorized actions. We may need to support a variety of means of referencing that original authentication. In the most general case, this is some sort of state (token, cookie, or what have you) that is held by both ends of the authentication. The state might be implicit -- e.g., when Kerberos does a session key exchange, the use of that session key within its lifetime is an implicit reference to the authentication that established the session. If AAA is riding on a communication infrastructure that contains this sort of implicit authentication state (IPsec comes to mind), it may need the ability to understand that state and an interface to allow that communication infrastructure to add that state to an authorization request arriving at an authorization server. --David David L. Black, EMC Corporation From owner-aaa-wg@merit.edu Sun Feb 7 02:36:13 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id CAA04513 for ; Sun, 7 Feb 1999 02:36:13 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id CAA09411 for aaa-wg-outgoing; Sun, 7 Feb 1999 02:35:58 -0500 (EST) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by merit.edu (8.9.1a/8.9.1) with ESMTP id CAA09395; Sun, 7 Feb 1999 02:34:33 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id XAA12492; Sat, 6 Feb 1999 23:31:37 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns4.corpeast.baynetworks.com [132.245.135.76]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id CAA17979; Sun, 7 Feb 1999 02:33:56 -0500 (EST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-hme0.corpeast.baynetworks.com [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id CAA20908; Sun, 7 Feb 1999 02:39:09 -0500 for Received: from thardjon.engeast.baynetworks.com ([132.245.134.194]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Sun, 7 Feb 1999 02:35:18 -0500 Message-Id: <3.0.5.32.19990206233128.00878e30@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 06 Feb 1999 23:31:28 -0800 To: skh@merit.edu, aaa-wg@merit.edu From: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) Subject: Re: Straw-person charter (deadline 2/6/99) Cc: skh@merit.edu, thardjono@baynetworks.com In-Reply-To: <199901281642.LAA07036@idrp.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Since Sue has requested that discussions about the Charter be terminated before 2/6/99, here's my two cents worth. (NB. Although I have been on the list since the first BOF I have been silent so far since I have not been convinced (until recently) that the AAA bof/wg was *serious* about addressing the real AA&A (aka. the "AAA transport" discussions)) (a) It remains unclear to me what is the larger scope of the work to be covered by the title "A-A-A" and what the effects (intended/un-intended) the work in AA&A will have on other areas (eg. traffic-shaping, policies, etc). (b) The charter is clearly too narrow and does not address the problems within AA&A properly. It is unclear whether the solutions are for short-term or long-term needs. Jumping straight into a list of applications that may "use AAA" seems to be too short-sighted, as new applications may emerge as a result of other developments. If the working group is to address *seriously* the larger context of AA&A, the following charter objectives is far too narrow: > - determining the current set of specific applications > that the AAA will service, > - documenting requirements for a base AAA protocol, > - selecting a transport protocol or set of transport protocol to > be used by a general AAA protocol based on the requirements, > - selecting the framework for the AAA protocols, > - specifying the base AAA protocol, > - specifying the data formats for information contained > in the AAA protocol information for authentication, > authorization, and accounting. (c) I am not against the idea of connecting certain technologies/boxes/products via a transport mechanism to achieve some well-defined level of AA&A, but we should NOT be applying the grand-title of "AAA" since it would be misleading. (d) It is unclear (to me, at least) the exact meaning of the singular "protocol" in Sue's charter: >The Authentication, Authorization and Accounting working group will >focus on the specification of a general Authentication, >Authorization, and Accounting protocol for the Internet. Can we really achieve one encompassing protocol for all that the real AA&A needs? (e) The time-line is far to agressive (unless, of course, the intention is to push for something pre-decided). As Brian has pointed-out, we need to get back to the basics and we can't do that properly within this very tight schedule. (f) Since user-authentication and identification will be the basis for authorization and service-granting, we need a more in-depth document on Authentication and on Authorization. Most of the discussion on user authentication so far has been too "RAS-centric". If the WG is to address in-depth the issue of authorization, then unavoidably the problem of certificates (both user-certificates and device-certificates) must be addressed in the context of delegations, propagations and dispute-resolutions (ie. disputes among providers of services). Yes, we don't yet have a PKI infrastructure, but we soon will and if we want a long-term useful *standard* then we will have to address it now. There is a large body of work on authorization out there, ranging from the basic Subject-Action-Object model to more complex and nested models. Perhaps some of that work could be the starting point for work in the WG I am prepared to work on such a document but with help from others (and from the mailing-list). cheers, Thomas Hardjono --------------- At 11:42 AM 1/28/99 -0500, skh@merit.edu wrote: > >Hi all: > >Below is a straw-person charter. I gave this straw-person charter >to Fred Baker at IETF for review as our area director. Fred was >going to create a revision for this document prior to me >sending it to all of you. Fred has been overwhelmed by his numerous >and necessary duties with the IETF and cisco. I am sending this >"proposed" AAA-charter to all of you to discuss on the mailing list. > >Please send comments to either me privately (if you are shy) or to the >list. For all you who volunteered for areas of work, I will be contacting >you within the week to put you in groupings by your interest. Please >note that joining one of these sub-group of the Working Group involves: > > 1) participating daily on a mail list, and weekly on > a conference call. > 2) volunteering for co-writing a section of the documents > >Please contact me privately if you wish to volunteer for >a subgrouping. > >The current sub-groups (given the current charter), will be by >work area: > > Documents for March presentation (draft finished by February) > Document 1 - List of applications that use AAA > Document 2 - AAA requirments > > Documents for April documents (drafts finished by April 15th) > Document 3 - Transport protocol recommendation/selection > Document 4 - Base Framework protocol. > > 2nd round of Documents subgroups > Document 5 - Document on Accounting > Document 6 - Document on Data Format > > >Sue Hares > >-------------- > > >AAA working group charter > >The Authentication, Authorization and Accounting working group will >focus on the specification of a general Authentication, >Authorization, and Accounting protocol for the Internet. >The purpose behind creating a general AAA protocol for the Internet is to create >a common base protocol for a number of specific AAA protocols which include >IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. >By creating a general base Protocol, the amount of work to create a >specific AAA protocols will be reduced. > >The problem space for a general AAA working group contains >work in: > - determining the current set of specific applications > that the AAA will service, > - documenting requirements for a base AAA protocol, > - selecting a transport protocol or set of transport protocol to > be used by a general AAA protocol based on the requirements, > - selecting the framework for the AAA protocols, > - specifying the base AAA protocol, > - specifying the data formats for information contained > in the AAA protocol information for authentication, > authorization, and accounting. > >Since the area of work is broad the working group will need to focus >on subsections of the work. To aid this effort, the charter of the >working group will be focused on a few sections of the total work. At the >time period, the working group nears completion of this work the >charter will be revised to include the next section of the work. > >The first step in this working group is to determine the requirements for the >AAA protocol. To accomplish this, we must document the current set of >applications that we will use to set our requirements. To set the >requirements, we will collect requirements and then cull out any requirements >which are specific to a particular instantiation of AAA. These requirements >will be forward to the appropriate working group working on a specific >AAA function such as NASREQ. The work on the requirements will leverage >the work done on AAA requirements by the two BOF meetings. > >After setting our requirements, we will use the requirements to >select a transport protocol and set the framework for the AAA protocols. >After having done all the background work for specifying the base AAA protocol, >The working group will select a base protocol for AAA functions. > >At this point, the work will diverge into two paths: > > - specification of data format for AAA functions such as > accounting, > - the specification of new specific protocols based on > the new AAA Base protocol. > >The working group should then re-examine the charter to tighten >the focus once again. > >Document Schedule > >April '99 AAA Applications (informational RFC) Working Group Draft > AAA Requirements to Working Group Draft > >May '99 AAA transport selection to Working Group Draft > AAA Base Protocol Framework Working Group Draft > >July '99 AAA Base protocol Specification to Working Group Draft > AAA Applications to Informational RFC > AAA Requirements to Informational RFC > >Nov '99 Revision of charter to include new specific protocols > and data formats. > > > > > > > ---------------------------------------------------------------------- Thomas Hardjono 3 Federal Street, BL3-03 Bay Architecture Lab Billerica, MA 01821, USA Nortel Networks Tel: 978-916-4538 email: thardjono@baynetworks.com Fax: 978-916-0620 ---------------------------------------------------------------------- From owner-aaa-wg@merit.edu Sun Feb 7 03:13:13 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id DAA04903 for ; Sun, 7 Feb 1999 03:13:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id DAA11008 for aaa-wg-outgoing; Sun, 7 Feb 1999 03:12:00 -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 DAA10985 for ; Sun, 7 Feb 1999 03:11:37 -0500 (EST) Received: from mci.net ([166.45.6.34]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7G3YKZQW68WW4LD@shoe.reston.mci.net> for aaa-wg@merit.edu; Sun, 7 Feb 1999 03:11:02 EST Date: Sun, 07 Feb 1999 00:10:33 -0800 From: Paul Krumviede Subject: Re: Straw-person charter (deadline 2/6/99) To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36BD4A79.C6A2E5C0@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: <3.0.5.32.19990206233128.00878e30@bl-mail2.corpeast.baynetworks.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk I'll try to keep this short. Thomas Hardjono wrote: > (f) Since user-authentication and identification will be the basis > for authorization and service-granting, we need a more > in-depth document on Authentication and on Authorization. > > Most of the discussion on user authentication so far has been > too "RAS-centric". If the WG is to address in-depth the issue > of authorization, then unavoidably the problem of certificates > (both user-certificates and device-certificates) must be addressed > in the context of delegations, propagations and dispute-resolutions > (ie. disputes among providers of services). > Yes, we don't yet have a PKI infrastructure, but we soon will > and if we want a long-term useful *standard* then we will > have to address it now. There has been considerable off-line discussion of this, as well as some on the list. I feel strongly that we need to not constrain ourselves to a simple model of, for example, a single user (this is in itself a generalization of the remote access scenario, as I see it). While one can make a strong argument that solving some of the potential problems for multicast is still an open research question, we should try to be flexible enough that we don't revisit this whole discussion when we need solutions to handle group interaction problems. I am, however, leery of tying this too tightly to certificates. For one thing, I've been hearing for too many years that "we soon will" have a PKI (at least in a global sense). One attempt around this was Ron Rivest's SDSI, subsumed into SPKI, but it isn't clear (at least to me) how to use something like that in some of the cases we're concerned about. To the extent that we can avoid dependency on a global, ubiquitous PKI, I think we should think about this very hard. Note that Sue's interest in bandwidth brokers seems to have many sides to it that don't seem to be obviously similar to the remote access scenarios. > There is a large body of work on authorization out there, > ranging from the basic Subject-Action-Object model > to more complex and nested models. Perhaps some of that > work could be the starting point for work in the WG And in a more concrete sense, something like Policymaker might be interesting in terms of how one expresses some of the relationships between entities (e.g., as a way of expressing delegation). But this might be a topic for the policy WG. > I am prepared to work on such a document but with help > from others (and from the mailing-list). I think that the WG co-chairs will welcome input, particularly as a counterpoint to the usual, more vocal, parties. From my perspective, I would really like to see more input from service operators, since many of the common contributors seem to be from suppliers. -paul From owner-aaa-wg@merit.edu Sun Feb 7 11:13:25 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA10009 for ; Sun, 7 Feb 1999 11:13:25 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA15438 for aaa-wg-outgoing; Sun, 7 Feb 1999 11:11:35 -0500 (EST) Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA15434; Sun, 7 Feb 1999 11:11:29 -0500 (EST) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA18729; Sun, 7 Feb 1999 08:10:27 -0800 (PST) Received: from fred-pc (fred-hm-dhcp3.cisco.com [171.69.128.118]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id IAA01347; Sun, 7 Feb 1999 08:10:27 -0800 (PST) Message-Id: <199902071610.IAA01347@kiwi.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 07 Feb 1999 08:09:23 -0800 To: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) From: Fred Baker Subject: Re: Straw-person charter (deadline 2/6/99) Cc: skh@merit.edu, aaa-wg@merit.edu, skh@merit.edu, thardjono@baynetworks.com In-Reply-To: <3.0.5.32.19990206233128.00878e30@bl-mail2.corpeast.baynetw orks.com> References: <199901281642.LAA07036@idrp.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk > If the working group is to address *seriously* > the larger context of AA&A, the following charter [and time line] > objectives is far too narrow: Telling us we have it wrong doesn't particularly help. What charter objectives do you think should be listed? From owner-aaa-wg@merit.edu Sun Feb 7 12:15:46 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA10454 for ; Sun, 7 Feb 1999 12:15:46 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA15925 for aaa-wg-outgoing; Sun, 7 Feb 1999 12:15:19 -0500 (EST) Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA15921 for ; Sun, 7 Feb 1999 12:15:14 -0500 (EST) Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca; Sun, 7 Feb 1999 12:14:48 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id <1M5VZ5NV>; Sun, 7 Feb 1999 12:14:47 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5023C5AB7@crchy270.us.nortel.com> From: "Emad Qaddoura" To: "'Shai Herzog'" Cc: "Basavaraj Patil" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Sun, 7 Feb 1999 12:14:27 -0500 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 Shai, Can you expand further on #2 below: >>(2) it does not contain things that cannot be justified >>for these N applications (future use stuff) The way I interpret it now, that it is MAINLY for the currently existing N applications, and may not be workable for future applications. Regards, Emad. > -----Original Message----- > From: Shai Herzog [SMTP:herzog@iphighway.com] > Sent: Friday, February 05, 1999 2:28 PM > To: Qaddoura, Emad [RICH2:IP10-M:EXCH] > Cc: 'Durham, David'; Patil, Basavaraj [RICH2:IP10:EXCH]; > aaa-wg@merit.edu > Subject: RE: Back to basics > > At 06:49 PM 2/4/99, Emad Qaddoura wrote: > >Shai, > > > >> "So, I guess I am saying that we must choose whether to take the > >long > >>road to define a very generic mechanism, or take the faster road and > >>define a unified solution for N AAA problems we already know. I > (obviously) > >>vote toward the later. Things would become much clearer if we list N > >>specific AAA problems the WG is trying to solve and completely put > >>aside the "whatever" clause. Further more, the N may be reduced even > more > >>if we find out some of the previously thought of problems have > >>different requirements" > > > > > > Or is there something in the middle? > > You can increase or decrease the N value ;-) > > It is fine to try to keep a protocol "OPEN" or "GENERIC" as long > as we all understand that (1) it is designed for N applications > and (2) it does not contain things that cannot be justified > for these N applications (future use stuff) and (3) that is not > artificially gluing very different applications just to > force a single protocol (e.g., one can design a TCP/UDP protocol > that does both, but we rather have them separate since their functionality > is very different). > > Shai > > > __________________________________________________________ > Shai Herzog Founder & CTO, IPHighway Inc. > Cell: (408) 390-3045 http://www.iphighway.com/herzog > Tel : (201) 585-0800 Fax : (212) 656-1006 From owner-aaa-wg@merit.edu Sun Feb 7 21:58:40 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id VAA15175 for ; Sun, 7 Feb 1999 21:58:40 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA21246 for aaa-wg-outgoing; Sun, 7 Feb 1999 21:57:10 -0500 (EST) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by merit.edu (8.9.1a/8.9.1) with ESMTP id VAA21242; Sun, 7 Feb 1999 21:57:05 -0500 (EST) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id SAA07582; Sun, 7 Feb 1999 18:54:10 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id SAA08576; Sun, 7 Feb 1999 18:56:30 -0800 (PST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-hme0.corpeast.baynetworks.com [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id VAA22536; Sun, 7 Feb 1999 21:56:24 -0500 for Received: from thardjon.engeast.baynetworks.com ([132.245.134.201]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Sun, 7 Feb 1999 21:57:48 -0500 Message-Id: <3.0.5.32.19990207185353.0082c100@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 07 Feb 1999 18:53:53 -0800 To: Fred Baker From: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) Subject: Re: Straw-person charter (deadline 2/6/99) Cc: skh@merit.edu, aaa-wg@merit.edu, thardjono@baynetworks.com In-Reply-To: <199902071610.IAA01347@kiwi.cisco.com> References: <3.0.5.32.19990206233128.00878e30@bl-mail2.corpeast.baynetw orks.com> <199901281642.LAA07036@idrp.merit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 08:09 AM 2/7/99 -0800, Fred Baker wrote: >> If the working group is to address *seriously* >> the larger context of AA&A, the following charter [and time line] >> objectives is far too narrow: > >Telling us we have it wrong doesn't particularly help. What charter >objectives do you think should be listed? > Fred, I was not saying that it is wrong. My apologies. To me its not a matter of right or wrong, but of everyone agreeing clearly what they mean by "A-A-A". I would prefer to see objectives somewhere along these lines: 1 Define the problem area and scope 2 Define a general framework for AA&A - couched in an open language and not referring to any particular system or technology - describe and discuss how the three A's are interrelated - describe and discuss how AA&A fits into other areas of work (such as QoS, policy, etc) - if necessary, define sub-framework for each of the A's - others 3 Identify and specify the requirements - taking into consideration the current applications and possible future applications - the requirements doc (draft-ietf-hares-aaa-req.txt) is on the right path, but needs more work 4 Identify existing protocol(s) that can be used 5 Identify the protocol(s) that need to be developed 6 Define how the chosen protocol(s) will interact with other constructs (eg. protocols, MIBs, etc) from other areas/WGs (any input, additions, changes, slams, most welcome). Now, having said all the above, clearly this process is going to take a longer timeline. The question that everyone must answer is whether we are willing to give ourselves more time to accomplish this. cheers, thomas ------ From owner-aaa-wg@merit.edu Mon Feb 8 10:33:12 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA21915 for ; Mon, 8 Feb 1999 10:33:12 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id KAA29588 for aaa-wg-outgoing; Mon, 8 Feb 1999 10:28:02 -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 KAA29580 for ; Mon, 8 Feb 1999 10:27:55 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA27483; Mon, 8 Feb 1999 07:27:16 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.95.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA02497; Mon, 8 Feb 1999 07:27:15 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA14085; Mon, 8 Feb 1999 07:27:00 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902081527.HAA14085@hsmpka.eng.sun.com> Date: Mon, 8 Feb 1999 07:23:21 -0800 To: , Reply-To: Subject: Re: Straw-person charter (deadline 2/6/99) 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 > >From my perspective, >I would really like to see more input from service operators, since >many of the common contributors seem to be from suppliers. This I cannot stress enough. Thanks for bringing it up Paul. PatC From owner-aaa-wg@merit.edu Mon Feb 8 15:57:09 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA24644 for ; Mon, 8 Feb 1999 15:57:09 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA07965 for aaa-wg-outgoing; Mon, 8 Feb 1999 15:56:29 -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 PAA07956 for ; Mon, 8 Feb 1999 15:56:23 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7I8Z36TVE8Y5A1L@shoe.reston.mci.net> for aaa-wg@merit.edu; Mon, 8 Feb 1999 15:55:47 EST Date: Mon, 08 Feb 1999 12:55:26 -0800 From: Paul Krumviede Subject: Re: Straw-person charter (deadline 2/6/99) To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36BF4F42.982D83BD@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3.0.5.32.19990208121745.00be9450@porky> Sender: owner-aaa-bof@merit.edu Precedence: bulk Matt Holdrege wrote: > > At 07:23 AM 2/8/99 -0800, Patrice Calhoun wrote: > > > >> > >>From my perspective, > >>I would really like to see more input from service operators, since > >>many of the common contributors seem to be from suppliers. > > > >This I cannot stress enough. Thanks for bringing it up Paul. > > I also brought up this point at the meeting. Some folks later said that > service providers won't do this because it would reveal their product plans > to competitors. Speaking as a service provider, I don't think this is the case. To the extent that we can or will speak of types of services or features, I don't think there is much risk to service providers. After all, saying "I want to be able to offer QoS" is not a surprise to anybody (but it also isn't enough to figure out what to design). > I would encourage service providers to attempt to forward their > requirements in an abstract manner. We don't want you to reveal any > proprietary information, but it is in your best interest that standard > interoperable implementations exist. It isn't necessary for your input to > be very specific. Actually, the real concern is that if we (as a service provider) feel that a WG is not doing much (or anything) of interest, we'll look elsewhere. We may still get standard interoperable implementations, but of a spec that did not come through the WG in question. So in one sense lack of service provider input makes one wonder if there is any real need for any such WG. (Note that I'm trying to speak of WGs in general, not AAA in particular.) -paul not attempting to speak for MCI WorldCom in toto From owner-aaa-wg@merit.edu Mon Feb 8 16:11:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA24766 for ; Mon, 8 Feb 1999 16:11:41 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id QAA08423 for aaa-wg-outgoing; Mon, 8 Feb 1999 16:11:28 -0500 (EST) Received: from smtpott2.nortel.ca (smtpott2.NortelNetworks.com [192.58.194.80]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA08416 for ; Mon, 8 Feb 1999 16:11:22 -0500 (EST) Received: from zrchb213.us.nortel.com (actually 47.100.128.42) by smtpott2.nortel.ca; Mon, 8 Feb 1999 16:10:57 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1LYQP2G9>; Mon, 8 Feb 1999 15:10:48 -0600 Message-ID: <31B1EFDD2CD3D11187710000F805A8D501625837@crchy270.us.nortel.com> From: "Mohamad Khalil" To: "'Shai Herzog'" , "Emad Qaddoura" Cc: "'Durham, David'" , "Basavaraj Patil" , aaa-wg@merit.edu Subject: RE: Back to basics Date: Mon, 8 Feb 1999 15:09:53 -0600 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 think it will be more appropriate to design the AAA protocol to fit a set of N problem or application domains instead of N problems or applications. Also, the AAA protocol it should be flexible enough to be extended beyond the set of problem or application domains it has defined for. > -----Original Message----- > From: Shai Herzog [SMTP:herzog@iphighway.com] > Sent: Friday, February 05, 1999 1:28 PM > To: Qaddoura, Emad [RICH2:IP10-M:EXCH] > Cc: 'Durham, David'; Patil, Basavaraj [RICH2:IP10:EXCH]; > aaa-wg@merit.edu > Subject: RE: Back to basics > > At 06:49 PM 2/4/99, Emad Qaddoura wrote: > >Shai, > > > >> "So, I guess I am saying that we must choose whether to take the > >long > >>road to define a very generic mechanism, or take the faster road and > >>define a unified solution for N AAA problems we already know. I > (obviously) > >>vote toward the later. Things would become much clearer if we list N > >>specific AAA problems the WG is trying to solve and completely put > >>aside the "whatever" clause. Further more, the N may be reduced even > more > >>if we find out some of the previously thought of problems have > >>different requirements" > > > > > > Or is there something in the middle? > > You can increase or decrease the N value ;-) > > It is fine to try to keep a protocol "OPEN" or "GENERIC" as long > as we all understand that (1) it is designed for N applications > and (2) it does not contain things that cannot be justified > for these N applications (future use stuff) and (3) that is not > artificially gluing very different applications just to > force a single protocol (e.g., one can design a TCP/UDP protocol > that does both, but we rather have them separate since their functionality > is very different). > > Shai > > > __________________________________________________________ > Shai Herzog Founder & CTO, IPHighway Inc. > Cell: (408) 390-3045 http://www.iphighway.com/herzog > Tel : (201) 585-0800 Fax : (212) 656-1006 From owner-aaa-wg@merit.edu Mon Feb 8 17:18:26 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA25174 for ; Mon, 8 Feb 1999 17:18:26 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA10232 for aaa-wg-outgoing; Mon, 8 Feb 1999 17:17:30 -0500 (EST) Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA10225 for ; Mon, 8 Feb 1999 17:17:24 -0500 (EST) Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id WAA23577; Mon, 8 Feb 1999 22:07:54 GMT Received: from sinnreich2 ([166.44.130.195]) by omss5.mcit.com (InterMail v03.02.05 118 120) with SMTP id <19990208220811.HEKA7750@[166.44.130.195]>; Mon, 8 Feb 1999 16:08:11 -0600 From: "Henry Sinnreich" To: "pcalhoun@eng.sun.com" , "Basavaraj Patil" Cc: , "Emad Qaddoura" , Subject: RE: Applications using AAA Date: Mon, 8 Feb 1999 16:07:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk I may be sounding like a broken record: Current work on exchanging records for payments and settlements between IP Tel carriers includes XML. In real time. So unless you don't want to drop the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... Sorry for the scratching sound... Henry > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of pcalhoun@eng.sun.com > Sent: Friday, February 05, 1999 6:14 PM > To: Basavaraj Patil > Cc: 'aaa-wg@merit.edu'; Emad Qaddoura > Subject: Re: Applications using AAA > > > > > > Part of the straw-person charter issued by Sue included : > > > > "The first step in this working group is to determine the > requirements for > > the > > AAA protocol. To accomplish this, we must document the current set of > > applications that we will use to set our requirements. To set the > > requirements, we will collect requirements and then cull out any > > requirements > > which are specific to a particular instantiation of AAA." > > > > Applications identified so far include : > > -IP Telephony > > -PPP Remote Dial-in (NAS) > > -Terminal Server (telnet etc.) > > -Bandwidth Broker > > -Mobile IP > > -IP Fax > > For now I would add ROAMOPS. Although ROAMOPS is not an > application, it will > make sure that Cross-Domain AAA works well. > > PatC > > > > What other applications, in use today, can we use and add to > this list which > > can serve as the basis for gathering/refining the requirements? > > > > Basavaraj Patil > > Nortel Networks > > From owner-aaa-wg@merit.edu Mon Feb 8 17:25:44 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA25386 for ; Mon, 8 Feb 1999 17:25:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA10405 for aaa-wg-outgoing; Mon, 8 Feb 1999 17:25:39 -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 RAA10401 for ; Mon, 8 Feb 1999 17:25:34 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA03054; Mon, 8 Feb 1999 14:21:29 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.101.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA21199; Mon, 8 Feb 1999 14:21:27 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14544; Mon, 8 Feb 1999 14:21:12 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902082221.OAA14544@hsmpka.eng.sun.com> Date: Mon, 8 Feb 1999 14:17:32 -0800 To: "Henry Sinnreich" , "Basavaraj Patil" , "pcalhoun@eng.sun.com" Cc: , "Emad Qaddoura" , Reply-To: Subject: RE: Applications using AAA 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 may be sounding like a broken record: > >Current work on exchanging records for payments and settlements between IP >Tel carriers includes XML. In real time. So unless you don't want to drop >the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... > >Sorry for the scratching sound... And my tune will also sound similar. At this point, if XML is necessary (as you describe) it is how it is presented to the user. This, I believe, does not need to be generated directly from the embedded system, be it a NAS or router. If we are stating that inter-domain accounting records MUST be in an XML format, then it means that the accounting data generated by the router MAY be different from what a AAA server would send to another provider. But as I also previously stated, XML parsing can add an additional 60% overhead. If you are all comfortable with this, then I have no problems with it (especially not if it means you have to upgrade your AAA server hardware :) PatC > >Henry > >> -----Original Message----- >> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >> Of pcalhoun@eng.sun.com >> Sent: Friday, February 05, 1999 6:14 PM >> To: Basavaraj Patil >> Cc: 'aaa-wg@merit.edu'; Emad Qaddoura >> Subject: Re: Applications using AAA >> >> >> > >> > Part of the straw-person charter issued by Sue included : >> > >> > "The first step in this working group is to determine the >> requirements for >> > the >> > AAA protocol. To accomplish this, we must document the current set of >> > applications that we will use to set our requirements. To set the >> > requirements, we will collect requirements and then cull out any >> > requirements >> > which are specific to a particular instantiation of AAA." >> > >> > Applications identified so far include : >> > -IP Telephony >> > -PPP Remote Dial-in (NAS) >> > -Terminal Server (telnet etc.) >> > -Bandwidth Broker >> > -Mobile IP >> > -IP Fax >> >> For now I would add ROAMOPS. Although ROAMOPS is not an >> application, it will >> make sure that Cross-Domain AAA works well. >> >> PatC >> > >> > What other applications, in use today, can we use and add to >> this list which >> > can serve as the basis for gathering/refining the requirements? >> > >> > Basavaraj Patil >> > Nortel Networks >> >> > From owner-aaa-wg@merit.edu Mon Feb 8 17:36:08 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA25550 for ; Mon, 8 Feb 1999 17:36:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA10592 for aaa-wg-outgoing; Mon, 8 Feb 1999 17:35:57 -0500 (EST) Received: from harlequin.MorningStar.Com (harlequin.MorningStar.Com [137.175.80.154]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA10588 for ; Mon, 8 Feb 1999 17:35:53 -0500 (EST) Received: (from edguer@localhost) by harlequin.MorningStar.Com (8.9.0/8.9.0) id RAA22485 for aaa-wg@merit.edu; Mon, 8 Feb 1999 17:35:20 -0500 (EST) From: Aydin Edguer Message-Id: <199902082235.RAA22485@harlequin.MorningStar.Com> Subject: Re: Applications using AAA To: aaa-wg@merit.edu Date: Mon, 8 Feb 1999 17:35:18 -0500 (EST) In-Reply-To: from "Henry Sinnreich" at Feb 8, 99 04:07:27 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk > Current work on exchanging records for payments and settlements between IP > Tel carriers includes XML. In real time. So unless you don't want to drop > the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... Who is doing the "current work"? Is it a standards body or a proprietary organization (Bellcore, Nortel)? If it is a standards body, which group (ANSI, IETF)? Where is the documentation on their requirements, and usage justifications? No one has said "no" to anything yet and I have seen nothing that would preclude sending XML, Morse Code, or psychic messages for Accounting purposes. If you have a requirement and you think it is relevant to the Working Group then either write up a draft document describing the work or give us pointers to the necessary information. From owner-aaa-wg@merit.edu Mon Feb 8 18:47:08 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA26613 for ; Mon, 8 Feb 1999 18:47:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA11937 for aaa-wg-outgoing; Mon, 8 Feb 1999 18:46:48 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.nortel.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA11933 for ; Mon, 8 Feb 1999 18:46:43 -0500 (EST) Received: from zrchb213.us.nortel.com (actually 47.100.128.42) by smtprtp.nortel.com; Mon, 8 Feb 1999 18:45:59 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1LYQPLMR>; Mon, 8 Feb 1999 17:46:01 -0600 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E89@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Henry Sinnreich'" , "pcalhoun@eng.sun.com" Cc: aaa-wg , "Emad Qaddoura" , "stephen.thomas" Subject: RE: Applications using AAA Date: Mon, 8 Feb 1999 17:45:57 -0600 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 may be sounding like a broken record: > >Current work on exchanging records for payments and settlements between IP >Tel carriers includes XML. In real time. So unless you don't want to drop >the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... > >Sorry for the scratching sound... > >Henry I agree that XML may be a solution for payments and settlements between carriers. However I am not sure if the data generated by the network nodes that is used for accounting needs to be in XML format. So between routers (of a carrier) there could be an optimized dataset defined by this WG for transporting accounting data and then use XML between some billing servers for Inter-carrier settlements. The overhead of XML would then exist only between the settlement servers. -Basavaraj Patil From owner-aaa-wg@merit.edu Mon Feb 8 20:07:35 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA27230 for ; Mon, 8 Feb 1999 20:07:35 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA13167 for aaa-wg-outgoing; Mon, 8 Feb 1999 20:07:07 -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 UAA13161 for ; Mon, 8 Feb 1999 20:06:59 -0500 (EST) Received: from mailhost.BayNetworks.COM (h016d.s86b1.BayNetworks.COM [134.177.1.109]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id RAA18571; Mon, 8 Feb 1999 17:05:41 -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 RAA23252; Mon, 8 Feb 1999 17:06:02 -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 UAA10596; Mon, 8 Feb 1999 20:07:26 -0500 for Received: from msquire ([132.245.134.8]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Mon, 8 Feb 1999 20:07:24 -0500 Message-Id: <3.0.32.19990208195643.00a1cb50@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 08 Feb 1999 19:56:46 -0500 To: From: Matt Squire Subject: RE: Applications using AAA Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 02:17 PM 2/8/99 -0800, you wrote: > >>I may be sounding like a broken record: >> >>Current work on exchanging records for payments and settlements between IP >>Tel carriers includes XML. In real time. So unless you don't want to drop >>the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... >> >>Sorry for the scratching sound... > >And my tune will also sound similar. > >At this point, if XML is necessary (as you describe) it is how it is presented >to the user. This, I believe, does not need to be generated directly from the >embedded system, be it a NAS or router. If we are stating that inter-domain >accounting records MUST be in an XML format, then it means that the accounting >data generated by the router MAY be different from what a AAA server would send >to another provider. > >But as I also previously stated, XML parsing can add an additional 60% overhead. >If you are all comfortable with this, then I have no problems with it >(especially not if it means you have to upgrade your AAA server hardware :) > >PatC > >> >>Henry I'm personally not convinced that XML is required for client-server accounting exchanges. Although it would certainly make things general, there is the problem of overhead. However, the overhead of parsing is at the AAA server, not the client. A client should not have to parse these messages, it should just report data to a server. Some have argued that the client may need acctng data to make decisions (and hence have to parse). I disagree - the client can report acctng data to the server and use the authorization part of AAA to make decisions at the server (the policy decision point and policy enforcement point model). I see no reason why a client would have to parse. The overhead for generating an XML message is not nearly as high as the overhead for parsing. Without actually coding and measuring the performance, I'd guess xml generation overhead to be of only of minor significance to client performance. Server performance, on the other hand, may be effected by the parsing. But this effect would only be felt in those cases where the acctng data is used for real-time decisions. Offline tasks, such as bill generation, can easily sustain the processing overhead, and would most likely benefit from the most general format available. As such, I don't think its unreasonable to define a shorthand for a carefully defined subset of XML that simplifies parsing and that can be negotiated for real-time uses. Although we limit ourselves in generality, we gain performance when it is required. A fuller version of XML might be used when real-time decisions are not required. A table at the server can define the short-hand to full acctng format translation. My gut tells me that the generality of XML (or something similar) may be required for server-to-server communications. Defining a subset of the server-to-server acctng formats for client-to-server seems reasonable, as does the possibility of defining a short-hand expression to improve processing performance. - Matt - ps. my 2 cents is usally given away for free From owner-aaa-wg@merit.edu Mon Feb 8 20:23:39 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA27354 for ; Mon, 8 Feb 1999 20:23:39 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA13515 for aaa-wg-outgoing; Mon, 8 Feb 1999 20:23:23 -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 UAA13511 for ; Mon, 8 Feb 1999 20:23:18 -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 RAA21327; Mon, 8 Feb 1999 17:23:08 -0800 (PST) Message-Id: <3.0.6.32.19990208171945.009801b0@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 Feb 1999 17:19:45 -0800 To: "David L. Black" From: Brian Lloyd Subject: Re: Authorization without Authentication? Cc: aaa-wg@merit.edu In-Reply-To: <3.0.5.32.19990206233204.007ba100@pop.ma.ultranet.com> References: <3.0.6.32.19990204105655.009492e0@127.0.0.1> <31B1EFDD2CD3D11187710000F805A8D5022D5E65@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 11:32 PM 2/6/99 -0500, you wrote: >Back to the original example that kicked off this discussion. > >>Example: I walk up to a teller in a bank to request a transaction. > >Not exactly. I doubt Brian wants his ability to transfer funds from an >account available as public information to anyone who asks. The key >phrase in the above example is "by virtue of being the teller" -- in >other words the teller is authorized to check Brian's ability to >transfer funds out of the account by virtue of a previous authentication >of him/her as a teller to the bank's account management system. That is correct. The authorization to determine what brian is authorized to do is permitted to the teller. Here is a case where the authentication and authorization are for different things. >> I was just stating that you can make an authorization request without ever >> authenticating. The question is, "is U allowed to do X." The answer is, >> "yes, and here is how." This has nothing to do with the question, "is this >> entity that purports to be U really U?" > >This assumes that the answer to "is U allowed to do X" is public information >available to all comers. In the bank example (and many others), it isn't >and hence a prior authentication is necessary to read this information >(even if the request is not to actually do X). It may be public information and it may not. I didn't want to belabor that particular point. In the above scenario the authorization for the teller to have access to brian's authorizations may be granted based on where the query comes from (teller's terminal) or by virtue of a separate authentication of the teller. The point is that the authorization in which I have interest, i.e. brian's fund transfer capability, has no direct connection with the authentication, of the teller in this case. >IMHO, authorization without either authentication or reference to a prior >authentication is not something that serious amounts of time should >be invested in supporting. An authorization system without authentication >operates on the voluntary good will of its users -- if I tell it >that I'm the Prime Minister, it has no way of questioning that statement >or my ability to do things the Prime Minister is allowed to do. This >is not a wise move when one would like to charge for the authorized >actions. We have found several situations where "authentication by assertion,: i.e. asking for authorization information and not having to formally authenticate the user ID, is a useful operation. Usually it depends on who is asking the question but not always. I assert that "authentication by assertion" is a valid means of authentication for certain classes of service or for certain queries. >We may need to support a variety of means of referencing that original >authentication. In the most general case, this is some sort of state >(token, cookie, or what have you) that is held by both ends of the >authentication. The state might be implicit -- e.g., when Kerberos >does a session key exchange, the use of that session key within its >lifetime is an implicit reference to the authentication that established >the session. If AAA is riding on a communication infrastructure that contains >this sort of implicit authentication state (IPsec comes to mind), it >may need the ability to understand that state and an interface to >allow that communication infrastructure to add that state to an authorization >request arriving at an authorization server. Good point. 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-wg@merit.edu Mon Feb 8 20:26:44 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA27397 for ; Mon, 8 Feb 1999 20:26:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA13570 for aaa-wg-outgoing; Mon, 8 Feb 1999 20:26:37 -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 UAA13566 for ; Mon, 8 Feb 1999 20:26:32 -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 RAA21330; Mon, 8 Feb 1999 17:23:09 -0800 (PST) Message-Id: <3.0.6.32.19990208172106.00910930@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 Feb 1999 17:21:06 -0800 To: "Mohamad Khalil" From: Brian Lloyd Subject: RE: Back to basics Cc: aaa-wg@merit.edu In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D501625837@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 03:09 PM 2/8/99 -0600, Mohamad Khalil wrote: >I think it will be more appropriate to design the AAA protocol to >fit a set of N problem or application domains instead of N problems or >applications. I agree. >Also, the AAA protocol it should be flexible enough to be extended beyond >the set of problem or application domains it has defined for. But one of the tests for the correctness of our assumptions is to test against the known specific cases. 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-wg@merit.edu Mon Feb 8 20:43:54 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA27543 for ; Mon, 8 Feb 1999 20:43:54 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA13800 for aaa-wg-outgoing; Mon, 8 Feb 1999 20:43:43 -0500 (EST) Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA13796 for ; Mon, 8 Feb 1999 20:43:39 -0500 (EST) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id BAA09825; Tue, 9 Feb 1999 01:42:04 GMT Received: from sinnreich2 ([166.44.130.195]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990209014229.SVFP23797@sinnreich2>; Mon, 8 Feb 1999 19:42:29 -0600 From: "Henry Sinnreich" To: , "Basavaraj Patil" Cc: , "Emad Qaddoura" , Subject: RE: Applications using AAA Date: Mon, 8 Feb 1999 19:41:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <199902082221.OAA14544@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat wrote: > At this point, if XML is necessary (as you describe) it is how it > is presented > to the user. This, I believe, does not need to be generated > directly from the > embedded system, be it a NAS or router. If we are stating that > inter-domain > accounting records MUST be in an XML format, then it means that > the accounting > data generated by the router MAY be different from what a AAA > server would send > to another provider. Agree, you have expressed it very well. Henry > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Patrice Calhoun > Sent: Monday, February 08, 1999 5:18 PM > To: Henry Sinnreich; Basavaraj Patil; pcalhoun@eng.sun.com > Cc: stephen.thomas@transnexus.com; Emad Qaddoura; aaa-wg@merit.edu > Subject: RE: Applications using AAA > > > > >I may be sounding like a broken record: > > > >Current work on exchanging records for payments and settlements > between IP > >Tel carriers includes XML. In real time. So unless you don't want to drop > >the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... > > > >Sorry for the scratching sound... > > And my tune will also sound similar. > > At this point, if XML is necessary (as you describe) it is how it > is presented > to the user. This, I believe, does not need to be generated > directly from the > embedded system, be it a NAS or router. If we are stating that > inter-domain > accounting records MUST be in an XML format, then it means that > the accounting > data generated by the router MAY be different from what a AAA > server would send > to another provider. > > But as I also previously stated, XML parsing can add an > additional 60% overhead. > If you are all comfortable with this, then I have no problems with it > (especially not if it means you have to upgrade your AAA server > hardware :) > > PatC > > > > >Henry > > > >> -----Original Message----- > >> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > >> Of pcalhoun@eng.sun.com > >> Sent: Friday, February 05, 1999 6:14 PM > >> To: Basavaraj Patil > >> Cc: 'aaa-wg@merit.edu'; Emad Qaddoura > >> Subject: Re: Applications using AAA > >> > >> > >> > > >> > Part of the straw-person charter issued by Sue included : > >> > > >> > "The first step in this working group is to determine the > >> requirements for > >> > the > >> > AAA protocol. To accomplish this, we must document the > current set of > >> > applications that we will use to set our requirements. To set the > >> > requirements, we will collect requirements and then cull out any > >> > requirements > >> > which are specific to a particular instantiation of AAA." > >> > > >> > Applications identified so far include : > >> > -IP Telephony > >> > -PPP Remote Dial-in (NAS) > >> > -Terminal Server (telnet etc.) > >> > -Bandwidth Broker > >> > -Mobile IP > >> > -IP Fax > >> > >> For now I would add ROAMOPS. Although ROAMOPS is not an > >> application, it will > >> make sure that Cross-Domain AAA works well. > >> > >> PatC > >> > > >> > What other applications, in use today, can we use and add to > >> this list which > >> > can serve as the basis for gathering/refining the requirements? > >> > > >> > Basavaraj Patil > >> > Nortel Networks > >> > >> > > > > From owner-aaa-wg@merit.edu Mon Feb 8 20:46:41 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA27561 for ; Mon, 8 Feb 1999 20:46:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA13844 for aaa-wg-outgoing; Mon, 8 Feb 1999 20:46:33 -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 UAA13840 for ; Mon, 8 Feb 1999 20:46:28 -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 RAA21478 for ; Mon, 8 Feb 1999 17:46:26 -0800 (PST) Message-Id: <3.0.6.32.19990208174510.0094bcc0@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 Feb 1999 17:45:10 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: RE: Applications using AAA In-Reply-To: <3.0.32.19990208195643.00a1cb50@bl-mail1.corpeast.baynetwor ks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>Current work on exchanging records for payments and settlements between IP >>>Tel carriers includes XML. This falls under the same catagory as the discussion of TCP vs. UDP. We aren't to that point in the discussion yet. Please table the discussion of XML. 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-wg@merit.edu Mon Feb 8 21:06:20 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id VAA27687 for ; Mon, 8 Feb 1999 21:06:20 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA14091 for aaa-wg-outgoing; Mon, 8 Feb 1999 21:06:10 -0500 (EST) Received: from antiochus-fe0.ultra.net (antiochus-fe0.ultra.net [146.115.8.188]) by merit.edu (8.9.1a/8.9.1) with ESMTP id VAA14079 for ; Mon, 8 Feb 1999 21:06:03 -0500 (EST) Received: from pavilion (207-172-102-58.s566.tnt1.sbo.erols.com [207.172.102.58]) by antiochus-fe0.ultra.net (8.8.8/ult/n20340/mtc.v2) with SMTP id VAA21034; Mon, 8 Feb 1999 21:05:57 -0500 (EST) Message-Id: <3.0.5.32.19990208211254.007a3100@pop.ma.ultranet.com> X-Sender: dlb237@pop.ma.ultranet.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 08 Feb 1999 21:12:54 -0500 To: Brian Lloyd From: "David L. Black" Subject: Re: Authorization without Authentication? Cc: "David L. Black" , aaa-wg@merit.edu In-Reply-To: <3.0.6.32.19990208171945.009801b0@158.222.8.12> References: <3.0.5.32.19990206233204.007ba100@pop.ma.ultranet.com> <3.0.6.32.19990204105655.009492e0@127.0.0.1> <31B1EFDD2CD3D11187710000F805A8D5022D5E65@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk >In the above scenario the authorization for the teller >to have access to brian's authorizations may be granted based on where the >query comes from (teller's terminal) or by virtue of a separate >authentication of the teller. The point is that the authorization in which >I have interest, i.e. brian's fund transfer capability, has no direct >connection with the authentication, of the teller in this case. IMHO, this misses the point. The action the teller was authorized to do was "read authorization privileges (of Brian) for account XXX" for the object "Bank authorization database". This is very different from authorizing a "transfer" action for the object "account XXX". Sorry to be pedantic, but I strongly believe that the authorization system should be applied to management of the authorization system for the sake of consistency. >We have found several situations where "authentication by assertion,: i.e. >asking for authorization information and not having to formally >authenticate the user ID, is a useful operation. Usually it depends on who >is asking the question but not always. > >I assert that "authentication by assertion" is a valid means of >authentication for certain classes of service or for certain queries. That's ok as long as one understands that the authorization restrictions on disclosure of the authorization data in this case depend solely on the good will of those making the assertions. In other words, any hacker with access to the system can claim to be one of the good citizens and get any authorization data he wants. A related point is that authenticating the teller and hence authorizing the query based on where the query came from is reasonable in a world of fixed line terminals, but at the other extreme is very dangerous if the authorization server is connected to the public Internet. In that case, one probably wants to see a real authentication of some sort to establish that the entity claiming to be the teller's terminal really is the teller's terminal. --David David L. Black, EMC Corporation From owner-aaa-wg@merit.edu Tue Feb 9 09:12:21 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA03497 for ; Tue, 9 Feb 1999 09:12:20 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA22434 for aaa-wg-outgoing; Tue, 9 Feb 1999 09:09:33 -0500 (EST) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA22430 for ; Tue, 9 Feb 1999 09:09:28 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.115]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id GAA29831; Tue, 9 Feb 1999 06:06:01 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id JAA26338; Tue, 9 Feb 1999 09:08:23 -0500 (EST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-hme0.corpeast.baynetworks.com [132.245.135.82]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id JAA14328; Tue, 9 Feb 1999 09:08:22 -0500 for Received: from msquire ([132.245.134.207]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Tue, 9 Feb 1999 09:09:43 -0500 Message-Id: <3.0.32.19990209085855.007d7100@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 09 Feb 1999 08:58:57 -0500 To: Brian Lloyd From: Matt Squire Subject: Re: Authorization without Authentication? Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk > >>IMHO, authorization without either authentication or reference to a prior >>authentication is not something that serious amounts of time should >>be invested in supporting. An authorization system without authentication >>operates on the voluntary good will of its users -- if I tell it >>that I'm the Prime Minister, it has no way of questioning that statement >>or my ability to do things the Prime Minister is allowed to do. This >>is not a wise move when one would like to charge for the authorized >>actions. > >We have found several situations where "authentication by assertion,: i.e. >asking for authorization information and not having to formally >authenticate the user ID, is a useful operation. Usually it depends on who >is asking the question but not always. > >I assert that "authentication by assertion" is a valid means of >authentication for certain classes of service or for certain queries. > Authentication is performed in this case, only it is performed in conjunction with authorization and its based on the source of the query. This is certainly a useful scenario. The combined authentication/authorization could equally be based on some shared secret/hmac extension to the query. In general, aaa must be support simultaneous authentication and authorization, and must support simple (and less secure) methods such as simply looking at the source of a query. - Matt From owner-aaa-wg@merit.edu Tue Feb 9 09:22:03 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA03569 for ; Tue, 9 Feb 1999 09:22:03 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA22749 for aaa-wg-outgoing; Tue, 9 Feb 1999 09:21:53 -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 JAA22742 for ; Tue, 9 Feb 1999 09:21:48 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA03862; Tue, 9 Feb 1999 06:21:15 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.105.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA08959; Tue, 9 Feb 1999 06:21:12 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA00585; Tue, 9 Feb 1999 06:21:13 -0800 Date: Tue, 9 Feb 1999 06:21:21 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Applications using AAA To: Matt Squire Cc: Pat.Calhoun@eng.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3.0.32.19990208195643.00a1cb50@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 > At 02:17 PM 2/8/99 -0800, you wrote: > > > >>I may be sounding like a broken record: > >> > >>Current work on exchanging records for payments and settlements between IP > >>Tel carriers includes XML. In real time. So unless you don't want to drop > >>the 3rd A an (AAA), we need to figure this out. Aim the flame throwers... > >> > >>Sorry for the scratching sound... > > > >And my tune will also sound similar. > > > >At this point, if XML is necessary (as you describe) it is how it is > presented > >to the user. This, I believe, does not need to be generated directly from > the >embedded system, be it a NAS or router. If we are stating that > inter-domain >accounting records MUST be in an XML format, then it means > that the accounting > >data generated by the router MAY be different from what a AAA server would > send > >to another provider. > > > >But as I also previously stated, XML parsing can add an additional 60% > overhead. > >If you are all comfortable with this, then I have no problems with it > >(especially not if it means you have to upgrade your AAA server hardware :) > > > >PatC > > > >> > >>Henry > > I'm personally not convinced that XML is required for client-server > accounting exchanges. Although it would certainly make things general, > there is the problem of overhead. However, the overhead of parsing is at > the AAA server, not the client. A client should not have to parse these > messages, it should just report data to a server. Some have argued that > the client may need acctng data to make decisions (and hence have to > parse). I disagree - the client can report acctng data to the server and > use the authorization part of AAA to make decisions at the server (the > policy decision point and policy enforcement point model). I think that you will find that most people agree with you, myself included. > I see no reason > why a client would have to parse. The overhead for generating an XML > message is not nearly as high as the overhead for parsing. Without > actually coding and measuring the performance, I'd guess xml generation > overhead to be of only of minor significance to client performance. Perhaps, but I was worried more about the server than the client since the number of clients per server will typically be quite high (as history shows). > > Server performance, on the other hand, may be effected by the parsing. But > this effect would only be felt in those cases where the acctng data is used > for real-time decisions. Offline tasks, such as bill generation, can > easily sustain the processing overhead, and would most likely benefit from > the most general format available. I am not necessarily taking a position on XML here, but I must disagree with your statement. The server will always have to parse the XML accounting data to ensure that it is valid. If there are any errors, they must be reported back to the sender. Imagine a service provider that determines that he has 30 days' worth of useless data... PatC From owner-aaa-wg@merit.edu Tue Feb 9 09:37:02 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA03698 for ; Tue, 9 Feb 1999 09:37:02 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA23106 for aaa-wg-outgoing; Tue, 9 Feb 1999 09:36:55 -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 JAA23102 for ; Tue, 9 Feb 1999 09:36:50 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA07311; Tue, 9 Feb 1999 06:35:46 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.55.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA07865; Tue, 9 Feb 1999 06:35:43 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03021; Tue, 9 Feb 1999 06:35:43 -0800 Date: Tue, 9 Feb 1999 06:35:51 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Authorization without Authentication? To: Matt Squire Cc: Brian Lloyd , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3.0.32.19990209085855.007d7100@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 > > > >>IMHO, authorization without either authentication or reference to a prior > >>authentication is not something that serious amounts of time should > >>be invested in supporting. An authorization system without authentication > >>operates on the voluntary good will of its users -- if I tell it > >>that I'm the Prime Minister, it has no way of questioning that statement > >>or my ability to do things the Prime Minister is allowed to do. This > >>is not a wise move when one would like to charge for the authorized > >>actions. > > > >We have found several situations where "authentication by assertion,: i.e. > >asking for authorization information and not having to formally > >authenticate the user ID, is a useful operation. Usually it depends on who > >is asking the question but not always. > > > >I assert that "authentication by assertion" is a valid means of > >authentication for certain classes of service or for certain queries. > > > > Authentication is performed in this case, only it is performed in > conjunction with authorization and its based on the source of the query. > This is certainly a useful scenario. The combined > authentication/authorization could equally be based on some shared > secret/hmac extension to the query. In general, aaa must be support > simultaneous authentication and authorization, and must support simple (and > less secure) methods such as simply looking at the source of a query. I beg to differ. AAA must require a secure transport. This could either mean that the underlying transport is secured through some means such as IPSec (or some other session layer security protocol that handles whatever aaa runs over), or security could be built into the protocol. I agree that for the most cases, the use of IPSec would be good. However, for some networks we should allow the use of long-lived secret keys. There is also the roaming situation that has different requirements due to the fact that it requires end-to-end security through proxies. Paul K. sent me an e-mail on the DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, which would allow key generation on top of the AAA protocol. My point here is security is important. A(n) AAA Server should not respond to unsecured queries. PatC > > - Matt > From owner-aaa-wg@merit.edu Tue Feb 9 14:04:45 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA06998 for ; Tue, 9 Feb 1999 14:04:45 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id OAA02923 for aaa-wg-outgoing; Tue, 9 Feb 1999 14:03:42 -0500 (EST) Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2] (may be forged)) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA02913 for ; Tue, 9 Feb 1999 14:03:34 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2232.9) id ; Tue, 9 Feb 1999 11:03:33 -0800 Message-ID: From: Andrew Smith To: "'pcalhoun@eng.sun.com'" Cc: aaa-wg@merit.edu Subject: RE: Authorization without Authentication? Date: Tue, 9 Feb 1999 11:03:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, I think you'll be seriously limiting the applicability of such a AAA protocol if you *require* it to run over what I think you mean by "a secure transport", particularly in private enterprise nets (there are many thousands of people quite blissfully happy managing their nets using plaintext SNMPv1). I'm not sure that there is any significant protocol impact to having the ability to run over unsecured TCP or UDP so I do not quite understand why you feel the protocol needs to preclude that option. Andrew P.S. Oops, sorry folks, we're back talking about transport protocols again. Must be that bottom-up design urge I suppose :-( > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] > Sent: Tuesday, February 09, 1999 6:36 AM > To: Matt Squire > Cc: Brian Lloyd; aaa-wg@merit.edu > Subject: Re: Authorization without Authentication? > > In general, aaa must be support > > simultaneous authentication and authorization, and must support simple (and > > less secure) methods such as simply looking at the source of a query. > > I beg to differ. AAA must require a secure transport. ... > My point here is security is important. A(n) AAA Server > should not respond to unsecured queries. > > PatC **************************************************************** Andrew Smith tel: +1 (408) 863-2821 Extreme Networks fax: +1 (408) 342-0990 10460 Bandley Drive http://www.extremenetworks.com Cupertino CA 95014 em: andrew@extremenetworks.com **************************************************************** From owner-aaa-wg@merit.edu Tue Feb 9 14:16:13 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA07137 for ; Tue, 9 Feb 1999 14:16:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA03552 for aaa-wg-outgoing; Tue, 9 Feb 1999 14:15:50 -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 OAA03531 for ; Tue, 9 Feb 1999 14:15:38 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA09154; Tue, 9 Feb 1999 11:14:35 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.61.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA00424; Tue, 9 Feb 1999 11:14:33 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24986; Tue, 9 Feb 1999 11:14:33 -0800 Date: Tue, 9 Feb 1999 11:14:41 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Authorization without Authentication? To: Andrew Smith Cc: "'pcalhoun@eng.sun.com'" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat, > > I think you'll be seriously limiting the applicability of such a AAA > protocol if you *require* it to run over what I think you mean by "a secure > transport", particularly in private enterprise nets (there are many > thousands of people quite blissfully happy managing their nets using > plaintext SNMPv1). I'm not sure that there is any significant protocol > impact to having the ability to run over unsecured TCP or UDP so I do not > quite understand why you feel the protocol needs to preclude that option. I hate to mention specific protocols here, but the DIAMETER Proxy draft allows this, and would support address translation, which I presume is what you are talking about). I agree with your statement that this must be supported. PatC > > Andrew > > P.S. Oops, sorry folks, we're back talking about transport protocols again. > Must be that bottom-up design urge I suppose :-( > > > > -----Original Message----- > > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] > > Sent: Tuesday, February 09, 1999 6:36 AM > > To: Matt Squire > > Cc: Brian Lloyd; aaa-wg@merit.edu > > Subject: Re: Authorization without Authentication? > > > > In general, aaa must be support > > > simultaneous authentication and authorization, and must support simple > (and > > > less secure) methods such as simply looking at the source of a query. > > > > I beg to differ. AAA must require a secure transport. > ... > > My point here is security is important. A(n) AAA Server > > should not respond to unsecured queries. > > > > PatC > > **************************************************************** > Andrew Smith tel: +1 (408) 863-2821 > Extreme Networks fax: +1 (408) 342-0990 > 10460 Bandley Drive http://www.extremenetworks.com > Cupertino CA 95014 em: andrew@extremenetworks.com > **************************************************************** > From owner-aaa-wg@merit.edu Tue Feb 9 14:16:56 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA07151 for ; Tue, 9 Feb 1999 14:16:55 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id OAA03604 for aaa-wg-outgoing; Tue, 9 Feb 1999 14:16:46 -0500 (EST) Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2] (may be forged)) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA03590 for ; Tue, 9 Feb 1999 14:16:38 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2232.9) id ; Tue, 9 Feb 1999 11:16:36 -0800 Message-ID: From: Andrew Smith To: "'pcalhoun@eng.sun.com'" Cc: aaa-wg@merit.edu Subject: RE: Authorization without Authentication? Date: Tue, 9 Feb 1999 11:16:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, OK, thanks - I misunderstood your original comments. Andrew > -----Original Message----- > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Tuesday, February 09, 1999 11:15 AM > To: Andrew Smith > Cc: 'pcalhoun@eng.sun.com'; aaa-wg@merit.edu > Subject: RE: Authorization without Authentication? > > > > Pat, > > > > I think you'll be seriously limiting the applicability of such a AAA > > protocol if you *require* it to run over what I think you > mean by "a secure > > transport", particularly in private enterprise nets (there are many > > thousands of people quite blissfully happy managing their nets using > > plaintext SNMPv1). I'm not sure that there is any > significant protocol > > impact to having the ability to run over unsecured TCP or > UDP so I do not > > quite understand why you feel the protocol needs to > preclude that option. > > I hate to mention specific protocols here, but the DIAMETER > Proxy draft allows > this, and would support address translation, which I presume > is what you are > talking about). I agree with your statement that this must be > supported. > > PatC > > > > > Andrew > > > > P.S. Oops, sorry folks, we're back talking about transport > protocols again. > > Must be that bottom-up design urge I suppose :-( > > > > > > > -----Original Message----- > > > From: pcalhoun@eng.sun.com [mailto:Pat.Calhoun@eng.sun.com] > > > Sent: Tuesday, February 09, 1999 6:36 AM > > > To: Matt Squire > > > Cc: Brian Lloyd; aaa-wg@merit.edu > > > Subject: Re: Authorization without Authentication? > > > > > > In general, aaa must be support > > > > simultaneous authentication and authorization, and must > support simple > > (and > > > > less secure) methods such as simply looking at the > source of a query. > > > > > > I beg to differ. AAA must require a secure transport. > > ... > > > My point here is security is important. A(n) AAA Server > > > should not respond to unsecured queries. > > > > > > PatC > > > > **************************************************************** > > Andrew Smith tel: +1 (408) 863-2821 > > Extreme Networks fax: +1 (408) 342-0990 > > 10460 Bandley Drive http://www.extremenetworks.com > > Cupertino CA 95014 em: andrew@extremenetworks.com > > **************************************************************** > > > > From owner-aaa-wg@merit.edu Tue Feb 9 15:20:33 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA08259 for ; Tue, 9 Feb 1999 15:20:32 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id PAA04997 for aaa-wg-outgoing; Tue, 9 Feb 1999 15:19:42 -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 PAA04993 for ; Tue, 9 Feb 1999 15:19:36 -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 MAA28181; Tue, 9 Feb 1999 12:15:52 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id MAA02158; Tue, 9 Feb 1999 12:16:14 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-hme0.corpeast.baynetworks.com [132.245.135.82]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id PAA23659; Tue, 9 Feb 1999 15:16:13 -0500 for Received: from msquire ([132.245.134.149]) by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Tue, 9 Feb 1999 15:17:36 -0500 Message-Id: <3.0.32.19990209150652.00a1ba50@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 09 Feb 1999 15:06:55 -0500 To: "pcalhoun@eng.sun.com" From: Matt Squire Subject: Re: Authorization without Authentication? Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk >> > >> >> Authentication is performed in this case, only it is performed in >> conjunction with authorization and its based on the source of the query. >> This is certainly a useful scenario. The combined >> authentication/authorization could equally be based on some shared >> secret/hmac extension to the query. In general, aaa must be support >> simultaneous authentication and authorization, and must support simple (and >> less secure) methods such as simply looking at the source of a query. > >I beg to differ. AAA must require a secure transport. This could either mean >that the underlying transport is secured through some means such as IPSec (or >some other session layer security protocol that handles whatever aaa runs >over), or security could be built into the protocol. > >I agree that for the most cases, the use of IPSec would be good. However, for >some networks we should allow the use of long-lived secret keys. There is also >the roaming situation that has different requirements due to the fact that it >requires end-to-end security through proxies. Paul K. sent me an e-mail on the >DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, >which would allow key generation on top of the AAA protocol. > >My point here is security is important. A(n) AAA Server should not respond to >unsecured queries. > >PatC >> I think we might be in violent agreement, but maybe not. Security is important. Security can be provided by a means outside of the particular contents of an AAA message. For example, if I physically secure LAN/wire, that might be sufficient to provide authentication of a source. I might choose to use RADIUS to perform authentication, and then use the AAA protocol to perform authorization for various actions. The protocol must support various levels of security depending on the deployed environment, and to permit certain aspects of security to be provided by a means outside of the protocol itself. So the protcol might require authentication before authorization, but shouldn't require the that authentication be provided by the AAA protocol. I don't think that I should be required to use the AAA protocol for everything all the time. That would present a difficult roll-out scenario when many protocols are already in use for overlapping functions. - Matt From owner-aaa-wg@merit.edu Tue Feb 9 15:23:16 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA08328 for ; Tue, 9 Feb 1999 15:23:15 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id PAA05097 for aaa-wg-outgoing; Tue, 9 Feb 1999 15:23:05 -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 PAA05091 for ; Tue, 9 Feb 1999 15:22:59 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7JM43A17C8Y5A4X@shoe.reston.mci.net> for aaa-wg@merit.edu; Tue, 9 Feb 1999 15:22:27 EST Date: Tue, 09 Feb 1999 12:22:25 -0800 From: Paul Krumviede Subject: Re: Applications using AAA To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C09901.54D3193A@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: > I am not necessarily taking a position on XML here, but I must disagree with > your statement. The server will always have to parse the XML accounting data > to ensure that it is valid. If there are any errors, they must be reported > back to the sender. Imagine a service provider that determines that he has > 30 days' worth of useless data... So what can a server do if it is getting invalid data from a third party, such as in a roaming situation? To the extent that a "server" may not be monolithic, the components handling resource usage data (since "accounting data" seems to be overloaded here, lets see if I can avoid it) functionally only need to parse the data that would effect their operation. They may not see all the "accounting data" in some possible designs. -paul From owner-aaa-wg@merit.edu Tue Feb 9 15:30:40 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id PAA08450 for ; Tue, 9 Feb 1999 15:30:40 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id PAA05237 for aaa-wg-outgoing; Tue, 9 Feb 1999 15:30:30 -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 PAA05233 for ; Tue, 9 Feb 1999 15:30:25 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7JMDALGP88Y5A4Y@shoe.reston.mci.net> for aaa-wg@merit.edu; Tue, 9 Feb 1999 15:29:53 EST Date: Tue, 09 Feb 1999 12:29:50 -0800 From: Paul Krumviede Subject: Re: Authorization without Authentication? To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C09ABE.EEB7F5BD@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: > I beg to differ. AAA must require a secure transport. This could either mean > that the underlying transport is secured through some means such as IPSec (or > some other session layer security protocol that handles whatever aaa runs > over), or security could be built into the protocol. I think we already agreed that the phrase "must require a secure transport" is misleading. Also, for some values of "security" some functions probably need to be in the protocol. For example, IPsec could be used to authenticate components (AAA clients and servers), while for some services authorization data carried transitively may need to be itself authenticated (perhaps recursively). > I agree that for the most cases, the use of IPSec would be good. However, for > some networks we should allow the use of long-lived secret keys. There is also > the roaming situation that has different requirements due to the fact that it > requires end-to-end security through proxies. Paul K. sent me an e-mail on the > DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, > which would allow key generation on top of the AAA protocol. I don't think IPsec precludes use of "long-lived secret keys." But use of them can be a severe configuration problem. And the notion of an IPsec DOI for AAA would not run "on top of" an AAA protocol; IKE, with such a DOI, would run semi-independently, and the AAA protocol(s) in question would then use the sessions. > My point here is security is important. A(n) AAA Server should not respond to > unsecured queries. I think this is a policy question for the operator. -paul From owner-aaa-wg@merit.edu Tue Feb 9 17:56: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 RAA10795 for ; Tue, 9 Feb 1999 17:56:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA10693 for aaa-wg-outgoing; Tue, 9 Feb 1999 17:55:24 -0500 (EST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA10680; Tue, 9 Feb 1999 17:55:11 -0500 (EST) Received: from zrtpd00m.us.nortel.com (actually zrtpd00m) by smtprich.nortel.com; Tue, 9 Feb 1999 16:54:46 -0600 Received: from zrtpd00n.us.nortel.com by zrtpd00m.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id 1RKB5DND; Tue, 9 Feb 1999 17:54:45 -0500 Received: from brtpmd90.us.nortel.com by zrtpd00n.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id 1SKB4HXN; Tue, 9 Feb 1999 17:54:39 -0500 Message-ID: <36C0BC15.2783EDAE@americasm01.nt.com> Date: Tue, 09 Feb 1999 17:52:05 -0500 From: "Richard Hornaday" Organization: Nortel X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: skh@merit.edu CC: aaa-wg@merit.edu Subject: comments on AAA proposed charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I have a couple of comments regarding the straw-person charter; one on document sequence, and another clarifying intent of one of the documents. My focus in on accounting, so my comments apply primarily to the 'third A", but there might be some application to the other two A's. I envision a general accounting framework where many data sources exist within a network that will generate accounting information, and these generating elements will exchange this information with an accounting server(s). These accounting servers will do aggregation/correlation/distribution on this data in support of applications (one of which is billing). Given this framework, I think the primary purpose of the accounting part of this working group should be to develop a common language in which accounting information can be described at network devices, and to develop a common transport mechanism for transferring this information between devices (e.g., between data sources and accounting servers). My hope is that we can focus the WG to first identify a structured mechanism for expressing the content of accounting information (e.g., data elements) in a vendor-independent manner. Vendors and WGs that desire accounting can then use these "data elements" to describe the data in the accounting records. Once we begin to have a handle on these "data elements", then we should work to define a protocol mechanism for exchanging the accounting information we have expressed via the "data elements". This is my view of the unstated intent of Document 5 (and partially, Document 6) In addition to clarifying the intent of Documents 5/6, the work sequence I am proposing seems to be contrary to the sequence of documents proposed in the charter. **Existing Sequence** Application ID {document 1} AAA requirements {document 2} Xport protocol {document 3} Base protocol {document 4} Data description {document 5} Data format {document 6} **Proposed Sequence** Application ID AAA requirements Data description Data format Base protocol Xport protocol Ata a minimum, it is possible that a great deal of the Data Description/Format work could be done in parallel with the protocol work. On an additional note, there is much work underway in this problem space (e.g., other IETF WGs, ETSI TIPHON, IMTC, ITU-T, ANSI T1). We might want our charter to indicate how the Working Group will interact with these other groups. At a minimum, we will want to work in a collaborative manner to avoid duplication of effort... Richard ****************************************************************** Richard Hornaday Nortel 35 Davis Drive hornaday@nortelnetworks.com PO Box 13478 (919) 991-7301 - voice Research Triangle Park, NC 27709-3478 919-991-7057 - fax From owner-aaa-wg@merit.edu Tue Feb 9 18:05:25 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA10891 for ; Tue, 9 Feb 1999 18:05:25 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA10998 for aaa-wg-outgoing; Tue, 9 Feb 1999 18:05:10 -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 SAA10988 for ; Tue, 9 Feb 1999 18:05:01 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA26888; Tue, 9 Feb 1999 15:04:28 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.93.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA21998; Tue, 9 Feb 1999 15:04:28 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA08012; Tue, 9 Feb 1999 15:04:27 -0800 Date: Tue, 9 Feb 1999 15:04:35 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Applications using AAA To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C09901.54D3193A@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > I am not necessarily taking a position on XML here, but I must disagree with > > your statement. The server will always have to parse the XML accounting data > > to ensure that it is valid. If there are any errors, they must be reported > > back to the sender. Imagine a service provider that determines that he has > > 30 days' worth of useless data... > > So what can a server do if it is getting invalid data from a third party, > such as in a roaming situation? Send a notification back so the user's session is terminated. > > To the extent that a "server" may not be monolithic, the components > handling resource usage data (since "accounting data" seems to be > overloaded here, lets see if I can avoid it) functionally only need > to parse the data that would effect their operation. They may not > see all the "accounting data" in some possible designs. > > -paul From owner-aaa-wg@merit.edu Tue Feb 9 18:18:06 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA10981 for ; Tue, 9 Feb 1999 18:18:06 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA11354 for aaa-wg-outgoing; Tue, 9 Feb 1999 18:17:54 -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 SAA11346 for ; Tue, 9 Feb 1999 18:17:49 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7JS7RQAXS8Y5A5A@shoe.reston.mci.net> for aaa-wg@merit.edu; Tue, 9 Feb 1999 18:17:14 EST Date: Tue, 09 Feb 1999 15:17:12 -0800 From: Paul Krumviede Subject: Re: Applications using AAA To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C0C1F8.64FDA30B@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: > > > "pcalhoun@eng.sun.com" wrote: > > > > > I am not necessarily taking a position on XML here, but I must disagree with > > > your statement. The server will always have to parse the XML accounting data > > > to ensure that it is valid. If there are any errors, they must be reported > > > back to the sender. Imagine a service provider that determines that he has > > > 30 days' worth of useless data... > > > > So what can a server do if it is getting invalid data from a third party, > > such as in a roaming situation? > > Send a notification back so the user's session is terminated. If such an operator is sending me bogus messages, what makes you think they'd actually terminate the session? If I was trying to be rude, I'd just send a bunch of slightly bogus messages, hoping that I'd get some with enough parameters right to get you to attempt to terminate the sessions. If I have much luck, I kill off a bunch of users. A well protected session will help prevent such an attack seeming to come from your "peer" but if your peer is a proxy (in the roaming remote access case) you can't be sure how well that party protects itself from being used as a conduit. -paul From owner-aaa-wg@merit.edu Wed Feb 10 00:14:32 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id AAA14854 for ; Wed, 10 Feb 1999 00:14:32 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id AAA17488 for aaa-wg-outgoing; Wed, 10 Feb 1999 00:14:07 -0500 (EST) Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49]) by merit.edu (8.9.1a/8.9.1) with ESMTP id AAA17484 for ; Wed, 10 Feb 1999 00:14:03 -0500 (EST) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by omzrelay.mcit.com (8.8.7/) with ESMTP id EAA01712; Wed, 10 Feb 1999 04:12:57 GMT Received: from sinnreich2 ([166.44.130.195]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <19990210051328.BQOH6156@sinnreich2>; Tue, 9 Feb 1999 23:13:28 -0600 From: "Henry Sinnreich" To: "Aydin Edguer" , Subject: RE: Applications using AAA Date: Tue, 9 Feb 1999 23:12:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <199902082235.RAA22485@harlequin.MorningStar.Com> Sender: owner-aaa-bof@merit.edu Precedence: bulk > Who is doing the "current work"? Is it a standards body or a proprietary > organization (Bellcore, Nortel)? If it is a standards body, which group > (ANSI, IETF)? Where is the documentation on their requirements, and usage > justifications? http://ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-02.txt Henry > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Aydin Edguer > Sent: Monday, February 08, 1999 5:35 PM > To: aaa-wg@merit.edu > Subject: Re: Applications using AAA > > > > Current work on exchanging records for payments and settlements > between IP > > Tel carriers includes XML. In real time. So unless you don't > want to drop > > the 3rd A an (AAA), we need to figure this out. Aim the flame > throwers... > > Who is doing the "current work"? Is it a standards body or a proprietary > organization (Bellcore, Nortel)? If it is a standards body, which group > (ANSI, IETF)? Where is the documentation on their requirements, and usage > justifications? > > No one has said "no" to anything yet and I have seen nothing that would > preclude sending XML, Morse Code, or psychic messages for > Accounting purposes. > If you have a requirement and you think it is relevant to the > Working Group > then either write up a draft document describing the work or give > us pointers > to the necessary information. > From owner-aaa-wg@merit.edu Wed Feb 10 05:07:49 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id FAA17434 for ; Wed, 10 Feb 1999 05:07:49 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id FAA21090 for aaa-wg-outgoing; Wed, 10 Feb 1999 05:07:31 -0500 (EST) Received: from fw-es06.hac.com (fw-es06.HAC.COM [128.152.1.6]) by merit.edu (8.9.1a/8.9.1) with ESMTP id FAA21086 for ; Wed, 10 Feb 1999 05:07:27 -0500 (EST) From: stseng@mail.hac.com Received: from pmdf1.es.hac.com ([147.17.103.50]) by fw-es06.hac.com (8.8.4/8.8.4) with ESMTP id CAA06523 for ; Wed, 10 Feb 1999 02:06:54 -0800 (PST) Received: from mime.mail.hac.com by mail.hac.com (PMDF V5.1-12 #26580) id <0F6X00F01NYVEY@mail.hac.com> for aaa-wg@merit.edu; Wed, 10 Feb 1999 02:04:08 -0800 (PST) Date: Wed, 10 Feb 1999 01:19 -0800 (PST) Subject: Applications using AAA - IP Multicast To: aaa-wg@merit.edu Message-id: <0F6X00F0BNYWEY@mail.hac.com> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_M0uZxxEDSMRDrT7ZXkSlTA)" Sender: owner-aaa-bof@merit.edu Precedence: bulk --Boundary_(ID_M0uZxxEDSMRDrT7ZXkSlTA) Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-transfer-encoding: 7BIT > > What other applications, in use today, can we use and add to this list which > can serve as the basis for gathering/refining the requirements? > > Basavaraj Patil > Nortel Networks Would IP Multicast applications be able to use AAA mechanisms? Shirley Tseng --Boundary_(ID_M0uZxxEDSMRDrT7ZXkSlTA) Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-transfer-encoding: 7BIT RFC-822-headers: Received: from CONVERSION-DAEMON by mail.hac.com (PMDF V5.1-12 #D3246) id <0F6P00001EOF52@mail.hac.com>; Fri, 5 Feb 1999 15:03:35 -0800 (PST) Received: from PROCESS-DAEMON by mail.hac.com (PMDF V5.1-12 #D3246) id <0F6P00001EN917@mail.hac.com>; Fri, 05 Feb 1999 15:02:16 -0800 (PST) Received: from fw-es05.hac.com by mail.hac.com (PMDF V5.1-12 #D3246) with ESMTP id <0F6P00N1QEMO5A@mail.hac.com>; Fri, 05 Feb 1999 15:01:36 -0800 (PST) Received: from merit.edu ([198.108.1.42]) by fw-es05.hac.com (8.9.0/8.9.0) with ESMTP id OAA02115; Fri, 05 Feb 1999 14:59:13 -0800 (PST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA20530 for aaa-wg-outgoing; Fri, 05 Feb 1999 17:51:29 -0500 (EST) Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA20525 for ; Fri, 05 Feb 1999 17:51:24 -0500 (EST) Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca; Fri, 05 Feb 1999 17:43:36 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id <1HKYKBPR>; Fri, 05 Feb 1999 15:49:35 -0500 Date: Fri, 05 Feb 1999 15:49:30 -0500 From: Basavaraj Patil Subject: Applications using AAA Sender: owner-aaa-bof@merit.edu Message-id: <31B1EFDD2CD3D11187710000F805A8D5022D5E7A@crchy270.us.nortel.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-transfer-encoding: 7BIT Precedence: bulk --Boundary_(ID_M0uZxxEDSMRDrT7ZXkSlTA)-- From owner-aaa-wg@merit.edu Wed Feb 10 09:30:26 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA19629 for ; Wed, 10 Feb 1999 09:30:26 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA24538 for aaa-wg-outgoing; Wed, 10 Feb 1999 09:27:48 -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 JAA24532 for ; Wed, 10 Feb 1999 09:27:43 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA18818; Wed, 10 Feb 1999 06:27:11 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.61.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA12327; Wed, 10 Feb 1999 06:27:10 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05278; Wed, 10 Feb 1999 06:27:09 -0800 Date: Wed, 10 Feb 1999 06:27:17 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Authorization without Authentication? To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C09ABE.EEB7F5BD@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > I beg to differ. AAA must require a secure transport. This could either mean > > that the underlying transport is secured through some means such as IPSec (or > > some other session layer security protocol that handles whatever aaa runs > > over), or security could be built into the protocol. > > I think we already agreed that the phrase "must require a secure > transport" is misleading. Also, for some values of "security" some > functions probably need to be in the protocol. For example, IPsec > could be used to authenticate components (AAA clients and servers), > while for some services authorization data carried transitively > may need to be itself authenticated (perhaps recursively). > > > I agree that for the most cases, the use of IPSec would be good. However, for > > some networks we should allow the use of long-lived secret keys. There is also > > the roaming situation that has different requirements due to the fact that it > > requires end-to-end security through proxies. Paul K. sent me an e-mail on the > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, > > which would allow key generation on top of the AAA protocol. > > I don't think IPsec precludes use of "long-lived secret keys." But use of > them can be a severe configuration problem. And the notion of an IPsec > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such > a DOI, would run semi-independently, and the AAA protocol(s) in > question would then use the sessions. Hmmm.... ok. However this would cause problems with the brokers that must sit in between both endpoints. The broker provides settlement services, and must be active in the transaction. > > > My point here is security is important. A(n) AAA Server should not respond to > > unsecured queries. > > I think this is a policy question for the operator. Well one of the nice things about IPSec is the application has NO idea whether a policy exists that requires its messages to be secured. So if one doesn't have such a policy, AAA is unsecured. Personally, I would prefer to state that AAA can run with IPSec, which someone can simply ignore. > > -paul From owner-aaa-wg@merit.edu Wed Feb 10 09:33:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA19675 for ; Wed, 10 Feb 1999 09:33:42 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA24655 for aaa-wg-outgoing; Wed, 10 Feb 1999 09:33:36 -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 JAA24651 for ; Wed, 10 Feb 1999 09:33:31 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA20283; Wed, 10 Feb 1999 06:32:55 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.91.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA05907; Wed, 10 Feb 1999 06:32:52 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06319; Wed, 10 Feb 1999 06:32:54 -0800 Date: Wed, 10 Feb 1999 06:33:01 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Applications using AAA To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C0C1F8.64FDA30B@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > > I am not necessarily taking a position on XML here, but I must disagree with > > > > your statement. The server will always have to parse the XML accounting data > > > > to ensure that it is valid. If there are any errors, they must be reported > > > > back to the sender. Imagine a service provider that determines that he has > > > > 30 days' worth of useless data... > > > > > > So what can a server do if it is getting invalid data from a third party, > > > such as in a roaming situation? > > > > Send a notification back so the user's session is terminated. > > If such an operator is sending me bogus messages, what makes you think > they'd actually terminate the session? If I was trying to be rude, > I'd just send a bunch of slightly bogus messages, hoping that I'd > get some with enough parameters right to get you to attempt to > terminate the sessions. If I have much luck, I kill off a bunch > of users. Sure they don't have to terminate it, but you have record that you did not accept the accounting record (hence you requested that the session be terminated). At this point, as a service provider, you can decline to pay for the service that was provided to the user. > > A well protected session will help prevent such an attack seeming > to come from your "peer" but if your peer is a proxy (in the > roaming remote access case) you can't be sure how well that > party protects itself from being used as a conduit. I was not talking about any malicious attacks here, I was simply assuming that a valid peer sends you accounting information you do not like. PatC From owner-aaa-wg@merit.edu Wed Feb 10 09:39:53 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA19723 for ; Wed, 10 Feb 1999 09:39:53 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA24763 for aaa-wg-outgoing; Wed, 10 Feb 1999 09:39:41 -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 JAA24759 for ; Wed, 10 Feb 1999 09:39:37 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA21551; Wed, 10 Feb 1999 06:38:35 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.105.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA15219; Wed, 10 Feb 1999 06:38:34 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA07562; Wed, 10 Feb 1999 06:38:34 -0800 Date: Wed, 10 Feb 1999 06:38:41 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Applications using AAA - IP Multicast To: stseng@mail.hac.com Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <0F6X00F0BNYWEY@mail.hac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > > What other applications, in use today, can we use and add to this > list which > can serve as the basis for gathering/refining the > requirements? > > > > Basavaraj Patil > > Nortel Networks > > > > Would IP Multicast applications be able to use AAA mechanisms? Yes I believe so. A user may request to join a multicast group, but the user may have to be authenticated and authorized. Further, keeping accounting records for the multicast services could certainly be useful. Unfortunately, given the nature of multicast, it may become "difficult" to implement, since it is not possible to send the request back to the multicast root. I suppose this means that for cross-domain multicast, this provides little benefit, but can certainly be used to ensure that only the appropriate users within a domain get access to certain streams. PatC > > Shirley Tseng > > > > From owner-aaa-wg@merit.edu Wed Feb 10 11:19:50 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21214 for ; Wed, 10 Feb 1999 11:19:50 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA27650 for aaa-wg-outgoing; Wed, 10 Feb 1999 11:19:26 -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 LAA27642 for ; Wed, 10 Feb 1999 11:19:21 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7KRVENKFY8ZG7F9@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 10 Feb 1999 11:18:50 EST Date: Wed, 10 Feb 1999 08:18:47 -0800 From: Paul Krumviede Subject: Re: Authorization without Authentication? To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C1B167.87F383C9@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: > > > "pcalhoun@eng.sun.com" wrote: > > > I agree that for the most cases, the use of IPSec would be good. However, for > > > some networks we should allow the use of long-lived secret keys. There is also > > > the roaming situation that has different requirements due to the fact that it > > > requires end-to-end security through proxies. Paul K. sent me an e-mail on the > > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, > > > which would allow key generation on top of the AAA protocol. > > > > I don't think IPsec precludes use of "long-lived secret keys." But use of > > them can be a severe configuration problem. And the notion of an IPsec > > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such > > a DOI, would run semi-independently, and the AAA protocol(s) in > > question would then use the sessions. > Hmmm.... ok. However this would cause problems with the brokers that must sit > in between both endpoints. The broker provides settlement services, and must > be active in the transaction. My model is more one of "use IKE to protect the channel between 2 communicating parties" so I don't see the problem. A broker, if it is actively participating, is one such party. So communications like the with a path like A->broker->X would have 2 segments where keying material is generated (and where the parties may be authenticated to each other). But there would be no IKE setup directly between A and X. > > > My point here is security is important. A(n) AAA Server should not respond to > > > unsecured queries. > > > > I think this is a policy question for the operator. > > Well one of the nice things about IPSec is the application has NO idea whether > a policy exists that requires its messages to be secured. So if one doesn't > have such a policy, AAA is unsecured. Personally, I would prefer to state that > AAA can run with IPSec, which someone can simply ignore. This may only be true for IPsec implemented on gateways. I think that many who expect and want IPsec on end systems are also interested in APIs that will allow applications to query, and possibly modify, the policy database. And my point was that the choice should be left to the operator (not the application), and the operator will have to configure policy in the IPsec case no matter what. -paul From owner-aaa-wg@merit.edu Wed Feb 10 11:21:32 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21227 for ; Wed, 10 Feb 1999 11:21:31 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA27690 for aaa-wg-outgoing; Wed, 10 Feb 1999 11:21:21 -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 LAA27684 for ; Wed, 10 Feb 1999 11:21:16 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7KRXSV5S08ZG7FU@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 10 Feb 1999 11:20:45 EST Date: Wed, 10 Feb 1999 08:20:43 -0800 From: Paul Krumviede Subject: Re: Applications using AAA To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C1B1DB.950A8D2B@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: > > > "pcalhoun@eng.sun.com" wrote: > > > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > > > > I am not necessarily taking a position on XML here, but I must disagree with > > > > > your statement. The server will always have to parse the XML accounting data > > > > > to ensure that it is valid. If there are any errors, they must be reported > > > > > back to the sender. Imagine a service provider that determines that he has > > > > > 30 days' worth of useless data... > > > > > > > > So what can a server do if it is getting invalid data from a third party, > > > > such as in a roaming situation? > > > > > > Send a notification back so the user's session is terminated. > > > > If such an operator is sending me bogus messages, what makes you think > > they'd actually terminate the session? If I was trying to be rude, > > I'd just send a bunch of slightly bogus messages, hoping that I'd > > get some with enough parameters right to get you to attempt to > > terminate the sessions. If I have much luck, I kill off a bunch > > of users. > > Sure they don't have to terminate it, but you have record that you did not > accept the accounting record (hence you requested that the session be > terminated). At this point, as a service provider, you can decline to pay for > the service that was provided to the user. OK, so now I have an attack that gives me free service. > > > > A well protected session will help prevent such an attack seeming > > to come from your "peer" but if your peer is a proxy (in the > > roaming remote access case) you can't be sure how well that > > party protects itself from being used as a conduit. > > I was not talking about any malicious attacks here, I was simply assuming that > a valid peer sends you accounting information you do not like. But at the level of parsing data, I suspect they are indistinguishable. -paul From owner-aaa-wg@merit.edu Wed Feb 10 11:52:24 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21517 for ; Wed, 10 Feb 1999 11:52:24 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id LAA28506 for aaa-wg-outgoing; Wed, 10 Feb 1999 11:52:09 -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 LAA28488 for ; Wed, 10 Feb 1999 11:52:00 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA02681; Wed, 10 Feb 1999 08:51:27 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.123.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA01030; Wed, 10 Feb 1999 08:51:25 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA05277; Wed, 10 Feb 1999 08:51:20 -0800 Date: Wed, 10 Feb 1999 08:51:27 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Applications using AAA To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C1B1DB.950A8D2B@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > > > > > > I am not necessarily taking a position on XML here, but I must disagree with > > > > > > your statement. The server will always have to parse the XML accounting data > > > > > > to ensure that it is valid. If there are any errors, they must be reported > > > > > > back to the sender. Imagine a service provider that determines that he has > > > > > > 30 days' worth of useless data... > > > > > > > > > > So what can a server do if it is getting invalid data from a third party, > > > > > such as in a roaming situation? > > > > > > > > Send a notification back so the user's session is terminated. > > > > > > If such an operator is sending me bogus messages, what makes you think > > > they'd actually terminate the session? If I was trying to be rude, > > > I'd just send a bunch of slightly bogus messages, hoping that I'd > > > get some with enough parameters right to get you to attempt to > > > terminate the sessions. If I have much luck, I kill off a bunch > > > of users. > > > > Sure they don't have to terminate it, but you have record that you did not > > accept the accounting record (hence you requested that the session be > > terminated). At this point, as a service provider, you can decline to pay for > > the service that was provided to the user. > > OK, so now I have an attack that gives me free service. If you can mount such an attack, you would get many different benefits. It is not clear to me how we can create a protocol that still works if the keys are compromised. PatC > > > > > > > A well protected session will help prevent such an attack seeming > > > to come from your "peer" but if your peer is a proxy (in the > > > roaming remote access case) you can't be sure how well that > > > party protects itself from being used as a conduit. > > > > I was not talking about any malicious attacks here, I was simply assuming that > > a valid peer sends you accounting information you do not like. > > But at the level of parsing data, I suspect they are indistinguishable. > > -paul From owner-aaa-wg@merit.edu Wed Feb 10 11:55:18 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21549 for ; Wed, 10 Feb 1999 11:55:17 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA28587 for aaa-wg-outgoing; Wed, 10 Feb 1999 11:55:09 -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 LAA28583 for ; Wed, 10 Feb 1999 11:55:04 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA03657; Wed, 10 Feb 1999 08:54:32 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.123.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA01388; Wed, 10 Feb 1999 08:54:31 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA05831; Wed, 10 Feb 1999 08:54:31 -0800 Date: Wed, 10 Feb 1999 08:54:38 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Authorization without Authentication? To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C1B167.87F383C9@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > I agree that for the most cases, the use of IPSec would be good. However, for > > > > some networks we should allow the use of long-lived secret keys. There is also > > > > the roaming situation that has different requirements due to the fact that it > > > > requires end-to-end security through proxies. Paul K. sent me an e-mail on the > > > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, > > > > which would allow key generation on top of the AAA protocol. > > > > > > I don't think IPsec precludes use of "long-lived secret keys." But use of > > > them can be a severe configuration problem. And the notion of an IPsec > > > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such > > > a DOI, would run semi-independently, and the AAA protocol(s) in > > > question would then use the sessions. > > Hmmm.... ok. However this would cause problems with the brokers that must sit > > in between both endpoints. The broker provides settlement services, and must > > be active in the transaction. > > My model is more one of "use IKE to protect the channel between 2 > communicating parties" so I don't see the problem. A broker, if it > is actively participating, is one such party. So communications like > the with a path like A->broker->X would have 2 segments where keying > material is generated (and where the parties may be authenticated > to each other). But there would be no IKE setup directly between > A and X. Then we have the same model that RADIUS has, which is one that ROAMOPS has already agreed is broken. We really need to have end-to-end authentication (A<->X), while communicating through the broker. > > > > > My point here is security is important. A(n) AAA Server should not respond to > > > > unsecured queries. > > > > > > I think this is a policy question for the operator. > > > > Well one of the nice things about IPSec is the application has NO idea whether > > a policy exists that requires its messages to be secured. So if one doesn't > > have such a policy, AAA is unsecured. Personally, I would prefer to state that > > AAA can run with IPSec, which someone can simply ignore. > > This may only be true for IPsec implemented on gateways. I think > that many who expect and want IPsec on end systems are also interested > in APIs that will allow applications to query, and possibly modify, > the policy database. And my point was that the choice should be left > to the operator (not the application), and the operator will have > to configure policy in the IPsec case no matter what. Ok. here we are in violent agreement. PatC > > -paul From owner-aaa-wg@merit.edu Wed Feb 10 12:18:07 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA21822 for ; Wed, 10 Feb 1999 12:18:07 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA29286 for aaa-wg-outgoing; Wed, 10 Feb 1999 12:17:59 -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 MAA29281 for ; Wed, 10 Feb 1999 12:17:52 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7KTWY4XVM8Y5A6S@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 10 Feb 1999 12:17:21 EST Date: Wed, 10 Feb 1999 09:17:18 -0800 From: Paul Krumviede Subject: Re: Authorization without Authentication? To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C1BF1E.F4657436@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: > > > "pcalhoun@eng.sun.com" wrote: > > > > I don't think IPsec precludes use of "long-lived secret keys." But use of > > > > them can be a severe configuration problem. And the notion of an IPsec > > > > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such > > > > a DOI, would run semi-independently, and the AAA protocol(s) in > > > > question would then use the sessions. > > > Hmmm.... ok. However this would cause problems with the brokers that must sit > > > in between both endpoints. The broker provides settlement services, and must > > > be active in the transaction. > > > > My model is more one of "use IKE to protect the channel between 2 > > communicating parties" so I don't see the problem. A broker, if it > > is actively participating, is one such party. So communications like > > the with a path like A->broker->X would have 2 segments where keying > > material is generated (and where the parties may be authenticated > > to each other). But there would be no IKE setup directly between > > A and X. > > Then we have the same model that RADIUS has, which is one that ROAMOPS has > already agreed is broken. We really need to have end-to-end authentication > (A<->X), while communicating through the broker. Please distinguish between necessary and sufficient conditions. Protecting the communications between 2 parties is necessary; you are arguing that it is not sufficient, and I've never disagreed. In the cases where one has chains of parties, I suspect that some form of encapsulation, perhaps recursive, of objects being carried may be a reasonable approach. Note that IKE sets up keying material between 2 parties, not n>2. And the authentication modes of IKE (and many other such protocols) don't scale well to large numbers of parties (communication complexities grow, and it isn't clear what to do if one of the parties fails authentication to some, but not all, others). -paul From owner-aaa-wg@merit.edu Wed Feb 10 12:40:19 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA22048 for ; Wed, 10 Feb 1999 12:40:19 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA29955 for aaa-wg-outgoing; Wed, 10 Feb 1999 12:39: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 SMTP id MAA29946 for ; Wed, 10 Feb 1999 12:39:17 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA20049; Wed, 10 Feb 1999 09:38:44 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.55.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA22502; Wed, 10 Feb 1999 09:38:42 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18039; Wed, 10 Feb 1999 09:38:42 -0800 Date: Wed, 10 Feb 1999 09:38:50 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Authorization without Authentication? To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C1BF1E.F4657436@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > > > "pcalhoun@eng.sun.com" wrote: > > > > > > I don't think IPsec precludes use of "long-lived secret keys." But use of > > > > > them can be a severe configuration problem. And the notion of an IPsec > > > > > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such > > > > > a DOI, would run semi-independently, and the AAA protocol(s) in > > > > > question would then use the sessions. > > > > Hmmm.... ok. However this would cause problems with the brokers that must sit > > > > in between both endpoints. The broker provides settlement services, and must > > > > be active in the transaction. > > > > > > My model is more one of "use IKE to protect the channel between 2 > > > communicating parties" so I don't see the problem. A broker, if it > > > is actively participating, is one such party. So communications like > > > the with a path like A->broker->X would have 2 segments where keying > > > material is generated (and where the parties may be authenticated > > > to each other). But there would be no IKE setup directly between > > > A and X. > > > > Then we have the same model that RADIUS has, which is one that ROAMOPS has > > already agreed is broken. We really need to have end-to-end authentication > > (A<->X), while communicating through the broker. > > Please distinguish between necessary and sufficient conditions. Protecting > the communications between 2 parties is necessary; you are arguing that it > is not sufficient, and I've never disagreed. In the cases where one > has chains of parties, I suspect that some form of encapsulation, > perhaps recursive, of objects being carried may be a reasonable > approach. Again we agree. > > Note that IKE sets up keying material between 2 parties, not n>2. And > the authentication modes of IKE (and many other such protocols) don't > scale well to large numbers of parties (communication complexities > grow, and it isn't clear what to do if one of the parties fails > authentication to some, but not all, others). You are correct that IKE is currently not setup for this. However, what I had in mind may (possibly) be different than what you are currently thinking. Here it is: X <--------> Broker <--------> A <--IKE SA--> <--IKE SA--> (these use AH/ESP in transport mode) <------------IKE SA------------> (this does not use AH/ESP) Note that IKE the second IKE (X-A) shown above would not be used in conjunction with AH or ESP. I would propose that we use the keys negotiated within the AAA base protocol's hashing and encryption functions. How IKE runs through the broker is a problem that has yet to be solved though. Was this what you were thinking as well? PatC > > -paul From owner-aaa-wg@merit.edu Wed Feb 10 13:02:45 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA22323 for ; Wed, 10 Feb 1999 13:02:45 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id NAA01087 for aaa-wg-outgoing; Wed, 10 Feb 1999 13:02:27 -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 NAA01072 for ; Wed, 10 Feb 1999 13:02:17 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7KVGZDLH08Y5A7E@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 10 Feb 1999 13:01:44 EST Date: Wed, 10 Feb 1999 10:01:42 -0800 From: Paul Krumviede Subject: Re: Authorization without Authentication? To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C1C986.43440CF6@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: > > Note that IKE sets up keying material between 2 parties, not n>2. And > > the authentication modes of IKE (and many other such protocols) don't > > scale well to large numbers of parties (communication complexities > > grow, and it isn't clear what to do if one of the parties fails > > authentication to some, but not all, others). > > You are correct that IKE is currently not setup for this. However, what I had > in mind may (possibly) be different than what you are currently thinking. Here > it is: > > X <--------> Broker <--------> A > <--IKE SA--> <--IKE SA--> (these use AH/ESP in transport mode) > <------------IKE SA------------> (this does not use AH/ESP) > > Note that IKE the second IKE (X-A) shown above would not be used in > conjunction with AH or ESP. I would propose that we use the keys negotiated > within the AAA base protocol's hashing and encryption functions. How IKE runs > through the broker is a problem that has yet to be solved though. > > Was this what you were thinking as well? Originally, sort of. But I sort of concluded that one of the reasons for a broker is to hide the details of who exists behind the broker and to reduce or eliminate the need for pair wise configuration and communications. So in the examples, how do A and X know they need to negotiate such an SA? If this has to happen in real time when a request is made, we may have added substantial latency and computational costs. For that matter, there may be scenarios where A and X can't communicate directly: in at least some discussions I've seen, the broker and X communicate over a private path, and X may not be directly reachable. There are also the policy and configuration issues: X may have a policy along the lines of "accept and respond to requests from my own infrastructure and from a list of brokers." So a request comes in from A; can X determine that A is a legitimate client of the broker? So while I'd like to be able to do as you suggest, I'm unconvinced it is possible in all scenarios. -paul From owner-aaa-wg@merit.edu Wed Feb 10 13:21:01 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA22480 for ; Wed, 10 Feb 1999 13:21:01 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id NAA01803 for aaa-wg-outgoing; Wed, 10 Feb 1999 13:20:47 -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 NAA01792 for ; Wed, 10 Feb 1999 13:20:39 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA05491; Wed, 10 Feb 1999 10:20:05 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.53.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA00747; Wed, 10 Feb 1999 10:20:03 -0800 Received: from mordor by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01681; Wed, 10 Feb 1999 10:20:04 -0800 Date: Wed, 10 Feb 1999 10:20:08 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: Authorization without Authentication? To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36C1C986.43440CF6@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > "pcalhoun@eng.sun.com" wrote: > > > > Note that IKE sets up keying material between 2 parties, not n>2. And > > > the authentication modes of IKE (and many other such protocols) don't > > > scale well to large numbers of parties (communication complexities > > > grow, and it isn't clear what to do if one of the parties fails > > > authentication to some, but not all, others). > > > > You are correct that IKE is currently not setup for this. However, what I had > > in mind may (possibly) be different than what you are currently thinking. Here > > it is: > > > > X <--------> Broker <--------> A > > <--IKE SA--> <--IKE SA--> (these use AH/ESP in transport mode) > > <------------IKE SA------------> (this does not use AH/ESP) > > > > Note that IKE the second IKE (X-A) shown above would not be used in > > conjunction with AH or ESP. I would propose that we use the keys negotiated > > within the AAA base protocol's hashing and encryption functions. How IKE runs > > through the broker is a problem that has yet to be solved though. > > > > Was this what you were thinking as well? > > Originally, sort of. But I sort of concluded that one of the reasons for > a broker is to hide the details of who exists behind the broker and to > reduce or eliminate the need for pair wise configuration and > communications. > So in the examples, how do A and X know they need to negotiate such an > SA? If this has to happen in real time when a request is made, we may > have added substantial latency and computational costs. For that matter, > there may be scenarios where A and X can't communicate directly: in at > least some discussions I've seen, the broker and X communicate over > a private path, and X may not be directly reachable. There are also > the policy and configuration issues: X may have a policy along the > lines of "accept and respond to requests from my own infrastructure > and from a list of brokers." So a request comes in from A; can X > determine that A is a legitimate client of the broker? > > So while I'd like to be able to do as you suggest, I'm unconvinced > it is possible in all scenarios. You are correct. However one would have to make the assumption that the broker acts as the CA (which some brokers already do). As part of the business, X would have to accept (or rather should) any requests from a peer that claims to belong to the roaming consortium (which would be known by A's certificate). As for latency, this would have to be setup for the first request, and the lifetime could be setup with a longer lifetime (especially true if the amount of data through the SA will be low). I agree as well that I am not sure that this would work in all cases. PatC > > -paul From owner-aaa-wg@merit.edu Wed Feb 10 17:35:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA28825 for ; Wed, 10 Feb 1999 17:35:42 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA08998 for aaa-wg-outgoing; Wed, 10 Feb 1999 17:35:23 -0500 (EST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA08992 for ; Wed, 10 Feb 1999 17:35:19 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprich.nortel.com; Wed, 10 Feb 1999 16:35:06 -0600 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id <1HHZ2C1Z>; Wed, 10 Feb 1999 17:35:08 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E96@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'paul@mci.net'" , aaa-wg@merit.edu Cc: "Emad Qaddoura" Subject: RE: Authorization without Authentication? Date: Wed, 10 Feb 1999 17:35:03 -0500 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 >> >> > "pcalhoun@eng.sun.com" wrote: > >> > > I agree that for the most cases, the use of IPSec would be good. However, for >> > > some networks we should allow the use of long-lived secret keys. There is also >> > > the roaming situation that has different requirements due to the fact that it >> > > requires end-to-end security through proxies. Paul K. sent me an e-mail on the >> > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER DOI, >> > > which would allow key generation on top of the AAA protocol. >> > >> > I don't think IPsec precludes use of "long-lived secret keys." But use of >> > them can be a severe configuration problem. And the notion of an IPsec >> > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such >> > a DOI, would run semi-independently, and the AAA protocol(s) in >> > question would then use the sessions. >> Hmmm.... ok. However this would cause problems with the brokers that must sit >> in between both endpoints. The broker provides settlement services, and must >> be active in the transaction. > >My model is more one of "use IKE to protect the channel between 2 >communicating parties" so I don't see the problem. A broker, if it >is actively participating, is one such party. So communications like >the with a path like A->broker->X would have 2 segments where keying >material is generated (and where the parties may be authenticated >to each other). But there would be no IKE setup directly between >A and X. The implication this has is that all AAA messaging would have to flow through these two secure segments (A<-->Broker<-->X) to be secure. Since the broker has the Security Associations with A and X why not have the broker distribute keys to A and X over these secure links that can be used for the session between A and X. > >> > > My point here is security is important. A(n) AAA Server should not respond to >> > > unsecured queries. >> > >> > I think this is a policy question for the operator. >> >> Well one of the nice things about IPSec is the application has NO idea whether >> a policy exists that requires its messages to be secured. So if one doesn't >> have such a policy, AAA is unsecured. Personally, I would prefer to state that >> AAA can run with IPSec, which someone can simply ignore. > >This may only be true for IPsec implemented on gateways. I think >that many who expect and want IPsec on end systems are also interested >in APIs that will allow applications to query, and possibly modify, >the policy database. And my point was that the choice should be left >to the operator (not the application), and the operator will have >to configure policy in the IPsec case no matter what. > >-paul But AAA is only in the network components such as gateways etc. (that was my impression). I think having AAA run on an IPsec based security layer makes good sense. -Basavaraj Patil From owner-aaa-wg@merit.edu Wed Feb 10 18:02:10 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA29103 for ; Wed, 10 Feb 1999 18:02:10 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA09612 for aaa-wg-outgoing; Wed, 10 Feb 1999 18:02:04 -0500 (EST) Received: from mailgate.nortel.ca (mailgate.NortelNetworks.com [192.58.194.74]) by merit.edu (8.9.1a/8.9.1) with ESMTP id SAA09604; Wed, 10 Feb 1999 18:01:58 -0500 (EST) Received: from zcard00m.ca.nortel.com by mailgate.nortel.ca; Wed, 10 Feb 1999 18:01:28 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id <14J5HN7C>; Wed, 10 Feb 1999 18:01:27 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5E98@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "Susan Hares (E-mail)" , "'aaa-wg@merit.edu'" Cc: "Fred Baker [fred@cisco.com] (E-mail)" Subject: AAA at IETF 44?? Date: Wed, 10 Feb 1999 18:01:26 -0500 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 Hi, I have not (yet) seen AAA on the agenda for IETF 44. Is there going to be a AAA BOF/WG meeting in Minneapolis? Basavaraj Patil From owner-aaa-wg@merit.edu Wed Feb 10 18:37:49 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA29341 for ; Wed, 10 Feb 1999 18:37:49 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA10216 for aaa-wg-outgoing; Wed, 10 Feb 1999 18:37: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 SMTP id SAA10212 for ; Wed, 10 Feb 1999 18:37:08 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA01032; Wed, 10 Feb 1999 15:36:35 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.123.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA09230; Wed, 10 Feb 1999 15:36:34 -0800 Received: from mordor.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07161; Wed, 10 Feb 1999 15:36:25 -0800 Date: Wed, 10 Feb 1999 15:36:33 -0800 (PST) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Authorization without Authentication? To: Basavaraj Patil Cc: "'paul@mci.net'" , aaa-wg@merit.edu, Emad Qaddoura In-Reply-To: "Your message with ID" <31B1EFDD2CD3D11187710000F805A8D5022D5E96@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 > >> > >> > "pcalhoun@eng.sun.com" wrote: > > > >> > > I agree that for the most cases, the use of IPSec would be good. > However, for > >> > > some networks we should allow the use of long-lived secret keys. > There is also > >> > > the roaming situation that has different requirements due to the fact > that it > >> > > requires end-to-end security through proxies. Paul K. sent me an > e-mail on the > >> > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER > DOI, > >> > > which would allow key generation on top of the AAA protocol. > >> > > >> > I don't think IPsec precludes use of "long-lived secret keys." But use > of > >> > them can be a severe configuration problem. And the notion of an IPsec > >> > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such > >> > a DOI, would run semi-independently, and the AAA protocol(s) in > >> > question would then use the sessions. > >> Hmmm.... ok. However this would cause problems with the brokers that must > sit > >> in between both endpoints. The broker provides settlement services, and > must > >> be active in the transaction. > > > > >My model is more one of "use IKE to protect the channel between 2 > >communicating parties" so I don't see the problem. A broker, if it > >is actively participating, is one such party. So communications like > >the with a path like A->broker->X would have 2 segments where keying > >material is generated (and where the parties may be authenticated > >to each other). But there would be no IKE setup directly between > >A and X. > > The implication this has is that all AAA messaging would have to flow > through these two secure segments (A<-->Broker<-->X) to be > secure. Since the broker has the Security Associations with A and X > why not have the broker distribute keys to A and X over these secure > links that can be used for the session between A and X. > > > > >> > > My point here is security is important. A(n) AAA Server should not > respond to > >> > > unsecured queries. > >> > > >> > I think this is a policy question for the operator. > >> > >> Well one of the nice things about IPSec is the application has NO idea > whether > >> a policy exists that requires its messages to be secured. So if one > doesn't > >> have such a policy, AAA is unsecured. Personally, I would prefer to state > that > >> AAA can run with IPSec, which someone can simply ignore. > > > >This may only be true for IPsec implemented on gateways. I think > >that many who expect and want IPsec on end systems are also interested > >in APIs that will allow applications to query, and possibly modify, > >the policy database. And my point was that the choice should be left > >to the operator (not the application), and the operator will have > >to configure policy in the IPsec case no matter what. > > > >-paul > > But AAA is only in the network components such as gateways etc. (that > was my impression). I think having AAA run on an IPsec based security > layer makes good sense. > A Broker can be viewed as an "application layer" router. Therefore, it needs to be able to receive, process and modify portions of the AAA message. While this is done, it is necessary to maintain end-to-end integrity (and possibly privacy). I would recommend that you take a look at RFC2194 and at draft-ietf-roamops-auth-09.txt for more information. PatC From owner-aaa-wg@merit.edu Wed Feb 10 20:00:55 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA29931 for ; Wed, 10 Feb 1999 20:00:54 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA11481 for aaa-wg-outgoing; Wed, 10 Feb 1999 20:00:34 -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 UAA11477 for ; Wed, 10 Feb 1999 20:00:29 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7LA3H7JZA8WW4VN@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 10 Feb 1999 19:59:57 EST Date: Wed, 10 Feb 1999 16:59:56 -0800 From: Paul Krumviede Subject: Re: Authorization without Authentication? To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C22B8C.2F8247FB@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: <31B1EFDD2CD3D11187710000F805A8D5022D5E96@crchy270.us.nortel.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Basavaraj Patil wrote: > >My model is more one of "use IKE to protect the channel between 2 > >communicating parties" so I don't see the problem. A broker, if it > >is actively participating, is one such party. So communications like > >the with a path like A->broker->X would have 2 segments where keying > >material is generated (and where the parties may be authenticated > >to each other). But there would be no IKE setup directly between > >A and X. > > The implication this has is that all AAA messaging would have to flow > through these two secure segments (A<-->Broker<-->X) to be > secure. Since the broker has the Security Associations with A and X > why not have the broker distribute keys to A and X over these secure > links that can be used for the session between A and X. People may not want to implement a key generation mechanism in the broker. A broker can't generate keys used for integrity or signing between other parties without posing some problems (who really signed this message or attribute? The broker or the purported signer?). It isn't clear how this extends to longer chains. -paul From owner-aaa-wg@merit.edu Thu Feb 11 08:08:33 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id IAA05076 for ; Thu, 11 Feb 1999 08:08:32 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id IAA19713 for aaa-wg-outgoing; Thu, 11 Feb 1999 08:06:20 -0500 (EST) Received: from idrp.merit.edu (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.9.1a/8.9.1) with ESMTP id IAA19709; Thu, 11 Feb 1999 08:05:50 -0500 (EST) Received: from localhost by idrp.merit.edu (8.9.1a/8.9.1) with SMTP id IAA07390; Thu, 11 Feb 1999 08:05:49 -0500 (EST) X-Authentication-Warning: idrp.merit.edu: skh owned process doing -bs Date: Thu, 11 Feb 1999 08:05:49 -0500 (EST) From: Susan Hares To: Basavaraj Patil cc: "'aaa-wg@merit.edu'" , "Fred Baker [fred@cisco.com] (E-mail)" Subject: Re: AAA at IETF 44?? In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5022D5E98@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 I believe we will have a meeting there. I will circulate a new charter by Monday morning. Sue On Wed, 10 Feb 1999, Basavaraj Patil wrote: > > Hi, > > I have not (yet) seen AAA on the agenda for IETF 44. Is there going to be a > AAA BOF/WG meeting in Minneapolis? > > Basavaraj Patil > > From owner-aaa-wg@merit.edu Thu Feb 11 10:24:55 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA06389 for ; Thu, 11 Feb 1999 10:24:55 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA22938 for aaa-wg-outgoing; Thu, 11 Feb 1999 10:24:21 -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 KAA22932 for ; Thu, 11 Feb 1999 10:24:15 -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 HAA27988; Thu, 11 Feb 1999 07:22:44 -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 HAA27767; Thu, 11 Feb 1999 07:23:06 -0800 (PST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-nf0.corpeast.baynetworks.com [192.32.72.23]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id KAA12890; Thu, 11 Feb 1999 10:24:31 -0500 for Received: from thardjon.engeast.baynetworks.com ([192.32.214.192]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Thu, 11 Feb 1999 10:24:28 -0500 Message-Id: <3.0.5.32.19990211101946.009f6100@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 11 Feb 1999 10:19:46 -0800 To: "pcalhoun@eng.sun.com" From: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) Subject: Re: Authorization without Authentication? Cc: aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <36C09ABE.EEB7F5BD@mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 06:27 AM 2/10/99 -0800, you wrote: >> "pcalhoun@eng.sun.com" wrote: > >Well one of the nice things about IPSec is the application has NO idea whether >a policy exists that requires its messages to be secured. So if one doesn't >have such a policy, AAA is unsecured. Personally, I would prefer to state that >AAA can run with IPSec, which someone can simply ignore. This is perhaps worth considering. Some discussion have emerged in the last (and previous to last) IETF/IPsec as to the effects of IPsec ESP (encryption) on traffic-shapers/QoS. In talking about authentication I think we should distinguish between "user-authentication" and "data-authentication". My understanding of the requirements of AAA is that user-authentication is the primary topic to be addressed first, since it is the foundation under authorization and later accounting/auditing. I don't think we should get bogged-down on data or traffic authentication at this stage. thomas ------ From owner-aaa-wg@merit.edu Thu Feb 11 10:33:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id KAA06543 for ; Thu, 11 Feb 1999 10:33:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id KAA23169 for aaa-wg-outgoing; Thu, 11 Feb 1999 10:33:30 -0500 (EST) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by merit.edu (8.9.1a/8.9.1) with ESMTP id KAA23159 for ; Thu, 11 Feb 1999 10:33:23 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.84]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id HAA08707 for ; Thu, 11 Feb 1999 07:29:12 -0800 (PST) Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA21244; Thu, 11 Feb 1999 10:29:19 -0500 (EST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-hme0.corpeast.baynetworks.com [132.245.135.83]) by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id KAA25833; Thu, 11 Feb 1999 10:31:18 -0500 for Received: from thardjon.engeast.baynetworks.com ([192.32.214.192]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com; Thu, 11 Feb 1999 10:32:41 -0500 Message-Id: <3.0.5.32.19990211102800.007ce8b0@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 11 Feb 1999 10:28:00 -0800 To: "Basavaraj Patil" From: Thomas_Hardjono@baynetworks.com (Thomas Hardjono) Subject: RE: Authorization without Authentication? Cc: aaa-wg@merit.edu In-Reply-To: <31B1EFDD2CD3D11187710000F805A8D5022D5E96@crchy270.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 05:35 PM 2/10/99 -0500, Basavaraj Patil wrote: >>> >>> > "pcalhoun@eng.sun.com" wrote: >> >>> > > I agree that for the most cases, the use of IPSec would be good. >However, for >>> > > some networks we should allow the use of long-lived secret keys. >There is also >>> > > the roaming situation that has different requirements due to the fact >that it >>> > > requires end-to-end security through proxies. Paul K. sent me an >e-mail on the >>> > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER >DOI, >>> > > which would allow key generation on top of the AAA protocol. >>> > >>> > I don't think IPsec precludes use of "long-lived secret keys." But use >of >>> > them can be a severe configuration problem. And the notion of an IPsec >>> > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such >>> > a DOI, would run semi-independently, and the AAA protocol(s) in >>> > question would then use the sessions. >>> Hmmm.... ok. However this would cause problems with the brokers that must >sit >>> in between both endpoints. The broker provides settlement services, and >must >>> be active in the transaction. >> > >>My model is more one of "use IKE to protect the channel between 2 >>communicating parties" so I don't see the problem. A broker, if it >>is actively participating, is one such party. So communications like >>the with a path like A->broker->X would have 2 segments where keying >>material is generated (and where the parties may be authenticated >>to each other). But there would be no IKE setup directly between >>A and X. > >The implication this has is that all AAA messaging would have to flow >through these two secure segments (A<-->Broker<-->X) to be >secure. Since the broker has the Security Associations with A and X >why not have the broker distribute keys to A and X over these secure >links that can be used for the session between A and X. This is asking a lot of the broker. The assumption is then that both X and A trusts the broker to generate and handle the keys for them. If they trust the broker to such an extent, then the original problem disappears. thomas ------ From owner-aaa-wg@merit.edu Thu Feb 11 11:45:08 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA07246 for ; Thu, 11 Feb 1999 11:45:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA25322 for aaa-wg-outgoing; Thu, 11 Feb 1999 11:44: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 SMTP id LAA25310 for ; Thu, 11 Feb 1999 11:44:33 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA15987; Thu, 11 Feb 1999 08:42:17 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.103.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA10694; Thu, 11 Feb 1999 08:42:15 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA15795; Thu, 11 Feb 1999 08:42:03 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902111642.IAA15795@hsmpka.eng.sun.com> Date: Thu, 11 Feb 1999 08:38:01 -0800 To: "Thomas Hardjono" , "Basavaraj Patil" Cc: Reply-To: Subject: RE: Authorization without Authentication? 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 05:35 PM 2/10/99 -0500, Basavaraj Patil wrote: >>>> >>>> > "pcalhoun@eng.sun.com" wrote: >>> >>>> > > I agree that for the most cases, the use of IPSec would be good. >>However, for >>>> > > some networks we should allow the use of long-lived secret keys. >>There is also >>>> > > the roaming situation that has different requirements due to the fact >>that it >>>> > > requires end-to-end security through proxies. Paul K. sent me an >>e-mail on the >>>> > > DIAMETER list a while back proposing that we create an IPSEC DIAMETER >>DOI, >>>> > > which would allow key generation on top of the AAA protocol. >>>> > >>>> > I don't think IPsec precludes use of "long-lived secret keys." But use >>of >>>> > them can be a severe configuration problem. And the notion of an IPsec >>>> > DOI for AAA would not run "on top of" an AAA protocol; IKE, with such >>>> > a DOI, would run semi-independently, and the AAA protocol(s) in >>>> > question would then use the sessions. >>>> Hmmm.... ok. However this would cause problems with the brokers that must >>sit >>>> in between both endpoints. The broker provides settlement services, and >>must >>>> be active in the transaction. >>> >> >>>My model is more one of "use IKE to protect the channel between 2 >>>communicating parties" so I don't see the problem. A broker, if it >>>is actively participating, is one such party. So communications like >>>the with a path like A->broker->X would have 2 segments where keying >>>material is generated (and where the parties may be authenticated >>>to each other). But there would be no IKE setup directly between >>>A and X. >> >>The implication this has is that all AAA messaging would have to flow >>through these two secure segments (A<-->Broker<-->X) to be >>secure. Since the broker has the Security Associations with A and X >>why not have the broker distribute keys to A and X over these secure >>links that can be used for the session between A and X. > >This is asking a lot of the broker. The assumption is then that >both X and A trusts the broker to generate and handle the keys >for them. If they trust the broker to such an extent, then the original >problem disappears. hmmm, no. You missed my point. The broker can be viewed as the CA (the entity, not the broker's AAA server). It therefore issues certificates for all AAA servers within its roaming consortium. No keys are generated by the broker, all key exchanges are done between A and X, through the broker. Again, I was just interpreting how Paul K's proposal could work, which would make use of IKE for end-to-end security. This was not his original proposal, this is my hacked up version of his proposal. I am still not clear that this is a good idea, for two reasons: 1. Since keys are generated for symmetric algorithms, you lose non-repudiation, which may be necessary in this environment. 2. It adds complexity to the protocol, whereas simply signing is simple. Signing each message, however, does add significant per request processing cost, to the point that discussing the disadvantages to XML parsing become moot. PatC > >thomas >------ > > > > From owner-aaa-wg@merit.edu Thu Feb 11 16:14:24 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA10123 for ; Thu, 11 Feb 1999 16:14:23 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA08524 for aaa-wg-outgoing; Thu, 11 Feb 1999 16:13:51 -0500 (EST) Received: from digdug.cisco.com (digdug.cisco.com [171.69.30.215]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA08513 for ; Thu, 11 Feb 1999 16:13:43 -0500 (EST) Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by digdug.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA05960 for ; Thu, 11 Feb 1999 13:13:08 -0800 (PST) Received: from beasley.cisco.com (beasley.cisco.com [171.69.11.49]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id NAA02246 for ; Thu, 11 Feb 1999 13:13:57 -0800 (PST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by beasley.cisco.com (8.8.8/2.6/Cisco List Logging/CISCO.GATE.1.1) with ESMTP id NAA15261 for ; Thu, 11 Feb 1999 13:13:07 -0800 (PST) Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id NAA04230 for ; Thu, 11 Feb 1999 13:42:57 -0800 (PST) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id NAA10759 for ; Thu, 11 Feb 1999 13:13:05 -0800 (PST) Received: from motgate.mot.com(129.188.136.100) by proxy3.cisco.com via smap (V2.0) id xma010720; Thu, 11 Feb 99 21:12:56 GMT X-SMAP-Received-From: outside Received: from pobox2.mot.com (pobox2.mot.com [129.188.137.195]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id PAA10315 for ; Thu, 11 Feb 1999 15:03:26 -0600 (CST) Comments: ( Received on motgate.mot.com from client pobox2.mot.com, sender y10469@NAmerica.mot.com ) Received: from s-il06ak.corp.mot.com (s-il06ak.corp.mot.com [199.2.152.59]) by pobox2.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id PAA06778 for ; Thu, 11 Feb 1999 15:02:19 -0600 (CST) Received: by s-il06ak.corp.mot.com with Internet Mail Service (5.5.2417.0) id <1KGF7Y75>; Thu, 11 Feb 1999 15:03:25 -0600 Message-ID: <7BB2BE979A63D211BDA600805F57491E09000A@s-il06ak.corp.mot.com> From: StLorant Misha-y10469 To: "'aaa mail list'" Subject: Mail list addition Date: Thu, 11 Feb 1999 15:03:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2417.0) Content-Type: text/plain Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello, I would like to be put on the mail list and begin paticipation for this WG. Thanks Misha Misha St. Lorant Internet Standards Motorola 14595 Bel-Red Road, Suite 100 Bellevue, WA 98007-3928 Tel: (425) 614-2235 Fax: (425) 401-9887 email: y10469@email.mot.com From owner-aaa-wg@merit.edu Thu Feb 11 17:50:59 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA11945 for ; Thu, 11 Feb 1999 17:50:59 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id RAA11373 for aaa-wg-outgoing; Thu, 11 Feb 1999 17:50:11 -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 RAA11355 for ; Thu, 11 Feb 1999 17:49:59 -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 OAA21445 for ; Thu, 11 Feb 1999 14:49:51 -0800 (PST) Message-Id: <3.0.6.32.19990211144515.00927ea0@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 11 Feb 1999 14:45:15 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Re: Authorization without Authentication? In-Reply-To: References: <"Your message with ID" <36C1B167.87F383C9@mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 08:54 AM 2/10/99 -0800, pcalhoun@eng.sun.com wrote: >> My model is more one of "use IKE to protect the channel between 2 >> communicating parties" so I don't see the problem. A broker, if it >> is actively participating, is one such party. So communications like >> the with a path like A->broker->X would have 2 segments where keying >> material is generated (and where the parties may be authenticated >> to each other). But there would be no IKE setup directly between >> A and X. > >Then we have the same model that RADIUS has, which is one that ROAMOPS has >already agreed is broken. We really need to have end-to-end authentication >(A<->X), while communicating through the broker. I agree with Pat here. There may be a need to have a secure end-to-end session that cannot be compromised by the intervening systems. In reality you need to have some level of trust with the intermediate systems so, in real life, the point *may* be moot. 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-wg@merit.edu Thu Feb 11 18:30:38 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA12345 for ; Thu, 11 Feb 1999 18:30:38 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA12389 for aaa-wg-outgoing; Thu, 11 Feb 1999 18:30:15 -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 SAA12381 for ; Thu, 11 Feb 1999 18:30:08 -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 PAA22040 for ; Thu, 11 Feb 1999 15:30:05 -0800 (PST) Message-Id: <3.0.6.32.19990211152702.008f7510@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 11 Feb 1999 15:27:02 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Re: Authorization without Authentication? In-Reply-To: References: <"Your message with ID" <36C1BF1E.F4657436@mci.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 09:38 AM 2/10/99 -0800, pcalhoun@eng.sun.com wrote: >You are correct that IKE is currently not setup for this. However, what I had >in mind may (possibly) be different than what you are currently thinking. Here >it is: > > X <--------> Broker <--------> A > <--IKE SA--> <--IKE SA--> (these use AH/ESP in transport mode) > <------------IKE SA------------> (this does not use AH/ESP) > >Note that IKE the second IKE (X-A) shown above would not be used in >conjunction with AH or ESP. I would propose that we use the keys negotiated >within the AAA base protocol's hashing and encryption functions. How IKE runs >through the broker is a problem that has yet to be solved though. > >Was this what you were thinking as well? This is beginning to get excessively complex. Why are we doing this? Are we hiding information from the broker or brokers, are we hiding the information from a man-in-the-middle, are we just trying to authenticate/certify information end-to-end, or some combination of the above? I think we just might want to find a way to simplify this. The combinations of SAs for multiple hops through multiple brokers could become painful to manage. 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-wg@merit.edu Thu Feb 11 19:04:48 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA12583 for ; Thu, 11 Feb 1999 19:04:48 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id TAA13118 for aaa-wg-outgoing; Thu, 11 Feb 1999 19:04:37 -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 TAA13113 for ; Thu, 11 Feb 1999 19:04:32 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA10598; Thu, 11 Feb 1999 16:03:28 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.101.47]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA16007; Thu, 11 Feb 1999 16:03:27 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25952; Thu, 11 Feb 1999 16:03:18 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902120003.QAA25952@hsmpka.eng.sun.com> Date: Thu, 11 Feb 1999 15:59:06 -0800 To: "Brian Lloyd" , Reply-To: Subject: Re: Authorization without Authentication? 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 09:38 AM 2/10/99 -0800, pcalhoun@eng.sun.com wrote: >>You are correct that IKE is currently not setup for this. However, what I had >>in mind may (possibly) be different than what you are currently thinking. >Here >>it is: >> >> X <--------> Broker <--------> A >> <--IKE SA--> <--IKE SA--> (these use AH/ESP in transport mode) >> <------------IKE SA------------> (this does not use AH/ESP) >> >>Note that IKE the second IKE (X-A) shown above would not be used in >>conjunction with AH or ESP. I would propose that we use the keys negotiated >>within the AAA base protocol's hashing and encryption functions. How IKE runs >>through the broker is a problem that has yet to be solved though. >> >>Was this what you were thinking as well? > >This is beginning to get excessively complex. Why are we doing this? Are >we hiding information from the broker or brokers, are we hiding the >information from a man-in-the-middle, are we just trying to >authenticate/certify information end-to-end, or some combination of the >above? I think we just might want to find a way to simplify this. The >combinations of SAs for multiple hops through multiple brokers could become >painful to manage. Oh I agree. I was just seeing whether using IKE makes sense. To me, as I have repetedly stated, it seems like simply using certs is much simpler. We only need to decide whether we can absorb the processing cost. PatC > > >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-wg@merit.edu Thu Feb 11 19:51:16 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA12801 for ; Thu, 11 Feb 1999 19:51:15 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id TAA13682 for aaa-wg-outgoing; Thu, 11 Feb 1999 19:51:01 -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 TAA13677 for ; Thu, 11 Feb 1999 19:50:57 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7MO1ZP32C8WW4X7@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 11 Feb 1999 19:50:25 EST Date: Thu, 11 Feb 1999 16:50:21 -0800 From: Paul Krumviede Subject: Re: Authorization without Authentication? To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36C37ACD.BEE9C2D2@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: <199902120003.QAA25952@hsmpka.eng.sun.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk > >This is beginning to get excessively complex. Why are we doing this? Are > >we hiding information from the broker or brokers, are we hiding the > >information from a man-in-the-middle, are we just trying to > >authenticate/certify information end-to-end, or some combination of the > >above? I think we just might want to find a way to simplify this. The > >combinations of SAs for multiple hops through multiple brokers could become > >painful to manage. For some reason, most security protocols seem complex, and we're seeing a manifestation of that. > Oh I agree. I was just seeing whether using IKE makes sense. To me, as I have > repetedly stated, it seems like simply using certs is much simpler. We only > need to decide whether we can absorb the processing cost. Because certs don't do much by themselves, I'd argue they are not sufficient. If we want to avoid pre-configuring shared secrets all over the place, then something like Diffie-Hellman is nice. But that may take more than just the existence of, and ability to verify, certificates. But I'd like to listen to a proposal where using certificates might be sufficient in and of themselves. -paul From owner-aaa-wg@merit.edu Fri Feb 12 12:06:34 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA21455 for ; Fri, 12 Feb 1999 12:06:34 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA27573 for aaa-wg-outgoing; Fri, 12 Feb 1999 12:04: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 SMTP id MAA27569 for ; Fri, 12 Feb 1999 12:04:08 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA05086; Fri, 12 Feb 1999 09:03:35 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.105.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA09265; Fri, 12 Feb 1999 09:03:31 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00052; Fri, 12 Feb 1999 09:03:26 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902121703.JAA00052@hsmpka.eng.sun.com> Date: Fri, 12 Feb 1999 08:59:09 -0800 To: , Reply-To: Subject: Re: Authorization without Authentication? 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 > >> >This is beginning to get excessively complex. Why are we doing this? Are >> >we hiding information from the broker or brokers, are we hiding the >> >information from a man-in-the-middle, are we just trying to >> >authenticate/certify information end-to-end, or some combination of the >> >above? I think we just might want to find a way to simplify this. The >> >combinations of SAs for multiple hops through multiple brokers could become >> >painful to manage. > >For some reason, most security protocols seem complex, and we're >seeing a manifestation of that. > >> Oh I agree. I was just seeing whether using IKE makes sense. To me, as I have >> repetedly stated, it seems like simply using certs is much simpler. We only >> need to decide whether we can absorb the processing cost. > >Because certs don't do much by themselves, I'd argue they are not >sufficient. If we want to avoid pre-configuring shared secrets >all over the place, then something like Diffie-Hellman is nice. >But that may take more than just the existence of, and ability >to verify, certificates. > >But I'd like to listen to a proposal where using certificates might >be sufficient in and of themselves. I agree that certs, by themselves, are not enough. I don't think that's what Brian was proposing. However, securing AAA traffic using certs (at the application level) may be sufficient. As I previously stated, we need to figue out whether we are willing to pay the per-packet processing cost associated with PK crypto. PatC > >-paul From owner-aaa-wg@merit.edu Fri Feb 12 12:53:53 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA21756 for ; Fri, 12 Feb 1999 12:53:53 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id MAA28967 for aaa-wg-outgoing; Fri, 12 Feb 1999 12:53:35 -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 MAA28960 for ; Fri, 12 Feb 1999 12:53:27 -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 JAA28718; Fri, 12 Feb 1999 09:53:14 -0800 (PST) Message-Id: <3.0.6.32.19990212095208.0094cb60@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 12 Feb 1999 09:52:08 -0800 To: From: Brian Lloyd Subject: Re: Authorization without Authentication? Cc: In-Reply-To: <199902121703.JAA00052@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 08:59 AM 2/12/99 -0800, Patrice Calhoun wrote: > >>But I'd like to listen to a proposal where using certificates might >>be sufficient in and of themselves. > >I agree that certs, by themselves, are not enough. I don't think that's what >Brian was proposing. However, securing AAA traffic using certs (at the >application level) may be sufficient. As I previously stated, we need to >figue out whether we are willing to pay the per-packet processing cost >associated with PK crypto. One of the trends at IETF WGs is one that I have seen in the more traditional standards bodies: bloated protocols. The problem stems from the fact that people believe that, if they can conceive of a problem then it is indeed a problem and must be addressed in the protocol. Alternately, it may be that the problem occurs so infrequently, i.e. never appears in real life, and that the protocol deals with the problem, albeit ungracefully, without failing. Dedicating resources to solve a perceived problem may yield no return on the effort invested. So, what is the minimal set of security associations/relationships that we need to meet real-world requirements? This is where we need input from the user base. It may turn out that all the SAs we think we need are bogus and the problem turns out to be simple. 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-wg@merit.edu Fri Feb 12 12:59:34 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA21808 for ; Fri, 12 Feb 1999 12:59:33 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id MAA29213 for aaa-wg-outgoing; Fri, 12 Feb 1999 12:59:26 -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 MAA29206 for ; Fri, 12 Feb 1999 12:59:19 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA24070; Fri, 12 Feb 1999 09:57:58 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.122.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA10934; Fri, 12 Feb 1999 09:57:54 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15718; Fri, 12 Feb 1999 09:57:45 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902121757.JAA15718@hsmpka.eng.sun.com> Date: Fri, 12 Feb 1999 09:53:31 -0800 To: "Brian Lloyd" , Cc: Reply-To: Subject: Re: Authorization without Authentication? 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 08:59 AM 2/12/99 -0800, Patrice Calhoun wrote: >> >>>But I'd like to listen to a proposal where using certificates might >>>be sufficient in and of themselves. >> >>I agree that certs, by themselves, are not enough. I don't think that's what >>Brian was proposing. However, securing AAA traffic using certs (at the >>application level) may be sufficient. As I previously stated, we need to >>figue out whether we are willing to pay the per-packet processing cost >>associated with PK crypto. > >One of the trends at IETF WGs is one that I have seen in the more >traditional standards bodies: bloated protocols. dead cow floating downstream along side of all the OSI documentation> The >problem stems from the fact that people believe that, if they can conceive >of a problem then it is indeed a problem and must be addressed in the >protocol. Alternately, it may be that the problem occurs so infrequently, >i.e. never appears in real life, and that the protocol deals with the >problem, albeit ungracefully, without failing. Dedicating resources to >solve a perceived problem may yield no return on the effort invested. > >So, what is the minimal set of security associations/relationships that we >need to meet real-world requirements? This is where we need input from the >user base. It may turn out that all the SAs we think we need are bogus and >the problem turns out to be simple. Before I answer this question, I have a comment about the WG and its charter (make that proposed). I believe that this WG should be concentrating on the base protocol, and not necessarily the inter-domain issues that seemed to have plagued the list. I think that ROAMOPS should be dealing with this, since it has for years. Does this make sense, or should we continue to discuss this here? PatC > > >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-wg@merit.edu Fri Feb 12 14:03:40 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA22341 for ; Fri, 12 Feb 1999 14:03:40 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA00828 for aaa-wg-outgoing; Fri, 12 Feb 1999 14:03:02 -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 OAA00821 for ; Fri, 12 Feb 1999 14:02:56 -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 LAA29343; Fri, 12 Feb 1999 11:02:02 -0800 (PST) Message-Id: <3.0.6.32.19990212110045.00955580@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 12 Feb 1999 11:00:45 -0800 To: From: Brian Lloyd Subject: Re: Authorization without Authentication? Cc: In-Reply-To: <199902121757.JAA15718@hsmpka.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 09:53 AM 2/12/99 -0800, Patrice Calhoun wrote: >Before I answer this question, I have a comment about the WG and its charter >(make that proposed). I believe that this WG should be concentrating on the >base protocol, and not necessarily the inter-domain issues that seemed to have >plagued the list. I think that ROAMOPS should be dealing with this, since it >has for years. Let roamops deal with the subset that is specific to dial-up roaming. Before you can deal with the base protocol you have to know what problem you are solving. We need to understand the relationships between all the applications, the data, and the protocols before we sit down to craft YAP (yet another protocol). >Does this make sense, or should we continue to discuss this here? It needs to be discussed somewhere. I don't see anyone else really discussing it. It is germane to AAA. This seems like a very reasonable venue. 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-wg@merit.edu Fri Feb 12 14:06:58 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA22370 for ; Fri, 12 Feb 1999 14:06:58 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA00887 for aaa-wg-outgoing; Fri, 12 Feb 1999 14:06:48 -0500 (EST) Received: from smtpott1.nortel.ca (smtpott1.NortelNetworks.com [192.58.194.78]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA00883 for ; Fri, 12 Feb 1999 14:06:43 -0500 (EST) Received: from zcard00m.ca.nortel.com by smtpott1.nortel.ca; Fri, 12 Feb 1999 14:06:25 -0500 Received: by zcard00m.ca.nortel.com with Internet Mail Service (5.0.1460.8) id <14J52YAS>; Fri, 12 Feb 1999 14:06:21 -0500 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5EB7@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'aaa-wg@merit.edu'" Cc: "'pat.calhoun@eng.sun.com'" , "'brian@lloyd.com'" , "Emad Qaddoura" Subject: RE: Authorization without Authentication? Date: Fri, 12 Feb 1999 14:06:18 -0500 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 >Brian Lloyd wrote: >>One of the trends at IETF WGs is one that I have seen in the more >>traditional standards bodies: bloated protocols. >dead cow floating downstream along side of all the OSI documentation> The >>problem stems from the fact that people believe that, if they can conceive >>of a problem then it is indeed a problem and must be addressed in the >>protocol. Alternately, it may be that the problem occurs so infrequently, >>i.e. never appears in real life, and that the protocol deals with the >>problem, albeit ungracefully, without failing. Dedicating resources to >>solve a perceived problem may yield no return on the effort invested. >> >>So, what is the minimal set of security associations/relationships that we >>need to meet real-world requirements? This is where we need input from the >>user base. It may turn out that all the SAs we think we need are bogus and >>the problem turns out to be simple. > >PatC wrote: >Before I answer this question, I have a comment about the WG and its charter >(make that proposed). I believe that this WG should be concentrating on the >base protocol, and not necessarily the inter-domain issues that seemed to have >plagued the list. I think that ROAMOPS should be dealing with this, since it >has for years. > >Does this make sense, or should we continue to discuss this here? Discussing what needs to be in the base protocol at this point in time of the AAA BOF/WG is what I am interested in. Specific solutions to areas associated with security such as certificates, IPsec, XML etc.. will probably diminish the focus of what is being set out to do in the proposed charter. Discussions on this WG seem to be spinning off from the main topic, which in my opinion is the charter and the requirements of the AAA problem domain at the current stage. -Basavaraj Patil From owner-aaa-wg@merit.edu Fri Feb 12 14:11:00 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA22390 for ; Fri, 12 Feb 1999 14:10:59 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id OAA00994 for aaa-wg-outgoing; Fri, 12 Feb 1999 14:10:12 -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 OAA00983 for ; Fri, 12 Feb 1999 14:10:01 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA18143; Fri, 12 Feb 1999 11:08:56 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.103.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA24674; Fri, 12 Feb 1999 11:08:52 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08293; Fri, 12 Feb 1999 11:08:40 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902121908.LAA08293@hsmpka.eng.sun.com> Date: Fri, 12 Feb 1999 11:04:29 -0800 To: "Brian Lloyd" Cc: Reply-To: Subject: Re: Authorization without Authentication? 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 09:53 AM 2/12/99 -0800, Patrice Calhoun wrote: >>Before I answer this question, I have a comment about the WG and its charter >>(make that proposed). I believe that this WG should be concentrating on the >>base protocol, and not necessarily the inter-domain issues that seemed to >have >>plagued the list. I think that ROAMOPS should be dealing with this, since it >>has for years. > >Let roamops deal with the subset that is specific to dial-up roaming. > >Before you can deal with the base protocol you have to know what problem >you are solving. We need to understand the relationships between all the >applications, the data, and the protocols before we sit down to craft YAP >(yet another protocol). That is fine, but the ROAMOPS WG agreed at the last IETF to extend the inter-domain AAA communication (which, btw, is what ROAMOPS is working on) to more than just dial-up. In fact, most of what we do really has nothing to do with dial-up, it just happens to be one application for inter-domain communication. That said, we can all agree here that this is a requirement, and we can work it out here. However, given the fact that most of the inter-domain expertise is really in ROAMOPS, we cannot ignore them. > >>Does this make sense, or should we continue to discuss this here? > >It needs to be discussed somewhere. I don't see anyone else really >discussing it. It is germane to AAA. This seems like a very reasonable >venue. Not true. ROAMOPS RFCs 2194, 2477 and 2486 are all critical to this problem set. Therefore, there has been lots of work in this area already. This WG was just waiting for the AAA WG to get setup before we can look at something beyond RADIUS, which we've already identified as being insufficient. PatC > > >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-wg@merit.edu Fri Feb 12 14:13:47 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA22441 for ; Fri, 12 Feb 1999 14:13:46 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA01068 for aaa-wg-outgoing; Fri, 12 Feb 1999 14:13:35 -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 OAA01064 for ; Fri, 12 Feb 1999 14:13:29 -0500 (EST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA18779; Fri, 12 Feb 1999 11:11:04 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.103.37]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25218; Fri, 12 Feb 1999 11:11:01 -0800 Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08775; Fri, 12 Feb 1999 11:10:44 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902121910.LAA08775@hsmpka.eng.sun.com> Date: Fri, 12 Feb 1999 11:06:35 -0800 To: "Basavaraj Patil" , "'aaa-wg@merit.edu'" Cc: "Emad Qaddoura" , "'brian@lloyd.com'" , "'pat.calhoun@eng.sun.com'" Reply-To: Subject: RE: Authorization without Authentication? 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 > >>Brian Lloyd wrote: >>>One of the trends at IETF WGs is one that I have seen in the more >>>traditional standards bodies: bloated protocols. bloated >>>dead cow floating downstream along side of all the OSI documentation> The >>>problem stems from the fact that people believe that, if they can conceive >>>of a problem then it is indeed a problem and must be addressed in the >>>protocol. Alternately, it may be that the problem occurs so infrequently, >>>i.e. never appears in real life, and that the protocol deals with the >>>problem, albeit ungracefully, without failing. Dedicating resources to >>>solve a perceived problem may yield no return on the effort invested. >>> >>>So, what is the minimal set of security associations/relationships that we >>>need to meet real-world requirements? This is where we need input from >the >>>user base. It may turn out that all the SAs we think we need are bogus >and >>>the problem turns out to be simple. >> >>PatC wrote: >>Before I answer this question, I have a comment about the WG and its >charter >>(make that proposed). I believe that this WG should be concentrating on the >>base protocol, and not necessarily the inter-domain issues that seemed to >have >>plagued the list. I think that ROAMOPS should be dealing with this, since >it >>has for years. >> >>Does this make sense, or should we continue to discuss this here? > >Discussing what needs to be in the base protocol at this point in time >of the AAA BOF/WG is what I am interested in. Specific solutions to areas >associated with security such as certificates, IPsec, XML etc.. will >probably diminish the focus of what is being set out to do in the proposed >charter. Discussions on >this WG seem to be spinning off from the main topic, which in my >opinion is the charter and the requirements of the AAA problem domain at the >current stage. Then how about we assume that Fred and Sue's draft is a starting point and start discussing what is/isn't a requirement in that draft. For some reason, it seems like many people have forgotten that alot of work has already been done. PatC > >-Basavaraj Patil > > From owner-aaa-wg@merit.edu Mon Feb 15 06:37:09 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id GAA20597 for ; Mon, 15 Feb 1999 06:37:09 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id GAA02887 for aaa-wg-outgoing; Mon, 15 Feb 1999 06:34:03 -0500 (EST) Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by merit.edu (8.9.1a/8.9.1) with ESMTP id GAA02883 for ; Mon, 15 Feb 1999 06:33:58 -0500 (EST) Received: from GK-Portable (unverified [193.149.73.30]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id ; Mon, 15 Feb 1999 11:25:12 +0000 Message-Id: <3.0.32.19990215113044.006b60f8@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 15 Feb 1999 11:34:18 +0000 To: Brian Lloyd From: Graham Klyne Subject: What is the basic problem? Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 11:00 12/02/99 -0800, Brian Lloyd wrote: >Before you can deal with the base protocol you have to know what problem >you are solving. FWIW, I agree. For myself, I am still unclear whether this is to be network infrastructure AAA, or a more generic protocol that can service generic application AAA. I have heard statements that say the latter, but the discussion seems to emphasize the former. So I watch and wait... #g ------------ Graham Klyne (GK@ACM.ORG) From owner-aaa-wg@merit.edu Thu Feb 18 14:37:52 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA08126 for ; Thu, 18 Feb 1999 14:37:52 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA23829 for aaa-wg-outgoing; Thu, 18 Feb 1999 14:34:29 -0500 (EST) Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by merit.edu (8.9.1a/8.9.1) with ESMTP id OAA23825 for ; Thu, 18 Feb 1999 14:34:24 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by rhine.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA19315 for ; Thu, 18 Feb 1999 11:33:39 -0800 (PST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA14142 for ; Thu, 18 Feb 1999 11:33:47 -0800 (PST) Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id LAA07711 for ; Thu, 18 Feb 1999 11:33:22 -0800 (PST) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA21038; Thu, 18 Feb 1999 11:32:50 -0800 (PST) Received: from fred-pc (fred-hm-dhcp3.cisco.com [171.69.128.118]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id LAA29205; Thu, 18 Feb 1999 11:32:54 -0800 (PST) Message-Id: <199902181932.LAA29205@kiwi.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 18 Feb 1999 11:32:31 -0800 To: ietf-aaa@external.cisco.com From: Fred Baker Subject: Direction of this proposed working group Cc: iesg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk As you all know, I have been having far too much fun lately on various things - day job and IETF work as well. Sue, likewise, is overcommitted. For this reason, during the last IETF we actively discussed choice of chairs with various people, and have been working over the past few weeks to transition leadership to Brian Lloyd and Paul Krumviede . Brian indicates that he has quite a bit of time to commit to this effort, which will be very helpful. Also, Sue, Paul, Brian, and I have been actively discussing the charter for a working group, considering the comments you have been making on the proposed charter. What we came up with is, we hope, a simple plan: - At the coming IETF meeting, have two sessions to hammer requirements one more time. Post those as internet drafts soon thereafter, and publish as informational RFCs as soon as the working group believes that they are final - Start work on a base protocol, one which will carry the necessary information elements between systems and allow sufficient function and flexibility that accounting applications and policy-based authorization applications can be designed without having to extend or change the underlying protocols beyond adding information. - As soon as the direction is clear, recharter appropriately to that direction. Brian will be posting that proposed charter in a few minutes, and if consensus supports it, I will ask the IESG to approve it. I need that consensus by tomorrow evening to give the IESG time to review it. From owner-aaa-wg@merit.edu Thu Feb 18 16:12:40 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA09277 for ; Thu, 18 Feb 1999 16:12:40 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA26200 for aaa-wg-outgoing; Thu, 18 Feb 1999 16:11: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 QAA26195 for ; Thu, 18 Feb 1999 16:10:55 -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 NAA11378 for ; Thu, 18 Feb 1999 13:10:40 -0800 (PST) Message-Id: <3.0.6.32.19990218130910.00944af0@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 18 Feb 1999 13:09:10 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: current draft charter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk AAA working group charter The Authentication, Authorization and Accounting working group will focus on the specification of a general Authentication, Authorization, and Accounting protocol for the Internet. The purpose behind creating a general AAA protocol for the Internet is to create a common base protocol for a number of specific AAA applications. These include at least IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. By creating a general base Protocol, the amount of work to create a specific AAA protocols will be reduced. The problem space for a general AAA working group contains work in: - determining the current set of specific applications that the AAA will service; - documenting requirements for a base AAA protocol; - identifying the capabilities and limitations of protocols currently used to transport AAA information, e.g. RADIUS, Diameter, COPS, etc.; - selecting a transport protocol or set of transport protocols to be used by a general AAA protocol based on the requirements, - selecting the framework for the AAA protocols; - specifying the base AAA protocol; - specifying the data formats for information contained in the AAA protocol information for authentication, authorization, and accounting; - identify the relationship and interaction between Policy and Authorization. The first step in this working group is to determine the requirements for the AAA base protocol, and probable uses of that protocol. Once the requirements have been documented, the working group will be rechartered to implement to those requirements. A close second is to consider proposals of base protocols; ideally, the working group should be able to finalize requirements and review proposals during its second meeting. The working group will target the use of TCP and defined procedures on UDP. When RUTS produces a result, the working group will consider changing from TCP and UDP to that protocol. Document Schedule April '99 AAA Applications (informational RFC) Internet Draft Authentication Requirements initial Internet Draft Authorization Requirements initial Internet Draft Accounting Requirements initial Internet Draft June '99 AAA Base protocol proposals documented as Internet drafts August '99 AAA Base Protocol Framework Working Group Draft AAA Applications to Informational RFC AAA Requirements to Informational RFC September '99 Revision of charter to include statement of work regarding specific protocols and data formats. October '99 AAA Base Protocol(s) Specification to Internet Draft 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-wg@merit.edu Thu Feb 18 16:12:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA09283 for ; Thu, 18 Feb 1999 16:12:42 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA26196 for aaa-wg-outgoing; Thu, 18 Feb 1999 16:10:58 -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 QAA26190 for ; Thu, 18 Feb 1999 16:10:45 -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 NAA11375 for ; Thu, 18 Feb 1999 13:10:39 -0800 (PST) Message-Id: <3.0.6.32.19990218130923.00942370@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 18 Feb 1999 13:09:23 -0800 To: aaa-wg@merit.edu From: Brian Lloyd Subject: Re: Direction of this proposed working group In-Reply-To: <199902181932.LAA29205@kiwi.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 11:32 AM 2/18/99 -0800, you wrote: >As you all know, I have been having far too much fun lately on various >things - day job and IETF work as well. Sue, likewise, is overcommitted. >For this reason, during the last IETF we actively discussed choice of >chairs with various people, and have been working over the past few weeks >to transition leadership to Brian Lloyd and Paul >Krumviede . Brian indicates that he has quite a bit of time >to commit to this effort, which will be very helpful. See what happens when I open my big mouth! >Also, Sue, Paul, Brian, and I have been actively discussing the charter for >a working group, considering the comments you have been making on the >proposed charter. What we came up with is, we hope, a simple plan: > > - At the coming IETF meeting, have two sessions to hammer requirements one > more time. Post those as internet drafts soon thereafter, and publish as > informational RFCs as soon as the working group believes that they are > final > > - Start work on a base protocol, one which will carry the necessary > information elements between systems and allow sufficient function and > flexibility that accounting applications and policy-based authorization > applications can be designed without having to extend or change the > underlying protocols beyond adding information. > > - As soon as the direction is clear, recharter appropriately to that > direction. > >Brian will be posting that proposed charter in a few minutes, and if >consensus supports it, I will ask the IESG to approve it. I need that >consensus by tomorrow evening to give the IESG time to review it. Well, it wasn't a few minutes because I went out to lunch. (Some people consider that to be my normal waking state.) I will post the charter as a separate message in a few moments. 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-wg@merit.edu Thu Feb 18 17:10:08 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id RAA09863 for ; Thu, 18 Feb 1999 17:10:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA27506 for aaa-wg-outgoing; Thu, 18 Feb 1999 17:08:27 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by merit.edu (8.9.1a/8.9.1) with ESMTP id RAA27502 for ; Thu, 18 Feb 1999 17:08:22 -0500 (EST) Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.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 WAA10042; Thu, 18 Feb 1999 22:08:14 GMT Received: by FMSMSX29 with Internet Mail Service (5.5.2232.9) id <1DMDPQ49>; Thu, 18 Feb 1999 14:08:13 -0800 Message-ID: <4A043A1FE4B2D111AC3F00A0C96B513301B0F444@FMSMSX37> From: "Durham, David" To: "'Brian Lloyd'" , aaa-wg@merit.edu Subject: RE: current draft charter Date: Thu, 18 Feb 1999 14:08:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk my comments... > -----Original Message----- > From: Brian Lloyd [SMTP:brian@lloyd.com] > Sent: Thursday, February 18, 1999 1:09 PM > To: aaa-wg@merit.edu > Subject: current draft charter > > AAA working group charter > > The Authentication, Authorization and Accounting working group will focus > on the specification of a general Authentication, Authorization, and > Accounting protocol for the Internet. The purpose behind creating a > general AAA protocol for the Internet is to create a common base protocol > for a number of specific AAA applications. These include at least IP > Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. > By creating a general base Protocol, the amount of work to create a > specific AAA protocols will be reduced. > > The problem space for a general AAA working group contains work in: > > - determining the current set of specific applications that the AAA will > service; > - documenting requirements for a base AAA protocol; > [Durham, David] I am still not sure that we should jump to the conclusion that there will be a single protocol. Why not allow two (or three...) protocols that work great together to achieve AAA? In the very least the charter should state protocol or protocol(s) for achieving AAA. > - identifying the capabilities and limitations of protocols currently used > to transport AAA information, e.g. RADIUS, Diameter, COPS, etc.; > - selecting a transport protocol or set of transport protocols to be used > by a general AAA protocol based on the requirements, > - selecting the framework for the AAA protocols; > - specifying the base AAA protocol; [Durham, David] or protocol(s) :) > - specifying the data formats for information contained in the AAA > protocol > information for authentication, authorization, and accounting; [Durham, David] I would suggest a common data representation, and not leave it to just type/datablob. It would be nice if the datablob part was self describing or at least followed some general rules (aka. base data types). > - identify the relationship and interaction between Policy and > Authorization. > > The first step in this working group is to determine the requirements for > the AAA base protocol, and probable uses of that protocol. Once the > requirements have been documented, the working group will be rechartered > to > implement to those requirements. A close second is to consider proposals > of > base protocols; ideally, the working group should be able to finalize > requirements and review proposals during its second meeting. > > The working group will target the use of TCP and defined procedures on > UDP. > When RUTS produces a result, the working group will consider changing from > TCP and UDP to that protocol. [Durham, David] What does "defined procedures on UDP" mean? RUTS is addressing TCP issues, right? > Document Schedule > > April '99 AAA Applications (informational RFC) Internet Draft > Authentication Requirements initial Internet Draft > Authorization Requirements initial Internet Draft > Accounting Requirements initial Internet Draft > > June '99 AAA Base protocol proposals documented as Internet drafts > > August '99 AAA Base Protocol Framework Working Group Draft > AAA Applications to Informational RFC > AAA Requirements to Informational RFC > [Durham, David] August seems overly aggressive for the base protocol(s) framework draft given the proposals have only been considered in June. In fact, I'm not sure which should come first, framework or the proposals. Framework!=protocol right? > September '99 Revision of charter to include statement of work regarding > specific protocols and data formats. [Durham, David] This sounds good. > > October '99 AAA Base Protocol(s) Specification to Internet Draft > > > > 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-wg@merit.edu Thu Feb 18 19:37:55 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA11468 for ; Thu, 18 Feb 1999 19:37:55 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id TAA00763 for aaa-wg-outgoing; Thu, 18 Feb 1999 19:37:36 -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 TAA00759 for ; Thu, 18 Feb 1999 19:37:32 -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 QAA13604; Thu, 18 Feb 1999 16:37:21 -0800 (PST) Message-Id: <3.0.6.32.19990218163557.009418a0@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 18 Feb 1999 16:35:57 -0800 To: "Durham, David" From: Brian Lloyd Subject: RE: current draft charter Cc: aaa-wg@merit.edu In-Reply-To: <4A043A1FE4B2D111AC3F00A0C96B513301B0F444@FMSMSX37> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 02:08 PM 2/18/99 -0800, Durham, David wrote: > [Durham, David] I am still not sure that we should jump to > the conclusion that there will be a single protocol. We certainly aren't. > Why not allow > two (or three...) protocols that work great together to achieve > AAA? In the very least the charter should state protocol > or protocol(s) for achieving AAA. That is why we are doing some of the up-front work. >> - specifying the data formats for information contained in the AAA >> protocol >> information for authentication, authorization, and accounting; > [Durham, David] I would suggest a common data representation, > and not leave it to just type/datablob. It would be nice if > the datablob part was self describing or at least followed > some general rules (aka. base data types). I want to see common semantics for the data too. >> The working group will target the use of TCP and defined procedures on >> UDP. >> When RUTS produces a result, the working group will consider changing from >> TCP and UDP to that protocol. > [Durham, David] What does "defined procedures on UDP" mean? > RUTS is addressing TCP issues, right? Fred wanted that grafted on. It seems reasonable to include it. > [Durham, David] August seems overly aggressive for the base > protocol(s) framework draft given the proposals have only > been considered in June. In fact, I'm not sure which should > come first, framework or the proposals. Framework!=protocol > right? It is aggressive. We have lots of work to do, don't we. >> September '99 Revision of charter to include statement of work regarding >> specific protocols and data formats. > [Durham, David] This sounds good. We expect that the reqirements will carry us on for awhile. 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-wg@merit.edu Thu Feb 18 20:12:30 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA11706 for ; Thu, 18 Feb 1999 20:12:30 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA01246 for aaa-wg-outgoing; Thu, 18 Feb 1999 20:12:22 -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 UAA01242 for ; Thu, 18 Feb 1999 20:12:17 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7WGTU7O088Y5B99@shoe.reston.mci.net> for aaa-wg@merit.edu; Thu, 18 Feb 1999 20:11:43 EST Date: Thu, 18 Feb 1999 17:11:40 -0800 From: Paul Krumviede Subject: Re: current draft charter To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36CCBA4C.632FA0C2@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: <3.0.6.32.19990218163557.009418a0@158.222.8.12> Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian Lloyd wrote: > > At 02:08 PM 2/18/99 -0800, Durham, David wrote: > >> The working group will target the use of TCP and defined procedures on > >> UDP. > >> When RUTS produces a result, the working group will consider changing from > >> TCP and UDP to that protocol. > > [Durham, David] What does "defined procedures on UDP" mean? > > RUTS is addressing TCP issues, right? > > Fred wanted that grafted on. It seems reasonable to include it. I think it was Fred who pointed out in Orlando that UDP isn't a transport, it is simply a labeling or muxing mechanism. "Defined procedures on UDP" is meant to capture the notion that a little bit more than "just use UDP on port XYZ" is necessary. Vern's notes from the RUTS BOF state that the intent is to more fully explore the requirements, not to design transport protocols and/or TCP tweaks. So I don't think we can really say what may come out of the effort; if the requirements are sufficiently diverse it may not be practical to come up with a common solution. -paul From owner-aaa-wg@merit.edu Thu Feb 18 20:38:12 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA11904 for ; Thu, 18 Feb 1999 20:38:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA01484 for aaa-wg-outgoing; Thu, 18 Feb 1999 20:37:57 -0500 (EST) Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA01480 for ; Thu, 18 Feb 1999 20:37:53 -0500 (EST) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA04159; Thu, 18 Feb 1999 17:37:22 -0800 (PST) Received: from fred-pc (fred-hm-dhcp3.cisco.com [171.69.128.118]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id RAA08372; Thu, 18 Feb 1999 17:37:25 -0800 (PST) Message-Id: <199902190137.RAA08372@kiwi.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 18 Feb 1999 17:26:01 -0800 To: "Durham, David" From: Fred Baker Subject: RE: current draft charter Cc: "'Brian Lloyd'" , aaa-wg@merit.edu In-Reply-To: <4A043A1FE4B2D111AC3F00A0C96B513301B0F444@FMSMSX37> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 02:08 PM 2/18/99 -0800, Durham, David wrote: > [Durham, David] I am still not sure that we should jump to > the conclusion that there will be a single protocol. Why not allow > two (or three...) protocols that work great together to achieve > AAA? In the very least the charter should state protocol > or protocol(s) for achieving AAA. I'll buy that >> The working group will target the use of TCP and defined procedures on >> UDP. >> When RUTS produces a result, the working group will consider changing from >> TCP and UDP to that protocol. > [Durham, David] What does "defined procedures on UDP" mean? > RUTS is addressing TCP issues, right? RUTS is defining a protocol that will meet the needs of a community such as AAA, which needs to be able to have transactions serviced in a different order than transmission order (if a transmission is dropped, subsequent ones can still be serviced prior to its retransmission) and none-the-less deal with the congestion avoidance issues that TCP addresses. Today, we pretty clearly have two camps: one has small transactions that will fit into a single segment and need the non-specific order and very fast retransmission, and one which sends large requests on the order of 16K and is willing to deal with TCP. The first likes to say "we want UDP to be our transport" - but UDP is not a transport, it is a label, pretty much equivalent to the ports and checksum in the TCP header. For interoperability, if we're going to use UDP as a transport, we need to say what transport procedures we will follow when we use UDP. This is my way of saying "this working group will not spend any more time arguing about transport, or whether we should be arguing about transport. we will plan for the transports we know we need in the near term, and when an alternative is available, we will consider it on its merits and market demand." > [Durham, David] August seems overly aggressive for the base > protocol(s) framework draft given the proposals have only > been considered in June. In fact, I'm not sure which should > come first, framework or the proposals. Framework!=protocol > right? I don't think we're going to so a full-blown protocol here, nor (apart from DIAMETER, which is IMHO not a protocol but a way to write lots of protocols) are we likely to see full-blown proposals. My thinking is that at this point we will know the direction we are headed well enough that the rechartering can have some validity. From owner-aaa-wg@merit.edu Thu Feb 18 20:48:44 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id UAA11996 for ; Thu, 18 Feb 1999 20:48:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id UAA01602 for aaa-wg-outgoing; Thu, 18 Feb 1999 20:48:29 -0500 (EST) Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by merit.edu (8.9.1a/8.9.1) with ESMTP id UAA01597 for ; Thu, 18 Feb 1999 20:48:24 -0500 (EST) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA06260; Thu, 18 Feb 1999 17:47:19 -0800 (PST) Received: from fred-pc (fred-hm-dhcp3.cisco.com [171.69.128.118]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id RAA08498; Thu, 18 Feb 1999 17:47:22 -0800 (PST) Message-Id: <199902190147.RAA08498@kiwi.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 18 Feb 1999 17:43:57 -0800 To: paul@mci.net From: Fred Baker Subject: Re: current draft charter Cc: aaa-wg@merit.edu, Scott Bradner , Vern Paxson In-Reply-To: <36CCBA4C.632FA0C2@mci.net> References: <3.0.6.32.19990218163557.009418a0@158.222.8.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 05:11 PM 2/18/99 -0800, Paul Krumviede wrote: >Vern's notes from the RUTS BOF state that the intent is to more >fully explore the requirements, not to design transport protocols >and/or TCP tweaks. So I don't think we can really say what may >come out of the effort; if the requirements are sufficiently >diverse it may not be practical to come up with a common >solution. what he told me later led me to believe that I should drop any work on experimenting with or defining the protocol myself, which is fine; he seemed to think that the outcome would indeed be a protocol. IMHO, this application is the definitive application for a non-TCP transport. From owner-aaa-wg@merit.edu Fri Feb 19 03:08:20 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id DAA14475 for ; Fri, 19 Feb 1999 03:08:18 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id DAA06671 for aaa-wg-outgoing; Fri, 19 Feb 1999 03:06:53 -0500 (EST) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by merit.edu (8.9.1a/8.9.1) with ESMTP id DAA06667 for ; Fri, 19 Feb 1999 03:06:49 -0500 (EST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id AAA08510; Fri, 19 Feb 1999 00:06:47 -0800 (PST) Message-Id: <199902190806.AAA08510@daffy.ee.lbl.gov> To: Fred Baker Cc: paul@mci.net, aaa-wg@merit.edu, Scott Bradner Subject: Re: current draft charter In-reply-to: Your message of Thu, 18 Feb 1999 17:43:57 PST. Date: Fri, 19 Feb 1999 00:06:46 PST From: Vern Paxson Sender: owner-aaa-bof@merit.edu Precedence: bulk > At 05:11 PM 2/18/99 -0800, Paul Krumviede wrote: > >Vern's notes from the RUTS BOF state that the intent is to more > >fully explore the requirements, not to design transport protocols > >and/or TCP tweaks. So I don't think we can really say what may > >come out of the effort; if the requirements are sufficiently > >diverse it may not be practical to come up with a common > >solution. > > what he told me later led me to believe that I should drop any work on > experimenting with or defining the protocol myself, which is fine; he > seemed to think that the outcome would indeed be a protocol. IMHO, this > application is the definitive application for a non-TCP transport. Right - we're holding a BOF ("SLUMS") at Minneapolis to explore transport solutions to (a subset of) the RUTS requirements. We expect this will lead to chartering a WG. We'll be announcing it on the ruts list sometime next week. Vern From owner-aaa-wg@merit.edu Fri Feb 19 03:25:37 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id DAA14587 for ; Fri, 19 Feb 1999 03:25:37 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id DAA07090 for aaa-wg-outgoing; Fri, 19 Feb 1999 03:25:29 -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 DAA07080 for ; Fri, 19 Feb 1999 03:25:24 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA04845; Fri, 19 Feb 1999 00:24:49 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.101.37]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id AAA02827; Fri, 19 Feb 1999 00:24:49 -0800 (PST) Received: from epidote by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA29738; Fri, 19 Feb 1999 00:24:46 -0800 Date: Fri, 19 Feb 1999 09:20:35 +0100 (MET) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: current draft charter To: paul@mci.net Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <36CCBA4C.632FA0C2@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Brian Lloyd wrote: > > > > At 02:08 PM 2/18/99 -0800, Durham, David wrote: > > > >> The working group will target the use of TCP and defined procedures on > > >> UDP. > > >> When RUTS produces a result, the working group will consider changing from > > >> TCP and UDP to that protocol. > > > [Durham, David] What does "defined procedures on UDP" mean? > > > RUTS is addressing TCP issues, right? > > > > Fred wanted that grafted on. It seems reasonable to include it. > > I think it was Fred who pointed out in Orlando that UDP isn't a > transport, it is simply a labeling or muxing mechanism. "Defined > procedures on UDP" is meant to capture the notion that a little bit > more than "just use UDP on port XYZ" is necessary. > > Vern's notes from the RUTS BOF state that the intent is to more > fully explore the requirements, not to design transport protocols > and/or TCP tweaks. So I don't think we can really say what may > come out of the effort; if the requirements are sufficiently > diverse it may not be practical to come up with a common > solution. Yes I agree. It has been my experience in getting the DIAMETER/UDP draft ready that identified some real requirements, which we can then take to RUTS. PatC > > -paul From owner-aaa-wg@merit.edu Fri Feb 19 03:28:04 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id DAA14600 for ; Fri, 19 Feb 1999 03:28:04 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id DAA07144 for aaa-wg-outgoing; Fri, 19 Feb 1999 03:27:57 -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 DAA07138 for ; Fri, 19 Feb 1999 03:27:52 -0500 (EST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA05291; Fri, 19 Feb 1999 00:27:19 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.103.37]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id AAA03064; Fri, 19 Feb 1999 00:27:18 -0800 (PST) Received: from epidote by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA29841; Fri, 19 Feb 1999 00:27:14 -0800 Date: Fri, 19 Feb 1999 09:23:03 +0100 (MET) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: current draft charter To: Vern Paxson Cc: Fred Baker , paul@mci.net, aaa-wg@merit.edu, Scott Bradner In-Reply-To: "Your message with ID" <199902190806.AAA08510@daffy.ee.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > At 05:11 PM 2/18/99 -0800, Paul Krumviede wrote: > > >Vern's notes from the RUTS BOF state that the intent is to more > > >fully explore the requirements, not to design transport protocols > > >and/or TCP tweaks. So I don't think we can really say what may > > >come out of the effort; if the requirements are sufficiently > > >diverse it may not be practical to come up with a common > > >solution. > > > > what he told me later led me to believe that I should drop any work on > > experimenting with or defining the protocol myself, which is fine; he > > seemed to think that the outcome would indeed be a protocol. IMHO, this > > application is the definitive application for a non-TCP transport. > > Right - we're holding a BOF ("SLUMS") at Minneapolis to explore transport > solutions to (a subset of) the RUTS requirements. We expect this will lead > to chartering a WG. We'll be announcing it on the ruts list sometime next > week. It would be great if you could request that it not conflict with AAA this time around :) PatC From owner-aaa-wg@merit.edu Fri Feb 19 03:30:33 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id DAA14627 for ; Fri, 19 Feb 1999 03:30:33 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id DAA07219 for aaa-wg-outgoing; Fri, 19 Feb 1999 03:30:27 -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 DAA07215 for ; Fri, 19 Feb 1999 03:30:23 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA05523; Fri, 19 Feb 1999 00:29:19 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.61.47]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id AAA00719; Fri, 19 Feb 1999 00:29:16 -0800 (PST) Received: from epidote by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA00466; Fri, 19 Feb 1999 00:29:16 -0800 Date: Fri, 19 Feb 1999 09:25:05 +0100 (MET) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: current draft charter To: Brian Lloyd Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3.0.6.32.19990218130910.00944af0@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 > AAA working group charter > > The Authentication, Authorization and Accounting working group will focus > on the specification of a general Authentication, Authorization, and > Accounting protocol for the Internet. The purpose behind creating a > general AAA protocol for the Internet is to create a common base protocol > for a number of specific AAA applications. These include at least IP > Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. > By creating a general base Protocol, the amount of work to create a > specific AAA protocols will be reduced. I would really like you to include Mobile IP in the charter. There is a significant amount of work being done in MIP to tie it in with the AAA work. > > Document Schedule > > April '99 AAA Applications (informational RFC) Internet Draft > Authentication Requirements initial Internet Draft > Authorization Requirements initial Internet Draft > Accounting Requirements initial Internet Draft > > June '99 AAA Base protocol proposals documented as Internet drafts > > August '99 AAA Base Protocol Framework Working Group Draft > AAA Applications to Informational RFC > AAA Requirements to Informational RFC > > September '99 Revision of charter to include statement of work regarding > specific protocols and data formats. > > October '99 AAA Base Protocol(s) Specification to Internet Draft > Sounds agressive, but I like it. It sounds like we will need interim meetings and conference calls to get the work done on time. From owner-aaa-wg@merit.edu Fri Feb 19 09:11:40 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA17110 for ; Fri, 19 Feb 1999 09:11:40 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA11007 for aaa-wg-outgoing; Fri, 19 Feb 1999 09:09:24 -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 JAA11001 for ; Fri, 19 Feb 1999 09:09:20 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7X7YB6BDC8Y5BAB@shoe.reston.mci.net> for aaa-wg@merit.edu; Fri, 19 Feb 1999 09:08:48 EST Date: Fri, 19 Feb 1999 06:08:43 -0800 From: Paul Krumviede Subject: Re: current draft charter To: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36CD706B.75489020@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 Patrice Calhoun wrote: > > > AAA working group charter > > > > The Authentication, Authorization and Accounting working group will focus > > on the specification of a general Authentication, Authorization, and > > Accounting protocol for the Internet. The purpose behind creating a > > general AAA protocol for the Internet is to create a common base protocol > > for a number of specific AAA applications. These include at least IP > > Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. > > By creating a general base Protocol, the amount of work to create a > > specific AAA protocols will be reduced. > > I would really like you to include Mobile IP in the charter. There is a > significant amount of work being done in MIP to tie it in with the AAA work. We are soliciting input so we can figure out what we need to do. To the extent that MobileIP has requirements or desires, we're interested. I don't think we meant the charter to include an exhaustive list of things that would be considered (and we did not mean to imply that things not listed wouldn't be considered). -paul From owner-aaa-wg@merit.edu Fri Feb 19 09:52:08 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id JAA17509 for ; Fri, 19 Feb 1999 09:52:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA11764 for aaa-wg-outgoing; Fri, 19 Feb 1999 09:51:51 -0500 (EST) Received: from smtpott2.nortel.ca (smtpott2.NortelNetworks.com [192.58.194.80]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA11756 for ; Fri, 19 Feb 1999 09:51:45 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtpott2.nortel.ca; Fri, 19 Feb 1999 09:51:18 -0500 Received: from zrtpd003.us.nortel.com by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id 1HHZRSDR; Fri, 19 Feb 1999 09:45:10 -0500 Received: from archr20c.us.nortel.com by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id FAQ75L31; Fri, 19 Feb 1999 09:45:08 -0500 Message-ID: <36CD3290.BEBD775@nt.com> Date: Fri, 19 Feb 1999 09:45:01 +0000 From: "Kung Loh" X-Mailer: Mozilla 4.06 (Macintosh; I; PPC) MIME-Version: 1.0 To: paul@mci.net CC: aaa-wg@merit.edu Subject: Re: current draft charter References: <3.0.6.32.19990218163557.009418a0@158.222.8.12> <36CCBA4C.632FA0C2@mci.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Pual brought up a good point which I fully support: the working group should to "fully explore the requirements" of AAA applications, the informaiton elements associated with the applications/requirements, and the requirements of communications before start to design transport mechanisms. Kung Paul Krumviede wrote: > > Brian Lloyd wrote: > > > > At 02:08 PM 2/18/99 -0800, Durham, David wrote: > > > >> The working group will target the use of TCP and defined procedures on > > >> UDP. > > >> When RUTS produces a result, the working group will consider changing from > > >> TCP and UDP to that protocol. > > > [Durham, David] What does "defined procedures on UDP" mean? > > > RUTS is addressing TCP issues, right? > > > > Fred wanted that grafted on. It seems reasonable to include it. > > I think it was Fred who pointed out in Orlando that UDP isn't a > transport, it is simply a labeling or muxing mechanism. "Defined > procedures on UDP" is meant to capture the notion that a little bit > more than "just use UDP on port XYZ" is necessary. > > Vern's notes from the RUTS BOF state that the intent is to more > fully explore the requirements, not to design transport protocols > and/or TCP tweaks. So I don't think we can really say what may > come out of the effort; if the requirements are sufficiently > diverse it may not be practical to come up with a common > solution. > > -paul From owner-aaa-wg@merit.edu Fri Feb 19 11:07:45 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA18225 for ; Fri, 19 Feb 1999 11:07:45 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA13464 for aaa-wg-outgoing; Fri, 19 Feb 1999 11:07:07 -0500 (EST) Received: from research.solidum.com (IDENT:root@gigabit.solidum.com [209.151.29.225]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA13460 for ; Fri, 19 Feb 1999 11:07:00 -0500 (EST) Received: from venus.solidum.com (venus.solidum.com [192.168.1.1]) by research.solidum.com (8.8.4/8.8.4) with ESMTP id LAA27769 for ; Fri, 19 Feb 1999 11:02:45 -0500 Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by venus.solidum.com (8.8.7/8.8.7) with ESMTP id LAA23865 for ; Fri, 19 Feb 1999 11:06:55 -0500 Message-Id: <199902191606.LAA23865@venus.solidum.com> To: aaa-wg@merit.edu Subject: Re: current draft charter In-reply-to: Your message of "Thu, 18 Feb 1999 14:08:12 PST." <4A043A1FE4B2D111AC3F00A0C96B513301B0F444@FMSMSX37> Date: Fri, 19 Feb 1999 11:06:54 -0500 From: Michael Richardson Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> "Durham," == Durham, David writes: Durham,> [Durham, David] I am still not sure that we should jump to Durham,> the conclusion that there will be a single protocol. Why not allow Durham,> two (or three...) protocols that work great together to achieve Durham,> AAA? In the very least the charter should state protocol Durham,> or protocol(s) for achieving AAA. A very good example is the SSH version 2 (aka SecSH) protocol. It includes three layers of protocol: transport, connect and userauth (that doesn't seem quite right to me. But the drafts have expired) The transport protocol was intended to be replaceable by IPsec+TCP at a future time. So, I would concur with David here. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. From owner-aaa-wg@merit.edu Fri Feb 19 12:49:56 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id MAA19226 for ; Fri, 19 Feb 1999 12:49:56 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA15770 for aaa-wg-outgoing; Fri, 19 Feb 1999 12:49:33 -0500 (EST) Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA15765 for ; Fri, 19 Feb 1999 12:49:28 -0500 (EST) Received: from zrchb213.us.nortel.com (actually 47.100.128.42) by smtprtp.nortel.com; Fri, 19 Feb 1999 12:49:02 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.0.1460.8) id <19GLWA4T>; Fri, 19 Feb 1999 11:48:59 -0600 Message-ID: <31B1EFDD2CD3D11187710000F805A8D5022D5EEF@crchy270.us.nortel.com> From: "Basavaraj Patil" To: "'Brian Lloyd'" Cc: aaa-wg@merit.edu, "Emad Qaddoura" Subject: RE: current draft charter Date: Fri, 19 Feb 1999 11:47:44 -0600 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 problem space for a general AAA working group contains work in: > >- determining the current set of specific applications that the AAA will >service; >- documenting requirements for a base AAA protocol; >- identifying the capabilities and limitations of protocols currently used >to transport AAA information, e.g. RADIUS, Diameter, COPS, etc.; >- selecting a transport protocol or set of transport protocols to be used >by a general AAA protocol based on the requirements, >- selecting the framework for the AAA protocols; I think a framework for the AAA protocols needs to be specified/developed based on the requirements. I'm not sure what you mean by "selecting" the framework. >- specifying the base AAA protocol; >- specifying the data formats for information contained in the AAA protocol >information for authentication, authorization, and accounting; >- identify the relationship and interaction between Policy and Authorization. > >The first step in this working group is to determine the requirements for >the AAA base protocol, and probable uses of that protocol. Once the >requirements have been documented, the working group will be rechartered to >implement to those requirements. Again, I would think that a followup task of the requirements phase is the definition of the framework. This will place specific boundaries on the goals to be accomplished within this WG. I tend to think that the specification of the framework comes before the task of specifying the base protocol. -Basavaraj Patil >A close second is to consider proposals of >base protocols; ideally, the working group should be able to finalize >requirements and review proposals during its second meeting. > >Document Schedule > >April '99 AAA Applications (informational RFC) Internet Draft > Authentication Requirements initial Internet Draft > Authorization Requirements initial Internet Draft > Accounting Requirements initial Internet Draft > >June '99 AAA Base protocol proposals documented as Internet drafts > >August '99 AAA Base Protocol Framework Working Group Draft > AAA Applications to Informational RFC > AAA Requirements to Informational RFC > >September '99 Revision of charter to include statement of work regarding >specific protocols and data formats. > >October '99 AAA Base Protocol(s) Specification to Internet Draft > > > >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-wg@merit.edu Fri Feb 19 13:04:25 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA19417 for ; Fri, 19 Feb 1999 13:04:24 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA16114 for aaa-wg-outgoing; Fri, 19 Feb 1999 13:04:06 -0500 (EST) Received: from quartz.airtouch.com (quartz.airtouch.com [151.144.253.22]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA16110 for ; Fri, 19 Feb 1999 13:04:01 -0500 (EST) From: Charles.Lo@Notes.airtouch.com Received: from Notes.airtouch.com (ath-irv-gwy3.it.cl.airtouch.com [153.114.106.136]) by quartz.airtouch.com (8.8.8+Sun/8.8.8) with SMTP id KAA19462 for ; Fri, 19 Feb 1999 10:06:29 -0800 (PST) Received: by Notes.airtouch.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 8825671D.00635172 ; Fri, 19 Feb 1999 10:04:49 -0800 X-Lotus-FromDomain: AIRTOUCH To: aaa-wg@merit.edu Message-ID: <8825671D.00634FC7.00@Notes.airtouch.com> Date: Fri, 19 Feb 1999 10:06:28 -0800 Subject: meeting schedule in Minneapolis Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-bof@merit.edu Precedence: bulk Brian, ASAP, could you post the meeting schedule for the AAA WG at the Minneaspolis IETF? Thanks, Charles Lo ========= AirTouch Communications 925-210-3460 charles.lo@airtouch.com From owner-aaa-wg@merit.edu Fri Feb 19 14:33:30 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id OAA20326 for ; Fri, 19 Feb 1999 14:33:29 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id OAA18050 for aaa-wg-outgoing; Fri, 19 Feb 1999 14:33:05 -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 OAA18042 for ; Fri, 19 Feb 1999 14:32:59 -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 LAA20052; Fri, 19 Feb 1999 11:32:48 -0800 (PST) Message-Id: <3.0.6.32.19990219112928.0091e430@158.222.8.12> X-Sender: brian@158.222.8.12 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 19 Feb 1999 11:29:28 -0800 To: Patrice Calhoun From: Brian Lloyd Subject: Re: current draft charter Cc: aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <3.0.6.32.19990218130910.00944af0@158.222.8.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 09:25 AM 2/19/99 +0100, Patrice Calhoun wrote: >> These include at least IP >> Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. >> By creating a general base Protocol, the amount of work to create a >> specific AAA protocols will be reduced. > >I would really like you to include Mobile IP in the charter. There is a >significant amount of work being done in MIP to tie it in with the AAA work. It wasn't an attempt to be exhaustive. >> >> Document Schedule >> >> >Sounds agressive, but I like it. It sounds like we will need interim meetings >and conference calls to get the work done on time. I already plan to do that. 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-wg@merit.edu Fri Feb 19 19:18:14 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id TAA23685 for ; Fri, 19 Feb 1999 19:18:14 -0500 (EST) Received: by merit.edu (8.9.1a/8.9.1) id TAA23494 for aaa-wg-outgoing; Fri, 19 Feb 1999 19:17: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 TAA23489 for ; Fri, 19 Feb 1999 19:17:35 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J7XT7G95468WW5DH@shoe.reston.mci.net> for aaa-wg@merit.edu; Fri, 19 Feb 1999 19:17:03 EST Date: Fri, 19 Feb 1999 16:16:54 -0800 From: Paul Krumviede Subject: Re: current draft charter To: Kung Loh Cc: aaa-wg@merit.edu Reply-to: paul@mci.net Message-id: <36CDFEF6.1EED4644@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: <3.0.6.32.19990218163557.009418a0@158.222.8.12> <36CCBA4C.632FA0C2@mci.net> <36CD3290.BEBD775@nt.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Which working group are you talking about here? My reference was to Vern's notes on the RUTS BOF, which has a potentially wider scope than the AAA work. I'm not sure I want to make us mutual hostages of each other's progress... -paul Kung Loh wrote: > > Pual brought up a good point which I fully support: the working group should > to "fully explore the requirements" of AAA applications, the informaiton > elements associated with the applications/requirements, and the requirements > of communications before start to design transport mechanisms. > > Kung > > Paul Krumviede wrote: > > > > Brian Lloyd wrote: > > > > > > At 02:08 PM 2/18/99 -0800, Durham, David wrote: > > > > > >> The working group will target the use of TCP and defined procedures on > > > >> UDP. > > > >> When RUTS produces a result, the working group will consider changing from > > > >> TCP and UDP to that protocol. > > > > [Durham, David] What does "defined procedures on UDP" mean? > > > > RUTS is addressing TCP issues, right? > > > > > > Fred wanted that grafted on. It seems reasonable to include it. > > > > I think it was Fred who pointed out in Orlando that UDP isn't a > > transport, it is simply a labeling or muxing mechanism. "Defined > > procedures on UDP" is meant to capture the notion that a little bit > > more than "just use UDP on port XYZ" is necessary. > > > > Vern's notes from the RUTS BOF state that the intent is to more > > fully explore the requirements, not to design transport protocols > > and/or TCP tweaks. So I don't think we can really say what may > > come out of the effort; if the requirements are sufficiently > > diverse it may not be practical to come up with a common > > solution. > > > > -paul From owner-aaa-wg@merit.edu Thu Feb 25 11:55:47 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA07598 for ; Thu, 25 Feb 1999 11:55:47 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA08106 for aaa-wg-outgoing; Thu, 25 Feb 1999 11:52:36 -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 LAA08100 for ; Thu, 25 Feb 1999 11:52:30 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA16743; Thu, 25 Feb 1999 08:51:23 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka.Eng.Sun.COM [129.146.103.37]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id IAA17892; Thu, 25 Feb 1999 08:51:19 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA19383; Thu, 25 Feb 1999 08:50:59 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902251650.IAA19383@hsmpka.eng.sun.com> Date: Thu, 25 Feb 1999 08:45:13 -0800 To: Cc: Reply-To: Subject: AAA Requirements Draft X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------919961113" Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------919961113 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Please post the attached Internet Draft. Thanks, PatC --------------919961113 Content-type: text/plain; name="draft-ietf-aaa-requirements-00.txt" Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="draft-ietf-aaa-requirements-00.txt" CgoKCgoKSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBQYXQgUi4gQ2FsaG91bgpDYXRlZ29yeTogU3RhbmRhcmRzIFRyYWNrICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQ2hhcmxlcyBFLiBQZXJraW5zClRpdGxlOiBkcmFmdC1pZXRm LWFhYS1yZXF1aXJlbWVudHMtMDAudHh0ICAgICAgICAgICBTdW4gTWljcm9zeXN0ZW1zLCBJbmMu CkRhdGU6IEZlYnJ1YXJ5IDE5OTkKCgoKICAgICAgIEF1dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0 aW9uIGFuZCBBY2NvdW50aW5nIFJlcXVpcmVtZW50cwoKCgpTdGF0dXMgb2YgdGhpcyBNZW1vCgog ICBUaGlzIGRvY3VtZW50IGlzIGEgc3VibWlzc2lvbiBieSB0aGUgQUFBIFdvcmtpbmcgR3JvdXAg b2YgdGhlCiAgIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLiAgQ29tbWVu dHMgc2hvdWxkIGJlIHN1Ym1pdHRlZAogICB0byB0aGUgYWFhLXdnQG1lcml0LmVkdSBtYWlsaW5n IGxpc3QuCgogICBEaXN0cmlidXRpb24gb2YgdGhpcyBtZW1vIGlzIHVubGltaXRlZC4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aAogICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcKICAgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdp bmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLAogICBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQ6CgogICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQKCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQ6CgogICAgICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLgoKCkFic3RyYWN0CgogICBUaGUgQXV0aGVudGljYXRpb24sIEF1dGhv cml6YXRpb24gYW5kIEFjY291bnRpbmcgKEFBQSkgV0cgaXMKICAgY3VycmVudGx5IGNvbGxlY3Rp bmcgcmVxdWlyZW1lbnRzIHRoYXQgd2lsbCBiZSB1c2VkIHRvIGRlZmluZSBhIEFBQQogICBmcmFt ZXdvcmsgYW5kIGJhc2UgcHJvdG9jb2wuIFRoaXMgZG9jdW1lbnQgY29udGFpbnMgYSBzZXQgb2YK ICAgcmVxdWlyZW1lbnRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgYnkgdGhlIFdHLgoKCgoK CgpDYWxob3VuLCBQZXJraW5zICAgICAgICAgIGV4cGlyZXMgQXVndXN0IDE5OTkgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0KCgoKCgpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkKCgoxLjAgUmVxdWlyZW1lbnRz CgogICBXaXRoaW4gdGhlIEludGVybmV0LCBhIGN1c3RvbWVyIGJlbG9uZ2luZyB0byBvbmUgYWRt aW5pc3RyYXRpdmUKICAgZG9tYWluIChjYWxsZWQgdGhlIGhvbWUgZG9tYWluKSBvZnRlbiBuZWVk cyB0byB1c2UgcmVzb3VyY2VzIHByb3ZpZGVkCiAgIGJ5IGFub3RoZXIgYWRtaW5pc3RyYXRpdmUg ZG9tYWluIChjYWxsZWQgdGhlIGZvcmVpZ24gZG9tYWluKS4gIEFuCiAgIGFnZW50IGluIHRoZSBm b3JlaWduIGRvbWFpbiB0aGF0IGF0dGVuZGluZyB0byB0aGUgY3VzdG9tZXIncyByZXF1ZXN0CiAg IChjYWxsIHRoZSBhZ2VudCB0aGUgImF0dGVuZGFudCIpIGlzIGxpa2VseSB0byByZXF1aXJlIHRo YXQgdGhlCiAgIGN1c3RvbWVyIHByb3ZpZGUgc29tZSBjcmVkZW50aWFscyB0aGF0IGNhbiBiZSBh dXRoZW50aWNhdGVkIGJlZm9yZQogICBhY2Nlc3MgdG8gdGhlIHJlc291cmNlcyBpcyBwZXJtaXR0 ZWQuCgogICBUaGUgYXR0ZW5kYW50IG1heSBub3QgaGF2ZSBkaXJlY3QgYWNjZXNzIHRvIHRoZSBk YXRhIHRoYXQgaXMgbmVlZGVkCiAgIHRvIGNvbXBsZXRlIHRoZSB0cmFuc2FjdGlvbi4gIEluc3Rl YWQsIHRoZSBhdHRlbmRhbnQgaXMgZXhwZWN0ZWQgdG8KICAgY29uc3VsdCBhIGxvY2FsIGF1dGhv cml0eSBpbiB0aGUgc2FtZSBmb3JlaWduIGRvbWFpbiBpbiBvcmRlciB0bwogICBvYnRhaW4gcHJv b2YgdGhhdCB0aGUgY3VzdG9tZXIgaGFzIGFjY2VwdGFibGUgY3JlZGVudGlhbHMuICBTaW5jZSB0 aGUKICAgYXR0ZW5kYW50IGFuZCB0aGUgbG9jYWwgYXV0aG9yaXR5IGFyZSBwYXJ0IG9mIHRoZSBz YW1lIGFkbWluaXN0cmF0aXZlCiAgIGRvbWFpbiwgdGhleSBoYXZlIHNlY3VyaXR5IHJlbGF0aW9u c2hpcHMgdGhhdCBlbmFibGUgdGhlbSB0byBzZWN1cmVseQogICB0cmFuc2FjdCBpbmZvcm1hdGlv biBsb2NhbGx5LgoKICAgVGhlIGxvY2FsIGF1dGhvcml0eSBpdHNlbGYgbWF5IG5vdCBoYXZlIGVu b3VnaCBpbmZvcm1hdGlvbiB0byB2ZXJpZnkKICAgdGhlIGNyZWRlbnRpYWxzIG9mIHRoZSBjdXN0 b21lciwgYnV0IChhcyBvcHBvc2VkIHRvIHRoZSBhZ2VudAogICBhdHRlbmRpbmcgdGhlIGN1c3Rv bWVyKSBpdCBpcyBleHBlY3RlZCB0byBiZSBjb25maWd1cmVkIHRvIGJlIGFibGUgdG8KICAgbmVn b3RpYXRlIHRoZSB2ZXJpZmljYXRpb24gb2YgY3VzdG9tZXIgY3JlZGVudGlhbHMgd2l0aCBleHRl cm5hbAogICBhdXRob3JpdGllcy4gIFRoZSBsb2NhbCBhdXRob3JpdHkgYW5kIHRoZSBleHRlcm5h bCBhdXRob3JpdHkgYXJlCiAgIGNvbmZpZ3VyZWQgd2l0aCBzdWZmaWNpZW50IHNlY3VyaXR5IHJl bGF0aW9uc2hpcHMgYW5kIGFjY2VzcyBjb250cm9sCiAgIHNvIHRoYXQgdGhleSAoYW5kIHBvc3Np Ymx5IG5vIG90aGVyIGFnZW50cykgY2FuIG5lZ290aWF0ZSB0aGUKICAgYXV0aG9yaXphdGlvbiB0 aGF0IGVuYWJsZXMgdGhlIGN1c3RvbWVyIHRvIGhhdmUgYWNjZXNzIHRvIHRoZQogICByZXF1ZXN0 ZWQgcmVzb3VyY2VzLiAgSW4gbWFueSBjYXNlcywgdGhpcyBhdXRob3JpemF0aW9uIGRlcGVuZHMg dXBvbgogICBzZWN1cmUgYXV0aGVudGljYXRpb24gb2YgdGhlIGN1c3RvbWVyJ3MgY3JlZGVudGlh bHMuCgogICBPbmNlIHRoZSBhdXRob3JpemF0aW9uIGhhcyBiZWVuIG9idGFpbmVkIGJ5IHRoZSBs b2NhbCBhdXRob3JpdHksIGFuZAogICB0aGUgYXV0aG9yaXR5IGhhcyBub3RpZmllZCB0aGUgYXR0 ZW5kYW50IGFib3V0IHRoZSBzdWNjZXNzZnVsCiAgIG5lZ290aWF0aW9uLCB0aGUgYXR0ZW5kYW50 IGNhbiBwcm92aWRlIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2VzIHRvIHRoZQogICBjdXN0b21lci4K CiAgIEFzIGFuIGV4YW1wbGUgaW4gdG9kYXkncyBJbnRlcm5ldCwgd2UgY2FuIGNpdGUgdGhlIGRl cGxveW1lbnQgb2YKICAgUkFESVVTIHRvIGFsbG93IG1vYmlsZSBjb21wdXRlciBjdXN0b21lcnMg dG8gaGF2ZSBhY2Nlc3MgdG8gdGhlCiAgIEludGVybmV0IGJ5IHdheSBvZiBhIGxvY2FsIElTUC4g IFRoZSBJU1Agd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlCiAgIG1vYmlsZSBjdXN0b21lciBj YW4gcGF5IGZvciB0aGUgY29ubmVjdGlvbi4gIE9uY2UgdGhlIGN1c3RvbWVyIGhhcwogICBwcm92 aWRlZCBjcmVkZW50aWFscyAoZm9yIGluc3RhbmNlLCBpZGVudGlmaWNhdGlvbiBhbmQgYW4gdW5m b3JnZWFibGUKICAgc2lnbmF0dXJlKSwgdGhlIElTUCBjaGVja3Mgd2l0aCB0aGUgY3VzdG9tZXIn cyBob21lIGF1dGhvcml0eSB0bwogICB2ZXJpZnkgdGhlIHNpZ25hdHVyZSwgYW5kIHRvIG9idGFp biBhc3N1cmFuY2UgdGhhdCB0aGUgY3VzdG9tZXIgd2lsbAogICBwYXkgZm9yIHRoZSBjb25uZWN0 aW9uLiAgSGVyZSwgdGhlIGF0dGVuZGFudCBmdW5jdGlvbiBjYW4gYmUgY2FycmllZAogICBvdXQg YnkgdGhlIE5BUywgYW5kIHRoZSBsb2NhbCBhbmQgaG9tZSBhdXRob3JpdGllcyBhcmUgZG9uZSBi eSBSQURJVVMKICAgc2VydmVycy4KCgoKCgoKCkNhbGhvdW4sIFBlcmtpbnMgICAgICAgICAgZXhw aXJlcyBBdWd1c3QgMTk5OSAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoKCgoKCklOVEVSTkVU IERSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVh cnkgMTk5OQoKCiAgICAgRmlndXJlIDE6CiAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0r CiAgICAgKy0tLS0tLSsgICB8ICAgKy0tLS0tLSsgICB8ICAgICAgIEMgICAgPSAgY3VzdG9tZXIK ICAgICB8ICAgICAgfCAgIHwgICB8ICAgICAgfCAgIHwgICAgICAgQSAgICA9ICBhdHRlbmRhbnQK ICAgICB8ICAgQyAgfC0gLXwtIC18ICAgQSAgfCAgIHwgICAgICAgQUFBTCA9ICBsb2NhbCBhdXRo b3JpdHkKICAgICB8ICAgICAgfCAgIHwgICB8ICAgICAgfCAgIHwgICAgICAgQUFBSCA9ICBob21l IGF1dGhvcml0eQogICAgICstLS0tLS0rICAgfCAgICstLS0rLS0rICAgfAogICAgICAgICAgICAg ICAgfCAgICAgICB8ICAgICAgfCAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAg ICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgIHwgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgfCAgICstLS0rLS0rICAgfCAgICAg ICAgICAgfCAgICstLS0tLS0rICAgICAgICAgICB8CiAgICAgICAgICAgICAgICB8ICAgfCAgICAg IHwgICB8ICAgICAgICAgICB8ICAgfCAgICAgIHwgICAgICAgICAgIHwKICAgICAgICAgICAgICAg IHwgICB8IEFBQUwgfCAgIHwgICAgICAgICAgIHwgICB8IEFBQUggfCAgICAgICAgICAgfAogICAg ICAgICAgICAgICAgfCAgIHwgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICB8ICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICB8ICAgKy0tLS0tLSsgICB8ICAgICAgICAgICB8ICAgKy0t LS0tLSsgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAg IExvY2FsIERvbWFpbiAgICAgICAgICAgICAgICAgIEhvbWUgRG9tYWluCgogICBJbiB0aGUgcGlj dHVyZSwgdGhlcmUgd291bGQgYmUgbWFueSBhdHRlbmRhbnRzIGZvciBlYWNoIEFBQUwsIGFuZAog ICB0aGVyZSB3b3VsZCBiZSBtYW55IGN1c3RvbWVycyBmcm9tIG1hbnkgZGlmZmVyZW50IEhvbWUg RG9tYWlucywgZWFjaAogICBIb21lIERvbWFpbiBwcm92aWRpbmcgYSBBQUFIIHRoYXQgY2FuIGNo ZWNrIGNyZWRlbnRpYWxzIGZyb20KICAgY3VzdG9tZXJzIGFkbWluaXN0ZXJlZCBieSB0aGF0IEhv bWUgRG9tYWluLgoKICAgRnJvbSB0aGUgZGVzY3JpcHRpb24gYW5kIGV4YW1wbGUgYWJvdmUsIHdl IGNhbiBpZGVudGlmeSBzZXZlcmFsCiAgIHJlcXVpcmVtZW50cy4KCiAgICAgIC0gVGhlIGxvY2Fs IGF0dGVuZGFudHMgYW5kIHRoZSBsb2NhbCBhdXRob3JpdHkgaGF2ZSB0byBzaGFyZQogICAgICAg IHNlY3VyaXR5IHJlbGF0aW9uc2hpcHMKCiAgICAgIC0gVGhlIGxvY2FsIGF1dGhvcml0eSBoYXMg dG8gc2hhcmUgc2VjdXJpdHkgcmVsYXRpb25zaGlwcyB3aXRoCiAgICAgICAgZXh0ZXJuYWwgYXV0 aG9yaXRpZXMgdGhhdCBhcmUgYWJsZSB0byBjaGVjayBjdXN0b21lciBjcmVkZW50aWFscwoKICAg ICAgLSBUaGUgYXR0ZW5kYW50IGhhcyB0byBrZWVwIHN0YXRlIGZvciBwZW5kaW5nIGN1c3RvbWVy IHJlcXVlc3RzCiAgICAgICAgd2hpbGUgdGhlIGxvY2FsIGF1dGhvcml0eSBjb250YWN0cyB0aGUg YXBwcm9wcmlhdGUgZXh0ZXJuYWwKICAgICAgICBhdXRob3JpdHkKCiAgICAgIC0gVGhlcmUgYXJl IHNjZW5hcmlvcyBpbiB3aGljaCBhbiBhdHRlbmRhbnQgd2lsbCBoYXZlIHRvIG1hbmFnZQogICAg ICAgIHJlcXVlc3RzIGZvciB2ZXJ5IG1hbnkgY3VzdG9tZXJzIGF0IHRoZSBzYW1lIHRpbWUuCgog ICAgICAtIFRoZSBhdHRlbmRhbnQgZXF1aXBtZW50IHNob3VsZCBiZSBhcyBpbmV4cGVuc2l2ZSBh cyBwb3NzaWJsZSwKICAgICAgICBzaW5jZSBpdCB3aWxsIGJlIHJlcGxpY2F0ZWQgYXMgbWFueSB0 aW1lcyBhcyBwb3NzaWJsZSB0byBoYW5kbGUKICAgICAgICBhcyBtYW55IGN1c3RvbWVycyBhcyBw b3NzaWJsZS4KCiAgICAgIC0gU2luY2UgdGhlIGN1c3RvbWVyIGlzIG5vdCBpbiBkaXJlY3QgY29u dGFjdCB3aXRoIHRoZSBleHRlcm5hbAogICAgICAgIGF1dGhvcml0eSB0aGF0IGlzIHBlcmZvcm1p bmcgdGhlIGF1dGhvcml6YXRpb24sIHRoZSBjdXN0b21lciBoYXMKICAgICAgICB0byBwcm92aWRl IHVuZm9yZ2VhYmxlIGNyZWRlbnRpYWxzIHRoYXQgY2FuIGJlIGNoZWNrZWQgYnkgdGhlCiAgICAg ICAgdGhlIGV4dGVybmFsIGF1dGhvcml0eS4gIEZ1cnRoZXJtb3JlLCB0byBzYXRpc2Z5IHRoZSBy ZXF1aXJlbWVudAoKCgpDYWxob3VuLCBQZXJraW5zICAgICAgICAgIGV4cGlyZXMgQXVndXN0IDE5 OTkgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KCgoKCgpJTlRFUk5FVCBEUkFGVCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkKCgogICAg ICAgIHRoYXQgdGhlIGNyZWRlbnRpYWxzIHJlbWFpbiB1bmZvcmdlYWJsZSwgdGhlIGF0dGVuZGFu dCBhbmQgdGhlCiAgICAgICAgbG9jYWwgYXV0aG9yaXR5IG11c3Qgbm90IGJlIGFibGUgdG8gbGVh cm4gYW55IHNlY3JldCBpbmZvcm1hdGlvbgogICAgICAgIHRoYXQgaXMgdXNlZCB0byBjcmVhdGUg dGhlIHVuZm9yZ2VhYmxlIGNyZWRlbnRpYWxzLgoKICAgRnJvbSB0aGlzIGxhc3QgcmVxdWlyZW1l bnQsIHdlIGNhbiBkZXJpdmUgdGhlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnQKICAgdGhhdCB0aGUg Y3VzdG9tZXIgaGFzIHRvIHNoYXJlIGEgc2VjdXJpdHkgcmVsYXRpb25zaGlwIHdpdGggdGhlCiAg IGV4dGVybmFsIGF1dGhvcml0eSBpbiB0aGUgSG9tZSBEb21haW4uICBPdGhlcndpc2UsIGl0IGlz IHRlY2huaWNhbGx5CiAgIGluZmVhc2libGUgKGdpdmVuIHRoZSBpbXBsaWVkIG5ldHdvcmsgdG9w b2xvZ3kpIGZvciB0aGUgY3VzdG9tZXIgdG8KICAgcHJvZHVjZSB1bmZvcmdlYWJsZSBzaWduYXR1 cmVzLgoKCjIuMCBCcm9rZXIgUmVxdWlyZW1lbnRzCgogICBUaGUgcGljdHVyZSBpbiBGaWd1cmUg MSBzaG93cyBhIGNvbmZpZ3VyYXRpb24gaW4gd2hpY2ggdGhlIGxvY2FsIGFuZAogICB0aGUgaG9t ZSBhdXRob3JpdHkgaGF2ZSB0byBzaGFyZSB0cnVzdC4gIFRoaXMgY29uZmlndXJhdGlvbiBjYXVz ZXMgYQogICBxdWFkcmF0aWMgZ3Jvd3RoIGluIHRoZSBudW1iZXIgb2YgdHJ1c3QgcmVsYXRpb25z aGlwcyBhcyB0aGUgbnVtYmVyCiAgIG9mIEFBQSBhdXRob3JpdGllcyAoQUFBTCBhbmQgQUFBSCkg aW5jcmVhc2VzLiAgVGhpcyBoYXMgYmVlbgogICBpZGVudGlmaWVkIGFzIGEgcHJvYmxlbSBieSB0 aGUgcm9hbW9wcyB3b3JraW5nIGdyb3VwLCBhbmQgYW55IEFBQQogICBzb2x1dGlvbiBoYXMgdG8g b2ZmZXIgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0uICBUaGVyZSBhcmUgYWxyZWFkeQogICBl bnRpdGllcyBrbm93biBhcyAiYnJva2VycyIgdGhhdCBhbGxvdyBsb2NhbCBhdXRob3JpdGllcyB0 byByZWR1Y2UKICAgdGhlIG51bWJlciBvZiB0cnVzdCByZWxhdGlvbnNoaXBzIHRoYXQgbmVlZCB0 byBiZSBtYWludGFpbmVkLgoKICAgICBGaWd1cmUgMjoKICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLSsKICAgICArLS0tLS0tKyAgIHwgICArLS0tLS0tKyAgIHwgICAgICAgQyAgICA9ICBj dXN0b21lcgogICAgIHwgICAgICB8ICAgfCAgIHwgICAgICB8ICAgfCAgICAgICBBICAgID0gIGF0 dGVuZGFudAogICAgIHwgICBDICB8LSAtfC0gLXwgICBBICB8ICAgfCAgICAgICBBQUFMID0gIGxv Y2FsIGF1dGhvcml0eQogICAgIHwgICAgICB8ICAgfCAgIHwgICAgICB8ICAgfCAgICAgICBBQUFI ID0gIGhvbWUgYXV0aG9yaXR5CiAgICAgKy0tLS0tLSsgICB8ICAgKy0tLSstLSsgICB8ICAgICAg IEFBQUIgPSAgYnJva2VyIGF1dGhvcml0eQogICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAg fCAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgICAg fCAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgfCAgICstLS0rLS0rICAgfCAgICstLS0tLS0r ICAgIHwgICArLS0tLS0tKyAgICAgICAgICAgfAogICAgICAgICAgICAgICAgfCAgIHwgICAgICB8 ICAgfCAgIHwgICAgICB8ICAgIHwgICB8ICAgICAgfCAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgfCAgIHwgQUFBTCArLS0tLS0tLSsgQUFBQiArLS0tLS0tLS0rIEFBQUggfCAgICAgICAgICAg fAogICAgICAgICAgICAgICAgfCAgIHwgICAgICB8ICAgfCAgIHwgICAgICB8ICAgIHwgICB8ICAg ICAgfCAgICAgICAgICAgfAogICAgICAgICAgICAgICAgfCAgICstLS0tLS0rICAgfCAgICstLS0t LS0rICAgIHwgICArLS0tLS0tKyAgICAgICAgICAgfAogICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tKyAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tKwogICAgICAgICAgICAgICAgICBMb2NhbCBEb21haW4gICAgICAgICAgICAgICAgICAgICBI b21lIERvbWFpbgoKICAgVGhlIEFBQUIgaW4gdGhlIGFib3ZlIHBpY3R1cmUgaXMgdGhlIGJyb2tl cidzIGF1dGhvcml0eSBzZXJ2ZXIuICBUaGUKICAgYnJva2VyIGFjdHMgYXMgYSBzZXR0bGVtZW50 IGFnZW50LCBwcm92aWRpbmcgc2VjdXJpdHkgYW5kIGEgY2VudHJhbAogICBwb2ludCBvZiBjb250 YWN0IGZvciBtYW55IHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBlbnRlcnByaXNlcy4KCiAgIFRoZSBB QUFCIGVuYWJsZXMgdGhlIGxvY2FsIGFuZCBob21lIGRvbWFpbnMgdG8gY29vcGVyYXRlIHdpdGhv dXQKICAgcmVxdWlyaW5nIGVhY2ggbmV0d29yayB0byBoYXZlIGEgZGlyZWN0IHJlbGF0aW9uc2hp cCB3aXRoIGFsbCBvdGhlcgogICBuZXR3b3Jrcy4gIFRodXMsIGJyb2tlcnMgb2ZmZXIgdGhlIG5l ZWRlZCBzY2FsYWJpbGl0eSBmb3IgbWFuYWdpbmcKCgoKQ2FsaG91biwgUGVya2lucyAgICAgICAg ICBleHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDRdCgoKCgoKSU5U RVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG ZWJydWFyeSAxOTk5CgoKICAgdHJ1c3QgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIG90aGVyd2lzZSBp bmRlcGVuZGVudCBuZXR3b3JrIGRvbWFpbnMuCiAgIFVzZSBvZiB0aGUgYnJva2VyIGRvZXMgbm90 IHByZWNsdWRlIG1hbmFnaW5nIHNlcGFyYXRlIHRydXN0CiAgIHJlbGF0aW9uc2hpcHMgYmV0d2Vl biBkb21haW5zLCBidXQgaXQgZG9lcyBvZmZlciBhbiBhbHRlcm5hdGl2ZSB0bwogICBkb2luZyBz by4KCiAgIFRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnRzIGNvbWUgbW9zdGx5IGZyb20gWzFdLCB3 aGljaCBkaXNjdXNzZXMgdXNlCiAgIG9mIGJyb2tlcnMgaW4gdGhlIHBhcnRpY3VsYXIgY2FzZSBv ZiBhdXRob3JpemluZyByb2FtaW5nIGRpYWwtdXAKICAgdXNlcnMuCgogICAgICAtIEFsbG93aW5n IG1hbmFnZW1lbnQgb2YgdHJ1c3Qgd2l0aCBleHRlcm5hbCBkb21haW5zIGJ5IHdheSBvZgogICAg ICAgIGJyb2tlcmVkIEFBQS4KCiAgICAgIC0gQ2FwYWJpbGl0aWVzIGFkanVzdG1lbnQuIEVhY2gg bWFudWZhY3R1cmVyJ3MgZXF1aXBtZW50IGhhcwogICAgICAgIGRpZmZlcmVudCBjYXBhYmlsaXRp ZXMuICBUaHVzLCB0aGUgQUFBTCBtYXkgaGF2ZSB0byBtb2RpZnkgdGhlCiAgICAgICAgYXV0aG9y aXphdGlvbiBpbmZvcm1hdGlvbiBmcm9tIHRoZSBBQUFILgoKICAgICAgLSBBY2NvdW50aW5nIHJl bGlhYmlsaXR5LiBBY2NvdW50aW5nIGRhdGEgdGhhdCB0cmF2ZXJzZXMgdGhlCiAgICAgICAgSW50 ZXJuZXQgbWF5IHN1ZmZlciBzdWJzdGFudGlhbCBwYWNrZXQgbG9zcy4gIFNpbmNlIFRDUCBtYXkg YmUKICAgICAgICB1bnN1aXRhYmxlIGluIGNhc2VzIHdoZXJlIHRoZSBhdHRlbmRhbnQgaGFzIHRv IG1hbmFnZSBsYXJnZQogICAgICAgIG51bWJlcnMgb2YgaW5jb21pbmcgcmVxdWVzdHMsIHNwZWNp YWwgcmV0cmFuc21pc3Npb24gYWxnb3JpdGhtcwogICAgICAgIG1heSBiZSBuZWVkZWQuICBTaW5j ZSBhY2NvdW50aW5nIHBhY2tldHMgbWF5IHRyYXZlcnNlIG9uZSBvcgogICAgICAgIG1vcmUgaW50 ZXJtZWRpYXRlIGF1dGhvcml6YXRpb24gcG9pbnRzIChlLmcuLCBicm9rZXJzKSwKICAgICAgICBl eHBlcmllbmNlIGluZGljYXRlcyB0aGUgbmVlZCBmb3IgcmV0cmFuc21pc3Npb24gZnJvbQogICAg ICAgIGludGVybWVkaWF0ZSBwb2ludHMgdG8gYXZvaWQgbG9uZyBlbmQtdG8tZW5kIGRlbGF5cy4K CiAgICAgIC0gRW5kIHRvIEVuZCBzZWN1cml0eS4gVGhlIExvY2FsIERvbWFpbiBhbmQgSG9tZSBE b21haW4gbXVzdCBiZQogICAgICAgIGFibGUgdG8gdmVyaWZ5IHNpZ25hdHVyZXMgd2l0aGluIHRo ZSBtZXNzYWdlLCBldmVuIHRob3VnaCB0aGUKICAgICAgICBtZXNzYWdlIGlzIHBhc3NlZCB0aHJv dWdoIGFuIGludGVybWVkaWF0ZSBhdXRob3JpdHkgc2VydmVyLiBUaGlzCiAgICAgICAgaXMgbmVj ZXNzYXJ5IGJlY2F1c2UgdGhlIGZvbGxvd2luZyBhdHRhY2tzIHdlcmUgaWRlbnRpZmllZCB3aGVu CiAgICAgICAgdGhpcyBvcGVyYXRpb24gaXMgZG9uZSB1c2luZyB0aGUgUkFESVVTIHByb3RvY29s IChzZWUgWzFdIGZvcgogICAgICAgIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIGluZGl2aWR1YWwg YXR0YWNrcyk6CiAgICAgICAgICAgICsgTWVzc2FnZSBlZGl0aW5nCiAgICAgICAgICAgICsgQXR0 cmlidXRlIGVkaXRpbmcKICAgICAgICAgICAgKyBUaGVmdCBvZiBwYXNzd29yZHMKICAgICAgICAg ICAgKyBUaGVmdCBhbmQgbW9kaWZpY2F0aW9uIG9mIGFjY291bnRpbmcgZGF0YQogICAgICAgICAg ICArIFJlcGxheSBhdHRhY2tzCiAgICAgICAgICAgICsgQ29ubmVjdGlvbiBoaWphY2tpbmcKICAg ICAgICAgICAgKyBGcmF1ZHVsZW50IGFjY291bnRpbmcKCgo1LjAgIFJlZmVyZW5jZXMKCiAgIFsx XSBBYm9iYSwgVm9sbGJyZWNodCwgIlByb3h5IENoYWluaW5nIGFuZCBQb2xpY3kgSW1wbGVtZW50 YXRpb24gaW4KICAgICAgIFJvYW1pbmciLCBkcmFmdC1pZXRmLXJvYW1vcHMtYXV0aC0xMC50eHQs IFdvcmsgaW4gUHJvZ3Jlc3MsCiAgICAgICBGZWJydWFyeSAxOTk5LgogICBbMl0gQWJvYmEsIEJl YWRsZXMgIlRoZSBOZXR3b3JrIEFjY2VzcyBJZGVudGlmaWVyLiIgUkZDIDI0ODYuCiAgICAgICBK YW51YXJ5IDE5OTkuCiAgIFszXSBBYm9iYSwgWm9ybiwgIkNyaXRlcmlhIGZvciBFdmFsdWF0aW5n IFJvYW1pbmcgUHJvdG9jb2xzIiwKCgoKQ2FsaG91biwgUGVya2lucyAgICAgICAgICBleHBpcmVz IEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgoKCgoKSU5URVJORVQgRFJB RlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAx OTk5CgoKICAgICAgIFJGQyAyNDc3LCBKYW51YXJ5IDE5OTkuCgozLjAgIEF1dGhvcnMnIEFkZHJl c3NlcwoKICAgUXVlc3Rpb25zIGFib3V0IHRoaXMgbWVtbyBjYW4gYmUgZGlyZWN0ZWQgdG86Cgog ICAgICBQYXQgUi4gQ2FsaG91bgogICAgICBOZXR3b3JrIGFuZCBTZWN1cml0eSBSZXNlYXJjaCBD ZW50ZXIsIFN1biBMYWJzCiAgICAgIFN1biBNaWNyb3N5c3RlbXMsIEluYy4KICAgICAgMTUgTmV0 d29yayBDaXJjbGUKICAgICAgTWVubG8gUGFyaywgQ2FsaWZvcm5pYSwgOTQwMjUKICAgICAgVVNB CgogICAgICAgUGhvbmU6ICAxLTY1MC03ODYtNzczMwogICAgICAgICBGYXg6ICAxLTY1MC03ODYt NjQ0NQogICAgICBFLW1haWw6ICBwY2FsaG91bkBlbmcuc3VuLmNvbQoKCiAgICAgIENoYXJsZXMg RS4gUGVya2lucwogICAgICBOZXR3b3JrIGFuZCBTZWN1cml0eSBSZXNlYXJjaCBDZW50ZXIsIFN1 biBMYWJzCiAgICAgIFN1biBNaWNyb3N5c3RlbXMsIEluYy4KICAgICAgMTUgTmV0d29yayBDaXJj bGUKICAgICAgTWVubG8gUGFyaywgQ2FsaWZvcm5pYSwgOTQwMjUKICAgICAgVVNBCgogICAgICAg UGhvbmU6ICAxLTY1MC03ODYtNjQ2NAogICAgICAgICBGYXg6ICAxLTY1MC03ODYtNjQ0NQogICAg ICBFLW1haWw6ICBjaGFybGVzLnBlcmtpbnNAZW5nLnN1bi5jb20KCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgpDYWxob3VuLCBQZXJraW5zICAgICAgICAgIGV4cGlyZXMgQXVndXN0IDE5OTkgICAgICAg ICAgICAgICAgICAgW1BhZ2UgNl0KCgo= --------------919961113-- From owner-aaa-wg@merit.edu Thu Feb 25 16:59:55 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA11125 for ; Thu, 25 Feb 1999 16:59:54 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA15088 for aaa-wg-outgoing; Thu, 25 Feb 1999 16:59:21 -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 QAA15084 for ; Thu, 25 Feb 1999 16:59:16 -0500 (EST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA04086 for ; Thu, 25 Feb 1999 13:58:45 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.103.47]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id NAA01765; Thu, 25 Feb 1999 13:58:43 -0800 (PST) Received: from hsmpka.eng.sun.com by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA20783; Thu, 25 Feb 1999 13:58:21 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902252158.NAA20783@hsmpka.eng.sun.com> Date: Thu, 25 Feb 1999 13:52:26 -0800 To: , Reply-To: Subject: Re: AAA Requirements Draft X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------919979546" Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------919979546 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit All, I was just informed that not everyone uses Unix as its operating system :), so the file I just previously sent did not have any , and made it difficult for some people to read. Here is a non-unix friendly version :) PatC --------------919979546 Content-type: text/plain; name="draft-ietf-aaa-requirements-00.txt" Content-Transfer-Encoding: BASE64 Content-Disposition: attachment; filename="draft-ietf-aaa-requirements-00.txt" DQoNCg0KDQoNCg0KSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBQYXQgUi4gQ2FsaG91bg0KQ2F0ZWdvcnk6IFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoYXJsZXMgRS4gUGVya2lucw0KVGl0bGU6IGRy YWZ0LWlldGYtYWFhLXJlcXVpcmVtZW50cy0wMC50eHQgICAgICAgICAgIFN1biBNaWNyb3N5c3Rl bXMsIEluYy4NCkRhdGU6IEZlYnJ1YXJ5IDE5OTkNCg0KDQoNCiAgICAgICBBdXRoZW50aWNhdGlv biwgQXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGluZyBSZXF1aXJlbWVudHMNCg0KDQoNClN0YXR1 cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBhIHN1Ym1pc3Npb24gYnkgdGhl IEFBQSBXb3JraW5nIEdyb3VwIG9mIHRoZQ0KICAgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBG b3JjZSAoSUVURikuICBDb21tZW50cyBzaG91bGQgYmUgc3VibWl0dGVkDQogICB0byB0aGUgYWFh LXdnQG1lcml0LmVkdSBtYWlsaW5nIGxpc3QuDQoNCiAgIERpc3RyaWJ1dGlvbiBvZiB0aGlzIG1l bW8gaXMgdW5saW1pdGVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92aXNpb25zIG9mIFNl Y3Rpb24gMTAgb2YgUkZDMjAyNi4gIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZw0KICAgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLA0KICAgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91 cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt RHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm b3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAg bWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3Mu Ig0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz ZWQgYXQ6DQoNCiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4 dA0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0Og0KDQogICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0KDQoNCkFic3RyYWN0DQoNCiAgIFRoZSBBdXRoZW50aWNhdGlvbiwgQXV0aG9yaXphdGlvbiBh bmQgQWNjb3VudGluZyAoQUFBKSBXRyBpcw0KICAgY3VycmVudGx5IGNvbGxlY3RpbmcgcmVxdWly ZW1lbnRzIHRoYXQgd2lsbCBiZSB1c2VkIHRvIGRlZmluZSBhIEFBQQ0KICAgZnJhbWV3b3JrIGFu ZCBiYXNlIHByb3RvY29sLiBUaGlzIGRvY3VtZW50IGNvbnRhaW5zIGEgc2V0IG9mDQogICByZXF1 aXJlbWVudHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBieSB0aGUgV0cuDQoNCg0KDQoNCg0K DQpDYWxob3VuLCBQZXJraW5zICAgICAgICAgIGV4cGlyZXMgQXVndXN0IDE5OTkgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0NCg0KDQoNCg0KDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDE5OTkNCg0KDQoxLjAgUmVx dWlyZW1lbnRzDQoNCiAgIFdpdGhpbiB0aGUgSW50ZXJuZXQsIGEgY3VzdG9tZXIgYmVsb25naW5n IHRvIG9uZSBhZG1pbmlzdHJhdGl2ZQ0KICAgZG9tYWluIChjYWxsZWQgdGhlIGhvbWUgZG9tYWlu KSBvZnRlbiBuZWVkcyB0byB1c2UgcmVzb3VyY2VzIHByb3ZpZGVkDQogICBieSBhbm90aGVyIGFk bWluaXN0cmF0aXZlIGRvbWFpbiAoY2FsbGVkIHRoZSBmb3JlaWduIGRvbWFpbikuICBBbg0KICAg YWdlbnQgaW4gdGhlIGZvcmVpZ24gZG9tYWluIHRoYXQgYXR0ZW5kaW5nIHRvIHRoZSBjdXN0b21l cidzIHJlcXVlc3QNCiAgIChjYWxsIHRoZSBhZ2VudCB0aGUgImF0dGVuZGFudCIpIGlzIGxpa2Vs eSB0byByZXF1aXJlIHRoYXQgdGhlDQogICBjdXN0b21lciBwcm92aWRlIHNvbWUgY3JlZGVudGlh bHMgdGhhdCBjYW4gYmUgYXV0aGVudGljYXRlZCBiZWZvcmUNCiAgIGFjY2VzcyB0byB0aGUgcmVz b3VyY2VzIGlzIHBlcm1pdHRlZC4NCg0KICAgVGhlIGF0dGVuZGFudCBtYXkgbm90IGhhdmUgZGly ZWN0IGFjY2VzcyB0byB0aGUgZGF0YSB0aGF0IGlzIG5lZWRlZA0KICAgdG8gY29tcGxldGUgdGhl IHRyYW5zYWN0aW9uLiAgSW5zdGVhZCwgdGhlIGF0dGVuZGFudCBpcyBleHBlY3RlZCB0bw0KICAg Y29uc3VsdCBhIGxvY2FsIGF1dGhvcml0eSBpbiB0aGUgc2FtZSBmb3JlaWduIGRvbWFpbiBpbiBv cmRlciB0bw0KICAgb2J0YWluIHByb29mIHRoYXQgdGhlIGN1c3RvbWVyIGhhcyBhY2NlcHRhYmxl IGNyZWRlbnRpYWxzLiAgU2luY2UgdGhlDQogICBhdHRlbmRhbnQgYW5kIHRoZSBsb2NhbCBhdXRo b3JpdHkgYXJlIHBhcnQgb2YgdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUNCiAgIGRvbWFpbiwgdGhl eSBoYXZlIHNlY3VyaXR5IHJlbGF0aW9uc2hpcHMgdGhhdCBlbmFibGUgdGhlbSB0byBzZWN1cmVs eQ0KICAgdHJhbnNhY3QgaW5mb3JtYXRpb24gbG9jYWxseS4NCg0KICAgVGhlIGxvY2FsIGF1dGhv cml0eSBpdHNlbGYgbWF5IG5vdCBoYXZlIGVub3VnaCBpbmZvcm1hdGlvbiB0byB2ZXJpZnkNCiAg IHRoZSBjcmVkZW50aWFscyBvZiB0aGUgY3VzdG9tZXIsIGJ1dCAoYXMgb3Bwb3NlZCB0byB0aGUg YWdlbnQNCiAgIGF0dGVuZGluZyB0aGUgY3VzdG9tZXIpIGl0IGlzIGV4cGVjdGVkIHRvIGJlIGNv bmZpZ3VyZWQgdG8gYmUgYWJsZSB0bw0KICAgbmVnb3RpYXRlIHRoZSB2ZXJpZmljYXRpb24gb2Yg Y3VzdG9tZXIgY3JlZGVudGlhbHMgd2l0aCBleHRlcm5hbA0KICAgYXV0aG9yaXRpZXMuICBUaGUg bG9jYWwgYXV0aG9yaXR5IGFuZCB0aGUgZXh0ZXJuYWwgYXV0aG9yaXR5IGFyZQ0KICAgY29uZmln dXJlZCB3aXRoIHN1ZmZpY2llbnQgc2VjdXJpdHkgcmVsYXRpb25zaGlwcyBhbmQgYWNjZXNzIGNv bnRyb2wNCiAgIHNvIHRoYXQgdGhleSAoYW5kIHBvc3NpYmx5IG5vIG90aGVyIGFnZW50cykgY2Fu IG5lZ290aWF0ZSB0aGUNCiAgIGF1dGhvcml6YXRpb24gdGhhdCBlbmFibGVzIHRoZSBjdXN0b21l ciB0byBoYXZlIGFjY2VzcyB0byB0aGUNCiAgIHJlcXVlc3RlZCByZXNvdXJjZXMuICBJbiBtYW55 IGNhc2VzLCB0aGlzIGF1dGhvcml6YXRpb24gZGVwZW5kcyB1cG9uDQogICBzZWN1cmUgYXV0aGVu dGljYXRpb24gb2YgdGhlIGN1c3RvbWVyJ3MgY3JlZGVudGlhbHMuDQoNCiAgIE9uY2UgdGhlIGF1 dGhvcml6YXRpb24gaGFzIGJlZW4gb2J0YWluZWQgYnkgdGhlIGxvY2FsIGF1dGhvcml0eSwgYW5k DQogICB0aGUgYXV0aG9yaXR5IGhhcyBub3RpZmllZCB0aGUgYXR0ZW5kYW50IGFib3V0IHRoZSBz dWNjZXNzZnVsDQogICBuZWdvdGlhdGlvbiwgdGhlIGF0dGVuZGFudCBjYW4gcHJvdmlkZSB0aGUg cmVxdWVzdGVkIHJlc291cmNlcyB0byB0aGUNCiAgIGN1c3RvbWVyLg0KDQogICBBcyBhbiBleGFt cGxlIGluIHRvZGF5J3MgSW50ZXJuZXQsIHdlIGNhbiBjaXRlIHRoZSBkZXBsb3ltZW50IG9mDQog ICBSQURJVVMgdG8gYWxsb3cgbW9iaWxlIGNvbXB1dGVyIGN1c3RvbWVycyB0byBoYXZlIGFjY2Vz cyB0byB0aGUNCiAgIEludGVybmV0IGJ5IHdheSBvZiBhIGxvY2FsIElTUC4gIFRoZSBJU1Agd2Fu dHMgdG8gbWFrZSBzdXJlIHRoYXQgdGhlDQogICBtb2JpbGUgY3VzdG9tZXIgY2FuIHBheSBmb3Ig dGhlIGNvbm5lY3Rpb24uICBPbmNlIHRoZSBjdXN0b21lciBoYXMNCiAgIHByb3ZpZGVkIGNyZWRl bnRpYWxzIChmb3IgaW5zdGFuY2UsIGlkZW50aWZpY2F0aW9uIGFuZCBhbiB1bmZvcmdlYWJsZQ0K ICAgc2lnbmF0dXJlKSwgdGhlIElTUCBjaGVja3Mgd2l0aCB0aGUgY3VzdG9tZXIncyBob21lIGF1 dGhvcml0eSB0bw0KICAgdmVyaWZ5IHRoZSBzaWduYXR1cmUsIGFuZCB0byBvYnRhaW4gYXNzdXJh bmNlIHRoYXQgdGhlIGN1c3RvbWVyIHdpbGwNCiAgIHBheSBmb3IgdGhlIGNvbm5lY3Rpb24uICBI ZXJlLCB0aGUgYXR0ZW5kYW50IGZ1bmN0aW9uIGNhbiBiZSBjYXJyaWVkDQogICBvdXQgYnkgdGhl IE5BUywgYW5kIHRoZSBsb2NhbCBhbmQgaG9tZSBhdXRob3JpdGllcyBhcmUgZG9uZSBieSBSQURJ VVMNCiAgIHNlcnZlcnMuDQoNCg0KDQoNCg0KDQoNCkNhbGhvdW4sIFBlcmtpbnMgICAgICAgICAg ZXhwaXJlcyBBdWd1c3QgMTk5OSAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQoNCg0KDQoN CklOVEVSTkVUIERSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRmVicnVhcnkgMTk5OQ0KDQoNCiAgICAgRmlndXJlIDE6DQogICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tKw0KICAgICArLS0tLS0tKyAgIHwgICArLS0tLS0tKyAgIHwgICAgICAgQyAg ICA9ICBjdXN0b21lcg0KICAgICB8ICAgICAgfCAgIHwgICB8ICAgICAgfCAgIHwgICAgICAgQSAg ICA9ICBhdHRlbmRhbnQNCiAgICAgfCAgIEMgIHwtIC18LSAtfCAgIEEgIHwgICB8ICAgICAgIEFB QUwgPSAgbG9jYWwgYXV0aG9yaXR5DQogICAgIHwgICAgICB8ICAgfCAgIHwgICAgICB8ICAgfCAg ICAgICBBQUFIID0gIGhvbWUgYXV0aG9yaXR5DQogICAgICstLS0tLS0rICAgfCAgICstLS0rLS0r ICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgIHwgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgIHwgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAgfCAg ICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg IHwgICArLS0tKy0tKyAgIHwgICAgICAgICAgIHwgICArLS0tLS0tKyAgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgIHwgICB8ICAgICAgfCAgIHwgICAgICAgICAgIHwgICB8ICAgICAgfCAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICB8IEFBQUwgfCAgIHwgICAgICAgICAgIHwgICB8 IEFBQUggfCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICB8ICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0rICAgICAgfCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICArLS0t LS0tKyAgIHwgICAgICAgICAgIHwgICArLS0tLS0tKyAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgTG9jYWwgRG9tYWluICAgICAgICAgICAgICAg ICAgSG9tZSBEb21haW4NCg0KICAgSW4gdGhlIHBpY3R1cmUsIHRoZXJlIHdvdWxkIGJlIG1hbnkg YXR0ZW5kYW50cyBmb3IgZWFjaCBBQUFMLCBhbmQNCiAgIHRoZXJlIHdvdWxkIGJlIG1hbnkgY3Vz dG9tZXJzIGZyb20gbWFueSBkaWZmZXJlbnQgSG9tZSBEb21haW5zLCBlYWNoDQogICBIb21lIERv bWFpbiBwcm92aWRpbmcgYSBBQUFIIHRoYXQgY2FuIGNoZWNrIGNyZWRlbnRpYWxzIGZyb20NCiAg IGN1c3RvbWVycyBhZG1pbmlzdGVyZWQgYnkgdGhhdCBIb21lIERvbWFpbi4NCg0KICAgRnJvbSB0 aGUgZGVzY3JpcHRpb24gYW5kIGV4YW1wbGUgYWJvdmUsIHdlIGNhbiBpZGVudGlmeSBzZXZlcmFs DQogICByZXF1aXJlbWVudHMuDQoNCiAgICAgIC0gVGhlIGxvY2FsIGF0dGVuZGFudHMgYW5kIHRo ZSBsb2NhbCBhdXRob3JpdHkgaGF2ZSB0byBzaGFyZQ0KICAgICAgICBzZWN1cml0eSByZWxhdGlv bnNoaXBzDQoNCiAgICAgIC0gVGhlIGxvY2FsIGF1dGhvcml0eSBoYXMgdG8gc2hhcmUgc2VjdXJp dHkgcmVsYXRpb25zaGlwcyB3aXRoDQogICAgICAgIGV4dGVybmFsIGF1dGhvcml0aWVzIHRoYXQg YXJlIGFibGUgdG8gY2hlY2sgY3VzdG9tZXIgY3JlZGVudGlhbHMNCg0KICAgICAgLSBUaGUgYXR0 ZW5kYW50IGhhcyB0byBrZWVwIHN0YXRlIGZvciBwZW5kaW5nIGN1c3RvbWVyIHJlcXVlc3RzDQog ICAgICAgIHdoaWxlIHRoZSBsb2NhbCBhdXRob3JpdHkgY29udGFjdHMgdGhlIGFwcHJvcHJpYXRl IGV4dGVybmFsDQogICAgICAgIGF1dGhvcml0eQ0KDQogICAgICAtIFRoZXJlIGFyZSBzY2VuYXJp b3MgaW4gd2hpY2ggYW4gYXR0ZW5kYW50IHdpbGwgaGF2ZSB0byBtYW5hZ2UNCiAgICAgICAgcmVx dWVzdHMgZm9yIHZlcnkgbWFueSBjdXN0b21lcnMgYXQgdGhlIHNhbWUgdGltZS4NCg0KICAgICAg LSBUaGUgYXR0ZW5kYW50IGVxdWlwbWVudCBzaG91bGQgYmUgYXMgaW5leHBlbnNpdmUgYXMgcG9z c2libGUsDQogICAgICAgIHNpbmNlIGl0IHdpbGwgYmUgcmVwbGljYXRlZCBhcyBtYW55IHRpbWVz IGFzIHBvc3NpYmxlIHRvIGhhbmRsZQ0KICAgICAgICBhcyBtYW55IGN1c3RvbWVycyBhcyBwb3Nz aWJsZS4NCg0KICAgICAgLSBTaW5jZSB0aGUgY3VzdG9tZXIgaXMgbm90IGluIGRpcmVjdCBjb250 YWN0IHdpdGggdGhlIGV4dGVybmFsDQogICAgICAgIGF1dGhvcml0eSB0aGF0IGlzIHBlcmZvcm1p bmcgdGhlIGF1dGhvcml6YXRpb24sIHRoZSBjdXN0b21lciBoYXMNCiAgICAgICAgdG8gcHJvdmlk ZSB1bmZvcmdlYWJsZSBjcmVkZW50aWFscyB0aGF0IGNhbiBiZSBjaGVja2VkIGJ5IHRoZQ0KICAg ICAgICB0aGUgZXh0ZXJuYWwgYXV0aG9yaXR5LiAgRnVydGhlcm1vcmUsIHRvIHNhdGlzZnkgdGhl IHJlcXVpcmVtZW50DQoNCg0KDQpDYWxob3VuLCBQZXJraW5zICAgICAgICAgIGV4cGlyZXMgQXVn dXN0IDE5OTkgICAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCg0KDQoNCg0KDQpJTlRFUk5FVCBE UkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5 IDE5OTkNCg0KDQogICAgICAgIHRoYXQgdGhlIGNyZWRlbnRpYWxzIHJlbWFpbiB1bmZvcmdlYWJs ZSwgdGhlIGF0dGVuZGFudCBhbmQgdGhlDQogICAgICAgIGxvY2FsIGF1dGhvcml0eSBtdXN0IG5v dCBiZSBhYmxlIHRvIGxlYXJuIGFueSBzZWNyZXQgaW5mb3JtYXRpb24NCiAgICAgICAgdGhhdCBp cyB1c2VkIHRvIGNyZWF0ZSB0aGUgdW5mb3JnZWFibGUgY3JlZGVudGlhbHMuDQoNCiAgIEZyb20g dGhpcyBsYXN0IHJlcXVpcmVtZW50LCB3ZSBjYW4gZGVyaXZlIHRoZSBhZGRpdGlvbmFsIHJlcXVp cmVtZW50DQogICB0aGF0IHRoZSBjdXN0b21lciBoYXMgdG8gc2hhcmUgYSBzZWN1cml0eSByZWxh dGlvbnNoaXAgd2l0aCB0aGUNCiAgIGV4dGVybmFsIGF1dGhvcml0eSBpbiB0aGUgSG9tZSBEb21h aW4uICBPdGhlcndpc2UsIGl0IGlzIHRlY2huaWNhbGx5DQogICBpbmZlYXNpYmxlIChnaXZlbiB0 aGUgaW1wbGllZCBuZXR3b3JrIHRvcG9sb2d5KSBmb3IgdGhlIGN1c3RvbWVyIHRvDQogICBwcm9k dWNlIHVuZm9yZ2VhYmxlIHNpZ25hdHVyZXMuDQoNCg0KMi4wIEJyb2tlciBSZXF1aXJlbWVudHMN Cg0KICAgVGhlIHBpY3R1cmUgaW4gRmlndXJlIDEgc2hvd3MgYSBjb25maWd1cmF0aW9uIGluIHdo aWNoIHRoZSBsb2NhbCBhbmQNCiAgIHRoZSBob21lIGF1dGhvcml0eSBoYXZlIHRvIHNoYXJlIHRy dXN0LiAgVGhpcyBjb25maWd1cmF0aW9uIGNhdXNlcyBhDQogICBxdWFkcmF0aWMgZ3Jvd3RoIGlu IHRoZSBudW1iZXIgb2YgdHJ1c3QgcmVsYXRpb25zaGlwcyBhcyB0aGUgbnVtYmVyDQogICBvZiBB QUEgYXV0aG9yaXRpZXMgKEFBQUwgYW5kIEFBQUgpIGluY3JlYXNlcy4gIFRoaXMgaGFzIGJlZW4N CiAgIGlkZW50aWZpZWQgYXMgYSBwcm9ibGVtIGJ5IHRoZSByb2Ftb3BzIHdvcmtpbmcgZ3JvdXAs IGFuZCBhbnkgQUFBDQogICBzb2x1dGlvbiBoYXMgdG8gb2ZmZXIgYSBzb2x1dGlvbiB0byB0aGlz IHByb2JsZW0uICBUaGVyZSBhcmUgYWxyZWFkeQ0KICAgZW50aXRpZXMga25vd24gYXMgImJyb2tl cnMiIHRoYXQgYWxsb3cgbG9jYWwgYXV0aG9yaXRpZXMgdG8gcmVkdWNlDQogICB0aGUgbnVtYmVy IG9mIHRydXN0IHJlbGF0aW9uc2hpcHMgdGhhdCBuZWVkIHRvIGJlIG1haW50YWluZWQuDQoNCiAg ICAgRmlndXJlIDI6DQogICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgICArLS0t LS0tKyAgIHwgICArLS0tLS0tKyAgIHwgICAgICAgQyAgICA9ICBjdXN0b21lcg0KICAgICB8ICAg ICAgfCAgIHwgICB8ICAgICAgfCAgIHwgICAgICAgQSAgICA9ICBhdHRlbmRhbnQNCiAgICAgfCAg IEMgIHwtIC18LSAtfCAgIEEgIHwgICB8ICAgICAgIEFBQUwgPSAgbG9jYWwgYXV0aG9yaXR5DQog ICAgIHwgICAgICB8ICAgfCAgIHwgICAgICB8ICAgfCAgICAgICBBQUFIID0gIGhvbWUgYXV0aG9y aXR5DQogICAgICstLS0tLS0rICAgfCAgICstLS0rLS0rICAgfCAgICAgICBBQUFCID0gIGJyb2tl ciBhdXRob3JpdHkNCiAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICB8ICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgfCAgICAgICB8ICAg ICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgIHwgICAgICAgfCAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICB8ICAgKy0tLSstLSsgICB8ICAgKy0tLS0tLSsgICAgfCAgICst LS0tLS0rICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgIHwgICAgICB8ICAgfCAgIHwg ICAgICB8ICAgIHwgICB8ICAgICAgfCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICB8 IEFBQUwgKy0tLS0tLS0rIEFBQUIgKy0tLS0tLS0tKyBBQUFIIHwgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICB8ICAgfCAgICAgIHwgICB8ICAgfCAgICAgIHwgICAgfCAgIHwgICAgICB8ICAg ICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICstLS0tLS0rICAgfCAgICstLS0tLS0rICAg IHwgICArLS0tLS0tKyAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICAgICAgICAgICAgICAgICBMb2NhbCBEb21haW4gICAgICAgICAgICAgICAgICAgICBIb21l IERvbWFpbg0KDQogICBUaGUgQUFBQiBpbiB0aGUgYWJvdmUgcGljdHVyZSBpcyB0aGUgYnJva2Vy J3MgYXV0aG9yaXR5IHNlcnZlci4gIFRoZQ0KICAgYnJva2VyIGFjdHMgYXMgYSBzZXR0bGVtZW50 IGFnZW50LCBwcm92aWRpbmcgc2VjdXJpdHkgYW5kIGEgY2VudHJhbA0KICAgcG9pbnQgb2YgY29u dGFjdCBmb3IgbWFueSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgZW50ZXJwcmlzZXMuDQoNCiAgIFRo ZSBBQUFCIGVuYWJsZXMgdGhlIGxvY2FsIGFuZCBob21lIGRvbWFpbnMgdG8gY29vcGVyYXRlIHdp dGhvdXQNCiAgIHJlcXVpcmluZyBlYWNoIG5ldHdvcmsgdG8gaGF2ZSBhIGRpcmVjdCByZWxhdGlv bnNoaXAgd2l0aCBhbGwgb3RoZXINCiAgIG5ldHdvcmtzLiAgVGh1cywgYnJva2VycyBvZmZlciB0 aGUgbmVlZGVkIHNjYWxhYmlsaXR5IGZvciBtYW5hZ2luZw0KDQoNCg0KQ2FsaG91biwgUGVya2lu cyAgICAgICAgICBleHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDRd DQoNCg0KDQoNCg0KSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBGZWJydWFyeSAxOTk5DQoNCg0KICAgdHJ1c3QgcmVsYXRpb25zaGlwcyBi ZXR3ZWVuIG90aGVyd2lzZSBpbmRlcGVuZGVudCBuZXR3b3JrIGRvbWFpbnMuDQogICBVc2Ugb2Yg dGhlIGJyb2tlciBkb2VzIG5vdCBwcmVjbHVkZSBtYW5hZ2luZyBzZXBhcmF0ZSB0cnVzdA0KICAg cmVsYXRpb25zaGlwcyBiZXR3ZWVuIGRvbWFpbnMsIGJ1dCBpdCBkb2VzIG9mZmVyIGFuIGFsdGVy bmF0aXZlIHRvDQogICBkb2luZyBzby4NCg0KICAgVGhlIGZvbGxvd2luZyByZXF1aXJlbWVudHMg Y29tZSBtb3N0bHkgZnJvbSBbMV0sIHdoaWNoIGRpc2N1c3NlcyB1c2UNCiAgIG9mIGJyb2tlcnMg aW4gdGhlIHBhcnRpY3VsYXIgY2FzZSBvZiBhdXRob3JpemluZyByb2FtaW5nIGRpYWwtdXANCiAg IHVzZXJzLg0KDQogICAgICAtIEFsbG93aW5nIG1hbmFnZW1lbnQgb2YgdHJ1c3Qgd2l0aCBleHRl cm5hbCBkb21haW5zIGJ5IHdheSBvZg0KICAgICAgICBicm9rZXJlZCBBQUEuDQoNCiAgICAgIC0g Q2FwYWJpbGl0aWVzIGFkanVzdG1lbnQuIEVhY2ggbWFudWZhY3R1cmVyJ3MgZXF1aXBtZW50IGhh cw0KICAgICAgICBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzLiAgVGh1cywgdGhlIEFBQUwgbWF5IGhh dmUgdG8gbW9kaWZ5IHRoZQ0KICAgICAgICBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGZyb20g dGhlIEFBQUguDQoNCiAgICAgIC0gQWNjb3VudGluZyByZWxpYWJpbGl0eS4gQWNjb3VudGluZyBk YXRhIHRoYXQgdHJhdmVyc2VzIHRoZQ0KICAgICAgICBJbnRlcm5ldCBtYXkgc3VmZmVyIHN1YnN0 YW50aWFsIHBhY2tldCBsb3NzLiAgU2luY2UgVENQIG1heSBiZQ0KICAgICAgICB1bnN1aXRhYmxl IGluIGNhc2VzIHdoZXJlIHRoZSBhdHRlbmRhbnQgaGFzIHRvIG1hbmFnZSBsYXJnZQ0KICAgICAg ICBudW1iZXJzIG9mIGluY29taW5nIHJlcXVlc3RzLCBzcGVjaWFsIHJldHJhbnNtaXNzaW9uIGFs Z29yaXRobXMNCiAgICAgICAgbWF5IGJlIG5lZWRlZC4gIFNpbmNlIGFjY291bnRpbmcgcGFja2V0 cyBtYXkgdHJhdmVyc2Ugb25lIG9yDQogICAgICAgIG1vcmUgaW50ZXJtZWRpYXRlIGF1dGhvcml6 YXRpb24gcG9pbnRzIChlLmcuLCBicm9rZXJzKSwNCiAgICAgICAgZXhwZXJpZW5jZSBpbmRpY2F0 ZXMgdGhlIG5lZWQgZm9yIHJldHJhbnNtaXNzaW9uIGZyb20NCiAgICAgICAgaW50ZXJtZWRpYXRl IHBvaW50cyB0byBhdm9pZCBsb25nIGVuZC10by1lbmQgZGVsYXlzLg0KDQogICAgICAtIEVuZCB0 byBFbmQgc2VjdXJpdHkuIFRoZSBMb2NhbCBEb21haW4gYW5kIEhvbWUgRG9tYWluIG11c3QgYmUN CiAgICAgICAgYWJsZSB0byB2ZXJpZnkgc2lnbmF0dXJlcyB3aXRoaW4gdGhlIG1lc3NhZ2UsIGV2 ZW4gdGhvdWdoIHRoZQ0KICAgICAgICBtZXNzYWdlIGlzIHBhc3NlZCB0aHJvdWdoIGFuIGludGVy bWVkaWF0ZSBhdXRob3JpdHkgc2VydmVyLiBUaGlzDQogICAgICAgIGlzIG5lY2Vzc2FyeSBiZWNh dXNlIHRoZSBmb2xsb3dpbmcgYXR0YWNrcyB3ZXJlIGlkZW50aWZpZWQgd2hlbg0KICAgICAgICB0 aGlzIG9wZXJhdGlvbiBpcyBkb25lIHVzaW5nIHRoZSBSQURJVVMgcHJvdG9jb2wgKHNlZSBbMV0g Zm9yDQogICAgICAgIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIGluZGl2aWR1YWwgYXR0YWNrcyk6 DQogICAgICAgICAgICArIE1lc3NhZ2UgZWRpdGluZw0KICAgICAgICAgICAgKyBBdHRyaWJ1dGUg ZWRpdGluZw0KICAgICAgICAgICAgKyBUaGVmdCBvZiBwYXNzd29yZHMNCiAgICAgICAgICAgICsg VGhlZnQgYW5kIG1vZGlmaWNhdGlvbiBvZiBhY2NvdW50aW5nIGRhdGENCiAgICAgICAgICAgICsg UmVwbGF5IGF0dGFja3MNCiAgICAgICAgICAgICsgQ29ubmVjdGlvbiBoaWphY2tpbmcNCiAgICAg ICAgICAgICsgRnJhdWR1bGVudCBhY2NvdW50aW5nDQoNCg0KNS4wICBSZWZlcmVuY2VzDQoNCiAg IFsxXSBBYm9iYSwgVm9sbGJyZWNodCwgIlByb3h5IENoYWluaW5nIGFuZCBQb2xpY3kgSW1wbGVt ZW50YXRpb24gaW4NCiAgICAgICBSb2FtaW5nIiwgZHJhZnQtaWV0Zi1yb2Ftb3BzLWF1dGgtMTAu dHh0LCBXb3JrIGluIFByb2dyZXNzLA0KICAgICAgIEZlYnJ1YXJ5IDE5OTkuDQogICBbMl0gQWJv YmEsIEJlYWRsZXMgIlRoZSBOZXR3b3JrIEFjY2VzcyBJZGVudGlmaWVyLiIgUkZDIDI0ODYuDQog ICAgICAgSmFudWFyeSAxOTk5Lg0KICAgWzNdIEFib2JhLCBab3JuLCAiQ3JpdGVyaWEgZm9yIEV2 YWx1YXRpbmcgUm9hbWluZyBQcm90b2NvbHMiLA0KDQoNCg0KQ2FsaG91biwgUGVya2lucyAgICAg ICAgICBleHBpcmVzIEF1Z3VzdCAxOTk5ICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoNCg0K DQoNCg0KSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGZWJydWFyeSAxOTk5DQoNCg0KICAgICAgIFJGQyAyNDc3LCBKYW51YXJ5IDE5OTku DQoNCjMuMCAgQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFF1ZXN0aW9ucyBhYm91dCB0aGlzIG1l bW8gY2FuIGJlIGRpcmVjdGVkIHRvOg0KDQogICAgICBQYXQgUi4gQ2FsaG91bg0KICAgICAgTmV0 d29yayBhbmQgU2VjdXJpdHkgUmVzZWFyY2ggQ2VudGVyLCBTdW4gTGFicw0KICAgICAgU3VuIE1p Y3Jvc3lzdGVtcywgSW5jLg0KICAgICAgMTUgTmV0d29yayBDaXJjbGUNCiAgICAgIE1lbmxvIFBh cmssIENhbGlmb3JuaWEsIDk0MDI1DQogICAgICBVU0ENCg0KICAgICAgIFBob25lOiAgMS02NTAt Nzg2LTc3MzMNCiAgICAgICAgIEZheDogIDEtNjUwLTc4Ni02NDQ1DQogICAgICBFLW1haWw6ICBw Y2FsaG91bkBlbmcuc3VuLmNvbQ0KDQoNCiAgICAgIENoYXJsZXMgRS4gUGVya2lucw0KICAgICAg TmV0d29yayBhbmQgU2VjdXJpdHkgUmVzZWFyY2ggQ2VudGVyLCBTdW4gTGFicw0KICAgICAgU3Vu IE1pY3Jvc3lzdGVtcywgSW5jLg0KICAgICAgMTUgTmV0d29yayBDaXJjbGUNCiAgICAgIE1lbmxv IFBhcmssIENhbGlmb3JuaWEsIDk0MDI1DQogICAgICBVU0ENCg0KICAgICAgIFBob25lOiAgMS02 NTAtNzg2LTY0NjQNCiAgICAgICAgIEZheDogIDEtNjUwLTc4Ni02NDQ1DQogICAgICBFLW1haWw6 ICBjaGFybGVzLnBlcmtpbnNAZW5nLnN1bi5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpDYWxob3VuLCBQZXJraW5zICAgICAgICAgIGV4cGlyZXMgQXVn dXN0IDE5OTkgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KDQo= --------------919979546-- From owner-aaa-wg@merit.edu Thu Feb 25 18:35:59 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id SAA12583 for ; Thu, 25 Feb 1999 18:35:59 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id SAA16484 for aaa-wg-outgoing; Thu, 25 Feb 1999 18:35:34 -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 SAA16480 for ; Thu, 25 Feb 1999 18:35:29 -0500 (EST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA03079 for ; Thu, 25 Feb 1999 15:32:20 -0800 Received: from hsmpka.eng.sun.com (hsmpka.Eng.Sun.COM [129.146.63.47]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with SMTP id PAA26855 for ; Thu, 25 Feb 1999 15:32:17 -0800 (PST) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA18887; Thu, 25 Feb 1999 15:32:18 -0800 Message-Id: <199902252332.PAA18887@hsmpka.eng.sun.com> Date: Thu, 25 Feb 1999 15:27:26 -0800 (PST) From: Charles Perkins Reply-To: Charles Perkins Subject: AAA requirements document Internet Draft To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3GXiMAwaasQR+GEuQJvakQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk After some pointed suggestion by someone I won't name (but you know who you are), Pat Calhoun and I have been prodded into formulating a requirements document for the proposed AAA functions. The document has been submitted as an Internet Draft, and is also available at http://www.svrloc.org/~charliep/txt/aaa/Reqs.txt Comments are encouraged. Regards, Charles E. Perkins From owner-aaa-wg@merit.edu Fri Feb 26 11:10:42 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id LAA20280 for ; Fri, 26 Feb 1999 11:10:42 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA27857 for aaa-wg-outgoing; Fri, 26 Feb 1999 11:08:33 -0500 (EST) X-Authentication-Warning: merit.edu: majordom set sender to owner-aaa-bof@merit.edu using -f Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA27853 for ; Fri, 26 Feb 1999 11:08:27 -0500 (EST) Received: from GK-Portable (unverified [193.149.71.153]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id ; Fri, 26 Feb 1999 16:00:27 +0000 Message-Id: <3.0.32.19990226155836.01571ec0@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 26 Feb 1999 16:09:41 +0000 To: Charles Perkins From: Graham Klyne Subject: Re: AAA requirements document Internet Draft Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 15:27 25/02/99 -0800, Charles Perkins wrote: > >After some pointed suggestion by someone I won't name (but you know >who you are), Pat Calhoun and I have been prodded into formulating >a requirements document for the proposed AAA functions. The >document has been submitted as an Internet Draft, and is also >available at http://www.svrloc.org/~charliep/txt/aaa/Reqs.txt I think this is helpful in indicating the intended scope of this work. 1. A few small comments on your draft ------------------------------------- I found myself a little confused by the use of "foreign domain" and "local domain": as far as I can tell, they have the same meaning in this context. The text and figure 1 seem slightly at odds, in that the "customer" is described as belonging to the "home domain", but this is not shown in the diagram. The last paragraph in section 1.0 introduces the "implied network topology", which I think could usefully be made explicit earlier in the memo. If I have understood correctly: a "customer" C's access to a resource is controlled by an "attendant" A, who obtains consults a "local authority" AAAL in the "foreign domain" to obtain authorization; AAAL negotiates this authorization with an "external authrity" in the "home domain". Yes? 2. Scope of AAA work -------------------- I think your requirements indicate that the AAA framework is really intended to control access to the network communication infrastructure, and is not really applicable to other forms of authorization. My reason for saying this is: Once access to the network has been granted, there seems little point in using the same framework to gain access to other resources, since the customer might as well contact AAAH or AAAB directly, and avoid a degree of complexity. To put it another way, the main raison d'etre for this framework seems to be to overcome the problem of allowing a "roaming" user to connect to any administrative domain in a network and gain properly authorized access to network communication resources. If I am correct, I don't see this as a weakness; rather, a recognition that network access is a special case for AAA. But (if true) I do think it would help to state this clearly. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-aaa-wg@merit.edu Fri Feb 26 13:03:38 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id NAA21630 for ; Fri, 26 Feb 1999 13:03:38 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id NAA00335 for aaa-wg-outgoing; Fri, 26 Feb 1999 13:03:04 -0500 (EST) X-Authentication-Warning: merit.edu: majordom set sender to owner-aaa-bof@merit.edu using -f Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by merit.edu (8.9.1a/8.9.1) with ESMTP id NAA00328; Fri, 26 Feb 1999 13:02:57 -0500 (EST) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21899; Fri, 26 Feb 1999 10:02:25 -0800 (PST) Received: from fred-pc (fred-hm-dhcp3.cisco.com [171.69.128.118]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id KAA04921; Fri, 26 Feb 1999 10:02:31 -0800 (PST) Message-Id: <199902261802.KAA04921@kiwi.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 26 Feb 1999 09:56:29 -0800 To: aaa-wg@merit.edu From: Fred Baker Subject: proposed charter for AAA as updated by IESG discussion Cc: Brian Lloyd , paul@mci.net, skh@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk The charter was amended somewhat; this is what the IESG approved the following. ---------------------------------------------------------------------- Authentication, Authorization, and Accounting (AAA) Working Group charter Chair(s): Brian Lloyd Paul Krumviede General Area Director(s): Fred Baker General Area Advisor: Fred Baker Mailing Lists: General Discussion:aaa-wg@merit.edu To Subscribe: majordomo@merit.edu In Body: subscribe aaa-wg Archive: http://www.merit.edu Description of Working Group: The Authentication, Authorization and Accounting working group will focus on the specification of a general Authentication, Authorization, and Accounting architecture for the Internet. The purpose behind this is to create a set of base protocols applicable to a number of specific AAA applications. These include at least IP Telephony, SS7 AAA, Bandwidth Broker AAA, and Network Access Server AAA. By creating an architecture and set of base protocols, the amount of work to create specific AAA protocols will be reduced. The list of target applications implies a strong interaction with many areas of IETF activity, which is the justification for doing this work in the General Area. The working group will dialog specifically with the Application, Transport, and Security Areas, and others as needed, to achieve its objectives. The problem space for a general AAA working group contains work in: - determining the current set of specific applications that the AAA will service; - documenting requirements for a base AAA architecture; - identifying the capabilities and limitations of protocols currently used to represent and transport AAA information, e.g. RADIUS, Diameter, COPS, etc.; - selecting a transport protocol or set of transport protocols to be used by a general AAA protocol based on the requirements, - selecting the framework for the AAA protocols; - specifying the AAA architecture and nature of the implied protocols; - specifying the data formats for information contained in the AAA protocol information for authentication, authorization, and accounting; - identify the relationship and interaction between Policy and Authorization. The first step in this working group is to determine the requirements for the AAA architecture, and probable uses of that architecture. Once the requirements have been documented, the working group will be rechartered to implement to those requirements. A close second is to consider proposals of base protocols; ideally, the working group should be able to finalize requirements and review proposals during its second meeting. The working group will target the use of TCP and defined procedures on UDP. When a transaction transport protocol has been developed elsewhere in the IETF, the working group will consider changing from TCP and UDP to that protocol. Document Schedule April '99 AAA Applications (informational RFC) Internet Draft Authentication Requirements initial Internet Draft Authorization Requirements initial Internet Draft Accounting Requirements initial Internet Draft June '99 AAA architectural framework proposals documented as Internet drafts August '99 AAA Applications to Informational RFC AAA Requirements to Informational RFC AAA Architectural Framework to Informational RFC September '99 Revision of charter to include statement of work regarding specific protocols and data formats. Internet Drafts "Requirements for Internet-Scale Accounting Management", 08/06/1998, "Introduction to Accounting Management", 08/06/1998, From owner-aaa-wg@merit.edu Sun Feb 28 16:24:10 1999 Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.9.1a/8.9.1) with ESMTP id QAA16836 for ; Sun, 28 Feb 1999 16:24:10 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA03988 for aaa-wg-outgoing; Sun, 28 Feb 1999 16:22:46 -0500 (EST) X-Authentication-Warning: merit.edu: majordom set sender to owner-aaa-bof@merit.edu using -f 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 QAA03984 for ; Sun, 28 Feb 1999 16:22:42 -0500 (EST) Received: from mci.net ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8A7PPDJ4E8Y5C8X@shoe.reston.mci.net> for aaa-wg@merit.edu; Sun, 28 Feb 1999 16:22:10 EST Date: Sun, 28 Feb 1999 13:22:07 -0800 From: Paul Krumviede Subject: [Fwd: SLUMS BOF for addressing RUTS requirements] To: AAA WG Reply-to: paul@mci.net Message-id: <36D9B37F.567EB017@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_JsGakWG3cNySvbqKVE59sw)" X-Accept-Language: en Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_JsGakWG3cNySvbqKVE59sw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT fyi... -paul --Boundary_(ID_JsGakWG3cNySvbqKVE59sw) Content-type: MESSAGE/RFC822 Return-path: ruts-request@listserv.lbl.gov Received: from listserv.lbl.gov ([128.3.7.140]) by shoe.reston.mci.net (PMDF V5.2-29 #33823) with ESMTP id <01J8A0WNRROG8WW5ZE@shoe.reston.mci.net> for krumviede@shoe.reston.mci.net (ORCPT rfc822;paul@MCI.NET); Sun, 28 Feb 1999 13:06:55 -0500 (EST) Received: (from list@localhost) by listserv.lbl.gov (8.9.0/8.9.0) id KAA08608; Sun, 28 Feb 1999 10:03:40 -0800 (PST) Resent-date: Sun, 28 Feb 1999 10:03:40 -0800 (PST) Date: Sun, 28 Feb 1999 10:03:26 -0800 (PST) Resent-from: ruts@listserv.lbl.gov From: Vern Paxson Subject: SLUMS BOF for addressing RUTS requirements Resent-sender: ruts-request@listserv.lbl.gov To: ruts@lbl.gov Cc: srini@watson.ibm.com, hari@lcs.mit.edu, spreitze@parc.xerox.com Resent-message-id: <"bG3t6.0.K62.pJOss"@listserv> Message-id: <199902281803.KAA11122@daffy.ee.lbl.gov> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Precedence: list X-Loop: ruts@listserv.lbl.gov X-Authentication-warning: listserv.lbl.gov: list set sender to ruts-request@listserv.lbl.gov using -f X-Mailing-List: archive/latest/7 Original-recipient: rfc822;paul@MCI.NET There will be a BOF at the next IETF called SLUMS (= Support for Lots of Unicast Multiplexed Sessions) that will explore possible transport solutions to addressing a subset of the requirements that came out of the RUTS BOF at the last IETF. SLUMS is tentatively scheduled for Wednesday (3/17) afternoon, 1PM-3PM. The subset of the requirements we're picturing as in scope for SLUMS is: - quick establishment/activation, which is in tension with security considerations (authentication, flooding - not holding state) - support for application level framing: - control over reliability (e.g., setting time limits on how long to try to deliver a message) - the ability to supercede previous application messages - minimize state requirements; think of servers with 1e6 connections - muxing: PDUs muxed, delivered ASAP. Want ACK aggregation across the different communication streams; isolated flow-control; QoS consciousness between the streams. - congestion control across multiple communication streams - reducing slow start delays for multiple communication streams - failover: transport connection can survive across change in IP address - on connection attempt, SYN timeout are viewed as expensive - mid-stream, need to switch to backup interfaces - ability for application to indicate "a reply is coming" versus "no more coming now, go ahead and ack, don't delay" And the ones that are not in scope: - support for application level framing: - visibility into network conditions - want to deal with transport at a 'frame' granularity (record marking) - per-message priority control - congestion control - slow start hit (bursty vs. even flow) - snappy after idle (bursty vs. even flow) - optionally becoming aggressive during loss (for control traffic whose job is to stem the congestion); e.g., FEC - small footprint The goal of the BOF is to explore different basic approaches for addressing these requirements. All of the proposed approaches deal primarily with the muxing requirement, ensuring that multiple communication threads between two hosts obey the fundamental congestion control principles. Addressing the other requirements is generally deferred to higher-layer solutions, which strikes us as a good way to divide up the problem. Srini Seshan will discuss an approach that he, Hari Balakrishnan, and colleagues have developed called the "Congestion Manager" (CM). The basic idea is that a host's different communication streams use a CM service to determine when they can send and at what rate. The CM is described in the paper "An Integrated Congestion Management Architecture for Internet Hosts", available from http://inat.lcs.mit.edu/papers/BRS99.ps Please read this document if you have a chance - it's a very interesting framework that has little overhead (none in the case of managing multiple TCP connections). Mike Spreitze will discuss MEMUX, which has come out of the HTTP-NG muxing work. MEMUX operates above the transport layer, multiplexing a set of communication streams on top of a single transport connection. We may also have advocates for integrating congestion control across multiple TCP streams. One can then implement lightweight communication streams using multiple T/TCP connections. - Vern & Scott --Boundary_(ID_JsGakWG3cNySvbqKVE59sw)--