From owner-aaa-bof@merit.edu Tue Jan 2 15:02:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14480 for ; Tue, 2 Jan 2001 15:02:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D0BC5DEA2; Tue, 2 Jan 2001 15:00:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D12C45DE01; Tue, 2 Jan 2001 15:00:16 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id E7F395DEA1 for ; Tue, 2 Jan 2001 15:00:09 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f02JvgC29816 for ; Tue, 2 Jan 2001 11:57:42 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: Announcement: AAA WG Interim meeting on Security and Transport issues Date: Tue, 2 Jan 2001 12:00:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk We have decided to have a AAA WG Interim meeting focusing on transport and security issues on February 7, 2001. The meeting will occur in San Diego, CA. If you would like to attend the interim meeting, please send mail to aboba@internaut.com and I will mail the details to you as soon as they are available. Unfortunately, alternative dates in late January in the Netherlands were not feasible due to the 30-day advance notice requirement. However, we are currently investigating other potential venues to advance the discussion on Data Modelling. From owner-aaa-bof@merit.edu Tue Jan 2 19:39:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18619 for ; Tue, 2 Jan 2001 19:39:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36B795DDCE; Tue, 2 Jan 2001 19:39:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 259925DDBF; Tue, 2 Jan 2001 19:39:03 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 036FC5DDA6 for ; Tue, 2 Jan 2001 19:39:02 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06466; Tue, 2 Jan 2001 16:38:59 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA14402; Tue, 2 Jan 2001 16:38:58 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA17922; Tue, 2 Jan 2001 16:38:57 -0800 (PST) Date: Tue, 2 Jan 2001 16:35:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Erik Guttman Cc: Bob.Natale@AppliedSNMP.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 > In my opinion we should select the XML solution since it is simple, > and adequate. But the most important factor, which we agreed to > in advance, is that we can do something which can move forward QUICKLY > in the standards process. Since SMIng is not yet standard, I don't > think it is presently an option. We simply can't hold up DIAMETER any > longer by making it's process contingent upon other standardization > efforts. I will be honest here, I don't have a preference as to the actual model we use is. However, I do have a preference that the work be done within a reasonable timeframe. The issue I have with SMIng, which I have NOT been following in the IETF, is the fact that the work is relatively new. I feel uncomfortable tying the documents to something that is still in flux. So far, I have heard from support for XML and SMIng more than UML, which according to David does not have many free "tools" available for. Given these points, which are not technical in nature, I would opt for XML. PatC From owner-aaa-bof@merit.edu Tue Jan 2 20:04:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA19136 for ; Tue, 2 Jan 2001 20:04:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id D4AA55DE24; Tue, 2 Jan 2001 20:02:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C30995DE23; Tue, 2 Jan 2001 20:02:06 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id AB7985DE1F for ; Tue, 2 Jan 2001 20:02:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11284; Tue, 2 Jan 2001 17:01:55 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA21256; Tue, 2 Jan 2001 17:01:55 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id RAA18892; Tue, 2 Jan 2001 17:01:53 -0800 (PST) Date: Tue, 2 Jan 2001 16:58:24 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt To: Bernard Aboba Cc: 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 > At IETF 49, Pat Calhoun presented draft-ietf-aaa-solutions-00.txt. > > With the exception of three areas (transport, security and > data modelling), we did not have a great deal of comment on > the solutions draft. > > As a result, I'd like to request that AAA WG members re-read > the solutions draft, and comment on whether it is adequate > aside from the three areas above. > > If we do indeed have consensus on the rest of the solutions > draft, then one possible approach would be to break off the > discussion of transport, security and data modelling into > separate drafts, move the rest of the solutions draft to > WG last call and make the indicated changes to the DIAMETER > spec. > > Opinions? I agree, and would request that if no comments are forthcoming the chairs do a last call on the document. That is unfortunately sometimes the only way to get people to find the time to participate :) PatC From owner-aaa-bof@merit.edu Wed Jan 3 05:19:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA04810 for ; Wed, 3 Jan 2001 05:19:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id E7D6A5DDF4; Wed, 3 Jan 2001 05:16:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CA8495DDAE; Wed, 3 Jan 2001 05:16:38 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id F2F855DD99 for ; Wed, 3 Jan 2001 05:16:36 -0500 (EST) Received: from fredrikj (c8.localhost.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA17433; Wed, 3 Jan 2001 11:16:40 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" , "Bernard Aboba" Cc: Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt Date: Wed, 3 Jan 2001 11:18:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk After having browsed through draft-ietf-aaa-solutions-01.txt this morning, here are some comments. - Section 3: If I'm not misstaken, consencus at the WG meeting in San Diego was not to use ADIF for Accounting. - Typo in section 4.2 "IPv5" - Section 7: Is there a document describing the protocol gateway procedures? - Section 13: The Filter-Rule AVP provides the basic data needed for filtering. However if you would like to create more advanced filter using for example; Keep State, Quick, or Grouping of filters. It has to be indicated in some way. It could be done by grouping a with an ther avp ("Filter-Rule-Option AVP"). The latter can be used for indicating extra options not supported by the . The avp code of a "filter-rule-option avp" must be assigned so that the session will be terminated if the receiver does not understand the avp. As usual the avp should be returned to the sender, this way it is up to the sender to determine if it can do without that specific option. /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 3 januari 2001 01:58 >To: Bernard Aboba >Cc: aaa-wg@merit.edu >Subject: Re: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt > > >> At IETF 49, Pat Calhoun presented draft-ietf-aaa-solutions-00.txt. >> >> With the exception of three areas (transport, security and >> data modelling), we did not have a great deal of comment on >> the solutions draft. >> >> As a result, I'd like to request that AAA WG members re-read >> the solutions draft, and comment on whether it is adequate >> aside from the three areas above. >> >> If we do indeed have consensus on the rest of the solutions >> draft, then one possible approach would be to break off the >> discussion of transport, security and data modelling into >> separate drafts, move the rest of the solutions draft to >> WG last call and make the indicated changes to the DIAMETER >> spec. >> >> Opinions? > >I agree, and would request that if no comments are forthcoming the >chairs do a >last call on the document. That is unfortunately sometimes the >only way to get >people to find the time to participate :) > >PatC > From owner-aaa-bof@merit.edu Wed Jan 3 09:26:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA07772 for ; Wed, 3 Jan 2001 09:26:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9231E5DDF1; Wed, 3 Jan 2001 09:26:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8175D5DDED; Wed, 3 Jan 2001 09:26:36 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 242E75DDB1 for ; Wed, 3 Jan 2001 09:26:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24298; Wed, 3 Jan 2001 06:26:25 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA22852; Wed, 3 Jan 2001 06:26:24 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA07463; Wed, 3 Jan 2001 06:26:23 -0800 (PST) Date: Wed, 3 Jan 2001 06:22:53 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt To: Fredrik Johansson Cc: Pat Calhoun , Bernard Aboba , 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 > After having browsed through draft-ietf-aaa-solutions-01.txt this morning, > here are some comments. > > - Section 3: If I'm not misstaken, consencus at the WG meeting in San Diego > was not to use ADIF for Accounting. Correct, so section 3 needs to be updated. However, we need to get WG concensus on the mailing list before removing ADIF. Bernard? > > - Typo in section 4.2 "IPv5" ok. > > - Section 7: Is there a document describing the protocol gateway procedures? Yes, it can be found in the Implementor's Guidelines I-D. > > - Section 13: The Filter-Rule AVP provides the basic data needed for > filtering. However if you would like to create more advanced filter using > for example; Keep State, Quick, or Grouping of filters. It has to be > indicated in some way. It could be done by grouping a with > an ther avp ("Filter-Rule-Option AVP"). The latter can be used for > indicating extra options not supported by the . The avp > code of a "filter-rule-option avp" must be assigned so that the session will > be terminated if the receiver does not understand the avp. As usual the avp > should be returned to the sender, this way it is up to the sender to > determine if it can do without that specific option. hmmm.... the current proposed AVP has some fairly high chance of interoperability. Adding a new AVP as you suggest seems to reduce that change dramatically, especially when the new AVP's behavior is not well defined. PatC From owner-aaa-bof@merit.edu Wed Jan 3 11:30:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10489 for ; Wed, 3 Jan 2001 11:30:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id B18185DE9A; Wed, 3 Jan 2001 11:18:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99DF85DE93; Wed, 3 Jan 2001 11:18:51 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 2971D5DDBE for ; Wed, 3 Jan 2001 11:18:50 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f03GBbK46500; Wed, 3 Jan 2001 11:11:37 -0500 (EST) (envelope-from barney) Date: Wed, 3 Jan 2001 11:11:36 -0500 From: Barney Wolff To: Pat Calhoun Cc: Fredrik Johansson , Bernard Aboba , aaa-wg@merit.edu Subject: Re: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt Message-ID: <20010103111136.A46407@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@eng.sun.com on Wed, Jan 03, 2001 at 06:22:53AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk The exclusion of state-keeping from the filter syntax was a deliberate choice. I considered it unlikely to be implemented by NAS vendors, and in some sense not appropriate. Such firewall features would typically be used to protect things "behind" the firewall, whereas NAS filtering is mostly intended to protect the ISP's infrastructure and set limits on what the caller can do, and for that statefulness is not needed. I'm not saying that statefulness is not a useful feature, just that one unlikely to be implemented. A server that knows the NAS can do it can probably also know a filter name, as we are not removing that facility. Barney On Wed, Jan 03, 2001 at 06:22:53AM -0800, Pat Calhoun wrote: > > > > - Section 13: The Filter-Rule AVP provides the basic data needed for > > filtering. However if you would like to create more advanced filter using > > for example; Keep State, Quick, or Grouping of filters. It has to be > > indicated in some way. It could be done by grouping a with > > an ther avp ("Filter-Rule-Option AVP"). The latter can be used for > > indicating extra options not supported by the . The avp > > code of a "filter-rule-option avp" must be assigned so that the session will > > be terminated if the receiver does not understand the avp. As usual the avp > > should be returned to the sender, this way it is up to the sender to > > determine if it can do without that specific option. > > hmmm.... the current proposed AVP has some fairly high chance of > interoperability. Adding a new AVP as you suggest seems to reduce that change > dramatically, especially when the new AVP's behavior is not well defined. From owner-aaa-bof@merit.edu Wed Jan 3 11:38:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10618 for ; Wed, 3 Jan 2001 11:38:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id E43895DDBE; Wed, 3 Jan 2001 11:38:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D16B15DD8E; Wed, 3 Jan 2001 11:38:24 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id B09B95DE3C for ; Wed, 3 Jan 2001 11:38:22 -0500 (EST) Received: from fredrikj (c8.localhost.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA22166; Wed, 3 Jan 2001 17:38:17 +0100 From: "Fredrik Johansson" To: "Barney Wolff" , "Pat Calhoun" Cc: "Bernard Aboba" , Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt Date: Wed, 3 Jan 2001 17:40:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010103111136.A46407@mx.databus.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk That's true, but a is not limited to be used by a NAS, it can also be used to push rules to a firewall when a user registers. Therefore, I would like the to be as general as possible. However a receiver that does not understand the grouping can not accept the rules as is since it might cause security problems. If a reject is sent indicating that it failed because of the grouping, it is up to the server to retry with a new set of rules (if it find that it can mananage with the weaker security). /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Barney Wolff >Sent: den 3 januari 2001 17:12 >To: Pat Calhoun >Cc: Fredrik Johansson; Bernard Aboba; aaa-wg@merit.edu >Subject: Re: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt > > >The exclusion of state-keeping from the filter syntax was a >deliberate choice. I considered it unlikely to be implemented >by NAS vendors, and in some sense not appropriate. Such firewall >features would typically be used to protect things "behind" the >firewall, whereas NAS filtering is mostly intended to protect >the ISP's infrastructure and set limits on what the caller can >do, and for that statefulness is not needed. > >I'm not saying that statefulness is not a useful feature, just >that one unlikely to be implemented. A server that knows the >NAS can do it can probably also know a filter name, as we are >not removing that facility. > >Barney > >On Wed, Jan 03, 2001 at 06:22:53AM -0800, Pat Calhoun wrote: >> > >> > - Section 13: The Filter-Rule AVP provides the basic data needed for >> > filtering. However if you would like to create more advanced >filter using >> > for example; Keep State, Quick, or Grouping of filters. It has to be >> > indicated in some way. It could be done by grouping a > with >> > an ther avp ("Filter-Rule-Option AVP"). The latter can be used for >> > indicating extra options not supported by the AVP>. The avp >> > code of a "filter-rule-option avp" must be assigned so that >the session will >> > be terminated if the receiver does not understand the avp. As >usual the avp >> > should be returned to the sender, this way it is up to the sender to >> > determine if it can do without that specific option. >> >> hmmm.... the current proposed AVP has some fairly high chance of >> interoperability. Adding a new AVP as you suggest seems to >reduce that change >> dramatically, especially when the new AVP's behavior is not well >defined. From owner-aaa-bof@merit.edu Wed Jan 3 11:42:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10691 for ; Wed, 3 Jan 2001 11:42:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id A0CFD5DDC6; Wed, 3 Jan 2001 11:42:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F9E05DDC1; Wed, 3 Jan 2001 11:42:17 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5DEDB5DD8E for ; Wed, 3 Jan 2001 11:42:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14734; Wed, 3 Jan 2001 08:41:54 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA07381; Wed, 3 Jan 2001 08:41:53 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA11024; Wed, 3 Jan 2001 08:41:49 -0800 (PST) Date: Wed, 3 Jan 2001 08:38:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt To: Fredrik Johansson Cc: Barney Wolff , Pat Calhoun , Bernard Aboba , 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 > That's true, but a is not limited to be used by a NAS, it > can also be used to push rules to a firewall when a user registers. > Therefore, I would like the to be as general as possible. > However a receiver that does not understand the grouping can not accept the > rules as is since it might cause security problems. If a reject is sent > indicating that it failed because of the grouping, it is up to the server to > retry with a new set of rules (if it find that it can mananage with the > weaker security). > Could I, perhaps, ask that you provide some actual text, of AVP definition, that I could read and understand better? I *thought* I understood, but now I find myself lost. Support of Grouped Filter-Rules is mandatory, but it sounds like you need/want more. PatC From owner-aaa-bof@merit.edu Wed Jan 3 11:44:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10759 for ; Wed, 3 Jan 2001 11:44:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 006075DDED; Wed, 3 Jan 2001 11:44:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E249B5DDCB; Wed, 3 Jan 2001 11:44:12 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id 2C6A35DD8E for ; Wed, 3 Jan 2001 11:44:11 -0500 (EST) Received: from fredrikj (c8.localhost.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA22223; Wed, 3 Jan 2001 17:43:33 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "Bernard Aboba" , Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt Date: Wed, 3 Jan 2001 17:45:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk comments below. /Fredrik >-----Original Message----- >From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] >Sent: den 3 januari 2001 15:23 >To: Fredrik Johansson >Cc: Pat Calhoun; Bernard Aboba; aaa-wg@merit.edu >Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt > > >> After having browsed through draft-ietf-aaa-solutions-01.txt >this morning, >> here are some comments. >> >> - Section 3: If I'm not misstaken, consencus at the WG meeting >in San Diego >> was not to use ADIF for Accounting. > >Correct, so section 3 needs to be updated. However, we need to get WG >concensus on the mailing list before removing ADIF. Bernard? > >> >> - Typo in section 4.2 "IPv5" > >ok. > >> >> - Section 7: Is there a document describing the protocol gateway >procedures? > >Yes, it can be found in the Implementor's Guidelines I-D. > ok, have not read it in a while. >> >> - Section 13: The Filter-Rule AVP provides the basic data needed for >> filtering. However if you would like to create more advanced filter using >> for example; Keep State, Quick, or Grouping of filters. It has to be >> indicated in some way. It could be done by grouping a > with >> an ther avp ("Filter-Rule-Option AVP"). The latter can be used for >> indicating extra options not supported by the . The avp >> code of a "filter-rule-option avp" must be assigned so that the >session will >> be terminated if the receiver does not understand the avp. As >usual the avp >> should be returned to the sender, this way it is up to the sender to >> determine if it can do without that specific option. > >hmmm.... the current proposed AVP has some fairly high chance of >interoperability. Adding a new AVP as you suggest seems to reduce >that change >dramatically, especially when the new AVP's behavior is not well defined. > I agree that the original AVP should be as is to increase the chance of interoperability. However, if it should be possible to group filter-rules together and/or add extra options to it not specified in the so I believe that some mechanism need to be specified. If the receiver doesn't understand the grouping, it sends a reply saying so and it is up to the Diameter server to make a policy decision if it would like to retry using simpler rules. /Fredrik >PatC From owner-aaa-bof@merit.edu Wed Jan 3 12:44:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11820 for ; Wed, 3 Jan 2001 12:44:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 065A25DDC1; Wed, 3 Jan 2001 12:44:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAE905DD8E; Wed, 3 Jan 2001 12:44:02 -0500 (EST) Received: from kb (host-216-78-52-69.ath.bellsouth.net [216.78.52.69]) by segue.merit.edu (Postfix) with SMTP id 70DE05DDB9 for ; Wed, 3 Jan 2001 12:44:00 -0500 (EST) From: "The Solution" To: Subject: Finally Available !! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 3 Jan 2001 12:51:57 Message-Id: <20010103174400.70DE05DDB9@segue.merit.edu> Sender: owner-aaa-bof@merit.edu Precedence: bulk Exciting News! Now available for the U.S.......a TRUE Unlimited Use Flat Fee Long Distance! ++ No internet ++ No credit check ++ No pin codes ++ No contract ++ No changing current carrier Covers in state and out of state long distance. Available 24/7 Fiber optic quality Personal, SOHO Business or Commercial ****************************************** SPECIAL INCENTIVE******************************* For everyone choosing this offer: A 3 Day, 2 Night Grand Getaway Vacation of your choice! ( over 20 locations to choose from )( not a timeshare ) plus; $500.00 in Spending Benefits! Call toll free: 1-877-276-5171 for details or to order. Agents needed: Earn several hundred dollars a day! Work from your home with your own business. (not MLM or telemarketing). Telecommunications is HOT!! ....and our system does the selling for you! This message is sent in compliance of the new email bill section 301. Under Bill S.1618 TITLE III passed by the 105th US Congress. This message cannot be considered spam as long as we include the way to be removed, Paragraph (a)(c) of S.1618, further transmissions to you may be stopped at no cost to you by sending us, "Remove" , mailto:returned@hotmail.com From owner-aaa-bof@merit.edu Wed Jan 3 14:51:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14563 for ; Wed, 3 Jan 2001 14:51:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63D5B5DDA2; Wed, 3 Jan 2001 14:51:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3DCFE5DDC2; Wed, 3 Jan 2001 14:51:20 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id C9C005DDA2 for ; Wed, 3 Jan 2001 14:51:18 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id PAA01644 for ; Wed, 3 Jan 2001 15:47:02 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id OAA03383 for ; Wed, 3 Jan 2001 14:51:32 -0500 (EST) From: "Mark Jones" To: Subject: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 Date: Wed, 3 Jan 2001 14:58:01 -0500 Message-ID: <001e01c075bf$7a089500$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk I have a couple of questions on Section 6.1 of the AAA Solutions draft: In an access wholesaling scenario, the User-Name AVP may be present in the AAA request but the decision to proxy is still based on the Called-Station-Id AVP (or some other AVP) since the realm portion of the NAI has no significance to the access wholesaler. Should the Home-Realm AVP still be appended by the first hop DIAMETER proxy in this case? In the case of a proxy chain, the first hop DIAMETER proxy appends the Home-Realm AVP that it used to route the message to the second hop DIAMETER proxy. However, if the second hop DIAMETER uses a different Home-Realm to route to the final destination, is it expected to append a second Home-Realm AVP to the request? For example, the first hop DIAMETER proxy routes based on the Called-Station-Id AVP and the second hop DIAMETER proxy routes based on the realm portion of the User-Name AVP. The draft states that "When present, the Home-Realm AVP MUST be used to perform any message routing decisions." (section 6.4.2.3) but this does not appear to be practical in this case. In a proxy chain, I think the Home-Realm is generally refined as the request gets closer to the server where the realm is locally supported so it is inappropriate for one DIAMETER proxy to dictate the message routing behavior of the next hop proxy using the Home-Realm AVP. Regards, Mark From owner-aaa-bof@merit.edu Wed Jan 3 17:00:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA16534 for ; Wed, 3 Jan 2001 17:00:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 804E15DE86; Wed, 3 Jan 2001 16:59:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 686D25DE81; Wed, 3 Jan 2001 16:59:55 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 34E365DE72 for ; Wed, 3 Jan 2001 16:59:54 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14938; Wed, 3 Jan 2001 13:59:52 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA07344; Wed, 3 Jan 2001 13:59:51 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA23131; Wed, 3 Jan 2001 13:59:49 -0800 (PST) Date: Wed, 3 Jan 2001 13:56:07 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 To: Mark Jones Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <001e01c075bf$7a089500$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I have a couple of questions on Section 6.1 of the AAA Solutions draft: Good. I hope to have a couple of answers for you (and thanks for taking the time to read the I-D). > > In an access wholesaling scenario, the User-Name AVP may be present in the > AAA request but the decision to proxy is still based on the > Called-Station-Id AVP (or some other AVP) since the realm portion of the NAI > has no significance to the access wholesaler. Should the Home-Realm AVP > still be appended by the first hop DIAMETER proxy in this case? It seems somewhat simple to allow the first hop to add the Home-Realm AVP. All that is needed is a Called-Station-Id -> Home Realm table, which can be provisioned when the contract is negotiated. > > In the case of a proxy chain, the first hop DIAMETER proxy appends the > Home-Realm AVP that it used to route the message to the second hop DIAMETER > proxy. However, if the second hop DIAMETER uses a different Home-Realm to > route to the final destination, is it expected to append a second Home-Realm > AVP to the request? May I ask why two would be necessary? Is the outsourcer, outsourcing? I would have expected the Home-Realm to be the same in both cases, no? > > For example, the first hop DIAMETER proxy routes based on the > Called-Station-Id AVP and the second hop DIAMETER proxy routes based on the > realm portion of the User-Name AVP. The draft states that "When present, the > Home-Realm AVP MUST be used to perform any message routing decisions." > (section 6.4.2.3) but this does not appear to be practical in this case. If the User-Name is present, hence the NAI, why is this not used as opposed to the Called-Station-Id? Or are you in fact stating that many realms may be supported by a single Called-Station-Id, and the first hop doesn't care about realms, which I suppose is possible. > > In a proxy chain, I think the Home-Realm is generally refined as the request > gets closer to the server where the realm is locally supported so it is > inappropriate for one DIAMETER proxy to dictate the message routing behavior > of the next hop proxy using the Home-Realm AVP. ok. I *think* I understand the problem. Could you please provide me with proposed text changes that would support such a scenario? PatC From owner-aaa-bof@merit.edu Wed Jan 3 17:40:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17088 for ; Wed, 3 Jan 2001 17:40:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5CE85DDFC; Wed, 3 Jan 2001 17:40:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6A905DDC7; Wed, 3 Jan 2001 17:40:39 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 5C0675DDB8 for ; Wed, 3 Jan 2001 17:40:38 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA20028 for ; Wed, 3 Jan 2001 17:46:17 -0500 (EST) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma020020; Wed, 3 Jan 01 17:45:21 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id RAA18859 for ; Wed, 3 Jan 2001 17:39:40 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 17:39:40 -0500 Message-ID: From: "Nelson, David" To: aaa-wg@merit.edu Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 Date: Wed, 3 Jan 2001 17:39:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075D6.0E22E856" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C075D6.0E22E856 Content-Type: text/plain; charset="iso-8859-1" >> In a proxy chain, I think the Home-Realm is generally refined as the request >> gets closer to the server where the realm is locally supported so it is >> inappropriate for one DIAMETER proxy to dictate the message routing behavior >> of the next hop proxy using the Home-Realm AVP. > ok. I *think* I understand the problem. Could you please provide me with > proposed text changes that would support such a scenario? I'm trying to reconstruct the thought process that went into the relevant section of the AAA Solutions ID. I don't think we considered scenarios in which the home realm would change along the proxy path. For me, the home realm would likely be "enterasys.com", and while the request might traverse more than one proxy, the ultimate destination would not likely change. The only scenario in which I might see it changing is when pseudonyms are used. This would be analogous to SMTP forwarding, in which an address of the form "dave@some-vanity-domain.com" might get translated and forwarded to "dnelson@my-real-ISP.net". Is this the sort of usage envisioned here? Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C075D6.0E22E856 Content-Type: text/html; charset="iso-8859-1" RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1

 
>> In a proxy chain, I think the Home-Realm is generally refined as the request
>> gets closer to the server where the realm is locally supported so it is
>> inappropriate for one DIAMETER proxy to dictate the message routing behavior
>> of the next hop proxy using the Home-Realm AVP.

> ok. I *think* I understand the problem. Could you please provide me with
> proposed text changes that would support such a scenario?

I'm trying to reconstruct the thought process that went into the relevant section
of the AAA Solutions ID.  I don't think we considered scenarios in which the
home realm would change along the proxy path. For me, the home realm would likely
be "enterasys.com", and while the request might traverse more than one proxy, the
ultimate destination would not likely change.  The only scenario in which I might
see it changing is when pseudonyms are used.  This would be analogous to SMTP
forwarding, in which an address of the form "dave@some-vanity-domain.com" might get
translated and forwarded to "dnelson@my-real-ISP.net".  Is this the sort of usage
envisioned here?

Regards,
 
Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com
 

------_=_NextPart_001_01C075D6.0E22E856-- From owner-aaa-bof@merit.edu Wed Jan 3 18:21:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA17501 for ; Wed, 3 Jan 2001 18:21:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 43AF05DDC7; Wed, 3 Jan 2001 18:21:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 32B9E5DDB8; Wed, 3 Jan 2001 18:21:17 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id AA21C5DD8D for ; Wed, 3 Jan 2001 18:21:15 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA03309 for ; Wed, 3 Jan 2001 19:17:03 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA07154 for ; Wed, 3 Jan 2001 18:21:33 -0500 (EST) From: "Mark Jones" To: Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 Date: Wed, 3 Jan 2001 18:28:02 -0500 Message-ID: <000801c075dc$d0bb13b0$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk > > I have a couple of questions on Section 6.1 of the AAA Solutions draft: > > Good. I hope to have a couple of answers for you (and thanks for > taking the > time to read the I-D). > Thanks for your quick reply, Pat. Clarifications are inline. > > > > In an access wholesaling scenario, the User-Name AVP may be > present in the > > AAA request but the decision to proxy is still based on the > > Called-Station-Id AVP (or some other AVP) since the realm > portion of the NAI > > has no significance to the access wholesaler. Should the Home-Realm AVP > > still be appended by the first hop DIAMETER proxy in this case? > > It seems somewhat simple to allow the first hop to add the > Home-Realm AVP. All > that is needed is a Called-Station-Id -> Home Realm table, which can be > provisioned when the contract is negotiated. > My concern is that the first hop DIAMETER proxy may not know the Home-Realm of the subscriber. It may only know the Home-Realm for the next hop. > > > > In the case of a proxy chain, the first hop DIAMETER proxy appends the > > Home-Realm AVP that it used to route the message to the second > hop DIAMETER > > proxy. However, if the second hop DIAMETER uses a different > Home-Realm to > > route to the final destination, is it expected to append a > second Home-Realm > > AVP to the request? > > May I ask why two would be necessary? Is the outsourcer, > outsourcing? I would > have expected the Home-Realm to be the same in both cases, no? > Yes, the outsourcer is outsourcing. The access wholesaler provides a dedicated 1-800 number for a large service provider. At the first hop DIAMETER proxy, the decision to proxy is therefore based on the Called-Station-Id AVP. The large service provider has several large corporate customers each with their own DIAMETER server. The second hop DIAMETER proxy (belonging to the service provider) makes its decision to proxy based on the realm component of the NAI (the realm of the corporation). > > > > For example, the first hop DIAMETER proxy routes based on the > > Called-Station-Id AVP and the second hop DIAMETER proxy routes > based on the > > realm portion of the User-Name AVP. The draft states that "When > present, the > > Home-Realm AVP MUST be used to perform any message routing decisions." > > (section 6.4.2.3) but this does not appear to be practical in this case. > > If the User-Name is present, hence the NAI, why is this not used > as opposed to > the Called-Station-Id? Or are you in fact stating that many realms may be > supported by a single Called-Station-Id, and the first hop > doesn't care about > realms, which I suppose is possible. > Exactly. In my example there are many realms supported via a single Called-Station-Id so the first hop DIAMETER proxy makes the proxy decision based on the Called-Station Id, adds Home-Realm="bigisp.com" to the request and forwards it onto the second hop DIAMETER server belonging to the large service provider. This Home-Realm AVP is of no use to the second hop DIAMETER proxy in determining how to route the message to its destination. At first glance, this looks like a low runner scenario but with the increasing specialization of the access/service providers, we are seeing more occurances of proxy policies like this amongst our RADIUS customers. > > > > In a proxy chain, I think the Home-Realm is generally refined > as the request > > gets closer to the server where the realm is locally supported so it is > > inappropriate for one DIAMETER proxy to dictate the message > routing behavior > > of the next hop proxy using the Home-Realm AVP. > > ok. I *think* I understand the problem. Could you please provide me with > proposed text changes that would support such a scenario? > Let me know if further clarification is required for the scenario described above. The conclusion is that the Home-Realm AVP as currently specified can not be used consistently to perform message routing decisions. So we can either tighten up the conditions around when it should be added to a packet, e.g. "The Home-Realm AVP MUST only be added by a first hop DIAMETER proxy if the Home-Realm of the subscriber is known". (But how does the first hop DIAMETER proxy know if the Home-Realm on which it made its proxy decision is the Home-Realm of the subscriber?) Or we can relax the conditions surrounding its use for message routing by the next hop DIAMETER proxy, e.g. "When present, the Home-Realm AVP MAY be used to perform message routing decisions". Regards, Mark From owner-aaa-bof@merit.edu Wed Jan 3 18:35:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA17649 for ; Wed, 3 Jan 2001 18:35:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 213D65DE3E; Wed, 3 Jan 2001 18:34:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 10AA65DDB8; Wed, 3 Jan 2001 18:34:17 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A9F6B5DD8D for ; Wed, 3 Jan 2001 18:34:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00396; Wed, 3 Jan 2001 15:34:11 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA10639; Wed, 3 Jan 2001 15:34:07 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA26612; Wed, 3 Jan 2001 15:33:51 -0800 (PST) Date: Wed, 3 Jan 2001 15:30:20 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 To: Mark Jones Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <000801c075dc$d0bb13b0$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk [lots of good stuff deleted] > My concern is that the first hop DIAMETER proxy may not know the Home-Realm > of the subscriber. It may only know the Home-Realm for the next hop. ok, I think that I understand the situation, and I believe that it can easily be fixed by changing a MUST to a SHOULD and some additional clarifying text. The following: " There are instances where the User-Name AVP is not present in authorization requests. This is typically true in networks where a request is sent to the network before the call was even answered. However, such requests MAY need to be proxied. In such cases, the first hop DIAMETER proxy MUST append the Home-Realm AVP to the DIAMETER message, by using a DNIS or ANI to Home-Realm association table." would be changed to: " ... In such cases, the first hop DIAMETER proxy SHOULD append the Home-Realm AVP to the DIAMETER message, by using a DNIS or ANY to Home-Realm association table, if it is known. If the message is forwarded to a downstream proxy, the proxy MAY add the missing Home-Realm AVP, if the realm associated with the DNIS or ANI is known." Would this cover the case you described? Is it clear enough? PatC From owner-aaa-bof@merit.edu Wed Jan 3 18:55:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA17822 for ; Wed, 3 Jan 2001 18:55:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB3535DDB8; Wed, 3 Jan 2001 18:55:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BB2DF5DDCF; Wed, 3 Jan 2001 18:55:35 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id D12295DDB8 for ; Wed, 3 Jan 2001 18:55:34 -0500 (EST) Received: from [63.193.24.36] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G6M002FZ1K4LE@mta5.snfc21.pbi.net> for aaa-wg@merit.edu; Wed, 3 Jan 2001 15:36:04 -0800 (PST) Date: Wed, 03 Jan 2001 15:38:00 -0800 From: Richard Perlman Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 In-reply-to: X-Sender: rdp@mail.yikes.com (Unverified) To: "Nelson, David" , aaa-wg@merit.edu Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" ; format="flowed" References: Sender: owner-aaa-bof@merit.edu Precedence: bulk Dave: I think you are referring to DNS "MX" records which provide the reference from the "external" domain some "less public" domain. In the existing AAA model this is simply done on the AAA server through some "implementation specific" means. The example case would be an ISP (isp-inc) that provides remote access services for a number of banks. Every bank user is allowed to use the roaming alliance the ISP belongs to. So that NAIs of the form user@bank1 should really go to is to isp-inc -- but the original NAI must be kept intact so that isp-inc can correctly resolve the request. Getting back to the original question of the "first hop" processing. I think that each AAA server needs to always be able to determine the next hop (without knowing if it is the final hop or not). The AAA server also needs to know what information must be included (and how, i.e. in which attributes) so that the next hop can properly process the request. In my experience these types of arrangements are almost always unique to the pair of companies exchanging the data. Which leads to... At 1:56 PM -0800 1/3/01, Pat Calhoun wrote: >If the User-Name is present, hence the NAI, why is this not used as opposed to >the Called-Station-Id? Or are you in fact stating that many realms may be >supported by a single Called-Station-Id, and the first hop doesn't care about >realms, which I suppose is possible. This is often the case. In practice there are cases where... Many realms all use one DNIS (often with differing NAI formats) Many realms use many DNISs and one realm uses one DNIS so... >The draft states that "When present, the > Home-Realm AVP MUST be used to perform any message routing decisions." > (section 6.4.2.3) but this does not appear to be practical in this case. Would be wrong, or at least not a complete statement of the problem. and... > so it is > inappropriate for one DIAMETER proxy to dictate the message routing behavior > of the next hop proxy using the Home-Realm AVP. Is very true (in fact in my opinion, it should never dictate the behavior of the next hop server - regardless of AVP) . Each AAA server (regardless of protocol) should only be expected to provide the next-hop AAA server with the information needed to successfully process the request. Such processing may result in another forward or final resolution of the request. Richard As Nelson, David wrote (1/3/01 5:39 PM -0500): >The only scenario in which I might >see it changing is when pseudonyms are used. This would be analogous to SMTP >forwarding, in which an address of the form >"dave@some-vanity-domain.com" might get >translated and forwarded to "dnelson@my-real-ISP.net". Is this the >sort of usage >envisioned here? From owner-aaa-bof@merit.edu Wed Jan 3 19:12:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18080 for ; Wed, 3 Jan 2001 19:12:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9F4F5DDCF; Wed, 3 Jan 2001 19:11:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BB4645DE02; Wed, 3 Jan 2001 19:11:39 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 5B56F5DDCF for ; Wed, 3 Jan 2001 19:11:38 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id QAA13084; Wed, 3 Jan 2001 16:11:36 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01451; Wed, 3 Jan 01 16:34:31 -0800 Date: Wed, 3 Jan 2001 16:34:31 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Pat Calhoun Cc: Fredrik Johansson , Barney Wolff , Pat Calhoun , aaa-wg@merit.edu Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Could I, perhaps, ask that you provide some actual text, of AVP definition, > that I could read and understand better? In general, providing the text of a requested change is a good thing. That way we can make sure that we actually understand the request before discussing whether it is worthwhile ;) From owner-aaa-bof@merit.edu Wed Jan 3 19:12:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18088 for ; Wed, 3 Jan 2001 19:12:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E779C5DE27; Wed, 3 Jan 2001 19:11:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3BD065DE36; Wed, 3 Jan 2001 19:11:49 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id CD2B15DE1C for ; Wed, 3 Jan 2001 19:11:45 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id QAA19620; Wed, 3 Jan 2001 16:11:34 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01431; Wed, 3 Jan 01 16:27:47 -0800 Date: Wed, 3 Jan 2001 16:27:46 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Pat Calhoun Cc: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Correct, so section 3 needs to be updated. However, we need to get WG > concensus on the mailing list before removing ADIF. Bernard? > We haven't had any objections so far to the Request for Discussion on ADIF removal. So if anyone objects to removing ADIF, please speak up NOW! From owner-aaa-bof@merit.edu Wed Jan 3 19:36:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA18583 for ; Wed, 3 Jan 2001 19:36:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E0DC5DE1C; Wed, 3 Jan 2001 19:36:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E8045DE04; Wed, 3 Jan 2001 19:36:08 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id 2A9295DE02 for ; Wed, 3 Jan 2001 19:36:07 -0500 (EST) Received: from [63.193.24.36] by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G6M00KHF1P5NM@mta6.snfc21.pbi.net> for aaa-wg@merit.edu; Wed, 3 Jan 2001 15:39:05 -0800 (PST) Date: Wed, 03 Jan 2001 15:41:11 -0800 From: Richard Perlman Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 In-reply-to: X-Sender: rdp@mail.yikes.com (Unverified) To: Pat Calhoun , Mark Jones Cc: aaa-wg@merit.edu Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" ; format="flowed" References: Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat: Given the wide variance in operating models, I think the SHOULD should be a MAY. Richard As Pat Calhoun wrote (1/3/01 3:30 PM -0800): >would be changed to: > >" ... In such cases, the first hop DIAMETER proxy SHOULD append the > Home-Realm AVP to the DIAMETER message, by using a DNIS or ANY to > Home-Realm association table, if it is known. If the message is > forwarded to a downstream proxy, the proxy MAY add the missing > Home-Realm AVP, if the realm associated with the DNIS or ANI is > known." > >Would this cover the case you described? Is it clear enough? From owner-aaa-bof@merit.edu Wed Jan 3 21:35:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA21467 for ; Wed, 3 Jan 2001 21:35:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2E4F5DDD4; Wed, 3 Jan 2001 21:35:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C00E85DE03; Wed, 3 Jan 2001 21:35:35 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 9DC1E5DDD4 for ; Wed, 3 Jan 2001 21:35:34 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f042ZYK02207; Wed, 3 Jan 2001 20:35:34 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f042ZXB22719; Wed, 3 Jan 2001 20:35:33 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop.exu.ericsson.se [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id UAA02248; Wed, 3 Jan 2001 20:35:32 -0600 (CST) Received: from kev (busam65.berkeley.us.am.ericsson.se [138.85.159.215]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id UAA10187; Wed, 3 Jan 2001 20:35:31 -0600 (CST) Message-ID: <010201c075f6$a4395800$91aea8c0@erilab.com> From: "Kevin Purser" To: "Bernard Aboba" , Cc: "Tony Johansson" References: Subject: Re: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-01.txt Date: Wed, 3 Jan 2001 18:32:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk With the omission of section 9.3 (formal notation), section 8 (security), and section 5 (transport), we would agree on the move to WG last call. With these omissions, we are left to assume that the transport layer will default to SCTP (as indicated in the current base protocol draft), *for the time being*. This assumption must be made now considering upcoming testing during the March Connectathon. Also, in section 6.2.1, perhaps we can remove the "OTHER" action. Just a sidenote, while the April deadline is obviously important, we would like to stress the March Connectathon is equally important, since the results of this event could have a large impact on the protocol prior to the April deadline. ++++++++++++++++++++++++++++++++++++++++++++++++++ Kevin Purser Software Engineer III +1 (510) 305-6100 ++++++++++++++++++++++++++++++++++++++++++++++++++ Ericsson Berkeley Wireless Center 2100 Shattuck Avenue Berkeley, CA 94704 ++++++++++++++++++++++++++++++++++++++++++++++++++ ----- Original Message ----- From: "Bernard Aboba" To: Sent: Wednesday, December 20, 2000 10:41 AM Subject: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt > At IETF 49, Pat Calhoun presented draft-ietf-aaa-solutions-00.txt. > > With the exception of three areas (transport, security and > data modelling), we did not have a great deal of comment on > the solutions draft. > > As a result, I'd like to request that AAA WG members re-read > the solutions draft, and comment on whether it is adequate > aside from the three areas above. > > If we do indeed have consensus on the rest of the solutions > draft, then one possible approach would be to break off the > discussion of transport, security and data modelling into > separate drafts, move the rest of the solutions draft to > WG last call and make the indicated changes to the DIAMETER > spec. > > Opinions? > From owner-aaa-bof@merit.edu Wed Jan 3 23:23:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA24132 for ; Wed, 3 Jan 2001 23:23:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id CADD15DEBE; Wed, 3 Jan 2001 23:22:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8CB155DEC2; Wed, 3 Jan 2001 23:22:03 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id AA0EF5DEBE for ; Wed, 3 Jan 2001 23:22:00 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f044JRC06429 for ; Wed, 3 Jan 2001 20:19:27 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: Making the hard choices on AAA security Date: Wed, 3 Jan 2001 20:22:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk In the spirit of the AAA WG, which has always chosen to tackle the hard problems early, I would like to pose the following question: "What is the minimum security functionality that we need to meet the requirements?" Notice, I didn't ask: "How much security functionality can we cram in?" In discussing security there may be an assumption that we can have lots of security options. For example, we might make shared secret mandatory, throw in various options on hop-by-hop (IPSEC, SSL), and for good measure specify a couple of ways to do e2e security (CMS, Kerberos). Therein lies the road to h*ll. As Jeff Case has so eloquently stated, optional features are bad. You have to implement them because someone else might want to use them, but you can never be guaranteed to reap the benefits. I'd rather have one strong mandatory mechanism than one weak mandatory one and an optional strong mechanism. So, the question is "what must we have?" I think the case has been made that e2e security is needed in *some* circumstances. Not all circumstances -- for example, if you use referal you don't need it. Can we live with *one* e2e mechanism being the *only* security mechanism we support? If so, which one? If not, why won't this be adequate? And if we do this, can we get rid of the RADIUS password-hiding mechanism? If you think that we need hop by hop security too, how many of *those* mechanisms do we need? Can we live with *one* of those? Which one? If you think that IPSEC alone will magically sole our hop by hop security problems, think about this: a. IPSEC transport mode is not very widely deployed today. In fact, I know of no RADIUS deployment running over IPSEC. b. Specifying IPSEC doesn't guarantee instant interoperability. It's taken quite a while to get interoperability between L2TP/IPSEC implementations. To summarize: "There is no silver bullet, only hard choices". From owner-aaa-bof@merit.edu Thu Jan 4 01:30:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA00534 for ; Thu, 4 Jan 2001 01:30:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A6105DE4C; Thu, 4 Jan 2001 00:25:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 38B585DE03; Thu, 4 Jan 2001 00:25:24 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id A3D295DE4B for ; Thu, 4 Jan 2001 00:25:21 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA25049; Thu, 4 Jan 2001 10:51:21 +0530 (IST) From: Kaushik Narayan Message-Id: <200101040521.KAA25049@cisco.com> Subject: Re: Making the hard choices on AAA security To: aboba@internaut.com (Bernard Aboba) Date: Thu, 4 Jan 2001 10:51:21 +0530 (IST) Cc: aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) In-Reply-To: from "Bernard Aboba" at Jan 03, 2001 08:22:06 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk hi all, Find my comments inline > > In the spirit of the AAA WG, which has always chosen > to tackle the hard problems early, I would like to > pose the following question: > > "What is the minimum security functionality that we > need to meet the requirements?" > > Notice, I didn't ask: > > "How much security functionality can we cram in?" > > In discussing security there may be an assumption > that we can have lots of security options. > > For example, we might make shared secret > mandatory, throw in various options on hop-by-hop > (IPSEC, SSL), and for good measure specify a > couple of ways to do e2e security (CMS, Kerberos). > > Therein lies the road to h*ll. > > As Jeff Case has so eloquently stated, optional > features are bad. You have to implement them > because someone else might want to use them, > but you can never be guaranteed to reap the benefits. > > I'd rather have one strong mandatory mechanism than > one weak mandatory one and an optional strong > mechanism. > > So, the question is "what must we have?" > > I think the case has been made that e2e security > is needed in *some* circumstances. Not all > circumstances -- for example, if you use > referal you don't need it. > > Can we live with *one* e2e mechanism being > the *only* security mechanism we support? > If so, which one? If not, why won't this be > adequate? One solution to this problem is the use of GSSAPI for end-to-end security for diameter. I have been investigating this since the San Deigo meeting. The use of GSSAPI would mean that implementations need not bind the AAA security to a particular mechanism. kaushik! > > And if we do this, can we get rid of the > RADIUS password-hiding mechanism? > > If you think that we need hop by hop security > too, how many of *those* mechanisms do we need? > Can we live with *one* of those? Which one? > > If you think that IPSEC alone will magically > sole our hop by hop security problems, think > about this: > > a. IPSEC transport mode is not very widely > deployed today. In fact, I know of no RADIUS > deployment running over IPSEC. > > b. Specifying IPSEC doesn't guarantee > instant interoperability. It's taken quite a > while to get interoperability between > L2TP/IPSEC implementations. > > To summarize: > > "There is no silver bullet, only hard choices". > > From owner-aaa-bof@merit.edu Thu Jan 4 02:02:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA00992 for ; Thu, 4 Jan 2001 02:02:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE5745DDD5; Thu, 4 Jan 2001 02:00:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C5E385DE5B; Thu, 4 Jan 2001 02:00:23 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id A506B5DDD5 for ; Thu, 4 Jan 2001 02:00:21 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f046viC15038; Wed, 3 Jan 2001 22:57:44 -0800 From: "Bernard Aboba" To: "Kevin Purser" , Cc: "Tony Johansson" Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-01.txt Date: Wed, 3 Jan 2001 23:00:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <010201c075f6$a4395800$91aea8c0@erilab.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk >Just a sidenote, while the April deadline is obviously important, we would >like to stress the March Connectathon is equally important, since the >results of this event could have a large impact on the protocol prior to the >April deadline. Good point. We live by "rough consensus and running code." The ultimate test of a spec is whether people can interoperate purely based on what is written there. So any issues that come up at Connecathon are candidates for clarification. From owner-aaa-bof@merit.edu Thu Jan 4 02:19:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA01324 for ; Thu, 4 Jan 2001 02:19:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA5715DE57; Thu, 4 Jan 2001 02:19:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DAC165DE03; Thu, 4 Jan 2001 02:19:13 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 547925DE4B for ; Thu, 4 Jan 2001 02:19:12 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f047GcC16182; Wed, 3 Jan 2001 23:16:38 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Cc: "Smb@Research. Att. Com" Subject: Re: Making the hard choices on AAA security Date: Wed, 3 Jan 2001 23:19:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk The question of the day is: "How simple can we make this and still solve the problem?" > One solution to this problem is the use of > GSSAPI for end-to-end security for diameter. > I have been investigating this since the San > Deigo meeting. The use of GSSAPI would mean > that implementations need not bind the AAA > security to a particular mechanism. A few questions: a. How would GSSAPI work if you need more than a single round trip? I assume we would carry the GSSAPI tokens in the AAA request/response messages, no? Is the restriction to a single round-trip important or not? b. What is the mandatory to implement GSSAPI method for DIAMETER? KerbV? c. Assuming we do this, are we done? In other words, can we assume we *always* have at least e2e authentication/integrity protection turned on, and therefore don't need any hop-by-hop security? Or do we need password hiding because we may not always have confidentiality or hop-by-hop auth/integrity because we don't cover enough of the message with e2e? How simple can we make this and still solve the problem? -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Wednesday, January 03, 2001 8:22 PM To: Aaa-Wg@Merit. Edu Subject: Making the hard choices on AAA security In the spirit of the AAA WG, which has always chosen to tackle the hard problems early, I would like to pose the following question: "What is the minimum security functionality that we need to meet the requirements?" Notice, I didn't ask: "How much security functionality can we cram in?" In discussing security there may be an assumption that we can have lots of security options. For example, we might make shared secret mandatory, throw in various options on hop-by-hop (IPSEC, SSL), and for good measure specify a couple of ways to do e2e security (CMS, Kerberos). Therein lies the road to h*ll. As Jeff Case has so eloquently stated, optional features are bad. You have to implement them because someone else might want to use them, but you can never be guaranteed to reap the benefits. I'd rather have one strong mandatory mechanism than one weak mandatory one and an optional strong mechanism. So, the question is "what must we have?" I think the case has been made that e2e security is needed in *some* circumstances. Not all circumstances -- for example, if you use referal you don't need it. Can we live with *one* e2e mechanism being the *only* security mechanism we support? If so, which one? If not, why won't this be adequate? And if we do this, can we get rid of the RADIUS password-hiding mechanism? If you think that we need hop by hop security too, how many of *those* mechanisms do we need? Can we live with *one* of those? Which one? If you think that IPSEC alone will magically sole our hop by hop security problems, think about this: a. IPSEC transport mode is not very widely deployed today. In fact, I know of no RADIUS deployment running over IPSEC. b. Specifying IPSEC doesn't guarantee instant interoperability. It's taken quite a while to get interoperability between L2TP/IPSEC implementations. To summarize: "There is no silver bullet, only hard choices". From owner-aaa-bof@merit.edu Thu Jan 4 06:58:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA04667 for ; Thu, 4 Jan 2001 06:58:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2AD95DE7D; Thu, 4 Jan 2001 06:58:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C0DD05DE7C; Thu, 4 Jan 2001 06:58:18 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id E2F425DE79 for ; Thu, 4 Jan 2001 06:58:15 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA06616; Thu, 4 Jan 2001 17:24:12 +0530 (IST) From: Kaushik Narayan Message-Id: <200101041154.RAA06616@cisco.com> Subject: Re: Making the hard choices on AAA security To: aboba@internaut.com (Bernard Aboba) Date: Thu, 4 Jan 2001 17:24:12 +0530 (IST) Cc: aaa-wg@merit.edu (Aaa-Wg@Merit. Edu), smb@research.att.com (Smb@Research. Att. Com) In-Reply-To: from "Bernard Aboba" at Jan 03, 2001 11:19:18 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk bernard, hi! Find my reply inline. > > The question of the day is: > > "How simple can we make this and still solve > the problem?" > > > One solution to this problem is the use of > > GSSAPI for end-to-end security for diameter. > > I have been investigating this since the San > > Deigo meeting. The use of GSSAPI would mean > > that implementations need not bind the AAA > > security to a particular mechanism. > > A few questions: > > a. How would GSSAPI work if you need more than > a single round trip? I assume we would carry > the GSSAPI tokens in the AAA request/response > messages, no? Is the restriction to a single > round-trip important or not? Actually GSSAPI needs the underlying communication protocol (diameter in this case) to support more than a single round trip for session initiation. This is because some of the GSSAPI mechanisms require more than a single round trip for establishment of a security context. GSSAPI tokens would be carried in AAA requests and responses. GSSAPI has two components. 1> generic token formats and API definition These token formats are defined in RFC 2743 are mechanism independent and used for context establishment. These tokens are contain identifiers which indicate the mechanism to be used. 2> mechanism specific tokens formats, protocols and procedures these are to be implemented in order to realize GSS-API services atop particular security mechanisms. Some of the popular mechanims that have defined GSSAPI mechanisms. RFC2025 - The Simple Public-Key GSS-API Mechanism (SPKM) RFC1964 - The Kerberos Version 5 GSS-API Mechanism > > b. What is the mandatory to implement GSSAPI > method for DIAMETER? KerbV? GSSAPI doesnot have any mandatory mechanism, you can plug any mechanism that supports GSSAPI. Diameter implementations would use GSSAPI bindings to implement security services and the Diameter protocol would carry GSSAPI tokens. It depends on the implementation of the libaries of the mechanism to support GSSAPI bindings. The MIT kerberos v5 library implements the GSSAPI C-bindings (RFC-1509). Negotiation of mechanisms between diameter peers would happen using the SPNEGO (The Simple and Protected GSS-API Negotiation Mechanism). > > c. Assuming we do this, are we done? In other > words, can we assume we *always* have at least > e2e authentication/integrity protection turned > on, and therefore don't need any hop-by-hop > security? Or do we need password hiding because > we may not always have confidentiality or > hop-by-hop auth/integrity because we don't > cover enough of the message with e2e? Well the need for hop-by-hop security is dependent on whether there would be data inspected/added on a hop by hop basis. For a Remote Access protocol like Radius most of the attributes are end-to-end except for (User-Name, Called-Station-Id and Proxy-State) so really end-to-end privacy and integrity protection would be enough. Minimally hop by hop integrity protection is enough. In case of diameter since the scope of the intermediate proxy is much broader (noy just a routing proxy), hop by hop security would be more relevant. kaushik! > > How simple can we make this and still solve > the problem? > > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, January 03, 2001 8:22 PM > To: Aaa-Wg@Merit. Edu > Subject: Making the hard choices on AAA security > > > In the spirit of the AAA WG, which has always chosen > to tackle the hard problems early, I would like to > pose the following question: > > "What is the minimum security functionality that we > need to meet the requirements?" > > Notice, I didn't ask: > > "How much security functionality can we cram in?" > > In discussing security there may be an assumption > that we can have lots of security options. > > For example, we might make shared secret > mandatory, throw in various options on hop-by-hop > (IPSEC, SSL), and for good measure specify a > couple of ways to do e2e security (CMS, Kerberos). > > Therein lies the road to h*ll. > > As Jeff Case has so eloquently stated, optional > features are bad. You have to implement them > because someone else might want to use them, > but you can never be guaranteed to reap the benefits. > > I'd rather have one strong mandatory mechanism than > one weak mandatory one and an optional strong > mechanism. > > So, the question is "what must we have?" > > I think the case has been made that e2e security > is needed in *some* circumstances. Not all > circumstances -- for example, if you use > referal you don't need it. > > Can we live with *one* e2e mechanism being > the *only* security mechanism we support? > If so, which one? If not, why won't this be > adequate? > > And if we do this, can we get rid of the > RADIUS password-hiding mechanism? > > If you think that we need hop by hop security > too, how many of *those* mechanisms do we need? > Can we live with *one* of those? Which one? > > If you think that IPSEC alone will magically > sole our hop by hop security problems, think > about this: > > a. IPSEC transport mode is not very widely > deployed today. In fact, I know of no RADIUS > deployment running over IPSEC. > > b. Specifying IPSEC doesn't guarantee > instant interoperability. It's taken quite a > while to get interoperability between > L2TP/IPSEC implementations. > > To summarize: > > "There is no silver bullet, only hard choices". > > From owner-aaa-bof@merit.edu Thu Jan 4 07:37:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA05033 for ; Thu, 4 Jan 2001 07:37:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FEE65DE42; Thu, 4 Jan 2001 07:37:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E4825DE2F; Thu, 4 Jan 2001 07:37:25 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id B0CEA5DDF6 for ; Thu, 4 Jan 2001 07:37:23 -0500 (EST) Received: by balinese.baltimore.ie; id MAA15633; Thu, 4 Jan 2001 12:37:22 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma015584; Thu, 4 Jan 01 12:37:06 GMT Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA21176; Thu, 4 Jan 2001 12:41:08 GMT Message-ID: <3A546E71.55311E53@baltimore.ie> Date: Thu, 04 Jan 2001 12:37:05 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Bernard, Good questions! > For example, we might make shared secret > mandatory, throw in various options on hop-by-hop > (IPSEC, SSL), and for good measure specify a > couple of ways to do e2e security (CMS, Kerberos). > > Therein lies the road to h*ll. Agreed. However, at least the above identifies the list from which to pick. My take would be that the CMS route (especially if generally usable in a way compatible with pkcs#7) would be the best, since implementations are more widely available than Kerberos and there's no need to introduce a separate on-line security server. I would also have some serious doubts that the type of inter-realm Kerberos required for e2e security for DIAMETER would really work well. I don't think that wrapping in GSS-API is necessary. The main benefit of GSS-API encapsulation would be if we wanted to be able to support multiple e2e security mechanisms at some later date. I'm not clear that that's required (i.e. I think picking one is probably right for DIAMETER). If multi-mechanism support were a requirement then you'd presumably have to mandate SPNEGO, which AFAIK is not widely implemented. (I don't even know of anyone who's actually deployed SPNEGO in a multi-vendor environment - maybe there is though?) The only downside of the CMS approach I can see is that it possibly introduces a dependency on the rcek I-D from the smime WG, which is needed for efficient use of CMS between pairs of DIAMETER servers that often use e2e security. If the usage patterns were such that use of e2e security between any particular pair of DIAMETER servers was infrequent, then CMS with asymmetric crypto (i.e. pkcs#7) is fine as is. I'm not sure if that's the case though. If the usage patterns are such that the rcek stuff is a dependency, we should initiate a chat with the smime WG chair (Russ Housley) to see how soon he'd be happy moving rcek to last call, optimistically, I'd guess it should be doable to get the WG last call on rcek by next month. (It's a *very* simple & obvious extension to CMS:-) > If you think that we need hop by hop security > too, how many of *those* mechanisms do we need? > Can we live with *one* of those? Which one? Given the transport (still SCTP, isn't it?) seems like IPSec is the only option, so at least the picking part is easy (unless you want to define how to use TLS over connectionless transports). I guess the difficulty is whether IPSec support is mandatory or optional. Personally, I don't know what'd be right there. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Thu Jan 4 07:50:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA05178 for ; Thu, 4 Jan 2001 07:50:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3E595DE7E; Thu, 4 Jan 2001 07:49:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E32875DE7A; Thu, 4 Jan 2001 07:49:45 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 08D5C5DE68 for ; Thu, 4 Jan 2001 07:49:45 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 9364D1E015; Thu, 4 Jan 2001 07:49:44 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA16679; Thu, 4 Jan 2001 07:49:43 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 5249535DC2; Thu, 4 Jan 2001 07:49:43 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Kaushik Narayan Cc: aboba@internaut.com (Bernard Aboba), aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) Subject: Re: Making the hard choices on AAA security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jan 2001 07:49:43 -0500 Message-Id: <20010104124943.5249535DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message <200101040521.KAA25049@cisco.com>, Kaushik Narayan writes: >hi all, > > > > One solution to this problem is the use of > GSSAPI for end-to-end security for diameter. > I have been investigating this since the San > Deigo meeting. The use of GSSAPI would mean > that implementations need not bind the AAA > security to a particular mechanism. It also means we don't have guaranteed interoperability, unless each party picks the same instantiation of GSSAPI. GSSAPI is precisely what its name implies: an API. --Steve Bellovin From owner-aaa-bof@merit.edu Thu Jan 4 07:51:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA05194 for ; Thu, 4 Jan 2001 07:51:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A50A5DDEC; Thu, 4 Jan 2001 07:51:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 298595DDF6; Thu, 4 Jan 2001 07:51:15 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 3BF9B5DDEC for ; Thu, 4 Jan 2001 07:51:14 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id CAEB71E021; Thu, 4 Jan 2001 07:51:13 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id HAA16729; Thu, 4 Jan 2001 07:51:13 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 538A235DC2; Thu, 4 Jan 2001 07:51:09 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: stephen.farrell@baltimore.ie Cc: Bernard Aboba , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jan 2001 07:51:08 -0500 Message-Id: <20010104125109.538A235DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message <3A546E71.55311E53@baltimore.ie>, Stephen Farrell writes: > > >Given the transport (still SCTP, isn't it?) seems >like IPSec is the only option, so at least the >picking part is easy (unless you want to define how >to use TLS over connectionless transports). I guess >the difficulty is whether IPSec support is mandatory >or optional. Personally, I don't know what'd be right >there. There is not yet a spec for SCTP over IPsec, though there is work going on. In particular, the hard part is extending IKE to support the multiple address feature. --Steve Bellovin From owner-aaa-bof@merit.edu Thu Jan 4 08:22:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA05474 for ; Thu, 4 Jan 2001 08:22:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D85B5DE71; Thu, 4 Jan 2001 08:20:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B8BA5DE70; Thu, 4 Jan 2001 08:20:24 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 86CFD5DE6D for ; Thu, 4 Jan 2001 08:20:22 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f04DK1G22312; Thu, 4 Jan 2001 14:20:03 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA13462; Thu, 4 Jan 2001 15:19:50 +0200 (EET) Message-ID: <3A547876.9AC6F9D3@lmf.ericsson.se> Date: Thu, 04 Jan 2001 15:19:50 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" Cc: stephen.farrell@baltimore.ie, Bernard Aboba , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: <20010104125109.538A235DC2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk "Steven M. Bellovin" wrote: > There is not yet a spec for SCTP over IPsec, though there is work going > on. In particular, the hard part is extending IKE to support the > multiple address feature. Yes, but isn't this "just" an optimization? The problem with SCTP and IPsec is that as SCTP allows multihoming, if you have many interfaces then you'll be doing combinatorial number of SAs. I.e., if you have 2 interfaces on 2 boxes, when your box boots it'll have to negotiate 2^2=4 SA pairs instead of 1. Alternatively, renegotiate upon interface going down, and pay a penalty in the form of a delay. Unless your box had very many interfaces or tries to do something stupid like establish new SAs for every communication, I wonder if this is a real problem for DIAMETER deployment. Let alone standardization, given that work is already in progress. In any case, I think the SCTP IKE work is important for other reasons. Where is it taking place, by the way? Can you say if we can create the SAs in one phase 2 exchange or do we need several or perhaps also another set of phase 1 exchanges? Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply. From owner-aaa-bof@merit.edu Thu Jan 4 08:33:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA05624 for ; Thu, 4 Jan 2001 08:33:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 681235DE58; Thu, 4 Jan 2001 08:31:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 53E4C5DE59; Thu, 4 Jan 2001 08:31:15 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 61D985DE58 for ; Thu, 4 Jan 2001 08:31:14 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 1AF211E015; Thu, 4 Jan 2001 08:31:14 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id IAA17291; Thu, 4 Jan 2001 08:31:11 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 41EA935DC2; Thu, 4 Jan 2001 08:31:11 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Jari Arkko Cc: stephen.farrell@baltimore.ie, Bernard Aboba , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jan 2001 08:31:11 -0500 Message-Id: <20010104133111.41EA935DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message <3A547876.9AC6F9D3@lmf.ericsson.se>, Jari Arkko writes: >"Steven M. Bellovin" wrote: > >> There is not yet a spec for SCTP over IPsec, though there is work going >> on. In particular, the hard part is extending IKE to support the >> multiple address feature. > >Yes, but isn't this "just" an optimization? The problem with SCTP >and IPsec is that as SCTP allows multihoming, if you have many >interfaces then you'll be doing combinatorial number of SAs. I.e., >if you have 2 interfaces on 2 boxes, when your box boots it'll >have to negotiate 2^2=4 SA pairs instead of 1. Alternatively, >renegotiate upon interface going down, and pay a penalty in the >form of a delay. You could do that, but it is, as you say, expensive. See my slides from Adelaide (in both IPsec and SIGTRANS) for details. > >Unless your box had very many interfaces or tries to do >something stupid like establish new SAs for every communication, >I wonder if this is a real problem for DIAMETER deployment. >Let alone standardization, given that work is already in progress. > >In any case, I think the SCTP IKE work is important for other >reasons. Where is it taking place, by the way? Can you say if >we can create the SAs in one phase 2 exchange or do we need >several or perhaps also another set of phase 1 exchanges? > It would be one phase 2 exchange for the list of addresses, with a new phase 1 if potential addresses are added or deleted dynamically. We assume that that case would be uncommon. The draft is being written by Angelos Keromytis, along with me, Randall Stewart, and John Ioannidis. It will almost certainly be part of the IPsec group's work, since it specifies extensions to IPsec and IKE, rather than to SCTP. --Steve Bellovin From owner-aaa-bof@merit.edu Thu Jan 4 09:05:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA05947 for ; Thu, 4 Jan 2001 09:05:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 256765DE2A; Thu, 4 Jan 2001 09:04:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 06B1D5DE59; Thu, 4 Jan 2001 09:04:47 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id 3CAF65DE2A for ; Thu, 4 Jan 2001 09:04:46 -0500 (EST) Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA32295; Thu, 4 Jan 2001 15:04:36 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "Barney Wolff" , "Bernard Aboba" , Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt Date: Thu, 4 Jan 2001 15:06:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi As I understand it the intention of the filter rules is to protect the operator network for traffic coming in direction A (see fig below). One other use could be for an operator to provide firewall services for the MN, for example, it would be good to be able to keep state in order to only allow traffic in direction B if it is initiated from the MN. +----+ A ----> +-----+ | MN |---------------------------| NAS |----Operator Network +----+ <---- B +-----+ What I'm afraid of is that the as specified today is not easily extensible. It has many of the basic things of filtering, but if you for example use the IPF filtering from OpenBSD there migth be other things that you would like to add. However, since I'm not that familiar with the internals of a NAS, I assume that the AVP is all that is needed to support typical operator NAS services. If so, I'm happy with that and it is more important to get the this I-D to last call so it migth be a better idea to write a separate I-D for how filters could be distributed for use in firewalls. May I then suggest a name change to ? Since there might be other filter rules for other uses. Then I have another question on the following paragraph in section 13.1: "Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny." The last sentence seems a bit strange. If there is no match, should the last rule really determine if the packet should be dropped or not. Another thing that might be worth mentioning is that the ordering of filters does matter. Since there are no restrictions on ordering among other AVPs it migth be a good idea to specify that the filters must be inserted in the order they appear in the received message. /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 3 januari 2001 17:38 >To: Fredrik Johansson >Cc: Barney Wolff; Pat Calhoun; Bernard Aboba; aaa-wg@merit.edu >Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt > > >> That's true, but a is not limited to be used >by a NAS, it >> can also be used to push rules to a firewall when a user registers. >> Therefore, I would like the to be as general >as possible. >> However a receiver that does not understand the grouping can not >accept the >> rules as is since it might cause security problems. If a reject is sent >> indicating that it failed because of the grouping, it is up to >the server to >> retry with a new set of rules (if it find that it can mananage with the >> weaker security). >> > >Could I, perhaps, ask that you provide some actual text, of AVP definition, >that I could read and understand better? I *thought* I understood, >but now I >find myself lost. Support of Grouped Filter-Rules is mandatory, >but it sounds >like you need/want more. > >PatC > From owner-aaa-bof@merit.edu Thu Jan 4 10:11:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07032 for ; Thu, 4 Jan 2001 10:11:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB7DF5DE31; Thu, 4 Jan 2001 10:10:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B7D3A5DDB0; Thu, 4 Jan 2001 10:10:37 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 8DAF95DE31 for ; Thu, 4 Jan 2001 10:10:36 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id HAA18797; Thu, 4 Jan 2001 07:10:34 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00379; Thu, 4 Jan 01 07:18:59 -0800 Date: Thu, 4 Jan 2001 07:18:59 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security In-Reply-To: <20010104002815.A48730@mx.databus.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I would consider the following scenarios to be solid arguments for e2e (e.g. confidentiality *and* auth/integrity services): a. Protection of PAP passwords (NAS to AAA server) b. Protection of tunnel passwords (AAA server to NAS) c. Protection of MIP keys (AAA server to NAS) Note that these scenarios are somewhat different from ones involving attribute changes, where it might be argued that "since DIAMETER supports re-directs, if you use a proxy instead, you're making a choice." Here, even though I might have a business relationship with a proxy requiring me to use it to get paid, that doesn't mean that I want to trust my user or tunnel passwords, MIP keys, etc. to it. In addition, there are solid reasons to want to improve the ability of a AAA server to confirm that the service it asked for is the one it actually received. Here the problem can easily occur at the NAS (have had this happen in real life) so it's not clear to me that e2e can provide the benefits by itself. I think you also need the following: d. The filter attribute described in the solutions document, so you can be sure *exactly* what filter you're getting (with the infamous "Forrest Gump" filter name you're never sure what you're gonna get). e. Dave Mitton has suggested addition of a confirming ACK from NAS to AAA server, which would enable the authentication server (not just accounting) to confirm that the received service is close enough to the requested one. In DIAMETER it seems like auth/accounting integration is assumed to be somewhat closer than in RADIUS, so I'm not clear that this is necessary -- you could accomplish the same thing with accounting only, and issuing an unsolicited server message to kill the session if there was a discrepancy. On Thu, 4 Jan 2001, Barney Wolff wrote: > As I appear to have missed it, could you explain, or point to, > the made case? > Thanks, > Barney > > On Wed, Jan 03, 2001 at 08:22:06PM -0800, Bernard Aboba wrote: > > > > I think the case has been made that e2e security > > is needed in *some* circumstances. Not all > > circumstances -- for example, if you use > > referal you don't need it. > From owner-aaa-bof@merit.edu Thu Jan 4 10:11:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07043 for ; Thu, 4 Jan 2001 10:11:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id C51055DE67; Thu, 4 Jan 2001 10:10:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4012F5DE72; Thu, 4 Jan 2001 10:10:41 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id DBF685DE67 for ; Thu, 4 Jan 2001 10:10:37 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id HAA19793; Thu, 4 Jan 2001 07:10:35 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00410; Thu, 4 Jan 01 07:42:59 -0800 Date: Thu, 4 Jan 2001 07:42:58 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Stephen Farrell Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security In-Reply-To: <3A546E71.55311E53@baltimore.ie> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > My take would be that the CMS route (especially if > generally usable in a way compatible with pkcs#7) would > be the best, since implementations are more widely > available than Kerberos and there's no need to > introduce a separate on-line security server. > OK. Can CMS satisfy *all* the security needs? In other words, can I use it for *both* hop-by-hop (for auth/integrity/replay on the whole message) and for e2e (confidentiality/auth/integrity/replay) on the "non-header" attributes? Can it *always* work on a single round trip? And what are the dependencies? a. Does it require the NAS and AAA servers to implement public key functionality? b. Do you need an online CRL server? c. Are there low-overhead computation modes? > I would also have some serious doubts that the > type of inter-realm Kerberos required for > e2e security for DIAMETER would really work > well. Can you describe your concerns in more detail? Is it the Kerberos/DNS lookup stuff that bothers you? Feasibility of Kerb inter-realm trusts? > If multi-mechanism support were a requirement then > you'd presumably have to mandate SPNEGO, which AFAIK is > not widely implemented. Microsoft implements SPNEGO in NT 4 and Windows 2000. >(I don't even know of anyone > who's actually deployed SPNEGO in a multi-vendor > environment - maybe there is though?) SPNEGO interoperability has been demonstrated provided that compatible methods are available on both sides (e.g. KerbV GSSAPI). > > The only downside of the CMS approach I can see is that > it possibly introduces a dependency on the rcek I-D from > the smime WG, which is needed for efficient use of > CMS between pairs of DIAMETER servers that often > use e2e security. If the usage patterns were such > that use of e2e security between any particular pair > of DIAMETER servers was infrequent, then CMS with > asymmetric crypto (i.e. pkcs#7) is fine as is. I'm > not sure if that's the case though. That's the kind of assertion that requires data for validation. Anyone know the answer? My own (admittedly unscientific) guess is that if e2e originates on the NAS, that e2e between any pair would be infrequent (defined as only a few interactions within a 24 hour period). If it originates on the proxy, then it would be much more frequent (perhaps by one or two orders of magnitude, depending on the number of NASen). However, personally I'm somewhat uncomfortable with an "e2e" feature that we don't expect can be implemented from NAS to AAA server. > If the usage patterns are such that the rcek stuff > is a dependency, we should initiate a chat with the > smime WG chair (Russ Housley) Let's talk to Russ to understand the schedule. Can you take this on? > > Can we live with *one* of those? Which one? > > Given the transport (still SCTP, isn't it?) seems > like IPSec is the only option Can CMS be used for hop by hop too? Requiring *both* CMS *and* IPSEC *and* password hiding (in case you aren't using e2e and only have ESP null or AH) increases complexity significantly. Question of the day: "How simple can we make it and still solve the problem?" From owner-aaa-bof@merit.edu Thu Jan 4 10:11:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07050 for ; Thu, 4 Jan 2001 10:11:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F8785DDB0; Thu, 4 Jan 2001 10:10:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B6E805DE62; Thu, 4 Jan 2001 10:10:41 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 7F0965DE62 for ; Thu, 4 Jan 2001 10:10:37 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id HAA19554; Thu, 4 Jan 2001 07:10:35 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00397; Thu, 4 Jan 01 07:26:55 -0800 Date: Thu, 4 Jan 2001 07:26:54 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Kaushik Narayan Cc: aaa-wg@merit.edu, aboba@internaut.com, smb@research.att.com Subject: Re: Making the hard choices on AAA security In-Reply-To: <200101041154.RAA06616@cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Actually GSSAPI needs the underlying communication > protocol (diameter in this case) to support more > than a single round trip for session initiation. > This is because some of the GSSAPI mechanisms > require more than a single round trip for > establishment of a security context. Well, I suppose that it feasible -- though it would increase message count significantly for non-EAP authentications. > > b. What is the mandatory to implement GSSAPI > > method for DIAMETER? KerbV? > > GSSAPI doesnot have any mandatory mechanism, you can plug any > mechanism that supports GSSAPI. It seems to me that we'd need at least one mandatory to implement mechanism for DIAMETER or else we couldn't guarantee that any two peers would be able to negotiate with SPNEGO, right? > Well the need for hop-by-hop security is dependent > on whether there would be data inspected/added on a hop > by hop basis. For a Remote Access protocol like > Radius most of the attributes are end-to-end except > for (User-Name, Called-Station-Id and Proxy-State) > so really end-to-end privacy and integrity protection > would be enough. Minimally hop by hop integrity > protection is enough. > > In case of diameter since the scope of the > intermediate proxy is much broader (noy just a > routing proxy), hop by hop security would be > more relevant. > OK. So we could use {auth/integrity, replay} on the entire message (hop by hop) and e2e (confidentiality, auth, integrity, replay protection) on all but the "header" attributes (User-Name, Called-Station-ID, Proxy-State, etc.) which we could define. Question: can *always* assume that e2e confidentiality is used? If not, then it seems like we will need a "password" hiding hop-by-hop mechanism as well, no? From owner-aaa-bof@merit.edu Thu Jan 4 10:12:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07097 for ; Thu, 4 Jan 2001 10:12:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id D432E5DE6D; Thu, 4 Jan 2001 10:10:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7BEAB5DE75; Thu, 4 Jan 2001 10:10:43 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 13A105DE70 for ; Thu, 4 Jan 2001 10:10:40 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id HAA17387; Thu, 4 Jan 2001 07:10:36 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00430; Thu, 4 Jan 01 07:46:21 -0800 Date: Thu, 4 Jan 2001 07:46:21 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Fredrik Johansson Cc: Pat Calhoun , Barney Wolff , aaa-wg@merit.edu Subject: RE: DISCUSSION REQUESTED: draft-ietf-aaa-solutions-00.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, 4 Jan 2001, Fredrik Johansson wrote: > Hi > > As I understand it the intention of the filter rules is to protect the > operator network for traffic coming in direction A (see fig below). Not necessarily. We use it to provide a limited service to the user (e.g. registration server), limiting traffic in direction B as well. From owner-aaa-bof@merit.edu Thu Jan 4 10:54:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07794 for ; Thu, 4 Jan 2001 10:54:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id B82415DE64; Thu, 4 Jan 2001 10:53:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2B005DE68; Thu, 4 Jan 2001 10:53:39 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 536E45DE64 for ; Thu, 4 Jan 2001 10:53:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10325; Thu, 4 Jan 2001 07:53:27 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA01875; Thu, 4 Jan 2001 07:53:27 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA22219; Thu, 4 Jan 2001 07:53:25 -0800 (PST) Date: Thu, 4 Jan 2001 07:49:54 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: "Bernard D. Aboba" Cc: Kaushik Narayan , aaa-wg@merit.edu, smb@research.att.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 ok. I have been following this thread, and I believe that I have a couple of points that need to be raised. 1. First has to do with reliability and failover. As many of you know, RADIUS to an extent, and DIAMETER support failover techniques. When a proxy attempts to send a request to a downstream peer that is no longer available, it attempts to send it to an alternate server. In some cases these servers are proxies, and we don't care about that case at the moment. In other cases, the servers are the home servers. This means that the NAS (or whoever is initiating the e2e) doesn't actually know what server it will be contacting. I am not sure that many people have actually really thought this through, but how does the NAS initiate a security association with an unknown entity? There are four cases to consider: 1. public key auth. This is a non-issue since the initiator simply signs the request using its private key. It doesn't care who it is talking to. This is supported by CMS, and I do not know if GSSAPI does or not. 2. public key enc. This is problematic since the NAS (or whoever) needs to encrypt data using the peer's public key. How does the NAS know which cert to use? There may be several servers in the home network. 3. secret key auth. This is a problem again because a key must be negotiated with an unknown entity. Presumably, public key is used initially to authenticate and encrypt the secret key. Once this is done however, the transaction MUST terminate with the SAME home server. if a failover occurs to an alternate server, the alternate server will not have the secret key required to decrypt. 4. secret key enc. see #3 above. 2. hop-by-hop security. There is a question pending on whether hop-by-hop could be eliminated, and perhaps only use IPSec. Although DIAMETER does support IPSec, I believe that only relying on a third party security protocol is problematic. Even the cops guys eventually figured this out and had to add some secret key authentication stuff in their protocol (and this is rather recent). IPsec is not widely deployed today, but I am not sure this is a valid argument. Typically, when two AAA servers are setup to communicate, a shared secret is established. This shared secret could just as easily be used as an IKE pre-shared key. So what is easier? mandate IPSec, or provide a mechanism to authenticate the message based on a secret key? I will admit that the way DIAMETER's authentication works, one has to "walk" through the packet looking for the authentication AVP, and that MAY require more processing time than simply doing AH. Of course, this could easily be fixed, and I have been thinking about doing something to fix that. However, the amount of logic required to perform message authentication in DIAMETER is rather small, and the transform mandated is easily available (code is in the RFC!). My take is that a lightweight approach for hop-by-hop is good idea, but assume that the key is either created out of band. I believe that Paul at some point even talked about using IKE to distribute DIAMETER keys, but I don't think that's gone anywhere. 3. is hop-by-hop sufficient? I believe that our requirements state that it is not. 4. is e2e sufficient? Here is a good question. There are cases where e2e may not be necessary, so making it mandatory, or the only option, may be too heavy. However, if it reduces the complexity of the protocol then I believe it MAY be one of our goals. btw, now that I think of it, I am not sure why we have two approaches. If CMS, or some other method, allows for symmetric auth/enc, then we should only support one method. Albeit, that method will be significantly more complicated to implement. In fact, the presenter of the Kerberos/RADIUS discussion at the IETF stated that he did all the work in about 1000 lines of code. After talking this over with people that know about kerberos and GSSAPI, these lines of code did not include kerberos or GSSAPI, but only the RADIUS changes. So the amount of work is great (both GSSAPI and CMS require ASN.1 for example). However, putting the amount of work aside, if the e2e method can be used for hop-by-hop, why have two methods to authenticate/encrypt? Clearly, IPSec cannot provide e2e (as we define e2e anyways). My inclination is to choose a e2e that is relatively lightweight, and allow it to provide hop-by-hop, as well as e2e, and then remove some of the hop-by-hop stuff out of the protocol. This reduces the amount of protocol, but does now mandate e2e (something that people may object to). 5. Reliance on third party security servers. I believe that any solution that relies on yet another security server infrastructure is problematic. The 3G folks, for example, are actually trying to reduce the amount of stuff in their network. By using something that requires more servers is good for Sun perhaps, but complicates the network. Now CMS does require certificates, but these can be pre-configured using contract negotiation, so it is not required to have the PKI infrastructure. I am sure that I have more, but that's it for now. Thanks, PatC From owner-aaa-bof@merit.edu Thu Jan 4 11:05:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08087 for ; Thu, 4 Jan 2001 11:05:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3AC715DE6E; Thu, 4 Jan 2001 11:04:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A9195DE6B; Thu, 4 Jan 2001 11:04:24 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id 4FA555DE68 for ; Thu, 4 Jan 2001 11:04:22 -0500 (EST) Received: by balinese.baltimore.ie; id QAA25496; Thu, 4 Jan 2001 16:04:21 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma025226; Thu, 4 Jan 01 16:03:24 GMT Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA26235; Thu, 4 Jan 2001 16:07:27 GMT Message-ID: <3A549ECB.B381A535@baltimore.ie> Date: Thu, 04 Jan 2001 16:03:23 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bernard D. Aboba" Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard, > OK. Can CMS satisfy *all* the security needs? In other words, can I use > it for *both* hop-by-hop (for auth/integrity/replay on the whole message) > and for e2e (confidentiality/auth/integrity/replay) on the "non-header" > attributes? Yes and no. As currently defined in the strong-crypto I-D it only addresses e2e confid, origin auth & integrity, so that's the no. The yes is that there's no reason that CMS couldn't provide the same services in a hop-by-hop manner (though we might have to give some consideration to nested CMS blobs). Handling the entire message (as opposed to AVPs) would also require a bit of specification (we'd have to say which fields are digested and how, but there's no problem including the digest, its kind of like clear-signing in s/mime). Replay is a bit different, in that CMS itself doesn't provide anything. However, if you've got either sequencing or a nonce somewhere in a protected field, then you can provide replay protection. An alternative would be to include a CMS signedAttribute (or authenticatedAttribute) that contained the nonce/sequence. > Can it *always* work on a single round trip? You mean key distribution? Fair enough, CMS itself doesn't answer all the key management issues. However, at the expense either of a directory (for certs) or occasional signed messages (to distribute public keys) you can handle the key management reasonably ok. Its certainly much easier than key managment for mail user agents! So I guess the answer is something like "almost always" a single round trip. > And what are the dependencies? > a. Does it require the NAS and AAA servers to implement public key > functionality? You could work with shared secrets, but I'd guess public key is better. > b. Do you need an online CRL server? Depends. I'm not sure, but in this context it may be possible to operate with only occasional checks as to revocation of public keys (either using CRLs or OCSP). The assumption here is that key compromise is uncommon and that there may be other "AAA level" revocation mechanisms in place. Probably something to discuss, certainly I don't have enough knowledge of how DIAMETER servers will work to answer this just yet. > c. Are there low-overhead computation modes? That's the rcek stuff. > > I would also have some serious doubts that the > > type of inter-realm Kerberos required for > > e2e security for DIAMETER would really work > > well. > > Can you describe your concerns in more detail? Is it the Kerberos/DNS > lookup stuff that bothers you? Feasibility of Kerb inter-realm trusts? Not quite either. Kerberos inter-realm AFAIK requires the tgt holder in realm1 to directly contact the KDC in realm2 in order to get a service ticket (as well as somehow setting up realm1 in realm2's KDC db). You could get rid of this interaction (we did it 6 years ago when I was involved in SESAME), but it means inventing a new protocol between the DIAMETER server in realm2 and realm2's KDC. That new protocol also has some security considerations. 'Course maybe someone's already developed that protocol but if so, I haven't seen it. Bottom line is that with kerberos as is, you need two cross-realm connections (one to realm2's KDC and one to realm2's DIAMETER server), though the KDC interaction is only needed once per service-ticket/tgt expiration period. I'm also not sure how this would be used for e2e through a proxy (though maybe that's because I missed the presentation in San Diego due to nasty scheduling). I also personally think that handling root CA information is easier than configuring kerberos cross-realm trust, but that's clearly not someting that's provable (and maybe I'm a bit biased as well:-). > > If multi-mechanism support were a requirement then > > you'd presumably have to mandate SPNEGO, which AFAIK is > > not widely implemented. > > Microsoft implements SPNEGO in NT 4 and Windows 2000. Really? I didn't know, but that's interesting. In any case, I doubt anyone would argue that there are more SPNEGO implementations than CMS/pkcs#7 implementations. > >(I don't even know of anyone > > who's actually deployed SPNEGO in a multi-vendor > > environment - maybe there is though?) > > SPNEGO interoperability has been demonstrated > provided that compatible methods are available on both sides > (e.g. KerbV GSSAPI). Again that's interesting, was it multi-vendor? > > The only downside of the CMS approach I can see is that > > it possibly introduces a dependency on the rcek I-D from > > the smime WG, which is needed for efficient use of > > CMS between pairs of DIAMETER servers that often > > use e2e security. If the usage patterns were such > > that use of e2e security between any particular pair > > of DIAMETER servers was infrequent, then CMS with > > asymmetric crypto (i.e. pkcs#7) is fine as is. I'm > > not sure if that's the case though. > > That's the kind of assertion that requires data for validation. Anyone > know the answer? It wasn't an assertion, it was a confession of ignorance:-) > My own (admittedly unscientific) guess is that if e2e originates on the > NAS, that e2e between any pair would be infrequent (defined as only a few > interactions within a 24 hour period). If it originates on the proxy, > then it would be much more frequent (perhaps by one or two orders of > magnitude, depending on the number of NASen). > > However, personally I'm somewhat uncomfortable with an "e2e" feature that > we don't expect can be implemented from NAS to AAA server. Fair point. CMS with the rcek stuff is certainly much more attractive than without. > > If the usage patterns are such that the rcek stuff > > is a dependency, we should initiate a chat with the > > smime WG chair (Russ Housley) > > Let's talk to Russ to understand the schedule. Can you take this on? Will do. > > > Can we live with *one* of those? Which one? > > > > Given the transport (still SCTP, isn't it?) seems > > like IPSec is the only option > > Can CMS be used for hop by hop too? Requiring *both* CMS *and* IPSEC > *and* password hiding (in case you aren't using e2e and only > have ESP null or AH) increases complexity significantly. Fair enough, but OTOH I'd have (probably wrongly) thought that IPSec might be part of a NAS stack and so wouldn't make the DIAMETER implementation more complex. See above on CMS for hop-by-hop. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Thu Jan 4 11:41:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08851 for ; Thu, 4 Jan 2001 11:41:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 621825DE74; Thu, 4 Jan 2001 11:40:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 500065DE6B; Thu, 4 Jan 2001 11:40:50 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 0F8F85DE55 for ; Thu, 4 Jan 2001 11:40:49 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id MAA07577; Thu, 4 Jan 2001 12:36:36 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id LAA17809; Thu, 4 Jan 2001 11:41:06 -0500 (EST) From: "Mark Jones" To: "Richard Perlman" , "Pat Calhoun" Cc: Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 Date: Thu, 4 Jan 2001 11:47:34 -0500 Message-ID: <002901c0766e$09cdb450$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, I agree with Richard on relaxing the SHOULD to a MAY. The wording in section 6.4.2.3 also needs to be relaxed to: "When present, the Home-Realm AVP MAY be used to perform message routing decisions" In practice, I think this AVP can only be used for message routing when both parties have agreed beforehand on exactly when/how the Home-Realm AVP is used and configure their DIAMETER proxies accordingly. However, it is definitely a useful AVP and an improvement over the current RADIUS practice of appending or replacing the realm component in the User-Name attribute. Regards, Mark > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Richard Perlman > Sent: January 3, 2001 6:41 PM > To: Pat Calhoun; Mark Jones > Cc: aaa-wg@merit.edu > Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 > > > Pat: > > Given the wide variance in operating models, I think the SHOULD > should be a MAY. > > Richard > > As Pat Calhoun wrote (1/3/01 3:30 PM -0800): > >would be changed to: > > > >" ... In such cases, the first hop DIAMETER proxy SHOULD append the > > Home-Realm AVP to the DIAMETER message, by using a DNIS or ANY to > > Home-Realm association table, if it is known. If the message is > > forwarded to a downstream proxy, the proxy MAY add the missing > > Home-Realm AVP, if the realm associated with the DNIS or ANI is > > known." > > > >Would this cover the case you described? Is it clear enough? > > From owner-aaa-bof@merit.edu Thu Jan 4 11:51:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA09321 for ; Thu, 4 Jan 2001 11:51:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 249815DDDC; Thu, 4 Jan 2001 11:51:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 14ED35DE55; Thu, 4 Jan 2001 11:51:05 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 1C3385DDDC for ; Thu, 4 Jan 2001 11:51:04 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 18C774CE61; Thu, 4 Jan 2001 11:51:00 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA22237; Thu, 4 Jan 2001 11:50:58 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 5FC3B35DC2; Thu, 4 Jan 2001 11:50:58 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Bernard Aboba" Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jan 2001 11:50:58 -0500 Message-Id: <20010104165058.5FC3B35DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Without trying to propose any solutions, let me toss out a few concepts and decision criteria. By choosing appropriately from the latter, we may find that the decision space is sufficiently constrained that it's not a hard problem. First, there's the distinction between transmission security and object security. The former is typified by things like IPsec and TLS; the latter by S/MIME and PGP. Transmission security is at its best when a conversation is end-to-end, with no intermediaries; alternatively, one can use tranmission security hop-by-hop, but that works if and only if you (a) are sure that *all* hops are appropriately protected, and (b) if you trust that each intermediate site will do the right thing with the message, and that no such site has been penetrated. That's why we don't use transmission security for most email -- there are too many hops, and too much chance of the mail being picked off while it's sitting in a spool file somewhere. Security (roughly) consists of confidentiality, authenticity, and availability. Some things don't need to be kept secret; others do. In general, one *must* have authenticity checks as well if confidentiality is desired; otherwise, there are likely to be attacks that break confidentiality. Availability has to cover both malicious and non-malicious failures. In addition, there is also authorization -- does your peer have the right to send or receive the data. CRLs are used to handle authorization changes, i.e., some certificate is no longer authorized because the corresponding private key has been compromised. If there are human-level authorization mechanisms of sufficient granularity, you don't need CRLs. Given that AAA in a sense mirrors business decisions, that may suffice -- but you have to have to ability to change the authorization tables reasonably rapidly on all of your NAS boxes if some peer's key has leaked. (The definition of "rapidly" varies with what is at risk -- if you're an ISP, there is probably little revenue loss if unauthorized parties can dial in for an extra day or two, until your tables are updated. Access to a corporate net is a different matter.) You can't have security without trust. If you don't *know* that you can trust someone, it doesn't pay to encrypt the data you send them; they could work for EvilHackerDudes.com, and they'll be happy to accept the data in any form you send it. For AAA, end-to-end security via a proxy may be meaningless, if you don't know if you can trust the party that your (trusted) proxy relayed things to. As a corollary, when you receive a response, you have to be able to verify that the sender is authorized not just in general, but specifically to send this particular response. If there are no proxies or other third parties, transmission security will suffice. Since there are third parties, a decision needs to be made on what trust relationships need to be supported. If you always trust what the proxy tells you, or if you never know if you can trust the ultimate responders, there is again no need for object security. But you do need object security if (a) there are proxies, (b) you don't trustthem completely, (c) you sometimes can trust the ultimate responder and (d) you must verify that the reponse is indeed from such a party. In a different vein, can all AAA participants afford to do public key operations for each message sent or received? If not, some key management overhead is necessary, though the results of that process can often be cached. Other factors that go into the design of a key management scheme include the availability on all boxes of clocks, non-volatile storage for counters, random number generators, and ease of provisioning new boxes with necessary secrets. If you have proxies but also need end-to-end integrity protection, how does the proxy accomplish that? Clearly, modifiable data can't be encrypted end-to-end in such a scenario, and even integrity protection can be tricky. You also need a way to link requests to replies; otherwise, an enemy can replay old answers. Mechanisms for that include timers, counters, and "nonce" values -- random numbers that appear in both messages. There's more that can be said, but I think we need to answer these questions first, before we can start talking about CMS or IPsec or the like. I know we've discussed some of this in the past, but there has been enough variation in some of the messages in this thread that I felt it was worth restating these points. --Steve Bellovin From owner-aaa-bof@merit.edu Thu Jan 4 12:07:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10035 for ; Thu, 4 Jan 2001 12:07:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC1F25DE78; Thu, 4 Jan 2001 12:06:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 907C25DE5C; Thu, 4 Jan 2001 12:06:54 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 7450C5DDAB for ; Thu, 4 Jan 2001 12:06:52 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f04H3e405154; Thu, 4 Jan 2001 18:06:15 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA24370; Thu, 4 Jan 2001 19:03:32 +0200 (EET) Message-ID: <3A54ACE4.2CA72E86@lmf.ericsson.se> Date: Thu, 04 Jan 2001 19:03:32 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie, "Bernard D. Aboba" , Pat.Calhoun@Eng.Sun.COM Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: <3A549ECB.B381A535@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I won't enter the e2e vs hbh discussion, just though I'd respond on a number of IPsec question marks: >Fair enough, but OTOH I'd have (probably wrongly) thought that IPSec >might be part of a NAS stack and so wouldn't make the DIAMETER >implementation more complex. Well... depends on you case of course. I believe IPsec is available on recent versions of most commercial OSes, including Windows *, Linux, Solaris, * BSD, and so on. Whether it is available on particular company's propietary NAS box is more of a question mark, but I do know at least that quite a large number of boxes that support L2TP support also IPsec. Ours does, at least. In conclusion I think it would be likely that most AAA servers would have IPsec available anyway but it wouldn't be perhaps certain on the NAS side. Regarding complexity and such, there's a difference in requiring IPsec and requiring IPsec + IKE. Just pure IPsec gets you roughly the same kind of scalability and security as a RADIUS like scheme or the current DIAMETER Integrity-Check-AVP or Encrypted-Password AVP gives. >Although DIAMETER does support >IPSec, I believe that only relying on a third party security protocol is >problematic. Even the cops guys eventually figured this out and had to add >some secret key authentication stuff in their protocol (and this is rather >recent). Is this the Message Integrity Object or has something newer appeared somewhere? Last time I checked the COPS approach was to provide a fairly simple (RADIUS-like if you will) built-in integrity support and then rely on IPsec or TLS for encryption or finer PKI schemes and such. I think a major goal in this discussion would have to be the avoidance of mandatory new network nodes. Things like CRL directories are fine though since whether you use them and their functionality is a user's option. >b. Specifying IPSEC doesn't guarantee >instant interoperability. It's taken quite a >while to get interoperability between >L2TP/IPSEC implementations. This may or may not apply for the DIAMETER case. In L2TP, we tried to achieve fairly complex things on how the security inside the L2TP/PPP affected the outer security parameters, there were some port number floating issues, etc. Used for pure hop-by-hop security, I'm not sure I see that many issues that DIAMETER itself has to deal with. Assuming the SCTP SA number optimization is the problem of another layer and a working group. And assuming that we don't try to reinvent IPSec as an end-through-proxies-to-end security tool, which I hope we are not... Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply. From owner-aaa-bof@merit.edu Thu Jan 4 12:50:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00639 for ; Thu, 4 Jan 2001 12:50:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F20F5DE91; Thu, 4 Jan 2001 12:49:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4C5755DE82; Thu, 4 Jan 2001 12:49:47 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A640B5DDAB for ; Thu, 4 Jan 2001 12:49:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25891; Thu, 4 Jan 2001 09:49:40 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01854; Thu, 4 Jan 2001 09:49:40 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA26739; Thu, 4 Jan 2001 09:49:32 -0800 (PST) Date: Thu, 4 Jan 2001 09:46:02 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 To: Mark Jones Cc: Richard Perlman , Pat Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <002901c0766e$09cdb450$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Good. Any objections to the proposed changes before I update the solutions I-D? PatC > > I agree with Richard on relaxing the SHOULD to a MAY. The wording in section > 6.4.2.3 also needs to be relaxed to: > "When present, the Home-Realm AVP MAY be used to perform message routing > decisions" > > In practice, I think this AVP can only be used for message routing when both > parties have agreed beforehand on exactly when/how the Home-Realm AVP is > used and configure their DIAMETER proxies accordingly. However, it is > definitely a useful AVP and an improvement over the current RADIUS practice > of appending or replacing the realm component in the User-Name attribute. > > Regards, > Mark > > > -----Original Message----- > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > Of Richard Perlman > > Sent: January 3, 2001 6:41 PM > > To: Pat Calhoun; Mark Jones > > Cc: aaa-wg@merit.edu > > Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 > > > > > > Pat: > > > > Given the wide variance in operating models, I think the SHOULD > > should be a MAY. > > > > Richard > > > > As Pat Calhoun wrote (1/3/01 3:30 PM -0800): > > >would be changed to: > > > > > >" ... In such cases, the first hop DIAMETER proxy SHOULD append the > > > Home-Realm AVP to the DIAMETER message, by using a DNIS or ANY to > > > Home-Realm association table, if it is known. If the message is > > > forwarded to a downstream proxy, the proxy MAY add the missing > > > Home-Realm AVP, if the realm associated with the DNIS or ANI is > > > known." > > > > > >Would this cover the case you described? Is it clear enough? > > > > > From owner-aaa-bof@merit.edu Thu Jan 4 13:13:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01372 for ; Thu, 4 Jan 2001 13:13:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EA395DE93; Thu, 4 Jan 2001 13:12:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8CB205DE8E; Thu, 4 Jan 2001 13:12:44 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by segue.merit.edu (Postfix) with ESMTP id 2C8835DE8D for ; Thu, 4 Jan 2001 13:12:43 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQjwnw26551 for ; Thu, 4 Jan 2001 18:12:42 GMT Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQjwnw19365 for ; Thu, 4 Jan 2001 13:12:42 -0500 (EST) Date: Thu, 4 Jan 2001 13:12:42 -0500 (EST) From: Stuart A Barkley To: aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, 3 Jan 2001, Bernard Aboba wrote: > "What is the minimum security functionality that we need to meet > the requirements?" I think the minimum and maximum we need is encryption of the data stream between the AAA client and its immediate server (e.g. hop to hop). How this is implemented can use some discussion. In many ways I would just like to just require IPSec between the applications. IPSec could be either done with a preshared secret (similar configuration issues as with current radius implementations) or with preconfigured certificates and IKE (which increases the dependencies, but does make things easier). There certainly are some issues with using IPSec including availability in the equipment and compatibility issues between implementations. I also have not looked at any IPSec APIs, but the applications should use the necessary tools to ensure that IPSec is actually being used for the specific connections. I don't see the need for anything other than preshared keys or preconfigured certificates. My view may be a little colored, but I don't see any device or server I operate communicating with any other process which doesn't have a structured business relationship with a well defined path for certificate exchange. > If you think that IPSEC alone will magically sole our hop by hop > security problems, think about this: These are valid points which should be looked at. > a. IPSEC transport mode is not very widely deployed today. In > fact, I know of no RADIUS deployment running over IPSEC. Perhaps those systems that can't run IPSec will continue to run Radius and use a AAA gateway to convert the protocol stream. I certainly could see us continuing to run Radius on our NASes yet have our "proxies" talk AAA to the outside world. This is very likely to happen at least for a time anyway during the transition. There are plenty of other reasons why we will be wanting vendors to implement IPSec in most of our equipment. > b. Specifying IPSEC doesn't guarantee instant interoperability. > It's taken quite a while to get interoperability between > L2TP/IPSEC implementations. I don't know the current state of interoperability and can believe that there are still issues. The IPSec I've been using works fine, but that is expected since its the same implementation and even the bits are the same. Likewise, we want vendors to implement compatible version of IPSec for our equipment. c. I see that there has been some discussion of IPSec and SCTP interaction. I haven't digested that discussion yet. Finally, If IPSec isn't ready for our needs then we should just specify use of AES and an appropriate mode of operation (which is probably also easier said than done). Stuart -- Stuart A Barkley email: stuartb@uu.net UUNET WorldCom phone: +1 703 886 5645 I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone From owner-aaa-bof@merit.edu Thu Jan 4 15:37:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03751 for ; Thu, 4 Jan 2001 15:37:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EF345DE5C; Thu, 4 Jan 2001 15:35:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F0FC35DEB3; Thu, 4 Jan 2001 15:35:20 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 555505DE5C for ; Thu, 4 Jan 2001 15:35:19 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id QAA09795; Thu, 4 Jan 2001 16:31:06 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id PAA23076; Thu, 4 Jan 2001 15:35:37 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: "Richard Perlman" , Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 Date: Thu, 4 Jan 2001 15:42:05 -0500 Message-ID: <002601c0768e$cc479210$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Since we have established that this AVP is not necessarily the Home-Realm, I suggest renaming it to Routing-Realm. Any objections? Regards, Mark > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Pat Calhoun > Sent: January 4, 2001 12:46 PM > To: Mark Jones > Cc: Richard Perlman; Pat Calhoun; aaa-wg@merit.edu > Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 > > > Good. Any objections to the proposed changes before I update the > solutions I-D? > PatC > > > > I agree with Richard on relaxing the SHOULD to a MAY. The > wording in section > > 6.4.2.3 also needs to be relaxed to: > > "When present, the Home-Realm AVP MAY be used to perform > message routing > > decisions" > > > > In practice, I think this AVP can only be used for message > routing when both > > parties have agreed beforehand on exactly when/how the Home-Realm AVP is > > used and configure their DIAMETER proxies accordingly. However, it is > > definitely a useful AVP and an improvement over the current > RADIUS practice > > of appending or replacing the realm component in the User-Name > attribute. > > > > Regards, > > Mark > > > > > -----Original Message----- > > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > Of Richard Perlman > > Sent: January 3, 2001 6:41 PM > > To: Pat Calhoun; Mark Jones > > Cc: aaa-wg@merit.edu > > Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 > > > > > > Pat: > > > > Given the wide variance in operating models, I think the SHOULD > > should be a MAY. > > > > Richard > > > > As Pat Calhoun wrote (1/3/01 3:30 PM -0800): > > >would be changed to: > > > > > >" ... In such cases, the first hop DIAMETER proxy SHOULD append the > > > Home-Realm AVP to the DIAMETER message, by using a DNIS or ANY to > > > Home-Realm association table, if it is known. If the message is > > > forwarded to a downstream proxy, the proxy MAY add the missing > > > Home-Realm AVP, if the realm associated with the DNIS or ANI is > > > known." > > > > > >Would this cover the case you described? Is it clear enough? > > > > > From owner-aaa-bof@merit.edu Thu Jan 4 15:39:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03792 for ; Thu, 4 Jan 2001 15:39:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9C535DE02; Thu, 4 Jan 2001 15:38:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C6F6B5DDE3; Thu, 4 Jan 2001 15:38:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9D70A5DDCD for ; Thu, 4 Jan 2001 15:38:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20060; Thu, 4 Jan 2001 12:38:54 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA15883; Thu, 4 Jan 2001 12:38:45 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA02818; Thu, 4 Jan 2001 12:38:40 -0800 (PST) Date: Thu, 4 Jan 2001 12:35:09 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 To: Mark Jones Cc: Pat Calhoun , Richard Perlman , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <002601c0768e$cc479210$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Since we have established that this AVP is not necessarily the Home-Realm, I > suggest renaming it to Routing-Realm. Any objections? Routing-Realm.... I suppose I'm ok with that. In most, but not all, cases it would be the user's home realm. In certain outsourcing cases, it may contain something else. This, of course, still implies that only one Routing-Realm may be present in a message, right? And it MAY be overwritten by proxy nodes, correct? PatC From owner-aaa-bof@merit.edu Thu Jan 4 16:12:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04357 for ; Thu, 4 Jan 2001 16:12:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98E935DE87; Thu, 4 Jan 2001 16:08:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B3D9E5DE81; Thu, 4 Jan 2001 16:08:11 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 3B6005DF6F for ; Thu, 4 Jan 2001 16:04:20 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA10063; Thu, 4 Jan 2001 17:00:08 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA23685; Thu, 4 Jan 2001 16:04:38 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: "Richard Perlman" , Subject: RE: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.1 Date: Thu, 4 Jan 2001 16:11:06 -0500 Message-ID: <002b01c07692$da1fbdf0$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > This, of course, still implies that only one Routing-Realm may > be present in a message, right? Yes. This is consistent with the view that this AVP is a hint to the next hop DIAMETER proxy and not necessarily a hint to all DIAMETER proxies in the chain. > And it MAY be overwritten by proxy nodes, correct? Yes. If a proxy needs to provide a hint to the next hop proxy different than the one it received then it must be allowed to overwrite this AVP. This AVP may also be removed by a proxy node if the hint is only of local significance and should not be used by the next hop proxy in its routing decisions. Regards, Mark From owner-aaa-bof@merit.edu Thu Jan 4 17:04:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA05223 for ; Thu, 4 Jan 2001 17:04:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2B4D5DF4B; Thu, 4 Jan 2001 17:03:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2A4D5DF4A; Thu, 4 Jan 2001 17:03:53 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 2F2D85DF39 for ; Thu, 4 Jan 2001 17:03:52 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id OAA06899; Thu, 4 Jan 2001 14:03:50 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01207; Thu, 4 Jan 01 11:43:54 -0800 Date: Thu, 4 Jan 2001 11:43:53 -0800 (GMT-0800) From: "Bernard D. Aboba" To: "Steven M. Bellovin" Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security In-Reply-To: <20010104165058.5FC3B35DC2@smb.research.att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Thank you for your message, Steve. You have gotten to the heart of some of the "framework" questions that we are still a bit fuzzy on. Let me try to propose some "straw man" answers to your questions so that we can see where the WG stands. > You can't have security without trust. If you don't *know* that you > can trust someone, it doesn't pay to encrypt the data you send them; > they could work for EvilHackerDudes.com, and they'll be happy to accept > the data in any form you send it. I would like to propose that we assume that a NAS can be trusted in terms of handling of AAA attributes. That is, that we can assume that the NAS will not steal user/tunnel passwords and MIP keys. We can also assume that the NAS will conform to the protocol in carrying out the requested service to the best of its ability or indicating that it cannot do so. Also that the NAS will provide accurate accounting data to the best of its ability. This seems reasonable to me because while NAS devices are certainly hackable, it is harder to modify them nefariously than it is to say, hack a proxy server and its OS. I would like to propose that we assume that a AAA proxy cannot be trusted with knowledge of user/tunnel passwords and MIP keys. I would also propose that we assume that the AAA proxy MAY not be trusted with certain other security-critical attributes (e.g. filter specs, tunnel attributes, EAP-Message, etc.). I'd like to propose that the NAS/Proxy does not trust the AAA server in terms of the service request. That is, the AAA server may request a service that the NAS cannot perform, or that is not allowable under the business arrangements. So the NAS has to be able to say "no, I can't allow you to do that". This gets back to capability negotiation (where the NAS can tell the AAA server what it will accept) or Dave Mitton's suggestion on a third ACK/NAK message going from NAS to AAA server. > In a different vein, can all AAA participants afford to do public key > operations for each message sent or received? In general, a NAS will have a long-lived relationship with a AAA proxy, so that public key operations (at least for hop-by-hop) are too expensive and largely unnecessary. However, for e2e, I'm not sure. Roaming is probably only a small fraction of the total traffic on most NASen, and there may not be enough traffic to a single e2e destination to justify key exchange. From owner-aaa-bof@merit.edu Fri Jan 5 01:43:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA11410 for ; Fri, 5 Jan 2001 01:43:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C9AB5DDE9; Fri, 5 Jan 2001 01:43:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8BED85DDE8; Fri, 5 Jan 2001 01:43:19 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id E68AB5DDA9 for ; Fri, 5 Jan 2001 01:43:16 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA15839; Fri, 5 Jan 2001 12:11:32 +0530 (IST) From: Kaushik Narayan Message-Id: <200101050641.MAA15839@cisco.com> Subject: Re: Making the hard choices on AAA security To: aboba@internaut.com (Bernard D. Aboba) Date: Fri, 5 Jan 2001 12:11:32 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), aaa-wg@merit.edu, aboba@internaut.com, smb@research.att.com In-Reply-To: from "Bernard D. Aboba" at Jan 04, 2001 07:26:54 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk bernard, hi! Find my reply inline > > > > > Actually GSSAPI needs the underlying communication > > protocol (diameter in this case) to support more > > than a single round trip for session initiation. > > This is because some of the GSSAPI mechanisms > > require more than a single round trip for > > establishment of a security context. > > Well, I suppose that it feasible -- though it would > increase message count significantly for non-EAP > authentications. > > > > b. What is the mandatory to implement GSSAPI > > > method for DIAMETER? KerbV? > > > > GSSAPI doesnot have any mandatory mechanism, you can plug any > > mechanism that supports GSSAPI. > > It seems to me that we'd need at least one mandatory to implement > mechanism for DIAMETER or else we couldn't guarantee that any two peers > would be able to negotiate with SPNEGO, right? That's right. > > > Well the need for hop-by-hop security is dependent > > on whether there would be data inspected/added on a hop > > by hop basis. For a Remote Access protocol like > > Radius most of the attributes are end-to-end except > > for (User-Name, Called-Station-Id and Proxy-State) > > so really end-to-end privacy and integrity protection > > would be enough. Minimally hop by hop integrity > > protection is enough. > > > > In case of diameter since the scope of the > > intermediate proxy is much broader (noy just a > > routing proxy), hop by hop security would be > > more relevant. > > > OK. So we could use {auth/integrity, replay} on the entire message (hop > by hop) and e2e (confidentiality, auth, integrity, replay protection) on > all but the "header" attributes (User-Name, Called-Station-ID, Proxy-State, etc.) > which we could define. > > Question: can *always* assume that e2e confidentiality is used? If not, > then it seems like we will need a "password" hiding hop-by-hop mechanism as > well, no? If e2e security is not part of the base protocol and something that is turned on optionally then certainly the sensitive attributes (User-Password) need to be hidden/protected on a hop-by-hop basis (a la Radius). kaushik! From owner-aaa-bof@merit.edu Fri Jan 5 02:25:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA11944 for ; Fri, 5 Jan 2001 02:25:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87D665DDEB; Fri, 5 Jan 2001 02:25:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 75DAF5DDAC; Fri, 5 Jan 2001 02:25:20 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 0C8C85DDA9 for ; Fri, 5 Jan 2001 02:25:19 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f057PH412855; Fri, 5 Jan 2001 08:25:17 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA17056; Fri, 5 Jan 2001 09:25:16 +0200 (EET) Message-ID: <3A5576DC.FDA379C2@lmf.ericsson.se> Date: Fri, 05 Jan 2001 09:25:16 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I'd like to include also some 'process aspects' in this discussion. Namely, in the accounting discussions a couple of months back we reached a conclusion that a number of things were potentially useful but we weren't certain if there were absolutely needed and we had doubts about the exact desired workings of them [like proxying batches]. Then we decided to standardize a subset of the functionality that we saw very clearly and could agree on, still reserving the possibility to return back to the finer functionality in later extensions when we knew more. I wonder if the same process might be applied for AAA security, since I'm worried about the schedule aspects. All of the proposed e2e mechanisms are relatively complex. Some of the discussions seem to indicate that at least some modifications will be needed to the existing specs. I have a feeling that DIAMETER must get out very soon in order to be most useful. So, one approach could be that we NOW decide on only the simple hop-by-hop security that doesn't require anything from DIAMETER specs (IPsec) or requires very little (the Integrity-Check-Vector AVP). Then, as a Step 2, somewhat later, we reach a conclusion on the e2e security as an extension to the DIAMETER specs. Whether this is a good idea depends of course on * Whether DIAMETER is useful at all without e2e security [dunno, what do you others think?] * Whether we feel that the final e2e solution would somehow have an impact on the base protocol [in my opinion it won't] * Whether it is true that the the simple security is either done or goes fast in the standardization sense [I feel it would, both the AVP and the IPsec approach are old technology, though of course we could optimize them to infinity if we want] What do you think? [Also, in the accounting discussions we seemed to reach a conclusion that e2e security wasn't necessary, or at least we didn't find enough compelling arguments for it in the mailing list. Have to dig up the archives, that discussion is relevant for this discussion as well. Though perhaps for accounting e2e security isn't that important, but for authorization we need to have things like tunnel passwords, which do make e2e a necessary thing.] Jari ---- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply. From owner-aaa-bof@merit.edu Fri Jan 5 04:50:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA13449 for ; Fri, 5 Jan 2001 04:50:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEE7B5DDE8; Fri, 5 Jan 2001 04:50:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2A175DDEA; Fri, 5 Jan 2001 04:50:31 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 4C60D5DDE8 for ; Fri, 5 Jan 2001 04:50:29 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA04484; Fri, 5 Jan 2001 15:16:24 +0530 (IST) From: Kaushik Narayan Message-Id: <200101050946.PAA04484@cisco.com> Subject: Re: Making the hard choices on AAA security To: Pat.Calhoun@Eng.Sun.COM Date: Fri, 5 Jan 2001 15:16:24 +0530 (IST) Cc: aboba@internaut.com (Bernard D. Aboba), kaushik@cisco.com (Kaushik Narayan), aaa-wg@merit.edu, smb@research.att.com In-Reply-To: from "Pat Calhoun" at Jan 04, 2001 07:49:54 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk pat, hi! Find my reply inline. > > ok. I have been following this thread, and I believe that I have a couple of > points that need to be raised. > > 1. First has to do with reliability and failover. As many of you know, RADIUS > to an extent, and DIAMETER support failover techniques. When a proxy attempts > to send a request to a downstream peer that is no longer available, it > attempts to send it to an alternate server. In some cases these servers are > proxies, and we don't care about that case at the moment. In other cases, the > servers are the home servers. This means that the NAS (or whoever is > initiating the e2e) doesn't actually know what server it will be contacting. > > I am not sure that many people have actually really thought this through, but > how does the NAS initiate a security association with an unknown entity? There > are four cases to consider: > > 1. public key auth. This is a non-issue since the initiator simply > signs the request using its private key. It doesn't care who it is > talking to. This is supported by CMS, and I do not know if GSSAPI does > or not. > > 2. public key enc. This is problematic since the NAS (or whoever) needs > to encrypt data using the peer's public key. How does the NAS know > which cert to use? There may be several servers in the home network. > > 3. secret key auth. This is a problem again because a key must be > negotiated with an unknown entity. Presumably, public key is used > initially to authenticate and encrypt the secret key. Once this is > done however, the transaction MUST terminate with the SAME home server. > if a failover occurs to an alternate server, the alternate server will > not have the secret key required to decrypt. > > 4. secret key enc. see #3 above. > > 2. hop-by-hop security. There is a question pending on whether hop-by-hop could > be eliminated, and perhaps only use IPSec. Although DIAMETER does support > IPSec, I believe that only relying on a third party security protocol is > problematic. Even the cops guys eventually figured this out and had to add > some secret key authentication stuff in their protocol (and this is rather > recent). IPsec is not widely deployed today, but I am not sure this is a valid > argument. Typically, when two AAA servers are setup to communicate, a shared > secret is established. This shared secret could just as easily be used as an > IKE pre-shared key. > > So what is easier? mandate IPSec, or provide a mechanism to authenticate the > message based on a secret key? I will admit that the way DIAMETER's > authentication works, one has to "walk" through the packet looking for the > authentication AVP, and that MAY require more processing time than simply > doing AH. Of course, this could easily be fixed, and I have been thinking > about doing something to fix that. However, the amount of logic required to > perform message authentication in DIAMETER is rather small, and the transform > mandated is easily available (code is in the RFC!). > > My take is that a lightweight approach for hop-by-hop is good idea, but assume > that the key is either created out of band. I believe that Paul at some point > even talked about using IKE to distribute DIAMETER keys, but I don't think > that's gone anywhere. > > 3. is hop-by-hop sufficient? I believe that our requirements state that it is > not. > > 4. is e2e sufficient? Here is a good question. There are cases where e2e may > not be necessary, so making it mandatory, or the only option, may be too > heavy. However, if it reduces the complexity of the protocol then I believe it > MAY be one of our goals. > > btw, now that I think of it, I am not sure why we have two approaches. If CMS, > or some other method, allows for symmetric auth/enc, then we should only > support one method. Albeit, that method will be significantly more complicated > to implement. In fact, the presenter of the Kerberos/RADIUS discussion at the > IETF stated that he did all the work in about 1000 lines of code. After > talking this over with people that know about kerberos and GSSAPI, these lines > of code did not include kerberos or GSSAPI, but only the RADIUS changes. So > the amount of work is great (both GSSAPI and CMS require ASN.1 for example). In my presentation in San Diego I had stated that it required close to 1000 lines of change in the Merit 3.6B Radius server code and I used the Krb5.1.2.1 library from MIT. The purpose of stating this was to illustrate the ease of integrating Kerberos with a Radius/Radius like protocol. It is true that all this work is only Radius changes. Anyways since there is a standard reference implementation for Kerberos which supports GSSAPI v2, Radius or Diameter implementations wouldnot have to implement Kerberos or GSSAPI. > > However, putting the amount of work aside, if the e2e method can be used for > hop-by-hop, why have two methods to authenticate/encrypt? Clearly, IPSec > cannot provide e2e (as we define e2e anyways). > > My inclination is to choose a e2e that is relatively lightweight, and allow it > to provide hop-by-hop, as well as e2e, and then remove some of the hop-by-hop > stuff out of the protocol. This reduces the amount of protocol, but does now > mandate e2e (something that people may object to). When you look at computational intensity Kerberos is certainly very lightweight. Kerberos ticket acquisition is not a freqeunt operation(can be configured to occur anywhere between a few hours to a month) so all you are talking about is Kerberos Key exchange (KRB_AP_REQ/KRB_AP_REP) at the start of every Diameter session (e2e). The encryption and integrity protection operations use symmetric keys. If there needs to be a NAS-homeserver e2e security then Kerberos would a good choice since it might be pretty expensive to do public key (especially without the rcek stuff) on a NAS. > > 5. Reliance on third party security servers. I believe that any solution that > relies on yet another security server infrastructure is problematic. The 3G > folks, for example, are actually trying to reduce the amount of stuff in their > network. By using something that requires more servers is good for Sun > perhaps, but complicates the network. Now CMS does require certificates, but > these can be pre-configured using contract negotiation, so it is not required > to have the PKI infrastructure. The Kerberos KDC( third party security server) is used for acquiring TGTs and service principal tickets. The Kerberos-WG has a draft (PK-TAPP) which addresses elimination of the KDC and uses direct application exchange to acquire TGTs and service principal ticket. kaushik! > > I am sure that I have more, but that's it for now. > > Thanks, > > PatC > > > From owner-aaa-bof@merit.edu Fri Jan 5 05:49:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA14295 for ; Fri, 5 Jan 2001 05:49:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86A145DDF0; Fri, 5 Jan 2001 05:45:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 731685DDFD; Fri, 5 Jan 2001 05:45:59 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 19BE85DDF0 for ; Fri, 5 Jan 2001 05:45:57 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA09686; Fri, 5 Jan 2001 16:11:47 +0530 (IST) From: Kaushik Narayan Message-Id: <200101051041.QAA09686@cisco.com> Subject: Re: Making the hard choices on AAA security To: stephen.farrell@baltimore.ie Date: Fri, 5 Jan 2001 16:11:47 +0530 (IST) Cc: aboba@internaut.com (Bernard D. Aboba), aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) In-Reply-To: <3A549ECB.B381A535@baltimore.ie> from "Stephen Farrell" at Jan 04, 2001 04:03:23 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk stephen, hi! Find my reply inline. > > > Bernard, > > > OK. Can CMS satisfy *all* the security needs? In other words, can I use > > it for *both* hop-by-hop (for auth/integrity/replay on the whole message) > > and for e2e (confidentiality/auth/integrity/replay) on the "non-header" > > attributes? > > Yes and no. As currently defined in the strong-crypto I-D it only addresses > e2e confid, origin auth & integrity, so that's the no. The yes is that > there's no reason that CMS couldn't provide the same services in a hop-by-hop > manner (though we might have to give some consideration to nested CMS > blobs). Handling the entire message (as opposed to AVPs) would also require > a bit of specification (we'd have to say which fields are digested and > how, but there's no problem including the digest, its kind of like > clear-signing in s/mime). > > Replay is a bit different, in that CMS itself doesn't provide anything. > However, if you've got either sequencing or a nonce somewhere in a protected > field, then you can provide replay protection. An alternative would be to > include a CMS signedAttribute (or authenticatedAttribute) that contained > the nonce/sequence. > > > Can it *always* work on a single round trip? > > You mean key distribution? Fair enough, CMS itself doesn't > answer all the key management issues. However, at the expense > either of a directory (for certs) or occasional signed messages > (to distribute public keys) you can handle the key management > reasonably ok. Its certainly much easier than key managment > for mail user agents! > > So I guess the answer is something like "almost always" a > single round trip. > > > And what are the dependencies? > > a. Does it require the NAS and AAA servers to implement public key > > functionality? > > You could work with shared secrets, but I'd guess public key is > better. > > > b. Do you need an online CRL server? > > Depends. I'm not sure, but in this context it may be possible to operate > with only occasional checks as to revocation of public keys (either using > CRLs or OCSP). The assumption here is that key compromise is uncommon and > that there may be other "AAA level" revocation mechanisms in place. > Probably something to discuss, certainly I don't have enough knowledge > of how DIAMETER servers will work to answer this just yet. > > > c. Are there low-overhead computation modes? > > That's the rcek stuff. > > > > I would also have some serious doubts that the > > > type of inter-realm Kerberos required for > > > e2e security for DIAMETER would really work > > > well. > > > > Can you describe your concerns in more detail? Is it the Kerberos/DNS > > lookup stuff that bothers you? Feasibility of Kerb inter-realm trusts? > > Not quite either. Kerberos inter-realm AFAIK requires the tgt holder in > realm1 to directly contact the KDC in realm2 in order to get a service > ticket (as well as somehow setting up realm1 in realm2's KDC db). You > could get rid of this interaction (we did it 6 years ago when I was > involved in SESAME), but it means inventing a new protocol between > the DIAMETER server in realm2 and realm2's KDC. That new protocol also has > some security considerations. 'Course maybe someone's already developed > that protocol but if so, I haven't seen it. Bottom line is that with > kerberos as is, you need two cross-realm connections (one to realm2's > KDC and one to realm2's DIAMETER server), though the KDC interaction > is only needed once per service-ticket/tgt expiration period. Although there of two cross-realm interactions, since the TGT acquisition and service principal acquisition is not something that happens frequently it shouldn't be such a big problem. Morever with PKCROSS cross realm TGT acquisition would the using existing PKI and you no longer have to have a keys for each realm. > > I'm also not sure how this would be used for e2e through a proxy (though > maybe that's because I missed the presentation in San Diego due to > nasty scheduling). Well with Kerberos and Radius I have used a per server service principal. I create a Kerberos security context between the NAS/NAS realm proxy to the homeserver cutting through any intermediate proxies. The draft assumes the presence of a TGT on the Radius client and the service principal ticket acquired(if it is not present in the cache). The Radius client then builds the KRB_AP_REQ for key negotiation. In the latest version ( I will put this up within this weekend) of the draft there is a Kerberos-EndtoEnd attribute which inspected only a Radius end server (homeserver) and not any proxy. This Kerberos-EndtoEnd attribute would carry the KRB_AP_REQ/KRB_AP_REP for key exchange and the KRB_SAFE and KRB_PRIV messages which carry the MIC and the encrypted block respectively. This if for the end to end mode, similarly I can have hop by hop security contexts set up as well. > > I also personally think that handling root CA information is easier than > configuring kerberos cross-realm trust, but that's clearly not someting > that's provable (and maybe I'm a bit biased as well:-). You can avoid configuring cross realm trust at the KDC using PKCROSS. kaushik! > > > > If multi-mechanism support were a requirement then > > > you'd presumably have to mandate SPNEGO, which AFAIK is > > > not widely implemented. > > > > Microsoft implements SPNEGO in NT 4 and Windows 2000. > > Really? I didn't know, but that's interesting. In any case, I > doubt anyone would argue that there are more SPNEGO implementations > than CMS/pkcs#7 implementations. > > > >(I don't even know of anyone > > > who's actually deployed SPNEGO in a multi-vendor > > > environment - maybe there is though?) > > > > SPNEGO interoperability has been demonstrated > > provided that compatible methods are available on both sides > > (e.g. KerbV GSSAPI). > > Again that's interesting, was it multi-vendor? > > > > The only downside of the CMS approach I can see is that > > > it possibly introduces a dependency on the rcek I-D from > > > the smime WG, which is needed for efficient use of > > > CMS between pairs of DIAMETER servers that often > > > use e2e security. If the usage patterns were such > > > that use of e2e security between any particular pair > > > of DIAMETER servers was infrequent, then CMS with > > > asymmetric crypto (i.e. pkcs#7) is fine as is. I'm > > > not sure if that's the case though. > > > > That's the kind of assertion that requires data for validation. Anyone > > know the answer? > > It wasn't an assertion, it was a confession of ignorance:-) > > > My own (admittedly unscientific) guess is that if e2e originates on the > > NAS, that e2e between any pair would be infrequent (defined as only a few > > interactions within a 24 hour period). If it originates on the proxy, > > then it would be much more frequent (perhaps by one or two orders of > > magnitude, depending on the number of NASen). > > > > However, personally I'm somewhat uncomfortable with an "e2e" feature that > > we don't expect can be implemented from NAS to AAA server. > > Fair point. CMS with the rcek stuff is certainly much more attractive > than without. > > > > If the usage patterns are such that the rcek stuff > > > is a dependency, we should initiate a chat with the > > > smime WG chair (Russ Housley) > > > > Let's talk to Russ to understand the schedule. Can you take this on? > > Will do. > > > > > Can we live with *one* of those? Which one? > > > > > > Given the transport (still SCTP, isn't it?) seems > > > like IPSec is the only option > > > > Can CMS be used for hop by hop too? Requiring *both* CMS *and* IPSEC > > *and* password hiding (in case you aren't using e2e and only > > have ESP null or AH) increases complexity significantly. > > Fair enough, but OTOH I'd have (probably wrongly) thought that IPSec > might be part of a NAS stack and so wouldn't make the DIAMETER > implementation more complex. See above on CMS for hop-by-hop. > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com > > From owner-aaa-bof@merit.edu Fri Jan 5 06:10:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA14517 for ; Fri, 5 Jan 2001 06:10:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E44215DDF3; Fri, 5 Jan 2001 06:10:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE7115DDF7; Fri, 5 Jan 2001 06:10:01 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id BFB365DDF3 for ; Fri, 5 Jan 2001 06:09:57 -0500 (EST) Received: by balinese.baltimore.ie; id LAA16971; Fri, 5 Jan 2001 11:09:57 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma016589; Fri, 5 Jan 01 11:09:03 GMT Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA13193; Fri, 5 Jan 2001 11:09:02 GMT Message-ID: <3A55AB4F.71817035@baltimore.ie> Date: Fri, 05 Jan 2001 11:09:03 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaushik Narayan Cc: "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: <200101051041.QAA09686@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Kaushik, > > Not quite either. Kerberos inter-realm AFAIK requires the tgt holder in > > realm1 to directly contact the KDC in realm2 in order to get a service > > ticket (as well as somehow setting up realm1 in realm2's KDC db). You > > could get rid of this interaction (we did it 6 years ago when I was > > involved in SESAME), but it means inventing a new protocol between > > the DIAMETER server in realm2 and realm2's KDC. That new protocol also has > > some security considerations. 'Course maybe someone's already developed > > that protocol but if so, I haven't seen it. Bottom line is that with > > kerberos as is, you need two cross-realm connections (one to realm2's > > KDC and one to realm2's DIAMETER server), though the KDC interaction > > is only needed once per service-ticket/tgt expiration period. > > Although there of two cross-realm interactions, since the TGT > acquisition and service principal acquisition is not something > that happens frequently it shouldn't be such a big problem. I don't think that tgt acquisition is that big a deal since its local to realm1, however requiring the client in realm1 to contact realm2's KDC is definitely problematic. Maybe even more so if Bernard's views on the frequency of inter-realm communications are right - effectively you might end up acquiring a new service ticket for each and every use of e2e (say if tickets last 8 hours and you only need to encrypt a password for a given foreign realm once every 8 hours). In that (worst?) case, the additional inter-realm round-trip happens every single time. > > I'm also not sure how this would be used for e2e through a proxy (though > > maybe that's because I missed the presentation in San Diego due to > > nasty scheduling). > > Well with Kerberos and Radius I have used a per server service principal. > I create a Kerberos security context between the NAS/NAS realm proxy to > the homeserver cutting through any intermediate proxies. The draft > assumes the presence of a TGT on the Radius client and the service > principal ticket acquired(if it is not present in the cache). The > Radius client then builds the KRB_AP_REQ for key negotiation. In the latest > version ( I will put this up within this weekend) of the draft there > is a Kerberos-EndtoEnd attribute which inspected only a Radius end > server (homeserver) and not any proxy. This Kerberos-EndtoEnd attribute > would carry the KRB_AP_REQ/KRB_AP_REP for key exchange and the KRB_SAFE > and KRB_PRIV messages which carry the MIC and the encrypted block > respectively. This if for the end to end mode, similarly I can have hop > by hop security contexts set up as well. You should probably make it clear that the NAS has to contact the Radius server's KDC to get that service ticket. Assuming its already in the NASes ticket cache, esp. in the inter-realm case might be a bit misleading for folks who aren't that familiar with the innards of Kerberos. > > I also personally think that handling root CA information is easier than > > configuring kerberos cross-realm trust, but that's clearly not someting > > that's provable (and maybe I'm a bit biased as well:-). > > You can avoid configuring cross realm trust at the KDC using PKCROSS. I'm glad that you agree that handling roots is easier (sorry, couldn't resist it:-) Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Fri Jan 5 06:49:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA14940 for ; Fri, 5 Jan 2001 06:49:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 503215DE36; Fri, 5 Jan 2001 06:48:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 32BFA5DE19; Fri, 5 Jan 2001 06:48:31 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 4B50B5DE04 for ; Fri, 5 Jan 2001 06:48:28 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA17148; Fri, 5 Jan 2001 17:14:20 +0530 (IST) From: Kaushik Narayan Message-Id: <200101051144.RAA17148@cisco.com> Subject: Re: Making the hard choices on AAA security To: stephen.farrell@baltimore.ie Date: Fri, 5 Jan 2001 17:14:20 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), aboba@internaut.com (Bernard D. Aboba), aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) In-Reply-To: <3A55AB4F.71817035@baltimore.ie> from "Stephen Farrell" at Jan 05, 2001 11:09:03 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk stephen, hi! > > > Hi Kaushik, > > > > Not quite either. Kerberos inter-realm AFAIK requires the tgt holder in > > > realm1 to directly contact the KDC in realm2 in order to get a service > > > ticket (as well as somehow setting up realm1 in realm2's KDC db). You > > > could get rid of this interaction (we did it 6 years ago when I was > > > involved in SESAME), but it means inventing a new protocol between > > > the DIAMETER server in realm2 and realm2's KDC. That new protocol also has > > > some security considerations. 'Course maybe someone's already developed > > > that protocol but if so, I haven't seen it. Bottom line is that with > > > kerberos as is, you need two cross-realm connections (one to realm2's > > > KDC and one to realm2's DIAMETER server), though the KDC interaction > > > is only needed once per service-ticket/tgt expiration period. > > > > Although there of two cross-realm interactions, since the TGT > > acquisition and service principal acquisition is not something > > that happens frequently it shouldn't be such a big problem. > > I don't think that tgt acquisition is that big a deal since its local > to realm1, however requiring the client in realm1 to contact realm2's > KDC is definitely problematic. Maybe even more so if Bernard's views > on the frequency of inter-realm communications are right - effectively > you might end up acquiring a new service ticket for each and every > use of e2e (say if tickets last 8 hours and you only need to encrypt > a password for a given foreign realm once every 8 hours). In that > (worst?) case, the additional inter-realm round-trip happens every > single time. Well the lifetime for which the service principal ticket is purely a configuration issue. The 8 hours is just a default. In case inter realm communication happens only once in 8 hours the service prinicipal lifetime could be set to say 2 weeks to a month. This would effectively reduce the number of transactions with the KDC as compared to the key exchange. > > > > I'm also not sure how this would be used for e2e through a proxy (though > > > maybe that's because I missed the presentation in San Diego due to > > > nasty scheduling). > > > > Well with Kerberos and Radius I have used a per server service principal. > > I create a Kerberos security context between the NAS/NAS realm proxy to > > the homeserver cutting through any intermediate proxies. The draft > > assumes the presence of a TGT on the Radius client and the service > > principal ticket acquired(if it is not present in the cache). The > > Radius client then builds the KRB_AP_REQ for key negotiation. In the latest > > version ( I will put this up within this weekend) of the draft there > > is a Kerberos-EndtoEnd attribute which inspected only a Radius end > > server (homeserver) and not any proxy. This Kerberos-EndtoEnd attribute > > would carry the KRB_AP_REQ/KRB_AP_REP for key exchange and the KRB_SAFE > > and KRB_PRIV messages which carry the MIC and the encrypted block > > respectively. This if for the end to end mode, similarly I can have hop > > by hop security contexts set up as well. > > You should probably make it clear that the NAS has to contact the > Radius server's KDC to get that service ticket. Assuming its already > in the NASes ticket cache, esp. in the inter-realm case might be a bit > misleading for folks who aren't that familiar with the innards of > Kerberos. The slides were pretty clear about this. Anyways as I mentioned previously the number of transactions with NAS -> KDC is configurable and based on the lifetime of the service principal ticket. > > > > I also personally think that handling root CA information is easier than > > > configuring kerberos cross-realm trust, but that's clearly not someting > > > that's provable (and maybe I'm a bit biased as well:-). > > > > You can avoid configuring cross realm trust at the KDC using PKCROSS. > > I'm glad that you agree that handling roots is easier (sorry, couldn't > resist it:-) Well people who have a significant investment in PKI, PKCROSS provides an excellent mechanism to provide cross domain Kerberos trust utilizing the PKI. I don't think that cross-realm trust is that difficult to configure with the KDC. Actually in my draft I have left option of establshing cross-realm trust open and the assumption that a valid cross realm TGT is already present on the Radius client. kaushik! > > Regards, > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com > From owner-aaa-bof@merit.edu Fri Jan 5 09:07:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16417 for ; Fri, 5 Jan 2001 09:07:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id C05D85DDC4; Fri, 5 Jan 2001 09:06:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AEBC45DDF7; Fri, 5 Jan 2001 09:06:43 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9DA5D5DDC4 for ; Fri, 5 Jan 2001 09:06:42 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 25F8274 for ; Fri, 5 Jan 2001 09:06:49 -0500 (EST) Message-ID: <3A55D50B.58D574AE@Interlinknetworks.com> Date: Fri, 05 Jan 2001 09:07:07 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: Re: Choice of Data Model SMI vs XML vs. UML Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk It seems there were some problems with the mailing list, so I'm sending this again. My appologies if some of you did get this the first time. -------- Original Message -------- Subject: Re: Choice of Data Model SMI vs XML vs. UML Date: Thu, 04 Jan 2001 17:40:25 -0500 From: David Spence Organization: Interlink Networks, Inc. To: Alexander Hagen , aaa-wg@merit.edu References: <000c01c065fa$41e48aa0$226015ac@DCLNTAS1> Here are a few more thoughts on data modeling. 1. SMI Derivative vs. XML An advantage of using some derivative of SMI over XML is that the "formal specification" can actually be implemented in the edge device. This improves interoperability and allows interworking between tools that use different protocols. 2. Which derivative of SMI to use I don't have strong feelings as to which SMI derivative is best. We chose SPPI for draft-spence-aaa-nas-data-model-00.txt because it was designed for policy provisioning, is compatible with COPS (more on this at item 3, below), and is somewhat more mature than SMIng (has passed WG last call and is ready for IETF last call). The AAA WG may prefer to be more forward looking and use SMIng or to opt for greater maturity and use SMI v2. 3. Interworking COPS and DIAMETER If the AAA WG chooses XML or chooses an SMI derivative for formal notation only without providing a protocol mapping, then the following problem arises. Suppose an edge device wishes to provide both network access and premium QoS. It would be nice to be able to obtain a single admission decision covering both the network access and the premium QoS with a single request. It is troublesome to the ISP to allocate QoS resources and then deny access or to create an access session and then have to terminate it because the QoS request failed. If the edge device has to use DIAMETER to obtain the network access admission decision and COPS to obtain the QoS admission decision, it will be very difficult to coordinate the two decisions. If this happens, someone might be tempted to doubt the IETF's wisdom in standardizing two protocols where one might have sufficed. Of course, if the two protocols use the same data model, then the problem goes away. Either protocol could be used for either type of request, so the edge device could request the two related services in a single message using either protocol. But if the two protocols do not use the same data model, then it might be a good idea to create an escape mechanism. Could we at least define a DIAMETER AVP type of COPS message or COPS object which means, "shell out to the part of the AAA server that understands COPS, process this thing and then return"? That way, at least, the two requests could be piggybacked onto the same message so that a sophisticated enough AAA server could process them together. 4. What combinations of attributes make sense? A problem which RADIUS leaves unaddressed and which so far has not been addressed by DIAMETER is the question of which attributes can and can not be meaningfully combined in a message. Or, to put it another way, which attributes pertain to which services. Here's an example. The description of the Termination-Action attribute in RFC 2865 says simply, "This Attribute indicates what action the NAS should take when the specified service is completed. It is only used in Access-Accept packets." The RFC does not specify which services the attribute applies to. I assume it applies to the Login service. Could it also apply to the Framed service? If I combine it with attributes such as Framed-Protocol, Framed-IP-Address, and Framed-IP-Netmask, what am I expecting the NAS to do? A data model provides an answer to this sort of question by grouping elementary attributes by service. If an attribute applies to a service it is included with the service, either directly or by association. If an attribute does not apply, then it is not included in that part of the model. Ambiguities are resolved, and interoperability is enhanced. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Fri Jan 5 09:43:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16875 for ; Fri, 5 Jan 2001 09:43:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA2F55DE33; Fri, 5 Jan 2001 09:42:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D94335DE2B; Fri, 5 Jan 2001 09:42:54 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9B1D15DE1A for ; Fri, 5 Jan 2001 09:42:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA16634; Fri, 5 Jan 2001 06:42:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA19197; Fri, 5 Jan 2001 06:42:43 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA01140; Fri, 5 Jan 2001 06:42:30 -0800 (PST) Date: Fri, 5 Jan 2001 06:38:59 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: Jari Arkko Cc: "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <3A5576DC.FDA379C2@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > I'd like to include also some 'process aspects' in this > discussion. Namely, in the accounting discussions a couple > of months back we reached a conclusion that a number of > things were potentially useful but we weren't certain > if there were absolutely needed and we had doubts about > the exact desired workings of them [like proxying batches]. > Then we decided to standardize a subset of the functionality > that we saw very clearly and could agree on, still reserving > the possibility to return back to the finer functionality > in later extensions when we knew more. > > I wonder if the same process might be applied for AAA > security, since I'm worried about the schedule aspects. > All of the proposed e2e mechanisms are relatively complex. > Some of the discussions seem to indicate that at least > some modifications will be needed to the existing specs. > I have a feeling that DIAMETER must get out very soon > in order to be most useful. > > So, one approach could be that we NOW decide on only > the simple hop-by-hop security that doesn't require > anything from DIAMETER specs (IPsec) or requires > very little (the Integrity-Check-Vector AVP). Then, > as a Step 2, somewhat later, we reach a conclusion > on the e2e security as an extension to the DIAMETER > specs. > > Whether this is a good idea depends of course on > > * Whether DIAMETER is useful at all without e2e > security [dunno, what do you others think?] > > * Whether we feel that the final e2e solution > would somehow have an impact on the base > protocol [in my opinion it won't] > > * Whether it is true that the the simple security > is either done or goes fast in the standardization > sense [I feel it would, both the AVP and the IPsec > approach are old technology, though of course > we could optimize them to infinity if we want] > > What do you think? > As I stated at the IETF, 3GPP2's stance at this point is exactly what you've described above. They would like to see an e2e approach developed, but they do not want it to affect the schedule that they've been assuming for months. Therefore, I am in agreement that hop-by-hop stays in the document, since it is relatively simple, and addresses nodes that do not support IPSec. Later on we can add e2e. I think given some of the questions I've seen on the list, and Steven's e-mail, perhaps a design team should be put together to answer many of these questions and issues. My 2 cents, PatC From owner-aaa-bof@merit.edu Fri Jan 5 09:49:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16995 for ; Fri, 5 Jan 2001 09:49:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99A555DE04; Fri, 5 Jan 2001 09:48:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CDF15DE2B; Fri, 5 Jan 2001 09:48:54 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5CD9E5DE04 for ; Fri, 5 Jan 2001 09:48:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28669; Fri, 5 Jan 2001 06:48:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA20261; Fri, 5 Jan 2001 06:48:44 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA01306; Fri, 5 Jan 2001 06:48:42 -0800 (PST) Date: Fri, 5 Jan 2001 06:45:11 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: Kaushik Narayan Cc: Pat.Calhoun@eng.sun.com, "Bernard D. Aboba" , aaa-wg@merit.edu, smb@research.att.com In-Reply-To: "Your message with ID" <200101050946.PAA04484@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > 5. Reliance on third party security servers. I believe that any solution that > > relies on yet another security server infrastructure is problematic. The 3G > > folks, for example, are actually trying to reduce the amount of stuff in their > > network. By using something that requires more servers is good for Sun > > perhaps, but complicates the network. Now CMS does require certificates, but > > these can be pre-configured using contract negotiation, so it is not required > > to have the PKI infrastructure. > > > The Kerberos KDC( third party security server) is used for acquiring > TGTs and service principal tickets. The Kerberos-WG has a draft > (PK-TAPP) > which addresses elimination of the KDC and uses direct application > exchange > to acquire TGTs and service principal ticket. > What do you use as the bootstrap security association? Each device shares a secret keys with all other devices, or a cert? PatC From owner-aaa-bof@merit.edu Fri Jan 5 09:51:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17009 for ; Fri, 5 Jan 2001 09:51:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC2575DE3F; Fri, 5 Jan 2001 09:51:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A67215DE2B; Fri, 5 Jan 2001 09:51:31 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id C39F85DD9A for ; Fri, 5 Jan 2001 09:51:30 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 58CF774 for ; Fri, 5 Jan 2001 09:51:37 -0500 (EST) From: "Bob Kopacz" To: "Aaa-Wg@Merit. Edu" Subject: draft-ietf-aaa-solutions-01 / "M" bit handling by proxies Date: Fri, 5 Jan 2001 09:51:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Question re: "M" bit in AVP header. Do proxies handle the "M" bit differently than home servers and NASes? For example, it seems reasonable that a proxy server which receives an unknown mandatory AVP might want to pass the AVP along, whereas a NAS or home server would want to treat this as an error. The draft-ietf-aaa-solutions-01.txt states the following: > 9.5.3 What are correct error responses? > > If a DIAMETER peer receives an AVP with the "M" bit > set, and it does not recognize the AVP or does not > support the service described by the AVP, it must > reject the access request or treat the access response > as if it were a rejection. From owner-aaa-bof@merit.edu Fri Jan 5 09:52:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17021 for ; Fri, 5 Jan 2001 09:52:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FFF35DE2B; Fri, 5 Jan 2001 09:52:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6AFE05DE1A; Fri, 5 Jan 2001 09:52:33 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 743D95DD9A for ; Fri, 5 Jan 2001 09:52:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19044; Fri, 5 Jan 2001 06:52:18 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA20846; Fri, 5 Jan 2001 06:52:17 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA01393; Fri, 5 Jan 2001 06:52:16 -0800 (PST) Date: Fri, 5 Jan 2001 06:48:45 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: Kaushik Narayan Cc: stephen.farrell@baltimore.ie, "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <200101051041.QAA09686@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Well with Kerberos and Radius I have used a per server service principal. > I create a Kerberos security context between the NAS/NAS realm proxy to > the homeserver cutting through any intermediate proxies. Just to be clear, the existence of proxies is not due to some protocol deficiency, but rather due to some business relationships and/or network architecture. PatC From owner-aaa-bof@merit.edu Fri Jan 5 10:07:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17261 for ; Fri, 5 Jan 2001 10:07:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 03A285DE51; Fri, 5 Jan 2001 10:07:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DBA8E5DE44; Fri, 5 Jan 2001 10:07:25 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BD4F05DE1A for ; Fri, 5 Jan 2001 10:07:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23400; Fri, 5 Jan 2001 07:07:19 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA23901; Fri, 5 Jan 2001 07:07:14 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA01750; Fri, 5 Jan 2001 07:07:13 -0800 (PST) Date: Fri, 5 Jan 2001 07:03:42 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Choice of Data Model SMI vs XML vs. UML To: David Spence Cc: AAA Working Group In-Reply-To: "Your message with ID" <3A55D50B.58D574AE@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > 1. SMI Derivative vs. XML > > An advantage of using some derivative of SMI over XML is that the > "formal specification" can actually be implemented in the edge > device. This improves interoperability and allows interworking > between tools that use different protocols. > > 2. Which derivative of SMI to use > > I don't have strong feelings as to which SMI derivative is best. We > chose SPPI for draft-spence-aaa-nas-data-model-00.txt because it was > designed for policy provisioning, is compatible with COPS (more on > this at item 3, below), and is somewhat more mature than SMIng (has > passed WG last call and is ready for IETF last call). > > The AAA WG may prefer to be more forward looking and use SMIng or to > opt for greater maturity and use SMI v2. > Whatever the WG decides, it MUST be something mature, and currently work in progress. > 3. Interworking COPS and DIAMETER > > If the AAA WG chooses XML or chooses an SMI derivative for formal > notation only without providing a protocol mapping, then the > following problem arises. > > Suppose an edge device wishes to provide both network access and > premium QoS. It would be nice to be able to obtain a single > admission decision covering both the network access and the premium > QoS with a single request. It is troublesome to the ISP to allocate > QoS resources and then deny access or to create an access session and > then have to terminate it because the QoS request failed. If the > edge device has to use DIAMETER to obtain the network access > admission decision and COPS to obtain the QoS admission decision, it > will be very difficult to coordinate the two decisions. If this > happens, someone might be tempted to doubt the IETF's wisdom in > standardizing two protocols where one might have sufficed. > > Of course, if the two protocols use the same data model, then the > problem goes away. Either protocol could be used for either type of > request, so the edge device could request the two related services in > a single message using either protocol. > > But if the two protocols do not use the same data model, then it > might be a good idea to create an escape mechanism. Could we at > least define a DIAMETER AVP type of COPS message or COPS object which > means, "shell out to the part of the AAA server that understands > COPS, process this thing and then return"? That way, at least, the > two requests could be piggybacked onto the same message so that a > sophisticated enough AAA server could process them together. Just to be clear, I am not sure how allowing the dictionary and other config files), and the documentation to specify message formats in XML or SMI to really help interworking of protocols on the wire :( The scenario you described above *will* happen, and in the cases that I've seen, the local PDP will contact the local DIAMETER server to retrieve user profile information, since the information is in the user's home network and COPS doesn't do inter-domain. > > 4. What combinations of attributes make sense? > > A problem which RADIUS leaves unaddressed and which so far has not > been addressed by DIAMETER is the question of which attributes can > and can not be meaningfully combined in a message. Or, to put it > another way, which attributes pertain to which services. Here's an > example. > > The description of the Termination-Action attribute in RFC 2865 says > simply, > > "This Attribute indicates what action the NAS should take when the > specified service is completed. It is only used in Access-Accept > packets." > > The RFC does not specify which services the attribute applies to. I > assume it applies to the Login service. Could it also apply to the > Framed service? If I combine it with attributes such as > Framed-Protocol, Framed-IP-Address, and Framed-IP-Netmask, what am I > expecting the NAS to do? > > A data model provides an answer to this sort of question by grouping > elementary attributes by service. If an attribute applies to a > service it is included with the service, either directly or by > association. If an attribute does not apply, then it is not included > in that part of the model. Ambiguities are resolved, and > interoperability is enhanced. I agree that the specifications must be clear. If in theNAS dial-up world certain ambiguities still exist, then let's fix them in the spec. One possibility is to make use of different command sets for PPP and terminal server. In fact, this would REALLY clean up the extension IMHO. PatC From owner-aaa-bof@merit.edu Fri Jan 5 10:54:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA18276 for ; Fri, 5 Jan 2001 10:54:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 044A65DE44; Fri, 5 Jan 2001 10:53:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E85585DE1A; Fri, 5 Jan 2001 10:53:47 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 0EA695DDFF for ; Fri, 5 Jan 2001 10:53:47 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id A3D731E0B5; Fri, 5 Jan 2001 10:53:46 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA12938; Fri, 5 Jan 2001 10:53:45 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id A5AB835DC2; Fri, 5 Jan 2001 10:53:44 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Jari Arkko Cc: "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jan 2001 10:53:44 -0500 Message-Id: <20010105155344.A5AB835DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message <3A5576DC.FDA379C2@lmf.ericsson.se>, Jari Arkko writes: > >I wonder if the same process might be applied for AAA >security, since I'm worried about the schedule aspects. >All of the proposed e2e mechanisms are relatively complex. >Some of the discussions seem to indicate that at least >some modifications will be needed to the existing specs. >I have a feeling that DIAMETER must get out very soon >in order to be most useful. > >So, one approach could be that we NOW decide on only >the simple hop-by-hop security that doesn't require >anything from DIAMETER specs (IPsec) or requires >very little (the Integrity-Check-Vector AVP). Then, >as a Step 2, somewhat later, we reach a conclusion >on the e2e security as an extension to the DIAMETER >specs. The question is whether or not we can do this. Bernard's note included the folloiwng: > I would like to propose that we assume that a AAA proxy cannot be trusted > with knowledge of user/tunnel passwords and MIP keys. I would also > propose that we assume that the AAA proxy MAY not be trusted with certain > other security-critical attributes (e.g. filter specs, tunnel attributes, > EAP-Message, etc.). If the group accepts that, we have to have some end-to-end, object security. And the hard part isn't the syntax of the protected piece, it's figuring out how to set up the security association and transmit or exchange the necessary keys. In other words, we have to solve the biggest problem now. Everything else is pretty easy. --Steve Bellovin From owner-aaa-bof@merit.edu Fri Jan 5 11:00:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18328 for ; Fri, 5 Jan 2001 11:00:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD75E5DE55; Fri, 5 Jan 2001 10:59:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CBA725DE1A; Fri, 5 Jan 2001 10:59:39 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 64AD95DDFF for ; Fri, 5 Jan 2001 10:59:38 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA12592; Fri, 5 Jan 2001 16:59:33 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA00350; Fri, 5 Jan 2001 16:59:32 +0100 Date: Fri, 5 Jan 2001 16:59:32 +0100 Message-Id: <200101051559.QAA00350@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Erik.Guttman@germany.sun.com Cc: aaa-wg@merit.edu In-reply-to: (message from Erik Guttman on Fri, 29 Dec 2000 16:47:36 +0100 (MET)) Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Erik Guttman writes: Erik> In my opinion we should select the XML solution since it is Erik> simple, and adequate. Good to hear that you (as the author of this proposal) find is simple and adequate. :-) We unfortunately did not have any time during the last WG meeting to actually debate what is "adequate". My understanding of the three proposals is that they try to achive very different things. Here is how I look at the three proposals: Erik's proposal is more an XML version of a repository and focuses on things that are easily loaded into an implementation at runtime. XML DTD however only specify how XML tags may be nested. There is no way to specify in plain XML what is allowed between two tags or what is allowed as an attribute value. Furthermore, XML DTDs have no concept of version handling. Yes, this makes things simple - but will it be adequate in say 2 years from now if DIAMETER is a success? (Note that the XML folks created XML Schemas because it turns out that a simple DTD is not enough to specify data structures precisely enough.) Juergen's proposal tries to change the way AVPs are currently defined - use a real data definition language instead of free-form english text. SMIng is a data definition language with well defined semantics which allows to formally introduce new types or reusable components. SMIng definitions are also protocol independent which allows to reuse definitions across management protocols. SMIng also provides support for versioning. Of course, SMIng is an ongoing WG effort. The question is whether it is adequate to take something (perhaps too) simple which needs fixing in say 2 years or whether it is adequate to move a bit slower and to take something which is a safer long term investment. David's proposal comes yet again from another different angle. Its main background is the observation that AVP combinations that can be meaningfully combined in a message are actually not well defined. He obviously did some serious work to re-engineer this information out of the RADIUS specifications and later used this information to generate an SPPI definition. Given the fact that three people obviously had three pretty different opinions what is adequate data modeling in this context, I must conclude that we lack a common sense of what the requirements are. If we want to be serious, then we need to address this issue. Discussions of the style "I think XML is better than SMIng." without considering the motivations for the proposal and the pros and cons of the approaches is IMHO waste of bandwidth. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Fri Jan 5 11:03:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18429 for ; Fri, 5 Jan 2001 11:03:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A5C35DE7A; Fri, 5 Jan 2001 11:00:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7A5385DE1A; Fri, 5 Jan 2001 11:00:53 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id 81FE85DDFF for ; Fri, 5 Jan 2001 11:00:52 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQjwrg03250 for ; Fri, 5 Jan 2001 16:00:52 GMT Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQjwrg19480 for ; Fri, 5 Jan 2001 11:00:52 -0500 (EST) Date: Fri, 5 Jan 2001 11:00:52 -0500 (EST) From: Stuart A Barkley To: aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Thu, 4 Jan 2001, Bernard D. Aboba wrote: > I would like to propose that we assume that a NAS can be trusted > in terms of handling of AAA attributes. That is, that we can > assume that the NAS will not steal user/tunnel passwords and MIP > keys. We can also assume that the NAS will conform to the protocol > in carrying out the requested service to the best of its ability > or indicating that it cannot do so. Also that the NAS will provide > accurate accounting data to the best of its ability. This seems > reasonable to me because while NAS devices are certainly hackable, > it is harder to modify them nefariously than it is to say, hack a > proxy server and its OS. Who trusts the NAS? The owner of the NAS probably does (due to a business relationship with the vendor and testing of the NAS in addition to the trust), but does the HOME AAA server even know there really is a NAS? The only trust the home AAA server has is the chain of trust between the server and the proxies, brokers or gateways along the way. > I would like to propose that we assume that a AAA proxy cannot be > trusted with knowledge of user/tunnel passwords and MIP keys. I > would also propose that we assume that the AAA proxy MAY not be > trusted with certain other security-critical attributes (e.g. > filter specs, tunnel attributes, EAP-Message, etc.). I'm not sure why you would trust a NAS with reusable user passwords or tunnel passwords either. > In general, a NAS will have a long-lived relationship with a AAA > proxy, so that public key operations (at least for hop-by-hop) are > too expensive and largely unnecessary. In the portions of the trust web I've seen all the devices have long lived relationships. Each NAS has an association with a certain number of proxies. Each proxy has associations with a number of remote radius servers. These relationships change only very slowly over time. The NAS will typically have the same relationships for its entire life. The proxies will have fixed relationships which change with business contracts. > However, for e2e, I'm not sure [about long-lived relationships]. > Roaming is probably only a small fraction of the total traffic on > most NASen, and there may not be enough traffic to a single e2e > destination to justify key exchange. For the most part we treat ALL usage as roaming on our dial up systems. We really don't distinguish between our various corporate service offerings and customer service offerings. We are our own customer for dial service. Sometimes it will be the same person on both sides of the relationship, but we try to maintain the distinction between the roles. Our proxies exist mostly as a management tool so that we can keep the number of key exchanges and configurations under control. Our customers usually know that they are exchanging information with proxies instead of the NAS itself, but that isn't important. As far as they should be concerned the proxy cluster is one really big NAS. As far as our actual physical NAS equipment, they certainly are constantly dealing with 100s of different home AAA servers. I don't really see any advantage to having the NAS build and drop associations with these constantly. Stuart -- Stuart A Barkley email: stuartb@uu.net UUNET WorldCom phone: +1 703 886 5645 I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone From owner-aaa-bof@merit.edu Fri Jan 5 11:04:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18440 for ; Fri, 5 Jan 2001 11:04:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4393E5DEE5; Fri, 5 Jan 2001 11:03:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 329FE5DEE4; Fri, 5 Jan 2001 11:03:20 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id B4B955DEE3 for ; Fri, 5 Jan 2001 11:03:18 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA12886; Fri, 5 Jan 2001 17:03:17 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA00357; Fri, 5 Jan 2001 17:03:17 +0100 Date: Fri, 5 Jan 2001 17:03:17 +0100 Message-Id: <200101051603.RAA00357@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Pat.Calhoun@Eng.Sun.COM Cc: aaa-wg@merit.edu In-reply-to: (message from Pat Calhoun on Tue, 2 Jan 2001 16:35:27 -0800 (PST)) Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Pat Calhoun writes: Pat> So far, I have heard from support for XML and SMIng more than Pat> UML, which according to David does not have many free "tools" Pat> available for. Given these points, which are not technical in Pat> nature, I would opt for XML. FYI: is a great free UML editor. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Fri Jan 5 11:05:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18448 for ; Fri, 5 Jan 2001 11:05:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id D714D5DEEB; Fri, 5 Jan 2001 11:03:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BC5B15DEEA; Fri, 5 Jan 2001 11:03:25 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EE60B5DEE9 for ; Fri, 5 Jan 2001 11:03:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12994; Fri, 5 Jan 2001 08:03:12 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28866; Fri, 5 Jan 2001 08:03:11 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA03417; Fri, 5 Jan 2001 08:03:10 -0800 (PST) Date: Fri, 5 Jan 2001 07:59:38 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: "Steven M. Bellovin" Cc: Jari Arkko , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <20010105155344.A5AB835DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > The question is whether or not we can do this. Bernard's note included > the folloiwng: > > > I would like to propose that we assume that a AAA proxy cannot be trusted > > with knowledge of user/tunnel passwords and MIP keys. I would also > > propose that we assume that the AAA proxy MAY not be trusted with certain > > other security-critical attributes (e.g. filter specs, tunnel attributes, > > EAP-Message, etc.). > > If the group accepts that, we have to have some end-to-end, object security. > And the hard part isn't the syntax of the protected piece, it's > figuring out how to set up the security association and transmit or > exchange the necessary keys. In other words, we have to solve the > biggest problem now. Everything else is pretty easy. Right. And as I stated in another e-mail, how do you do this when the following are true: 1. A prior exchange MAY be needed in order to distribute symmetric keys. Should this be done within the DIAMETER protocol? I believe so given that the nodes do not interact direct, but rather through a set of proxies. 2. How complicated is the key distribution, when you have no idea of the identity of the box you will be communicating with on the home network (this is true because the home network may have many DIAMETER servers). So, first some way to retrieve the identity of the box is necessary, then the key distribution occurs (esp since the key distribution will include some encrypted text - assuming pk encription, of course). 3. How do you deal with the natural tendency of the protocol to fall back to an alternate server when a primary fails? If the NAS is communicating with a server in the home network, and a symmetric key has been negotiated, and the box fails, the proxies will tend to fall back to an alternate server. All encrypted text will not be decrypted by the alternate servers, and failures will occur. This breaks our high reliability features of the protocol. question for Steven: Is it feasible for all DIAMETER servers to "share" a private/public key? It is assumed, of course, that these servers are under the same administrative control. Doesn't this eliminate the possibility to make use of hardware crypto cards that do not allow for private keys to be exported (for security reasons?). Thanks, PatC From owner-aaa-bof@merit.edu Fri Jan 5 11:45:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19104 for ; Fri, 5 Jan 2001 11:45:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A4EE5DE1A; Fri, 5 Jan 2001 11:44:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 695105DE16; Fri, 5 Jan 2001 11:44:42 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 1803A5DDA5 for ; Fri, 5 Jan 2001 11:44:41 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f05GgS253946; Fri, 5 Jan 2001 11:42:28 -0500 (EST) (envelope-from barney) Date: Fri, 5 Jan 2001 11:42:28 -0500 From: Barney Wolff To: "Steven M. Bellovin" Cc: Jari Arkko , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security Message-ID: <20010105114228.A53850@mx.databus.com> References: <20010105155344.A5AB835DC2@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010105155344.A5AB835DC2@smb.research.att.com>; from smb@research.att.com on Fri, Jan 05, 2001 at 10:53:44AM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk Steve, does it actually make sense to trust the NAS, which is often loaded via TFTP, while not trusting the proxies? I understand the argument that the fewer the boxes that are trusted the better, but this strikes me as spending lots on a fancy door lock while leaving the windows open, or at least unbarred. Let's remember just what it is that we're trying to accomplish: Protect PAP passwords, when PAP has been deprecated for years. Protect Tunnel passwords, when it's perfectly possible to integrate an LNS with a AAA proxy and generate single-use tunnel passwords. Deter criminal or careless proxies - and do we really need to detect *every* instance of alteration, or just make it impossible to do it consistently without detection? Barney On Fri, Jan 05, 2001 at 10:53:44AM -0500, Steven M. Bellovin wrote: > > The question is whether or not we can do this. Bernard's note included > the folloiwng: > > > I would like to propose that we assume that a AAA proxy cannot be trusted > > with knowledge of user/tunnel passwords and MIP keys. I would also > > propose that we assume that the AAA proxy MAY not be trusted with certain > > other security-critical attributes (e.g. filter specs, tunnel attributes, > > EAP-Message, etc.). > > If the group accepts that, we have to have some end-to-end, object security. > And the hard part isn't the syntax of the protected piece, it's > figuring out how to set up the security association and transmit or > exchange the necessary keys. In other words, we have to solve the > biggest problem now. Everything else is pretty easy. From owner-aaa-bof@merit.edu Fri Jan 5 11:57:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19273 for ; Fri, 5 Jan 2001 11:57:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 77E085DFC7; Fri, 5 Jan 2001 11:54:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 51B3B5DFC3; Fri, 5 Jan 2001 11:54:54 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 1CB725DF30 for ; Fri, 5 Jan 2001 11:54:20 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 105794CE42; Fri, 5 Jan 2001 11:54:16 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA14008; Fri, 5 Jan 2001 11:54:15 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id EA8E435DC2; Fri, 5 Jan 2001 11:54:14 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Barney Wolff Cc: Jari Arkko , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jan 2001 11:54:14 -0500 Message-Id: <20010105165415.EA8E435DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message <20010105114228.A53850@mx.databus.com>, Barney Wolff writes: >Steve, does it actually make sense to trust the NAS, which is often >loaded via TFTP, while not trusting the proxies? I understand the >argument that the fewer the boxes that are trusted the better, but >this strikes me as spending lots on a fancy door lock while leaving >the windows open, or at least unbarred. > >Let's remember just what it is that we're trying to accomplish: >Protect PAP passwords, when PAP has been deprecated for years. >Protect Tunnel passwords, when it's perfectly possible to integrate >an LNS with a AAA proxy and generate single-use tunnel passwords. >Deter criminal or careless proxies - and do we really need to detect >*every* instance of alteration, or just make it impossible to do it >consistently without detection? I personally have no idea what sort of protection is necessary for various data -- I leave that to folks who understand the operational requirements. My job is to pose enough questions to make the security solution space quite small. I do agree with you that statistical detection is adequate, though design of such a mechanism may prove tricky. As for PAP -- well, yes, I dislike it as well, but it wasn't all that long ago that I was involved in a AAA-relevant situation where some players, at least, felt that PAP was necessary. --Steve Bellovin From owner-aaa-bof@merit.edu Fri Jan 5 11:57:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19280 for ; Fri, 5 Jan 2001 11:57:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB3905DEE8; Fri, 5 Jan 2001 11:54:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 209A65DF16; Fri, 5 Jan 2001 11:54:53 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9CCEF5DF24 for ; Fri, 5 Jan 2001 11:52:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00687; Fri, 5 Jan 2001 08:52:31 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA08963; Fri, 5 Jan 2001 08:52:30 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA04959; Fri, 5 Jan 2001 08:52:24 -0800 (PST) Date: Fri, 5 Jan 2001 08:48:52 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: Barney Wolff Cc: "Steven M. Bellovin" , Jari Arkko , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <20010105114228.A53850@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Let's remember just what it is that we're trying to accomplish: > Protect PAP passwords, when PAP has been deprecated for years. and MIP keys. PatC From owner-aaa-bof@merit.edu Fri Jan 5 12:03:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19338 for ; Fri, 5 Jan 2001 12:03:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CD5B5DEB6; Fri, 5 Jan 2001 12:03:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8909D5DEB3; Fri, 5 Jan 2001 12:03:09 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 589925DEAC for ; Fri, 5 Jan 2001 12:03:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23204; Fri, 5 Jan 2001 09:02:49 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA11644; Fri, 5 Jan 2001 09:02:44 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA05282; Fri, 5 Jan 2001 09:02:42 -0800 (PST) Date: Fri, 5 Jan 2001 08:59:10 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: "Steven M. Bellovin" Cc: Barney Wolff , Jari Arkko , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <20010105165415.EA8E435DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I do agree with you that statistical detection is adequate, though > design of such a mechanism may prove tricky. As for PAP -- well, yes, > I dislike it as well, but it wasn't all that long ago that I was > involved in a AAA-relevant situation where some players, at least, felt > that PAP was necessary. The reason for the original PAP comment where it decrecated was due to its security weaknesses when used with static passwords, but these days PAP is used for token card authentication. EAP does also provide support for token cards, but there are very few implementations around. PatC From owner-aaa-bof@merit.edu Fri Jan 5 12:06:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19413 for ; Fri, 5 Jan 2001 12:06:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E06355DEB9; Fri, 5 Jan 2001 12:05:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D000D5DEB8; Fri, 5 Jan 2001 12:05:52 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 744765DEB3 for ; Fri, 5 Jan 2001 12:05:50 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA11045; Fri, 5 Jan 2001 22:31:36 +0530 (IST) From: Kaushik Narayan Message-Id: <200101051701.WAA11045@cisco.com> Subject: Re: Making the hard choices on AAA security To: Pat.Calhoun@Eng.Sun.COM Date: Fri, 5 Jan 2001 22:31:36 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), stephen.farrell@baltimore.ie, aboba@internaut.com (Bernard D. Aboba), aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) In-Reply-To: from "Pat Calhoun" at Jan 05, 2001 06:48:45 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk pat, hi! > > > > Well with Kerberos and Radius I have used a per server service principal. > > I create a Kerberos security context between the NAS/NAS realm proxy to > > the homeserver cutting through any intermediate proxies. > > > Just to be clear, the existence of proxies is not due to some protocol > deficiency, but rather due to some business relationships and/or network > architecture. Sorry for the inappropriate use of words. What I meant to say is that in an end-to-end mode the security association created between the NAS and the homeserver would be transparent to any intermediate proxy. kaushik! > > PatC > > > From owner-aaa-bof@merit.edu Fri Jan 5 12:19:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19568 for ; Fri, 5 Jan 2001 12:19:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAF155DE9E; Fri, 5 Jan 2001 12:17:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D8E815DE9D; Fri, 5 Jan 2001 12:17:04 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id E0B2C5DE84 for ; Fri, 5 Jan 2001 12:17:01 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA11551; Fri, 5 Jan 2001 22:42:57 +0530 (IST) From: Kaushik Narayan Message-Id: <200101051712.WAA11551@cisco.com> Subject: Re: Making the hard choices on AAA security To: Pat.Calhoun@eng.sun.com Date: Fri, 5 Jan 2001 22:42:57 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), aboba@internaut.com (Bernard D. Aboba), aaa-wg@merit.edu, smb@research.att.com In-Reply-To: from "Pat Calhoun" at Jan 05, 2001 06:45:11 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk pat, hi! > > > > > > > > 5. Reliance on third party security servers. I believe that any solution that > > > relies on yet another security server infrastructure is problematic. The 3G > > > folks, for example, are actually trying to reduce the amount of stuff in their > > > network. By using something that requires more servers is good for Sun > > > perhaps, but complicates the network. Now CMS does require certificates, but > > > these can be pre-configured using contract negotiation, so it is not required > > > to have the PKI infrastructure. > > > > > > The Kerberos KDC( third party security server) is used for acquiring > > TGTs and service principal tickets. The Kerberos-WG has a draft > > (PK-TAPP) > > which addresses elimination of the KDC and uses direct application > > exchange > > to acquire TGTs and service principal ticket. > > > What do you use as the bootstrap security association? Each device shares a > secret keys with all other devices, or a cert? PK-TAPP would use public key certs for bootsrap security association and Kerberos for symmetric key exchange. kaushik! > > PatC > > From owner-aaa-bof@merit.edu Fri Jan 5 12:35:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19861 for ; Fri, 5 Jan 2001 12:35:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id A97715DE81; Fri, 5 Jan 2001 12:35:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 974765DE16; Fri, 5 Jan 2001 12:35:19 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 296345DDA5 for ; Fri, 5 Jan 2001 12:35:18 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16893; Fri, 5 Jan 2001 09:35:15 -0800 (PST) Received: from vayne (muc-isdn-12 [129.157.164.112]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA05341; Fri, 5 Jan 2001 18:35:12 +0100 (MET) Date: Fri, 5 Jan 2001 18:45:37 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101051559.QAA00350@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Juergen, > Erik> In my opinion we should select the XML solution since it is > Erik> simple, and adequate. > > Good to hear that you (as the author of this proposal) find is simple > and adequate. :-) I guess I came off sounding smug, sorry :-/ > We unfortunately did not have any time during the last WG meeting to > actually debate what is "adequate". That is indeed the crux of the issue. Let's pin down what we are trying to do. From the 'issues' draft, section 9.3: The use of a formal notation for the definition of (potentially complex) application specific data types has proven to be valuable, especially if a protocol is designed the be extensible. A formal notation enables tools that can (a) verify the correctness of data definitions, (b) automate some of the implementation process, (c) help in debugging scenarios, and (d) enable implementations that can be easily adapted to vendor specific extensions. Furthermore, the separation of the data definitions from the core protocol specification allows extension writers to re-use existing data definitions (e.g. for addressing types) and it thus promotes consistency across a variety of management protocols. The formal notation will serve the extensibility of AAA implementations in terms of their data storage, interpretation, validation, display, etc. Support for the formal notation is in this sense an implementation option to enhance support ease the integration of extensions, but not required for compliance. The formal notation is not intended to define the transfer encoding (the on-the-wire byte formatting). The DIAMETER specifications of the base types include these definitions and rules. In other words, the goals are: a. Express data definitions in formal terms, to make it easier to validate the spec and implementations b. Allow for automating some of the implementation process c. Allow for definitions to be used in debugging d. Allow for ability to add definitions for new extensions The application of these goals are for (1) interpreting, (2) displaying and (3) validating DIAMETER data, stored in different ways by programs. > Erik's proposal is more an XML version of a repository and focuses on > things that are easily loaded into an implementation at runtime. XML > DTD however only specify how XML tags may be nested. There is no way > to specify in plain XML what is allowed between two tags or what is > allowed as an attribute value. Furthermore, XML DTDs have no concept > of version handling. Yes, this makes things simple - but will it be > adequate in say 2 years from now if DIAMETER is a success? (Note that > the XML folks created XML Schemas because it turns out that a simple > DTD is not enough to specify data structures precisely enough.) Well - you can set the values that an entity attribute can have. And in the case of constrained values of an AVP, I defined an tag, whereby the xml can enumerate the allowable values. I agree with versioning - that is not even addressed with the XML approach. Can you be more specific what this goal consists of? It is not discussed in draft-ietf-aaa-issues-04.txt, but we can add it to our list of goals. > Juergen's proposal tries to change the way AVPs are currently defined > - use a real data definition language instead of free-form english > text. SMIng is a data definition language with well defined semantics > which allows to formally introduce new types or reusable components. > SMIng definitions are also protocol independent which allows to reuse > definitions across management protocols. SMIng also provides support > for versioning. Of course, SMIng is an ongoing WG effort. The question > is whether it is adequate to take something (perhaps too) simple which > needs fixing in say 2 years or whether it is adequate to move a bit > slower and to take something which is a safer long term investment. I have been pushing for an adequate near term solution. The data modelling 'solution' doesn't necessarily have to appear before DIAMETER is standardized. If we are willing to wait for SMIng to be standardized, this may be a better solution. Let's finish our assessment of what the goals are and revisit the evaluation. > David's proposal comes yet again from another different angle. Its > main background is the observation that AVP combinations that can be > meaningfully combined in a message are actually not well defined. I do not know that this is a very big issue. If DIAMETER command codes specify what MUST be there and how to interpret it, other AVPs which are present should not prevent proper interpretation of the command. We have been around this point a number of times - there are good reasons to use the RADIUS approach as it is flexible: Specify what is required, allow arbitrary ordering and additional AVP message components. No one has argued for removing this flexibility, though there has been discussion about how this would facilitate a formal ABNF for the protocol. > Given the fact that three people obviously had three pretty different > opinions what is adequate data modeling in this context, I must > conclude that we lack a common sense of what the requirements are. If > we want to be serious, then we need to address this issue. Can we agree on the list of goals (a-d) and applications (1-3) above? > Discussions of the style "I think XML is better than SMIng." without > considering the motivations for the proposal and the pros and cons of > the approaches is IMHO waste of bandwidth. That is certainly not my intent. I thought we had agreed already (to draft-ietf-aaa-issues-04.txt, for which section 9.3 hasn't received any comments yet.) Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Fri Jan 5 12:50:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20103 for ; Fri, 5 Jan 2001 12:50:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F1CB5DE16; Fri, 5 Jan 2001 12:50:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E4375DDA5; Fri, 5 Jan 2001 12:50:15 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id 731685DE8D for ; Fri, 5 Jan 2001 12:50:13 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQjwrn21650 for ; Fri, 5 Jan 2001 17:50:12 GMT Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQjwrn23026 for ; Fri, 5 Jan 2001 12:50:12 -0500 (EST) Date: Fri, 5 Jan 2001 12:50:12 -0500 (EST) From: Stuart A Barkley To: aaa-wg@merit.edu Subject: Re: DISCUSSION REQUESTED: ADIF, Batching, M bit In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Wed, 20 Dec 2000, Bernard Aboba wrote: > At IETF 49, we discussed a number of issues, and I'd like to > verify that there is consensus on these points on the mailing > list. If you disagree with the conclusions below, please speak up: > > 1. Remove application layer batching support from DIAMETER. Via > use of the Nagle algorithm, DIAMETER can still support transport > layer batching, and thus it was felt that it was not necessary to > support application layer batching as well. There is still the batch accounting requirement which needs to be met by AAA. There have been some discussions on this point about using other protocols to support the requirement. FTP and SNMP have been discussed as possible support protocols for this requirements, but I don't think anything much further has been discussed. A lot of this relates to the data modeling and follow on discussions about what data is included in the accounting records. I would like to see the results of the modeling effort give us a multi-record format which can be transfered either as individual records in the real time portion or in later bulk batch mode transfers. It is very important that the SAME data be contained in the two modes of operation. One of the biggest problems we have in our current implementation is that we cannot actually use the radius accounting data since it is inconsistent with the batch data we gather and use for our primary accounting. When I'm thinking about "batch mode" data transfers, I'm thinking about hundreds, thousands or more records being transfered in a batch. Signing, acknowledgment and other operations are performed on the entire data stream, not the individual records. The accounting server collects records from multiple NAS sources in batches, then processes the records separating them based upon destination for separate transfer to that server. From owner-aaa-bof@merit.edu Fri Jan 5 12:53:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20124 for ; Fri, 5 Jan 2001 12:53:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AB875DE8D; Fri, 5 Jan 2001 12:53:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ED4A05DE84; Fri, 5 Jan 2001 12:53:05 -0500 (EST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by segue.merit.edu (Postfix) with ESMTP id 2C5ED5DDA5 for ; Fri, 5 Jan 2001 12:53:04 -0500 (EST) Received: from jariws1 (ab189d3hel.dial.kolumbus.fi [212.54.18.189]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id TAA01019; Fri, 5 Jan 2001 19:49:31 +0200 (EET) Message-ID: <005901c0773f$de9ab620$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Steven M. Bellovin" Cc: "Barney Wolff" , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" References: Subject: Re: Making the hard choices on AAA security Date: Fri, 5 Jan 2001 19:49:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat writes... > The reason for the original PAP comment where it decrecated was due to its > security weaknesses when used with static passwords, but these days PAP is > used for token card authentication. EAP does also provide support for token > cards, but there are very few implementations around. and then... > and MIP keys. Steven, does it have security significance if the keys are one-time use only? Pat, aren't they in the token card case? What about the MIB key generation - are these keys static or used only once? (Where is that defined by the way?) Jari From owner-aaa-bof@merit.edu Fri Jan 5 12:54:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20133 for ; Fri, 5 Jan 2001 12:54:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8354A5DDA5; Fri, 5 Jan 2001 12:54:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6BD665DE84; Fri, 5 Jan 2001 12:54:02 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D13C05DDA5 for ; Fri, 5 Jan 2001 12:54:00 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27385; Fri, 5 Jan 2001 09:53:48 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA24231; Fri, 5 Jan 2001 09:53:48 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA07241; Fri, 5 Jan 2001 09:53:46 -0800 (PST) Date: Fri, 5 Jan 2001 09:50:14 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: Jari Arkko Cc: Pat Calhoun , "Steven M. Bellovin" , Barney Wolff , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <005901c0773f$de9ab620$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat writes... > > > The reason for the original PAP comment where it decrecated was due to its > > security weaknesses when used with static passwords, but these days PAP is > > used for token card authentication. EAP does also provide support for token > > cards, but there are very few implementations around. > > and then... > > > and MIP keys. > > Steven, does it have security significance if the keys are one-time use only? > Pat, aren't they in the token card case? What about the MIB key generation - > are these keys static or used only once? (Where is that defined by the way?) The MIP ephemeral keys are used more than once to secure Mobile IP messages. I would recommend you read section 5.0 in draft-calhoun-diameter-mobileip-11.txt PatC From owner-aaa-bof@merit.edu Fri Jan 5 12:59:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20219 for ; Fri, 5 Jan 2001 12:59:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 751855DE8F; Fri, 5 Jan 2001 12:59:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 641A75DE8E; Fri, 5 Jan 2001 12:59:16 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by segue.merit.edu (Postfix) with ESMTP id EBD455DE84 for ; Fri, 5 Jan 2001 12:59:14 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQjwrn28823 for ; Fri, 5 Jan 2001 17:59:14 GMT Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQjwrn23319 for ; Fri, 5 Jan 2001 12:59:14 -0500 (EST) Date: Fri, 5 Jan 2001 12:59:14 -0500 (EST) From: Stuart A Barkley To: aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, 5 Jan 2001, Pat Calhoun wrote: > and MIP keys. I'm sure I must have missed something. What is a MIP key? Why would we trust a NAS with it and not a proxy? From owner-aaa-bof@merit.edu Fri Jan 5 13:05:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20391 for ; Fri, 5 Jan 2001 13:05:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F5025DEA0; Fri, 5 Jan 2001 13:05:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F1EBC5DEA1; Fri, 5 Jan 2001 13:05:23 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C233E5DEA0 for ; Fri, 5 Jan 2001 13:05:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04646; Fri, 5 Jan 2001 10:05:18 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA27231; Fri, 5 Jan 2001 10:05:17 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA07888; Fri, 5 Jan 2001 10:05:16 -0800 (PST) Date: Fri, 5 Jan 2001 10:01:44 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Making the hard choices on AAA security To: Stuart A Barkley Cc: 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 > On Fri, 5 Jan 2001, Pat Calhoun wrote: > > > and MIP keys. > > I'm sure I must have missed something. > > What is a MIP key? > > Why would we trust a NAS with it and not a proxy? > I would trust a proxy in the foreign network, but not one that belongs to some other AS. The reason being that the keys are used to secure mobile ip messages, so you wouldn't want others to be able to forge mobile ip messages (although cooperation from the mobile is required anyways, so perhaps I am just paranoid). PatC From owner-aaa-bof@merit.edu Fri Jan 5 13:43:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21333 for ; Fri, 5 Jan 2001 13:43:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88CBB5DE95; Fri, 5 Jan 2001 13:43:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 734235DE9B; Fri, 5 Jan 2001 13:43:03 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id 7BAA35DE95 for ; Fri, 5 Jan 2001 13:42:59 -0500 (EST) Received: by balinese.baltimore.ie; id SAA01357; Fri, 5 Jan 2001 18:41:56 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma018335; Fri, 5 Jan 01 18:21:00 GMT Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA01940; Fri, 5 Jan 2001 18:20:54 GMT Message-ID: <3A561086.EFA68BFA@baltimore.ie> Date: Fri, 05 Jan 2001 18:20:54 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: "Steven M. Bellovin" , Jari Arkko , "Bernard D. Aboba" , "Aaa-Wg@Merit. Edu" Subject: Re: Making the hard choices on AAA security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Fairly sure I'm not the intended Ste[ph|v]en, but I'll answer anyway. > question for Steven: Is it feasible for all DIAMETER servers to "share" a > private/public key? It is assumed, of course, that these servers are under the > same administrative control. Doesn't this eliminate the possibility to make > use of hardware crypto cards that do not allow for private keys to be exported > (for security reasons?). Most crypto accelerators include the capability to create clones, so you can move private keys about. Its usually not that pretty a procedure though, but ok to do very occasionally. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Fri Jan 5 14:49:01 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22392 for ; Fri, 5 Jan 2001 14:49:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 111BC5DE97; Fri, 5 Jan 2001 14:47:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EE4E25DEAC; Fri, 5 Jan 2001 14:47:30 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 6A0455DE97 for ; Fri, 5 Jan 2001 14:47:29 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA04232; Fri, 5 Jan 2001 14:46:58 -0500 (EST) Date: Fri, 5 Jan 2001 14:46:57 -0500 (EST) From: Mark Eklund To: diameter@diameter.org, aaa-wg@merit.edu Subject: Diameter correspondences. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, I was reading draft-calhoun-diameter-17.txt and noticed that it says that for MD5 Encrypted-Payload the first 16 octets hash is formed from the nonce followed by the shared secret. Shouldn't this be the shared secret followed by the nonce to be compatible with RADIUS RFC-2865? draft-calhoun-diameter-17.txt says that MD5 Encrypted-Payload should be encrypted as One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 hash is performed on the: - last Nonce AVP which precedes the Encrypted-Payload AVP - the shared authentication secret This MD5 hash value is then XORed with the first 16 octet segment of the buffer to encrypt. The resulting 16 octet result is saved as the first 16 octets of the encrypted buffer. The result is also used to calculate a new value using MD5: - the shared authentication secret - the 16 byte result of the previous XOR While RFC2865 says it should be Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. Break the password into 16-octet chunks p1, p2, etc. with the last one padded at the end with nulls to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need intermediate values b1, b2, etc. b1 = MD5(S + RA) c(1) = p1 xor b1 b2 = MD5(S + c(1)) c(2) = p2 xor b2 . . . . . . bi = MD5(S + c(i-1)) c(i) = pi xor bi The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation. Thanks, -mark From owner-aaa-bof@merit.edu Fri Jan 5 15:04:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA22663 for ; Fri, 5 Jan 2001 15:04:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88E2A5DEC3; Fri, 5 Jan 2001 15:01:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 784065DE9D; Fri, 5 Jan 2001 15:01:39 -0500 (EST) Received: from omta01.mta.everyone.net (sitemail.everyone.net [216.200.145.35]) by segue.merit.edu (Postfix) with ESMTP id 81D3A5DE9C for ; Fri, 5 Jan 2001 15:01:38 -0500 (EST) Received: from sitemail.everyone.net (reports [216.200.145.62]) by omta01.mta.everyone.net (Postfix) with ESMTP id 308071B1F; Fri, 5 Jan 2001 12:01:17 -0800 (PST) Received: by sitemail.everyone.net (Postfix, from userid 99) id 71B882747; Fri, 5 Jan 2001 12:01:28 -0800 (PST) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) Date: Fri, 5 Jan 2001 12:01:28 -0800 (PST) From: Carlo Gold To: undisclosed Subject: Free Resume Access. Reply-To: employservice@emailaccount.com X-Originating-Ip: [65.80.105.205] Message-Id: <20010105200128.71B882747@sitemail.everyone.net> Sender: owner-aaa-bof@merit.edu Precedence: bulk Subject: Free Resume Access I understand you may have immediate needs for a resume database and on-line job posting ability. Would you have time to take a FREE look at our site and see if our services are something you need? I am offering you a FREE One-Day Trial that will allow you to search through over 5 million resumes and show you what it's like to be a member to one of the best on-line employment sites in the business today! Why not give us a try, you just might find that perfect candidate you're searching for without ever paying a cent. Also, if you sign-up within the next 5 days you will benefit from our special of 50%OFF our regular rates. If you'd like a FREE Trial at our site or more information about our services please contact me at (904) 261-0044 or I'd be happy to send you an e-mail with more detailed information. I look forward to hearing from you soon. Sincerely, Carlo Gold employservices@emailaccount.com _____________________________________________________________ Sign up for the world's most memorable free email address! Get yourname@emailaccount.com at http://www.emailaccount.com/ From owner-aaa-bof@merit.edu Fri Jan 5 16:29:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA23882 for ; Fri, 5 Jan 2001 16:29:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id D60465DEA3; Fri, 5 Jan 2001 16:29:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C4A435DEA1; Fri, 5 Jan 2001 16:29:04 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9281E5DE9D for ; Fri, 5 Jan 2001 16:29:03 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 3DFF774 for ; Fri, 5 Jan 2001 16:29:10 -0500 (EST) From: "Bob Kopacz" To: "Aaa-Wg@Merit. Edu" Subject: draft-calhoun-diameter-17.txt / DRI capabilities negotiation Date: Fri, 5 Jan 2001 16:28:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Question re: Advertisement of supported extensions in Device-Reboot-Ind (DRI) message. I'm fuzzy about what a AAA server, which may wear many hats, sends as its capabilities in a DRI. For example, suppose I am a AAA server which for some realms act as the home server, for other realms act as a simple routing proxy, and for others realms act as a broker proxy. And suppose I locally support only the NASREQ extension. When acting as a simple routing proxy, I may be able to pass through messages for extensions supported by the NAS and the remote home server, even if I don't locally support those extensions. When acting as a broker proxy, maybe I need to know more about locally unsupported extensions. What do I send the NAS in my DRI? If I say I only support NASREQ, then I'm advertising reduced proxying capablity. The draft-calhoun-diameter-17.txt states the following: > 2.6 Device-Reboot-Ind (DRI) Command > > [blah blah blah] > > The DRI message is also used for capabilities > negotiation, such as the supported protocol version > number, and the locally supported extensions. The > receiver uses the extensions advertised in order to > determine whether it SHOULD send certain > application-specific DIAMETER commands. A DIAMETER node > MUST retain the supported extensions in order to ensure > that unrecognized commands and/or AVPs are not sent to > a peer. and mentions the case where the downstream proxy is less capable: > Note that in a proxy environment, it is still possible > that a downstream proxy has no available peer that have > advertised the extension that corresponds to the > Command-Code, and therefore the request cannot be > forwarded any further. The DIAMETER base protocol > provides this error reporting, via the Result-Code AVP. -------------------------------------------------------------- Bob Kopacz mailto:bkopacz@interlinknetworks.com Interlink Networks, Inc. http://www.interlinknetworks.com [Tel] 734-821-1230 [Fax] 734-821-1235 From owner-aaa-bof@merit.edu Fri Jan 5 16:34:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA23957 for ; Fri, 5 Jan 2001 16:34:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E5735DE9D; Fri, 5 Jan 2001 16:33:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 999CF5DEF6; Fri, 5 Jan 2001 16:33:42 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 214BE5DE9D for ; Fri, 5 Jan 2001 16:33:41 -0500 (EST) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id VAA00804; Fri, 5 Jan 2001 21:34:57 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 05 Jan 2001 21:33:35 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 13:33:33 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39C80@FMSMSX34> From: "Durham, David" To: "'Erik Guttman'" , Juergen Schoenwaelder Cc: aaa-wg@merit.edu Subject: RE: Choice of Data Model SMI vs XML vs. UML Date: Fri, 5 Jan 2001 13:33:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] > > > We unfortunately did not have any time during the last WG meeting to > > actually debate what is "adequate". > > That is indeed the crux of the issue. Let's pin down what we > are trying > to do. [Dave] Seems to me that XML DTDs are lacking several important features from the AAA perspective: 1. XML DTDs do not have the ability to reuse data definitions in other contexts. 2. XML DTDs do not support inheritance. 3. XML has overly complicated pointer mechanisms that are highly document (& XML) centric (ala. XPointers). 4. XML does not have a consistent mechanism for instance naming. 5. XML is not protocol independent, unless your protocol is just used to transport documents. 6. XML has an inconsistent list of competing standards from SOAP to XMLData, DTDs to XMLSchema. 7. XML doesn't have mechanisms for relaying structured binary data (only text or textually encoded/unstructured binary). Finally, XML is really just a fresh white piece of paper on which you can scribble whatever document you like. It is not a modeling language, or even really a data definition language. Rather, it is a textual document markup language, that's the purpose for which it was designed. It could be used to compete with the DIAMETER protocol with AAA documents (XML tags plus values roughly equates to DIAMETER AVPs), but not to model DIAMETER's data constructs or messages in a DIAMETER compatible way. But this discussion really misses the point. The requirements need to state what features the language needs to support and the intended purpose for the language. For example, if the goal is to use data modeling to achieve consistency across IETF protocols, then XML falls far short. If the goal is to define reusable data definitions (because various uses of the AAA protocol typically reuse common data) XML falls short. If the goal is to model NASes and AAA servers, XML fall far short. If the goal is to leverage concepts of good OO design when developing AAA extensions/protocols/services, then XML falls far short. If the goal is to design model or implement interfaces between proxies, AAA servers, NASes, etc. XML falls short. I realize that when what you have is a hammer, everything else looks like a nail. But as engineers we must get past that a pick the right tool for the job. Step one, figure out exactly what the "job" is. From owner-aaa-bof@merit.edu Fri Jan 5 16:43:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24103 for ; Fri, 5 Jan 2001 16:43:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64FDC5DF18; Fri, 5 Jan 2001 16:42:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 43BEB5DF16; Fri, 5 Jan 2001 16:42:04 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A6EF95DF0A for ; Fri, 5 Jan 2001 16:41:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15846; Fri, 5 Jan 2001 13:41:53 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23796; Fri, 5 Jan 2001 13:41:53 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA15331; Fri, 5 Jan 2001 13:41:51 -0800 (PST) Date: Fri, 5 Jan 2001 13:38:20 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: Choice of Data Model SMI vs XML vs. UML To: "Durham, David" Cc: "'Erik Guttman'" , Juergen Schoenwaelder , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <10C8636AE359D4119118009027AE998704F39C80@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I realize that when what you have is a hammer, everything else looks like a > nail. But as engineers we must get past that a pick the right tool for the > job. Step one, figure out exactly what the "job" is. > ok, here is what I want to do: I want to have a standardized dictionary format, and I want the message in the DIAMETER specs to be prettier and parsable in some way by applications. That's all I want. PatC From owner-aaa-bof@merit.edu Fri Jan 5 16:51:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24163 for ; Fri, 5 Jan 2001 16:51:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B42C5DF06; Fri, 5 Jan 2001 16:49:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 398B45DEE4; Fri, 5 Jan 2001 16:49:40 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 262DA5DED1 for ; Fri, 5 Jan 2001 16:49:39 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Eeju-000LZW-00; Fri, 05 Jan 2001 13:49:34 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pat Calhoun Cc: "Durham, David" , "'Erik Guttman'" , Juergen Schoenwaelder , aaa-wg@merit.edu Subject: RE: Choice of Data Model SMI vs XML vs. UML References: <10C8636AE359D4119118009027AE998704F39C80@FMSMSX34> Message-Id: Date: Fri, 05 Jan 2001 13:49:34 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk > I want to have a standardized dictionary format, and I want the message > in the DIAMETER specs to be prettier and parsable in some way by > applications. ok. seems reasonable. so, some questions about the grammar. o is ordering important? o is definition of allowable subsets important? randy From owner-aaa-bof@merit.edu Fri Jan 5 16:53:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24234 for ; Fri, 5 Jan 2001 16:53:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27FD45DF0B; Fri, 5 Jan 2001 16:50:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 14F2F5DEE4; Fri, 5 Jan 2001 16:50:02 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id BB85F5DF0B for ; Fri, 5 Jan 2001 16:50:00 -0500 (EST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id VAA08589; Fri, 5 Jan 2001 21:51:19 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 05 Jan 2001 21:49:57 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 13:49:55 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39C81@FMSMSX34> From: "Durham, David" To: "'Pat Calhoun'" Cc: "'Erik Guttman'" , Juergen Schoenwaelder , aaa-wg@merit.edu Subject: RE: Choice of Data Model SMI vs XML vs. UML Date: Fri, 5 Jan 2001 13:49:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] > > > I realize that when what you have is a hammer, everything > else looks like a > > nail. But as engineers we must get past that a pick the > right tool for the > > job. Step one, figure out exactly what the "job" is. > > > ok, here is what I want to do: > > I want to have a standardized dictionary format, and I want > the message in the > DIAMETER specs to be prettier and parsable in some way by > applications. > > That's all I want. > > PatC > [Dave] Well, seems like that is what Juergen did with the DIAMETER mapping document for SMIng. The data definition is protocol independent, and the mapping tells you how it would look in a DIAMETER message. You can also achieve something similar with UML in terms of graphically representing the data , minus the explicit mapping. David S. et. al. did a model in UML for RADIUS, which goes to the next level and actually attempts to organize (model?) RADIUS data. The XML approach would allow people to use XML and maybe HTTP or BEEP to transport AAA data as XML documents, but wouldn't do much for to help DIAMETER. From owner-aaa-bof@merit.edu Fri Jan 5 17:57:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA24999 for ; Fri, 5 Jan 2001 17:57:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0CF495DEB3; Fri, 5 Jan 2001 17:56:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DCA945DEC8; Fri, 5 Jan 2001 17:56:46 -0500 (EST) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by segue.merit.edu (Postfix) with ESMTP id 7392C5DEB3 for ; Fri, 5 Jan 2001 17:56:41 -0500 (EST) Received: from matt.ipverse.com (lsanca1-ar5-208-222.dsl.gtei.net [4.33.208.222]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZV8K815A; Fri, 5 Jan 2001 14:56:41 -0800 Message-Id: <5.0.2.1.2.20010105143923.01e9bec0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 05 Jan 2001 14:56:29 -0800 To: "Durham, David" , "'Erik Guttman'" , Juergen Schoenwaelder From: Matt Holdrege Subject: RE: Choice of Data Model SMI vs XML vs. UML Cc: aaa-wg@merit.edu In-Reply-To: <10C8636AE359D4119118009027AE998704F39C80@FMSMSX34> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 01:33 PM 1/5/2001, Durham, David wrote: >Dave] Seems to me that XML DTDs are lacking several important features from >the AAA perspective: I'll try to address this, but please correct me if I'm wrong. >1. XML DTDs do not have the ability to reuse data definitions in other >contexts. Cut & paste. If your definition is good, it can certainly be reused. >2. XML DTDs do not support inheritance. Again, cut & paste. Or are you talking about something else? >3. XML has overly complicated pointer mechanisms that are highly document (& >XML) centric (ala. XPointers). This is a flexibility feature. >4. XML does not have a consistent mechanism for instance naming. It is left up to the user which makes XML more flexible. >5. XML is not protocol independent, unless your protocol is just used to >transport documents. Not sure what you mean here. Can you expand? >6. XML has an inconsistent list of competing standards from SOAP to XMLData, >DTDs to XMLSchema. The X stands for Extensible which people use to make XML work in their specific environment. This is regarded as a feature. >7. XML doesn't have mechanisms for relaying structured binary data (only >text or textually encoded/unstructured binary). Not sure if this is the case, I think XML can kick off a transfer of any type of data. Anyone else? Note that I agree with the ideas put forth in SMING, but I'm concerned about the timing of deliverables and even more concerned that after going through the "design-by-committee" phase that it will be too cumbersome and lack the flexibility that we need. Hopefully that won't be the case. From owner-aaa-bof@merit.edu Fri Jan 5 18:57:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA25605 for ; Fri, 5 Jan 2001 18:57:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA3F05DE49; Fri, 5 Jan 2001 18:56:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 995F45DE34; Fri, 5 Jan 2001 18:56:47 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 4429C5DE26 for ; Fri, 5 Jan 2001 18:56:46 -0500 (EST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id XAA06450; Fri, 5 Jan 2001 23:58:02 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 05 Jan 2001 23:56:40 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 15:56:38 -0800 Message-ID: <10C8636AE359D4119118009027AE998704F39C87@FMSMSX34> From: "Durham, David" To: "'Matt Holdrege'" , "'Erik Guttman'" , Juergen Schoenwaelder Cc: aaa-wg@merit.edu Subject: RE: Choice of Data Model SMI vs XML vs. UML Date: Fri, 5 Jan 2001 15:56:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > -----Original Message----- > From: Matt Holdrege [mailto:matt@ipverse.com] > > > >1. XML DTDs do not have the ability to reuse data > definitions in other > >contexts. > > Cut & paste. If your definition is good, it can certainly be reused. > [Dave] Cut & Paste is not a good mechanism for reuse. Once there is a copy, the copies will change and diverge, and not bear any resemblance to one another. Also common code can not be developed to interpret them because there is no single version of the definition with a unique name that can be used and referred to. Anyway, as a programmer, I should be disgusted at the very concept of Cut&Paste as the "solution" for reuse. > >2. XML DTDs do not support inheritance. > > Again, cut & paste. Or are you talking about something else? > [Dave] Cut and paste misses the point here. Inheritance is the idea of generalization of concepts and the organization of your data definitions. It then allows for the specialization of these general concepts into more specific forms. Interoperability is best achieved because the core/common concepts (attributes, constructs, data, whatever) can be abstracted away from its many specializations. > >3. XML has overly complicated pointer mechanisms that are > highly document (& > >XML) centric (ala. XPointers). > > This is a flexibility feature. > [Dave] Flexibility to the point of over-generality equals complexity. > >4. XML does not have a consistent mechanism for instance naming. > > It is left up to the user which makes XML more flexible. [Dave] Flexible equals non-standard. If its non-standard, then we are back to the point of why would AAA adopt something that is not already a standard? Let the user do whatever they want is not a standard. > > >5. XML is not protocol independent, unless your protocol is > just used to > >transport documents. > > Not sure what you mean here. Can you expand? > [Dave] XML looks like this: Dave grumpy This is what XML does. It provides structure to text documents. It does not define binary DIAMETER AVPs. A DIAMETER AVP may be able to carry the above text document, but to what end? You might as well use HTTP or BEEP over which XML is generally communicated. > >6. XML has an inconsistent list of competing standards from > SOAP to XMLData, > >DTDs to XMLSchema. > > The X stands for Extensible which people use to make XML work > in their > specific environment. This is regarded as a feature. [Dave] If non-standard or a set of warring standards is a feature, then fine. But I would call a spade a spade and say that XML is continuously a work in progress. I believe there was issue with sming because it isn't RFCed yet. My point is XML is no different from this perspective. If you want RFC, then better consider SMIv2 or SPPI. > > >7. XML doesn't have mechanisms for relaying structured > binary data (only > >text or textually encoded/unstructured binary). > > Not sure if this is the case, I think XML can kick off a > transfer of any > type of data. Anyone else? > [Dave] XML described structured binary data? That's ASN.1 or maybe IDL. > Note that I agree with the ideas put forth in SMING, but I'm > concerned > about the timing of deliverables and even more concerned that > after going > through the "design-by-committee" phase that it will be too > cumbersome and > lack the flexibility that we need. Hopefully that won't be the case. [Dave] Well, XML has the biggest committee of all trying to design it, right as we speak:-) It might be better to consider something with a little more focus, and is the right tool for the job. > > From owner-aaa-bof@merit.edu Fri Jan 5 22:08:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA27694 for ; Fri, 5 Jan 2001 22:08:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22F0A5DDA4; Fri, 5 Jan 2001 22:07:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0A81A5DE0B; Fri, 5 Jan 2001 22:07:57 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 5364E5DDA4 for ; Fri, 5 Jan 2001 22:07:55 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0635CC30414 for ; Fri, 5 Jan 2001 19:05:12 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: Re-direct versus proxies Date: Fri, 5 Jan 2001 19:08:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk I would like to drill down further into Stuart's position, which is that hop-by-hop security will suffice. For example, in a world with re-directs and IPSEC with non-null transform, we can perhaps dispense with e2e as well as "password hiding". However, let us consider the deployment implications of this. In my position as "advisor" to our internal IT staff, I am not sure that I could convince them to buy into a re-direct design. For example, they'd need to configure the firewall to accept incoming AAA packets from any of the service provider's NASen, not just from their proxy. With roaming (which we support), this would imply accepting incoming AAA from all NASen at any roaming consortium service provider -- at that point you might as well open the AAA ports to all comers. I doubt that I could get this past the corporate security team. So in practice, it's not clear to me that re-directs are very deployable. In terms of exposure, we will not implement tunnel passwords (we use IPSEC instead), we have a policy against accepting PAP authentication from proxies, and without e2e will probably try to avoid AAA MIP keys if at all possible so that we can lower our risk profile with respect to proxy compromise. Still, a user *can* misconfigure their client and negotiate PAP, and if a relatively simple and light weight e2e solution were available, we'd probably deploy a DIAMETER server. However, if it dramatically increased protocol complexity or had high performance impact, then we would probably rather live without it, stick with RADIUS, and maybe opt for requesting our service providers to turn off PAP. I'd also note that we have had problems with proxies mangling attributes in ways that cost us real money. Again, if e2e could remedy this kind of situation without a mammoth increase in complexity or decrease in performance, we'd probably deploy it. Of course, for this to be any use to us, our service provider would have to agree to it. If I sat in their shoes, I would be wary about e2e. Most existing NASen do not have loads of spare CPU power, and deploying e2e encrypting a significant fraction of packets with 3DES would have some dramatic impacts on performance unless a hardware accelerator card were added. That would probably require a forklift upgrade of all NASen since slots might not be available in existing boxes, and a CPU upgrade might be required. About the best we could get in the near term is a DIAMETER proxy which wouldn't really address any of our secret theft or proxy mangling concerns. All of this leads me to the conclusion that to be successful, e2e has to be *very* simple, have minimal performance impact, and be very compatible with service provider deployment practice. From owner-aaa-bof@merit.edu Sat Jan 6 13:28:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06945 for ; Sat, 6 Jan 2001 13:28:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 122025DDFB; Sat, 6 Jan 2001 13:28:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC8145DE01; Sat, 6 Jan 2001 13:28:04 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id CFCA95DDFB for ; Sat, 6 Jan 2001 13:28:03 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQjwvh28118 for ; Sat, 6 Jan 2001 18:28:03 GMT Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQjwvh25794 for ; Sat, 6 Jan 2001 13:28:03 -0500 (EST) Date: Sat, 6 Jan 2001 13:28:03 -0500 (EST) From: Stuart A Barkley To: aaa-wg@merit.edu Subject: Re: Re-direct versus proxies In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Fri, 5 Jan 2001, Bernard Aboba wrote: > For example, in a world with re-directs and IPSEC with non-null > transform, we can perhaps dispense with e2e as well as "password > hiding". > > However, let us consider the deployment implications of this. > > In my position as "advisor" to our internal IT staff, I am not > sure that I could convince them to buy into a re-direct design. > For example, they'd need to configure the firewall to accept > incoming AAA packets from any of the service provider's NASen, not > just from their proxy. With roaming (which we support), this would > imply accepting incoming AAA from all NASen at any roaming > consortium service provider -- at that point you might as well > open the AAA ports to all comers. I doubt that I could get this > past the corporate security team. My argument to allow the firewall traversal would be along the lines that it is a very specific destination inside the firewall which will be strongly managed to perform the desired function. Another way to look at it is that the destination itself becomes part of the firewall infrastructure. Its almost like an application gateway running in the firewall and the application should get the same treatment as other components of the firewall. I might not succeed in getting this past our firewall maintainers either, but it's not inherently a bad position. There are similar arguments (and potential negative response) for sctp, snmp or even ftp based elements. Those can also be designed so they only serve the desired information to the desired people. snmp through a firewall would be perfectly acceptable if it was to a specific interior point which implemented the appropriate access controls. You won't open up any of these fully through the firewall, but only to specific hosts and ports. Another approach we often use is that these services are part of the network infrastructure and thus are outside the corporate firewall. These servers will then have the necessary access to systems inside the firewall. These exterior servers may need extra hardening including mini firewalls in front of them, but that becomes part of the deployment procedure. In fact, servers I run inside our corporate firewall tend to have almost as much protection as one I would put out on the raw internet. My comments above are a little off of Bernard's point. Even a safe technical solution can run into problems with bureaucracy (and sometimes the bureaucracy is right). I'm not sure how much we need to worry about these issues in our protocol design although it deserves non-zero attention. As an service provider, I also am not in favor of redirects inside our structure. We use proxies to centralize and offload work from the NASes and doing redirects would just put a lot of that work back into the NAS (policy enforcement, logging, secret keying, etc). As a SP I could see our proxies accepting redirects from a broker should the broker so desire. However, while trying to think like a broker (probably not very successfully) I would think the broker wouldn't really want to use redirects either. My other concern with redirects is the extra level of complications it adds to the protocol and I would rather not do unnecessary complex work. > So in practice, it's not clear to me that re-directs are very > deployable. In terms of exposure, we will not implement tunnel > passwords (we use IPSEC instead), we have a policy against > accepting PAP authentication from proxies, and without e2e will > probably try to avoid AAA MIP keys if at all possible so that we > can lower our risk profile with respect to proxy compromise. > Still, a user *can* misconfigure their client and negotiate PAP, > and if a relatively simple and light weight e2e solution were > available, we'd probably deploy a DIAMETER server. However, if it > dramatically increased protocol complexity or had high performance > impact, then we would probably rather live without it, stick with > RADIUS, and maybe opt for requesting our service providers to turn > off PAP. We are back to the data elements which might need nas-to-home-AAA encryption. - PAP which is generally considered very bad and most people seem to agree should not be used. However, PAP is still somewhat useful for one time passwords (although those are even subject to being intercepted and redirected for other improper use) so many people are not willing to eliminate PAP entirely. You are then also subject to configuration errors where PAP is attempted before the home server can tell the client to not attempt PAP. This exposes the password even though the access gets rejected by policy. - Tunnel passwords: We have always been very wary of having tunnel passwords sent to our NASes. We would much rather see any tunneling done at the client instead of in the NAS. This is particularly true when the tunneling involves encryption of the data stream. As a result I have not studied this problem very thoroughly up to this point. - MIP keys (Mobile IP keys): I have done even less reading and thinking about mobile IP, but at this level I think the same comments as for tunnel passwords would apply. Another thought about tunnel passwords and mip keys: How does the work for exchanging keys between NAS and HOME-AAA compare with the work for exchanging keys between tunnel end points? It seems that these are essentially the same problem and so perhaps the solution falls back to the tunnel implementation. The only advantage to putting it into the AAA structure would be to leverage the AAA chain of trust. But if this entails adding significant change to the AAA chain of trust model (e.g. from simple preconfigured hop to hop encryption) to an elaborate certificate distribution model then we should maybe just push for the tunnel implementations to support certificate distribution models on their own. Are their other data elements people think need ede-to-end protection (encryption or just authentication)? > I'd also note that we have had problems with proxies mangling > attributes in ways that cost us real money. Again, if e2e could > remedy this kind of situation without a mammoth increase in > complexity or decrease in performance, we'd probably deploy it. I think you have mentioned this before. I'm trying to think about how such a thing could occur. About the only thing that I can think of is that your own proxy did the mangling. Wouldn't you have recourse against a business partner should their proxy (or one of their down stream proxies) have done the incorrect mangling. I could also see some potential revenue loss should something allow access which should have been denied. However, there is almost nothing anyone can do should a NAS allow access without a proper authorization (including a NAS which is open and never checks authorization). > Of course, for this to be any use to us, our service provider > would have to agree to it. If I sat in their shoes, I would be > wary about e2e. Most existing NASen do not have loads of spare CPU > power, and deploying e2e encrypting a significant fraction of > packets with 3DES would have some dramatic impacts on performance > unless a hardware accelerator card were added. That would probably > require a forklift upgrade of all NASen since slots might not be > available in existing boxes, and a CPU upgrade might be required. AES is a substantially less cpu intensive algorithm versus 3DES. AES is now going through the last formalizations for making it a full US Government Standard. The specific timings of AAA protocol completion and AES specification freezing might be important to look at. I believe the AES specification is essentially frozen, but until the actual formal publication occurs there is a slight possibility of a last minute change. > About the best we could get in the near term is a DIAMETER proxy > which wouldn't really address any of our secret theft or proxy > mangling concerns. > > All of this leads me to the conclusion that to be successful, e2e > has to be *very* simple, have minimal performance impact, and be > very compatible with service provider deployment practice. When end-to-end is discussed it is still unclear to me how we formally define the end points. For example, we might prefer to implement multiple country wide virtual NASes. These would essentially be our proxy servers, but there would be no formal indication that they were acting as protocol gateways. Is it incorrect for these gateways to decrypt the endpoint secret and then reencrypt it again to communicate to the physical NAS? At the other end of the scale, some of the NAS equipment we are seeing is becoming much more complicated than a single cpu box with rs-232 lines connected to modems. Many of these boxes have multiple independent processors in them. Some even have individual processors for each incoming DS0 which handles the ppp interaction. Should the end point be that specific processor or is the end point a AAA module running on a central processor in the box. -- Stuart A Barkley email: stuartb@uu.net UUNET WorldCom phone: +1 703 886 5645 I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone From owner-aaa-bof@merit.edu Sat Jan 6 14:18:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA07414 for ; Sat, 6 Jan 2001 14:18:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 32D605DE12; Sat, 6 Jan 2001 14:16:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 218C05DE0F; Sat, 6 Jan 2001 14:16:08 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id A11DC5DE0D for ; Sat, 6 Jan 2001 14:16:06 -0500 (EST) Received: (qmail 2822 invoked by uid 500); 6 Jan 2001 19:16:09 -0000 Date: Sat, 6 Jan 2001 13:16:09 -0600 From: David Frascone To: Mark Eklund Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) Message-ID: <20010106131609.A2508@newman.frascone.com> Mail-Followup-To: Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Fri, Jan 05, 2001 at 02:46:57PM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk The diameter Encrypted Payload packet can be used to encrypt ANY data. So, it was never meant to be RADIUS compatable. There probably needs to be a blurb in the spec about the User-Password and CHAP-Password being encrypted as described in RFC 2865. But, the Diameter Encrypted Payload is something completely different. On Fri, Jan 05, 2001 at 02:46:57PM -0500, Mark Eklund wrote: > Hi, > > I was reading draft-calhoun-diameter-17.txt and noticed that > it says that for MD5 Encrypted-Payload the first 16 octets hash > is formed from the nonce followed by the shared > secret. Shouldn't this be the shared secret followed by the > nonce to be compatible with RADIUS RFC-2865? > > draft-calhoun-diameter-17.txt says that MD5 Encrypted-Payload should be > encrypted as > > One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 > hash is performed on the: > > - last Nonce AVP which precedes the Encrypted-Payload AVP > - the shared authentication secret > > This MD5 hash value is then XORed with the first 16 octet segment of > the buffer to encrypt. The resulting 16 octet result is saved as the > first 16 octets of the encrypted buffer. The result is also used to > calculate a new value using MD5: > > - the shared authentication secret > - the 16 byte result of the previous XOR > > While RFC2865 says it should be > > Call the shared secret S and the pseudo-random 128-bit Request > Authenticator RA. Break the password into 16-octet chunks p1, p2, > etc. with the last one padded at the end with nulls to a 16-octet > boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need > intermediate values b1, b2, etc. > > b1 = MD5(S + RA) c(1) = p1 xor b1 > b2 = MD5(S + c(1)) c(2) = p2 xor b2 > . . > . . > . . > bi = MD5(S + c(i-1)) c(i) = pi xor bi > > The String will contain c(1)+c(2)+...+c(i) where + denotes > concatenation. > > Thanks, > -mark > From owner-aaa-bof@merit.edu Sun Jan 7 16:07:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA22312 for ; Sun, 7 Jan 2001 16:07:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 938F75DD9F; Sun, 7 Jan 2001 16:07:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 770935DDC3; Sun, 7 Jan 2001 16:07:00 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 655FC5DD9F for ; Sun, 7 Jan 2001 16:06:58 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f07L42C08972; Sun, 7 Jan 2001 13:04:02 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Cc: "Stuart A Barkley" Subject: Re: Re-direct vs. proxies Date: Sun, 7 Jan 2001 13:07:08 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >We use proxies to centralize and offload work from the >NASes and doing redirects would just put a lot of that work back into >the NAS (policy enforcement, logging, secret keying, etc)." Yup. Proxies provide many services, including centralization of security functions. As described below, replacing them with re-directs opens a can of worms in large networks. >My argument to allow the firewall traversal would be along the lines >that it is a very specific destination inside the firewall which will >be strongly managed to perform the desired function. Another way to >look at it is that the destination itself becomes part of the firewall >infrastructure. Its almost like an application gateway running in the >firewall and the application should get the same treatment as other >components of the firewall. I might not succeed in getting this past >our firewall maintainers either, but it's not inherently a bad >position." I think I could probably buy this if we were talking about AAA application layer shared secret security from a limited NAS/proxy pool. You'd open a hole in the firewall *only* for AAA, and you'd check the authenticator. If it's not from a known NAS/proxy, you drop the packet. However, if the traffic is protected by IPSEC things become more complex. You'd have to poke a firewall hole for IKE and IPSEC traffic from any destination -- and since this traffic is terminating on the AAA server, not the firewall, that means that the protocol-specific filtering would have to be done on the AAA server. That alone will make Security uncomfortable. But it gets worse. How exactly do you authenticate the IPSEC traffic? You could use IKE Shared Secrets -- this works ok for a limited number of NASen/proxies, as with app layer shared secrets. However, this doesn't scale. If you used certs, then you'd be asking IPSEC to do something it really wasn't made to do -- application layer authorization. You'd need to specify the acceptable root CAs for MM. Typically this would encode the business relationships -- for example you would accept CAs with a chain of trust terminating in one of the roaming consortium providers with whom you've signed a contract. However, there's a BIG gotcha. The IKE MM certificate policy will apply to *all* IPSEC traffic, not just AAA. This is cumbersome to say the least -- want to use Telnet over IPSEC to maintain the AAA server? Your host will need a certificate signed by your favorite Roaming Consortium provider! >then we should maybe just push for the tunnel implementations >to support certificate distribution models on their own. I've always favored this model, which is why we don't implement tunnel passwords. My understanding is that MIPv6 supports this model as well. >Are their other data elements people think need ede-to-end protection >(encryption or just authentication)? Maybe CHAP-Password and CHAP-Challenge to prevent replay? >I think you have mentioned this before. I'm trying to think about how >such a thing could occur. About the only thing that I can think of is >that your own proxy did the mangling. Think about older proxies that don't implement RFC 2869, and therefore might throw away Tunnel attributes. One thing we probably ought to do in the DIAMETER spec is rigidly define how proxies should handle non-mandatory but not understood attributes. I'd like to see it be mandated that those attributes be passed on unmodified. Today some proxies throw them away without even an error message. I'd like to see NASen/proxies provide error messages (a NAK message) to indicate a problem, rather than just silent discard. >Wouldn't you have recourse against a business partner I'd rather have a protocol that provides a clear indication of what service is being provided by the NAS, rather than relying on the court system ;) >Is it incorrect for these gateways to decrypt the endpoint >secret and then reencrypt it again to communicate to the physical NAS? It's not incorrect, but it does raise questions about trust. As long as AAA protocols pass around passwords and keys then it may be desirable to keep these materials off of more easily subvertable hosts. If as you say, you are not interested in supporting tunnel passwords or MIP keys and have customers who no longer use PAP, then this issue may not apply to you. >At the other end of the scale, some of the NAS equipment we are seeing >is becoming much more complicated With the advent of more economical ciphers such as AES, this seems to auger well for the feasibility of e2e, assuming that the other issues can be ironed out. From owner-aaa-bof@merit.edu Sun Jan 7 16:49:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA22711 for ; Sun, 7 Jan 2001 16:49:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3A675DDB3; Sun, 7 Jan 2001 16:46:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E03255DDCC; Sun, 7 Jan 2001 16:46:45 -0500 (EST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by segue.merit.edu (Postfix) with ESMTP id 504CF5DDB3 for ; Sun, 7 Jan 2001 16:46:44 -0500 (EST) Received: from jariws1 (ab16d3hel.dial.kolumbus.fi [212.54.18.16]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id XAA21710; Sun, 7 Jan 2001 23:46:41 +0200 (EET) Message-ID: <002101c078f3$54d67220$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Stuart A Barkley" , References: Subject: Re: DISCUSSION REQUESTED: ADIF, Batching, M bit Date: Sun, 7 Jan 2001 23:46:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Stuart writes: > It is very important that the SAME data be contained in the two modes > of operation. One of the biggest problems we have in our current > implementation is that we cannot actually use the radius accounting > data since it is inconsistent with the batch data we gather and use > for our primary accounting. This is one of the issues in removing ADIF. I mean I think we've got consensus on removing batch, but if we remove ADIF we need to make sure we *can* still batch. One issue is that if we don't define a format suitable for files as well, then we end up in a situation that DIAMETER Record -> Some File Format mapping won't be uniquely defined, and different vendors might get it in a different way, not to mention the likelihood that they'll get file different formats in the first place. Also, the issue is not only batching, but it also storage and various post processing systems, if we standardize on them then we'll be much better off than in the RADIUS times. In conclusion I'm saying that I'm quite OK for removing ADIF as well, but we just need to be aware of the things that go with it. Secondly, if we go from ADIF-Record to simply containing the DIAMETER attributes in the Accounting-Request commands: it's fine but let's just make sure we'll still keep the Grouped-AVP in there in order to make sure that if we later extend the protocol with batch, we still can do it and have the different records under different Grouped-AVP. Thirdly, I wonder if we select XML as the data description language, is there any benefit in shipping the accounting records also in XML? Jari ---- www.arkko.com From owner-aaa-bof@merit.edu Mon Jan 8 02:54:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA00765 for ; Mon, 8 Jan 2001 02:54:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id B393B5DD9D; Mon, 8 Jan 2001 02:54:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E8545DDCE; Mon, 8 Jan 2001 02:54:38 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 80DE25DD9D for ; Mon, 8 Jan 2001 02:54:37 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00691 for ; Sun, 7 Jan 2001 23:54:35 -0800 (PST) Received: from vayne (muc-isdn-13 [129.157.164.113]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id IAA09583; Mon, 8 Jan 2001 08:54:33 +0100 (MET) Date: Mon, 8 Jan 2001 09:05:00 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: Choice of Data Model SMI vs XML vs. UML To: aaa-wg@merit.edu Cc: "'Erik Guttman'" In-Reply-To: "Your message with ID" <10C8636AE359D4119118009027AE998704F39C87@FMSMSX34> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I want to get a list of requirements that we can begin to debate. We agree draft-ietf-aaa-issues-04.txt identifies four goals - as I haven't seen any debate on this on the mailing list. a. Express data definitions in formal terms, to make it easier to validate the spec and implementations b. Allow for automating some of the implementation process c. Allow for definitions to be used in debugging d. Allow for ability to add definitions for new extensions Let's identify the various requirements folks believe appropriate for the data definition language, then we can debate. We can start with the requirements from Pat's mail: P1. A standardized dictionary format P2. Prettier message definitions in the DIAMETER specs - parsable in some way by applications. Inverting David's criticism of applying XML to these requirements, I infer he asserts the following are requirements: D1. Reusability of data definitions in other contexts. D2. Inheritance. D3. Restricted/simple data definition mechanisms that are not document-centric. D4. A consistent naming mechanism. D5. Protocol independence for tranmission and interpretation of data description. D6. A single stable standard to cite for the data definition language. D7. A mechanism for describing (arbitrary) binary data. Juergen brought up the following points, too: J1. Ability to formally specify what is an allowed value. J2. Version handling. J3. Ability to introduce new types and reusable components. Randy asked whether these are requirements: R1. Ability to specify ordering as part of DIAMETER grammar R2. Ability to specify allowable subsets in DIAMETER grammar Do I have this right? Anything else? Could we be a lot more specific about points D1, D2, D4, J2 and J3? Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Mon Jan 8 10:09:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06048 for ; Mon, 8 Jan 2001 10:09:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5A5B5DEFF; Mon, 8 Jan 2001 10:07:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AFDCD5DEFE; Mon, 8 Jan 2001 10:07:10 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 107525DEAA for ; Mon, 8 Jan 2001 10:07:09 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24307 for ; Mon, 8 Jan 2001 07:07:08 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11854; Mon, 8 Jan 2001 07:07:07 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA18889; Mon, 8 Jan 2001 07:07:06 -0800 (PST) Date: Mon, 8 Jan 2001 07:03:30 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: Choice of Data Model SMI vs XML vs. UML To: Erik Guttman Cc: 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 > Do I have this right? Anything else? Could we be a lot more specific > about points D1, D2, D4, J2 and J3? I am not against D1 through R2, but I do have the following requirements: P3. Simplicity. When I say simplicity, it means that it must be very simple to read the specs, where each command is defined, without the use of a tool. P4. Compactness. If each command is defined using some new language, and each command takes up 2 pages, then I think that we've eliminated any possible benefits. P5. Time. I don't think that we can realistically rely on any language that will still be work in progress in the next couple of months. As an aside, I find some of the new requirements interesting. Given the relative narrow scope which the data model will be used for, do we *really* need a full OO design? It seems like inheritance defy my simplicity requirement, but I am not a data model person. Again, keep in mind requirements P1 and P2. I am, however, willing to be convinced otherwise, but I am looking for convincing comments and not handwaving. PatC From owner-aaa-bof@merit.edu Mon Jan 8 10:26:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06336 for ; Mon, 8 Jan 2001 10:26:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EAEB5DDF1; Mon, 8 Jan 2001 10:25:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7D57A5DDE7; Mon, 8 Jan 2001 10:25:56 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 284DB5DDD8 for ; Mon, 8 Jan 2001 10:25:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01383; Mon, 8 Jan 2001 07:25:51 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA16829; Mon, 8 Jan 2001 07:25:50 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA19280; Mon, 8 Jan 2001 07:25:49 -0800 (PST) Date: Mon, 8 Jan 2001 07:22:15 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Re-direct versus proxies To: Stuart A Barkley Cc: 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 > As a SP I could see our proxies accepting redirects from a broker > should the broker so desire. However, while trying to think like a > broker (probably not very successfully) I would think the broker > wouldn't really want to use redirects either. I am concerned about this as well. We have been trying to move towards the redirect model., but it isn't clear that brokers would be willing to NOT participate in the transactions. Some brokers do want to receive all messages for auditing purposes. > > My other concern with redirects is the extra level of complications it > adds to the protocol and I would rather not do unnecessary complex > work. It is more work, so I suppose we need to make sure that it is in fact required, and not just a requirement we've imposed due to the complexity of security through proxies. > - Tunnel passwords: We have always been very wary of having tunnel > passwords sent to our NASes. We would much rather see any tunneling > done at the client instead of in the NAS. This is particularly true > when the tunneling involves encryption of the data stream. As a > result I have not studied this problem very thoroughly up to this > point. > > - MIP keys (Mobile IP keys): I have done even less reading and > thinking about mobile IP, but at this level I think the same comments > as for tunnel passwords would apply. This is different from Tunnel Passwords, since the client DOES participate, but the NAS (Foreign Agent) must act as well. There are actually three entities involved in MIP, the mobile, foreign agent (NAS) and home agent (in home net). > > Another thought about tunnel passwords and mip keys: How does the > work for exchanging keys between NAS and HOME-AAA compare with the > work for exchanging keys between tunnel end points? It seems that > these are essentially the same problem and so perhaps the solution > falls back to the tunnel implementation. no, Read above. > The only advantage to > putting it into the AAA structure would be to leverage the AAA chain > of trust. But if this entails adding significant change to the AAA > chain of trust model (e.g. from simple preconfigured hop to hop > encryption) to an elaborate certificate distribution model then we > should maybe just push for the tunnel implementations to support > certificate distribution models on their own. The amount of complexity in doing it within the AAA infrastructure would be much simpler than in all of the mobility devices (the number of mobility devices is MUCH higher than AAA). > > Are their other data elements people think need ede-to-end protection > (encryption or just authentication)? I still think that authentication of accounting data is really important. > I think you have mentioned this before. I'm trying to think about how > such a thing could occur. About the only thing that I can think of is > that your own proxy did the mangling. Wouldn't you have recourse > against a business partner should their proxy (or one of their down > stream proxies) have done the incorrect mangling. I could also see > some potential revenue loss should something allow access which should > have been denied. However, there is almost nothing anyone can do > should a NAS allow access without a proper authorization (including a > NAS which is open and never checks authorization). Who cares? If a NAS is broken, and one can successfully prove that the home said X, but the SP did Y, then Y does not get paid for the services rendered. I *thought*that was the whole point. > > > About the best we could get in the near term is a DIAMETER proxy > > which wouldn't really address any of our secret theft or proxy > > mangling concerns. > > > > All of this leads me to the conclusion that to be successful, e2e > > has to be *very* simple, have minimal performance impact, and be > > very compatible with service provider deployment practice. > > When end-to-end is discussed it is still unclear to me how we formally > define the end points. > > For example, we might prefer to implement multiple country wide > virtual NASes. These would essentially be our proxy servers, but > there would be no formal indication that they were acting as protocol > gateways. Is it incorrect for these gateways to decrypt the endpoint > secret and then reencrypt it again to communicate to the physical NAS? > > At the other end of the scale, some of the NAS equipment we are seeing > is becoming much more complicated than a single cpu box with rs-232 > lines connected to modems. Many of these boxes have multiple > independent processors in them. Some even have individual processors > for each incoming DS0 which handles the ppp interaction. Should the > end point be that specific processor or is the end point a AAA module > running on a central processor in the box. e2e is between the AAA client on the NAS. In the architecture you've provided before, there is typically a single master routing processor that runs the AAA software. The independent CPUs only handle the traffic to/from the interfaces and perform the necessary framing. So I would state that it is between the AAA client on the NAS and the home server. If the end is masqueraded by the SP to be the first hop, then it really doesn't matter. The end result is that the SP has sent an authenticated set of accounting and/or authorization information are useful for: 1. ensuring that no one is breaking things in the middle 2. the service provided can be accountable for services rendered. PatC From owner-aaa-bof@merit.edu Mon Jan 8 10:28:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06353 for ; Mon, 8 Jan 2001 10:28:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 430125DDD8; Mon, 8 Jan 2001 10:28:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2E9EF5DDE5; Mon, 8 Jan 2001 10:28:38 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 9A7255DDD8 for ; Mon, 8 Jan 2001 10:28:36 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA19587; Mon, 8 Jan 2001 10:27:36 -0500 (EST) Date: Mon, 8 Jan 2001 10:27:36 -0500 (EST) From: Mark Eklund To: David Frascone Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) In-Reply-To: <20010106131609.A2508@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Dave, In draft-calhoun-diameter-17.txt 7.1.2.1 MD5 Payload Hiding, it says: MD5 Payload Hiding is supported by DIAMETER for backward compatibility with existing RADIUS infrastructure. User-Password and Tunnel-Password are the only RADIUS specific encryption that I know of. Since the MD5 encryption specification of the User-Password was similar in every way except digest order of the first 16 byte MD5 hash, I thought maybe this was an error while re-wording the RADIUS specification. Unless there is some security reason for changing the order of the digest creation, I would prefer it to be modified to be RADIUS compatible. If it isn't changed, I would bet that many developers would make the mistake of using their RADIUS password encryption code. I am suggesting changing the first two bullets in draft-calhoun-diameter-17.txt 7.1.2.1 MD5 Payload Hiding from - last Nonce AVP which precedes the Encrypted-Payload AVP - the shared authentication secret to - the shared authentication secret - last Nonce AVP which precedes the Encrypted-Payload AVP Thanks, -mark On Sat, 6 Jan 2001, David Frascone wrote: > The diameter Encrypted Payload packet can be used to encrypt ANY data. So, > it was never meant to be RADIUS compatable. There probably needs to be a > blurb in the spec about the User-Password and CHAP-Password being encrypted > as described in RFC 2865. > > But, the Diameter Encrypted Payload is something completely different. > > > On Fri, Jan 05, 2001 at 02:46:57PM -0500, Mark Eklund wrote: > > Hi, > > > > I was reading draft-calhoun-diameter-17.txt and noticed that > > it says that for MD5 Encrypted-Payload the first 16 octets hash > > is formed from the nonce followed by the shared > > secret. Shouldn't this be the shared secret followed by the > > nonce to be compatible with RADIUS RFC-2865? > > > > draft-calhoun-diameter-17.txt says that MD5 Encrypted-Payload should be > > encrypted as > > > > One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 > > hash is performed on the: > > > > - last Nonce AVP which precedes the Encrypted-Payload AVP > > - the shared authentication secret > > > > This MD5 hash value is then XORed with the first 16 octet segment of > > the buffer to encrypt. The resulting 16 octet result is saved as the > > first 16 octets of the encrypted buffer. The result is also used to > > calculate a new value using MD5: > > > > - the shared authentication secret > > - the 16 byte result of the previous XOR > > > > While RFC2865 says it should be > > > > Call the shared secret S and the pseudo-random 128-bit Request > > Authenticator RA. Break the password into 16-octet chunks p1, p2, > > etc. with the last one padded at the end with nulls to a 16-octet > > boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need > > intermediate values b1, b2, etc. > > > > b1 = MD5(S + RA) c(1) = p1 xor b1 > > b2 = MD5(S + c(1)) c(2) = p2 xor b2 > > . . > > . . > > . . > > bi = MD5(S + c(i-1)) c(i) = pi xor bi > > > > The String will contain c(1)+c(2)+...+c(i) where + denotes > > concatenation. > > > > Thanks, > > -mark > > > From owner-aaa-bof@merit.edu Mon Jan 8 10:50:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06606 for ; Mon, 8 Jan 2001 10:50:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94CD35DEDD; Mon, 8 Jan 2001 10:44:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 675C45E033; Mon, 8 Jan 2001 10:44:34 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 2A1D65DEC2 for ; Mon, 8 Jan 2001 10:36:27 -0500 (EST) Received: (qmail 16827 invoked by uid 500); 8 Jan 2001 15:37:03 -0000 Date: Mon, 8 Jan 2001 09:37:02 -0600 From: David Frascone To: Mark Eklund Cc: David Frascone , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) Message-ID: <20010108093702.B16595@newman.frascone.com> Mail-Followup-To: Mark Eklund , David Frascone , diameter@diameter.org, aaa-wg@merit.edu References: <20010106131609.A2508@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Mon, Jan 08, 2001 at 10:27:36AM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Hmm, sounds like a much easier change that the paragraphs I was proposing. I don't have any problem making the change in the code, but, I still think the text is misleading. Since the entire AVP(s) is/are encrypted, the actual data is *not* backward compatable with RADIUS. Being backward compatable would require the blurb I mentioned. So, should we change the current encryption? I think having it different would lessen the confusion, since it's definately not RADIUS compatable. But, we still need to handle radius encryption in the password RADIUS AVPs. Does anyone else have an opinion? -Dave > I am suggesting changing the first two bullets in > draft-calhoun-diameter-17.txt 7.1.2.1 MD5 Payload Hiding from > - last Nonce AVP which precedes the Encrypted-Payload AVP > - the shared authentication secret > to > - the shared authentication secret > - last Nonce AVP which precedes the Encrypted-Payload AVP > > Thanks, > > -mark > > On Sat, 6 Jan 2001, David Frascone wrote: > > > The diameter Encrypted Payload packet can be used to encrypt ANY data. So, > > it was never meant to be RADIUS compatable. There probably needs to be a > > blurb in the spec about the User-Password and CHAP-Password being encrypted > > as described in RFC 2865. > > > > But, the Diameter Encrypted Payload is something completely different. > > > > > > On Fri, Jan 05, 2001 at 02:46:57PM -0500, Mark Eklund wrote: > > > Hi, > > > > > > I was reading draft-calhoun-diameter-17.txt and noticed that > > > it says that for MD5 Encrypted-Payload the first 16 octets hash > > > is formed from the nonce followed by the shared > > > secret. Shouldn't this be the shared secret followed by the > > > nonce to be compatible with RADIUS RFC-2865? > > > > > > draft-calhoun-diameter-17.txt says that MD5 Encrypted-Payload should be > > > encrypted as > > > > > > One or more Nonce AVPs MUST precede an Encrypted-Payload AVP. An MD5 > > > hash is performed on the: > > > > > > - last Nonce AVP which precedes the Encrypted-Payload AVP > > > - the shared authentication secret > > > > > > This MD5 hash value is then XORed with the first 16 octet segment of > > > the buffer to encrypt. The resulting 16 octet result is saved as the > > > first 16 octets of the encrypted buffer. The result is also used to > > > calculate a new value using MD5: > > > > > > - the shared authentication secret > > > - the 16 byte result of the previous XOR > > > > > > While RFC2865 says it should be > > > > > > Call the shared secret S and the pseudo-random 128-bit Request > > > Authenticator RA. Break the password into 16-octet chunks p1, p2, > > > etc. with the last one padded at the end with nulls to a 16-octet > > > boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need > > > intermediate values b1, b2, etc. > > > > > > b1 = MD5(S + RA) c(1) = p1 xor b1 > > > b2 = MD5(S + c(1)) c(2) = p2 xor b2 > > > . . > > > . . > > > . . > > > bi = MD5(S + c(i-1)) c(i) = pi xor bi > > > > > > The String will contain c(1)+c(2)+...+c(i) where + denotes > > > concatenation. > > > > > > Thanks, > > > -mark > > > > > > > > From owner-aaa-bof@merit.edu Mon Jan 8 12:10:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08039 for ; Mon, 8 Jan 2001 12:10:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68F2A5DE22; Mon, 8 Jan 2001 12:09:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3C4435DE20; Mon, 8 Jan 2001 12:09:53 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id C41ED5DE13 for ; Mon, 8 Jan 2001 12:09:51 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f08H9mn67698; Mon, 8 Jan 2001 12:09:48 -0500 (EST) (envelope-from barney) Date: Mon, 8 Jan 2001 12:09:48 -0500 From: Barney Wolff To: Pat Calhoun Cc: Stuart A Barkley , aaa-wg@merit.edu Subject: Re: Re-direct versus proxies Message-ID: <20010108120948.A67622@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Mon, Jan 08, 2001 at 07:22:15AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk I valued redirect only because it seemed to offer a way to avoid doing public-key operations for NAS-Home_server security. But diameter-17 seems to say that redirects include certificates, so even that benefit has slipped through our fingers. That leaves the value of redirects at zero. Barney On Mon, Jan 08, 2001 at 07:22:15AM -0800, Pat Calhoun wrote: > > It is more work, so I suppose we need to make sure that it is in fact > required, and not just a requirement we've imposed due to the complexity of > security through proxies. From owner-aaa-bof@merit.edu Mon Jan 8 12:11:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08054 for ; Mon, 8 Jan 2001 12:11:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 392E55DE30; Mon, 8 Jan 2001 12:11:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 282F15DE20; Mon, 8 Jan 2001 12:11:18 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A55D75DE13 for ; Mon, 8 Jan 2001 12:11:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22117; Mon, 8 Jan 2001 09:11:13 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16200; Mon, 8 Jan 2001 09:11:12 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA21664; Mon, 8 Jan 2001 09:11:11 -0800 (PST) Date: Mon, 8 Jan 2001 09:07:37 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Re-direct versus proxies To: Barney Wolff Cc: Pat Calhoun , Stuart A Barkley , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010108120948.A67622@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I valued redirect only because it seemed to offer a way to avoid > doing public-key operations for NAS-Home_server security. But > diameter-17 seems to say that redirects include certificates, > so even that benefit has slipped through our fingers. That > leaves the value of redirects at zero. Which is why we have been investigating using a third party end-to-end key distribution mechanism. PatC From owner-aaa-bof@merit.edu Mon Jan 8 12:54:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08697 for ; Mon, 8 Jan 2001 12:54:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D3BE5DEF1; Mon, 8 Jan 2001 12:52:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4553A5DEF0; Mon, 8 Jan 2001 12:52:08 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1E9A05DEED for ; Mon, 8 Jan 2001 12:52:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29372; Mon, 8 Jan 2001 09:52:04 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25609; Mon, 8 Jan 2001 09:52:03 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA22659; Mon, 8 Jan 2001 09:52:02 -0800 (PST) Date: Mon, 8 Jan 2001 09:48:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] Diameter correspondences. (fwd) To: David Frascone Cc: Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010108093702.B16595@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk An opinion? hmmm... I've been known to have one :) So I believe that the issue is not that it doesn't work, but rather that the order is inversed to the way it is done in RADIUS, and this may lead to some confusion for RADIUS implementors. Correct? So, we have a couple of options: 1. leave it as-is (easy) 2. Change the order of the nonce and the shared secret (btw, keep in mind that the nonce is greater than 1 byte. 3. Eliminate the method of RADIUS-like "encryption", and make use of 3DES (or something equivalent such as AES). If any changes are to be done, I would much prefer to see #3 above be used. I believe that a real encryption protocol would be much simpler to get through IESG review than abuse of a hashing algorithm for encryption purposes. Comments? PatC From owner-aaa-bof@merit.edu Mon Jan 8 13:12:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA09029 for ; Mon, 8 Jan 2001 13:12:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DD0B5DF0D; Mon, 8 Jan 2001 13:08:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DDDB25DF48; Mon, 8 Jan 2001 13:08:52 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id D69565DF44 for ; Mon, 8 Jan 2001 13:08:50 -0500 (EST) Received: (qmail 18152 invoked by uid 500); 8 Jan 2001 18:09:28 -0000 Date: Mon, 8 Jan 2001 12:09:24 -0600 From: David Frascone To: Pat Calhoun Cc: David Frascone , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) Message-ID: <20010108120921.D17570@newman.frascone.com> Mail-Followup-To: Pat Calhoun , David Frascone , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu References: <20010108093702.B16595@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Mon, Jan 08, 2001 at 09:48:27AM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk To make sure I understand right: If a legacy RADIUS server sends it's Access-Request to a DIAMETER proxy, the User-Password and Tunnel-Password would be decrypted by the proxy, and then packeged up in an Encrypted Payload packet and re-encrypted with whatever encryption method is used, and sent on. I guess the CHAP-Password *could* also be included in the Encrypted-Payload, but it would be sent as-is. That works for me. On Mon, Jan 08, 2001 at 09:48:27AM -0800, Pat Calhoun wrote: > An opinion? hmmm... I've been known to have one :) > > So I believe that the issue is not that it doesn't work, but rather that the > order is inversed to the way it is done in RADIUS, and this may lead to some > confusion for RADIUS implementors. Correct? > > So, we have a couple of options: > 1. leave it as-is (easy) > 2. Change the order of the nonce and the shared secret (btw, keep in mind that > the nonce is greater than 1 byte. 3. Eliminate the method of RADIUS-like > "encryption", and make use of 3DES (or something equivalent such as AES). > > If any changes are to be done, I would much prefer to see #3 above be used. I > believe that a real encryption protocol would be much simpler to get through > IESG review than abuse of a hashing algorithm for encryption purposes. > > Comments? > > PatC > > From owner-aaa-bof@merit.edu Mon Jan 8 14:54:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA10815 for ; Mon, 8 Jan 2001 14:54:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id B70825DDE0; Mon, 8 Jan 2001 14:53:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A60F95DDD7; Mon, 8 Jan 2001 14:53:57 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 0AD465DDB9 for ; Mon, 8 Jan 2001 14:53:56 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA21765; Mon, 8 Jan 2001 14:52:56 -0500 (EST) Date: Mon, 8 Jan 2001 14:52:56 -0500 (EST) From: Mark Eklund To: Pat Calhoun Cc: David Frascone , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Good summary of options. Comments inline. On Mon, 8 Jan 2001, Pat Calhoun wrote: > An opinion? hmmm... I've been known to have one :) > > So I believe that the issue is not that it doesn't work, but rather that the > order is inversed to the way it is done in RADIUS, and this may lead to some > confusion for RADIUS implementors. Correct? > > So, we have a couple of options: > 1. leave it as-is (easy) Easy for now. I can imagine the headaches when the encryption code gets distributed by some kind sole that implemented it wrong and is used by several other people add it to their implementation. Finally it is discovered that it is wrong. Now everyone has to add flags as to if it is RFC compatible. Also you will have the fun of emails to the DIAMETER mailing list every four or five months asking if it is a miss print in DIAMETER. > 2. Change the order of the nonce and the shared secret (btw, keep in mind that > the nonce is greater than 1 byte. For my reason #1 above, I'd like this. > 3. Eliminate the method of RADIUS-like > "encryption", and make use of 3DES (or something equivalent such as AES). If you change it to this, I have no problem what the wording of the RADIUS-like MD5 encryption is when you remove it :) -mark > > If any changes are to be done, I would much prefer to see #3 above be used. I > believe that a real encryption protocol would be much simpler to get through > IESG review than abuse of a hashing algorithm for encryption purposes. > > Comments? > > PatC > > From owner-aaa-bof@merit.edu Mon Jan 8 15:30:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11655 for ; Mon, 8 Jan 2001 15:30:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F9105DEF4; Mon, 8 Jan 2001 15:17:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C5BA15DFCA; Mon, 8 Jan 2001 15:17:06 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3ACF15DF65 for ; Mon, 8 Jan 2001 15:16:46 -0500 (EST) Received: (qmail 18615 invoked by uid 500); 8 Jan 2001 20:17:25 -0000 Date: Mon, 8 Jan 2001 14:17:24 -0600 From: David Frascone To: Pat Calhoun Cc: Mark Eklund , David Frascone , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) Message-ID: <20010108141724.B18572@newman.frascone.com> Mail-Followup-To: Pat Calhoun , Mark Eklund , David Frascone , diameter@diameter.org, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pat.Calhoun@eng.sun.com on Mon, Jan 08, 2001 at 12:08:26PM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Since there's a transform ID, I'd suggest leaving the current encryption alone (after removing the reference to similarity to RADIUS), and ading other encryption schemes with different transform IDs (like 3DES). I'd like to see lots of transforms, so an app could pick what it wants, based on cpu/security requirements. On Mon, Jan 08, 2001 at 12:08:26PM -0800, Pat Calhoun wrote: > > Just as an aside, I prefer options 2 or 3 (I like 3 by far), but I really > would like to get some more feedback. > > PatC > > > > > On Mon, 8 Jan 2001, Pat Calhoun wrote: > > > > > An opinion? hmmm... I've been known to have one :) > > > > > > So I believe that the issue is not that it doesn't work, but rather that the > > > order is inversed to the way it is done in RADIUS, and this may lead to some > > > confusion for RADIUS implementors. Correct? > > > > > > So, we have a couple of options: > > > 1. leave it as-is (easy) > > > > Easy for now. I can imagine the headaches when the encryption > > code gets distributed by some kind sole that implemented it > > wrong and is used by several other people add it to their > > implementation. Finally it is discovered that it is wrong. Now > > everyone has to add flags as to if it is RFC compatible. > > > > Also you will have the fun of emails to the DIAMETER mailing > > list every four or five months asking if it is a miss print in > > DIAMETER. > > > > > 2. Change the order of the nonce and the shared secret (btw, keep in mind that > > > the nonce is greater than 1 byte. > > > > For my reason #1 above, I'd like this. > > > > > 3. Eliminate the method of RADIUS-like > > > "encryption", and make use of 3DES (or something equivalent such as AES). > > > > If you change it to this, I have no problem what the wording of > > the RADIUS-like MD5 encryption is when you remove it :) > > > > -mark > > > > > > > > If any changes are to be done, I would much prefer to see #3 above be used. I > > > believe that a real encryption protocol would be much simpler to get through > > > IESG review than abuse of a hashing algorithm for encryption purposes. > > > > > > Comments? > > > > > > PatC > > > > > > > > > > From owner-aaa-bof@merit.edu Mon Jan 8 15:33:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11691 for ; Mon, 8 Jan 2001 15:33:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9154D5E01D; Mon, 8 Jan 2001 15:17:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E1065DEE3; Mon, 8 Jan 2001 15:17:15 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id CBC105DEFE for ; Mon, 8 Jan 2001 15:12:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01189; Mon, 8 Jan 2001 12:12:04 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA06820; Mon, 8 Jan 2001 12:12:03 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA27244; Mon, 8 Jan 2001 12:12:01 -0800 (PST) Date: Mon, 8 Jan 2001 12:08:26 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] Diameter correspondences. (fwd) To: Mark Eklund Cc: Pat Calhoun , David Frascone , diameter@diameter.org, 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 Just as an aside, I prefer options 2 or 3 (I like 3 by far), but I really would like to get some more feedback. PatC > > On Mon, 8 Jan 2001, Pat Calhoun wrote: > > > An opinion? hmmm... I've been known to have one :) > > > > So I believe that the issue is not that it doesn't work, but rather that the > > order is inversed to the way it is done in RADIUS, and this may lead to some > > confusion for RADIUS implementors. Correct? > > > > So, we have a couple of options: > > 1. leave it as-is (easy) > > Easy for now. I can imagine the headaches when the encryption > code gets distributed by some kind sole that implemented it > wrong and is used by several other people add it to their > implementation. Finally it is discovered that it is wrong. Now > everyone has to add flags as to if it is RFC compatible. > > Also you will have the fun of emails to the DIAMETER mailing > list every four or five months asking if it is a miss print in > DIAMETER. > > > 2. Change the order of the nonce and the shared secret (btw, keep in mind that > > the nonce is greater than 1 byte. > > For my reason #1 above, I'd like this. > > > 3. Eliminate the method of RADIUS-like > > "encryption", and make use of 3DES (or something equivalent such as AES). > > If you change it to this, I have no problem what the wording of > the RADIUS-like MD5 encryption is when you remove it :) > > -mark > > > > > If any changes are to be done, I would much prefer to see #3 above be used. I > > believe that a real encryption protocol would be much simpler to get through > > IESG review than abuse of a hashing algorithm for encryption purposes. > > > > Comments? > > > > PatC > > > > > From owner-aaa-bof@merit.edu Mon Jan 8 15:36:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11794 for ; Mon, 8 Jan 2001 15:36:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F6265E03D; Mon, 8 Jan 2001 15:32:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8CB395E03C; Mon, 8 Jan 2001 15:32:40 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 69C9E5E036 for ; Mon, 8 Jan 2001 15:32:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26960; Mon, 8 Jan 2001 12:32:36 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12403; Mon, 8 Jan 2001 12:32:31 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA27852; Mon, 8 Jan 2001 12:32:29 -0800 (PST) Date: Mon, 8 Jan 2001 12:28:54 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] Diameter correspondences. (fwd) To: David Frascone Cc: Pat Calhoun , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010108141724.B18572@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Since there's a transform ID, I'd suggest leaving the current encryption > alone (after removing the reference to similarity to RADIUS), and ading > other encryption schemes with different transform IDs (like 3DES). > > I'd like to see lots of transforms, so an app could pick what it wants, > based on cpu/security requirements. no can do. We need to pick one to ensure interoperability. PatC From owner-aaa-bof@merit.edu Mon Jan 8 15:40:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11846 for ; Mon, 8 Jan 2001 15:40:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 612765DDD3; Mon, 8 Jan 2001 15:39:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 48C025DE14; Mon, 8 Jan 2001 15:39:55 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id AFE5A5DDD3 for ; Mon, 8 Jan 2001 15:39:53 -0500 (EST) Received: (qmail 18686 invoked by uid 500); 8 Jan 2001 20:40:34 -0000 Date: Mon, 8 Jan 2001 14:40:33 -0600 From: David Frascone To: Pat Calhoun Cc: David Frascone , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) Message-ID: <20010108144032.C18572@newman.frascone.com> Mail-Followup-To: Pat Calhoun , David Frascone , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu References: <20010108141724.B18572@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pat.Calhoun@eng.sun.com on Mon, Jan 08, 2001 at 12:28:54PM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Well, then, I don't think there's any need for a transform ID :) And, if I had to pick an encryption algorithm now, it would be 3DES. On Mon, Jan 08, 2001 at 12:28:54PM -0800, Pat Calhoun wrote: > > Since there's a transform ID, I'd suggest leaving the current encryption > > alone (after removing the reference to similarity to RADIUS), and ading > > other encryption schemes with different transform IDs (like 3DES). > > > > I'd like to see lots of transforms, so an app could pick what it wants, > > based on cpu/security requirements. > > no can do. We need to pick one to ensure interoperability. > > PatC > > From owner-aaa-bof@merit.edu Mon Jan 8 15:57:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12220 for ; Mon, 8 Jan 2001 15:57:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id CEF135DF14; Mon, 8 Jan 2001 15:53:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A5A2F5DF43; Mon, 8 Jan 2001 15:53:04 -0500 (EST) Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by segue.merit.edu (Postfix) with ESMTP id 866195DDFE for ; Mon, 8 Jan 2001 15:50:18 -0500 (EST) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id PAA24910; Mon, 8 Jan 2001 15:50:03 -0500 (EST) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id ; Mon, 8 Jan 2001 15:48:33 -0500 Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA952D@bigbird.gradient.com> From: Hal Lockhart To: "'David Frascone'" , Pat Calhoun Cc: Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: RE: [diameter] Diameter correspondences. (fwd) Date: Mon, 8 Jan 2001 15:48:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > And, if I had to pick an encryption algorithm now, it would be 3DES. Why not AES? Hal ======================================================= Harold W. Lockhart Entegrity Solutions 2 Mount Royal Avenue Marlborough, MA 01752 USA V: 1-508-624-9600 x 260 hal.lockhart@entegrity.com F: 1-508-229-0338 www.entegrity.com ======================================================= From owner-aaa-bof@merit.edu Mon Jan 8 15:58:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12229 for ; Mon, 8 Jan 2001 15:58:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B2315DF54; Mon, 8 Jan 2001 15:53:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D6BE85DF00; Mon, 8 Jan 2001 15:53:46 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E03545DF54 for ; Mon, 8 Jan 2001 15:53:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03158; Mon, 8 Jan 2001 12:53:18 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA17635; Mon, 8 Jan 2001 12:53:17 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA28542; Mon, 8 Jan 2001 12:53:14 -0800 (PST) Date: Mon, 8 Jan 2001 12:49:36 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] Diameter correspondences. (fwd) To: David Frascone Cc: Pat Calhoun , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010108144032.C18572@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk The general idea is that you want to pick (mandate) one, but allow for new transforms in the future (say someone finds a weakness in 3DES), hence the transform field. PatC > Well, then, I don't think there's any need for a transform ID :) > > And, if I had to pick an encryption algorithm now, it would be 3DES. > > On Mon, Jan 08, 2001 at 12:28:54PM -0800, Pat Calhoun wrote: > > > Since there's a transform ID, I'd suggest leaving the current encryption > > > alone (after removing the reference to similarity to RADIUS), and ading > > > other encryption schemes with different transform IDs (like 3DES). > > > > > > I'd like to see lots of transforms, so an app could pick what it wants, > > > based on cpu/security requirements. > > > > no can do. We need to pick one to ensure interoperability. > > > > PatC > > > > From owner-aaa-bof@merit.edu Mon Jan 8 16:10:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12460 for ; Mon, 8 Jan 2001 16:10:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E7475DE15; Mon, 8 Jan 2001 16:08:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 549C15DDD7; Mon, 8 Jan 2001 16:08:34 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D466E5DDB9 for ; Mon, 8 Jan 2001 16:08:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06378; Mon, 8 Jan 2001 13:08:26 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA02720; Mon, 8 Jan 2001 13:08:25 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA29148; Mon, 8 Jan 2001 13:08:20 -0800 (PST) Date: Mon, 8 Jan 2001 13:04:45 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] Diameter correspondences. (fwd) To: Hal Lockhart Cc: "'David Frascone'" , Pat Calhoun , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <899128A30EEDD1118FC900A0C9C74A34BA952D@bigbird.gradient.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > And, if I had to pick an encryption algorithm now, it would be 3DES. > > Why not AES? > When will NIST offically release AES? PatC From owner-aaa-bof@merit.edu Mon Jan 8 17:28:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14833 for ; Mon, 8 Jan 2001 17:28:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 136B55E01A; Mon, 8 Jan 2001 17:19:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D7CF05E012; Mon, 8 Jan 2001 17:09:32 -0500 (EST) Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by segue.merit.edu (Postfix) with ESMTP id 80DC95DFDB for ; Mon, 8 Jan 2001 16:58:39 -0500 (EST) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id QAA25246; Mon, 8 Jan 2001 16:58:33 -0500 (EST) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id ; Mon, 8 Jan 2001 16:57:03 -0500 Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA952E@bigbird.gradient.com> From: Hal Lockhart To: "'Pat Calhoun'" , Hal Lockhart Cc: "'David Frascone'" , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: RE: [diameter] Diameter correspondences. (fwd) Date: Mon, 8 Jan 2001 16:57:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk NIST has officially made their "recommendation." This will be rubber stamped sometime later this year to make it an official FIPS. But it is considered a done deal. TLS, SMIME and IPSEC all have drafts out on how to use AES in their respective protocols. I don't see any reason to use 3DES (or anything else) in new standards. Hal > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Monday, January 08, 2001 4:05 PM > To: Hal Lockhart > Cc: 'David Frascone'; Pat Calhoun; Mark Eklund; diameter@diameter.org; > aaa-wg@merit.edu > Subject: RE: [diameter] Diameter correspondences. (fwd) > > > > > And, if I had to pick an encryption algorithm now, it > would be 3DES. > > > > Why not AES? > > > When will NIST offically release AES? > > PatC > From owner-aaa-bof@merit.edu Mon Jan 8 17:43:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15043 for ; Mon, 8 Jan 2001 17:43:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7024B5E232; Mon, 8 Jan 2001 17:24:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C7ED45E2FA; Mon, 8 Jan 2001 17:10:58 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id DDDE25E170 for ; Mon, 8 Jan 2001 17:04:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11786; Mon, 8 Jan 2001 14:04:46 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04637; Mon, 8 Jan 2001 14:04:46 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA00886; Mon, 8 Jan 2001 14:04:44 -0800 (PST) Date: Mon, 8 Jan 2001 14:01:08 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] Diameter correspondences. (fwd) To: Hal Lockhart Cc: "'Pat Calhoun'" , "'David Frascone'" , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <899128A30EEDD1118FC900A0C9C74A34BA952E@bigbird.gradient.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > NIST has officially made their "recommendation." This will be rubber stamped > sometime later this year to make it an official FIPS. But it is considered a > done deal. TLS, SMIME and IPSEC all have drafts out on how to use AES in > their respective protocols. I don't see any reason to use 3DES (or anything > else) in new standards. > Right, so my concern would be to depend on a standard that will probably be completed after we expect our work to be done. We've had similar issues with data modeling. PatC From owner-aaa-bof@merit.edu Mon Jan 8 17:58:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15252 for ; Mon, 8 Jan 2001 17:58:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33E0A5E143; Mon, 8 Jan 2001 17:45:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 096735DEF3; Mon, 8 Jan 2001 17:24:38 -0500 (EST) Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by segue.merit.edu (Postfix) with ESMTP id 3C0355E30D for ; Mon, 8 Jan 2001 17:11:25 -0500 (EST) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id RAA25351; Mon, 8 Jan 2001 17:11:16 -0500 (EST) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id ; Mon, 8 Jan 2001 17:09:46 -0500 Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA952F@bigbird.gradient.com> From: Hal Lockhart To: "'Pat Calhoun'" , Hal Lockhart Cc: "'David Frascone'" , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: RE: [diameter] Diameter correspondences. (fwd) Date: Mon, 8 Jan 2001 17:09:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk With respect, I don't think the situation is parallel. AES is not undergoing development. AES is not going to change. AES is already referenced by several Internet Drafts. We are simply waiting until April-June for the US government to publish a document which says the US government can require it in contracts. From the point of view of the IETF, the world banking community, etc. it is frozen and it is standard. Hal > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Monday, January 08, 2001 5:01 PM > To: Hal Lockhart > Cc: 'Pat Calhoun'; 'David Frascone'; Mark Eklund; > diameter@diameter.org; > aaa-wg@merit.edu > Subject: RE: [diameter] Diameter correspondences. (fwd) > > > > NIST has officially made their "recommendation." This will > be rubber stamped > > sometime later this year to make it an official FIPS. But > it is considered a > > done deal. TLS, SMIME and IPSEC all have drafts out on how > to use AES in > > their respective protocols. I don't see any reason to use > 3DES (or anything > > else) in new standards. > > > Right, so my concern would be to depend on a standard that > will probably be > completed after we expect our work to be done. > > We've had similar issues with data modeling. > > PatC > From owner-aaa-bof@merit.edu Mon Jan 8 18:03:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15370 for ; Mon, 8 Jan 2001 18:03:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3FDD5DFD1; Mon, 8 Jan 2001 17:56:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D3EA65DFA2; Mon, 8 Jan 2001 17:25:54 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 895F55DF4D for ; Mon, 8 Jan 2001 17:13:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28204; Mon, 8 Jan 2001 14:13:39 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06845; Mon, 8 Jan 2001 14:13:34 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA01072; Mon, 8 Jan 2001 14:13:32 -0800 (PST) Date: Mon, 8 Jan 2001 14:09:55 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] Diameter correspondences. (fwd) To: Hal Lockhart Cc: "'Pat Calhoun'" , "'David Frascone'" , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <899128A30EEDD1118FC900A0C9C74A34BA952F@bigbird.gradient.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk If that is the case, then I have no problems with using AES. PatC > With respect, I don't think the situation is parallel. AES is not undergoing > development. AES is not going to change. AES is already referenced by > several Internet Drafts. > > We are simply waiting until April-June for the US government to publish a > document which says the US government can require it in contracts. From the > point of view of the IETF, the world banking community, etc. it is frozen > and it is standard. > > Hal > > > -----Original Message----- > > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > > Sent: Monday, January 08, 2001 5:01 PM > > To: Hal Lockhart > > Cc: 'Pat Calhoun'; 'David Frascone'; Mark Eklund; > > diameter@diameter.org; > > aaa-wg@merit.edu > > Subject: RE: [diameter] Diameter correspondences. (fwd) > > > > > > > NIST has officially made their "recommendation." This will > > be rubber stamped > > > sometime later this year to make it an official FIPS. But > > it is considered a > > > done deal. TLS, SMIME and IPSEC all have drafts out on how > > to use AES in > > > their respective protocols. I don't see any reason to use > > 3DES (or anything > > > else) in new standards. > > > > > Right, so my concern would be to depend on a standard that > > will probably be > > completed after we expect our work to be done. > > > > We've had similar issues with data modeling. > > > > PatC > > From owner-aaa-bof@merit.edu Mon Jan 8 18:09:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA15503 for ; Mon, 8 Jan 2001 18:09:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 80A675DEDB; Mon, 8 Jan 2001 17:57:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D89CC5E23A; Mon, 8 Jan 2001 17:29:49 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by segue.merit.edu (Postfix) with ESMTP id 4F7725E20E for ; Mon, 8 Jan 2001 17:22:02 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQjxdh22439 for ; Mon, 8 Jan 2001 22:22:02 GMT Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQjxdh01065 for ; Mon, 8 Jan 2001 17:22:02 -0500 (EST) Date: Mon, 8 Jan 2001 17:22:02 -0500 (EST) From: Stuart A Barkley To: aaa-wg@merit.edu Subject: Normative references to AES In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, 8 Jan 2001, Pat Calhoun wrote: > When will NIST officially release AES? From: http://csrc.nist.gov/encryption/aes/round2/aesfact.html > 7. When will a draft of the AES standard become available? Will > the public be able to comment on the draft standard? > > NIST intends to publish a Draft FIPS for the AES approximately one > to two months after the AES announcement. At that time, a Federal > Register notice will solicit public comments on the Draft FIPS for > the AES for a period of 90 days. > > When the Federal Register publishes that notice, NIST will post > the Draft FIPS for the AES home page, along with information on > how and where to submit public comments. > > 8. When will the AES become an official standard? > > The AES will become official after the 90-day public comment > period concludes, NIST makes appropriate changes to the Draft > FIPS, and the Secretary of Commerce approves the FIPS. Current > estimates place this sometime in the spring of 2001 (i.e., > April-June). > > 9. In summary, what is the projected AES development timeline? > > A tentative timeline for the remainder of the AES development > effort is as follows: > > October 2, 2000 Announcement of NIST's selection for the AES. > > November 2000 Draft FIPS for the AES published for public comments. > > February 2001 Comment period closes. > > April-June 2001 (?) AES FIPS becomes official; conformance testing available. > > This timeline is subject to change, depending on the publication > date of the Draft FIPS and other factors. Its not clear to me where in this process we are at this time. The web site does not appear have the Draft FIPS (which should have been there in November) and a quick search at www.gpo.gov couldn't find anything. What are the current security experts expectations for the availability of AES as a normative standard? Do we also need a modes of operation reference or is that something we can directly specify? From owner-aaa-bof@merit.edu Mon Jan 8 20:30:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA17462 for ; Mon, 8 Jan 2001 20:30:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 73DFD5DEC2; Mon, 8 Jan 2001 20:26:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6323C5DEB8; Mon, 8 Jan 2001 20:26:37 -0500 (EST) Received: from roam.psg.com (mg-206253202-57.ricochet.net [206.253.202.57]) by segue.merit.edu (Postfix) with ESMTP id D6B5E5DEA9 for ; Mon, 8 Jan 2001 20:26:32 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14FmGt-000Mg9-00; Mon, 08 Jan 2001 16:04:15 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Frascone Cc: Pat Calhoun , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) References: <20010108141724.B18572@newman.frascone.com> <20010108144032.C18572@newman.frascone.com> Message-Id: Date: Mon, 08 Jan 2001 16:04:15 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk > And, if I had to pick an encryption algorithm now, it would be 3DES. this no longer seems to be the fashion, if i observe security culture well this year. randy From owner-aaa-bof@merit.edu Mon Jan 8 22:43:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA19423 for ; Mon, 8 Jan 2001 22:43:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 929875DE3E; Mon, 8 Jan 2001 22:37:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 418885DDCE; Mon, 8 Jan 2001 22:37:04 -0500 (EST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by segue.merit.edu (Postfix) with ESMTP id 9406F5DDCF for ; Mon, 8 Jan 2001 22:32:44 -0500 (EST) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id WAA03664; Mon, 8 Jan 2001 22:32:43 -0500 (EST) Posted-Date: Mon, 08 Jan 2001 22:36:39 -0500 Message-Id: <10101090336.AA22898@maia.east.isi.edu> Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 8 Jan 01 22:36:40 EST To: Pat Calhoun Cc: diameter@diameter.org, aaa-wg@merit.edu Reply-To: mankin@east.isi.edu Subject: Re: [diameter] Diameter correspondences. (fwd) In-Reply-To: Your message of Mon, 08 Jan 2001 14:01:08 -0800. Date: Mon, 08 Jan 2001 22:36:39 -0500 From: Allison Mankin Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, To underscore what Randy said, we in IESG are hearing from the Security ADs that new work should use AES. You can find some details from Marcus Leech, one of the Sec ADs, at http://csrc.nist.gov/encryption/aes/rijndael/misc/nissc3.pdf - up-to-date through October. Some pronouncement from IESG about this is in preparation too.I Allison Hal wrote: > > NIST has officially made their "recommendation." This will be rubber stamped > > sometime later this year to make it an official FIPS. But it is considered a > > done deal. TLS, SMIME and IPSEC all have drafts out on how to use AES in > > their respective protocols. I don't see any reason to use 3DES (or anything > > else) in new standards. > > Pat wrote: > Right, so my concern would be to depend on a standard that will probably be > completed after we expect our work to be done. > > We've had similar issues with data modeling. From owner-aaa-bof@merit.edu Mon Jan 8 22:45:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA19447 for ; Mon, 8 Jan 2001 22:45:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 335405DF02; Mon, 8 Jan 2001 22:40:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 210015DE63; Mon, 8 Jan 2001 22:40:41 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id D12E65DE5F for ; Mon, 8 Jan 2001 22:40:39 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f093edK02198 for ; Mon, 8 Jan 2001 21:40:39 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f093ecY25337 for ; Mon, 8 Jan 2001 21:40:38 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA25244 for ; Mon, 8 Jan 2001 21:40:38 -0600 (CST) Received: from ericsson.com (busam50.berkeley.us.am.ericsson.se [138.85.159.200]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA00245 for ; Mon, 8 Jan 2001 21:40:36 -0600 (CST) Message-ID: <3A5A8708.E9CF65AB@ericsson.com> Date: Mon, 08 Jan 2001 19:35:37 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.4.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk All, In section 6.4.1: "A Proxy Server MAY also include the Proxy-State AVP, which is used to encode local state information. The Proxy-State AVP is guaranteed to be present in the corresponding response. If the Proxy-State AVP is present, both the Route-Record and the Proxy-State AVPs MUST be encapsulated within the Grouped-AVP AVP." Why should the Route-Record and the Proxy-State AVP be encapsulated within a Grouped-AVP AVP? In the draft-calhoun-diameter-17.txt is ONLY one Proxy-State AVP allowed in a single DIAMETER message, so I don't see why we need to use a Grouped-AVP or is it now possible to have more the one Proxy-State AVP in a single message? BR, /Tony From owner-aaa-bof@merit.edu Mon Jan 8 22:49:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA19476 for ; Mon, 8 Jan 2001 22:49:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC5475DDB9; Mon, 8 Jan 2001 22:43:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 908B25DDFE; Mon, 8 Jan 2001 22:43:05 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 5662E5DDB9 for ; Mon, 8 Jan 2001 22:43:04 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15715; Mon, 8 Jan 2001 19:43:02 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA26889; Mon, 8 Jan 2001 19:42:46 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id TAA08688; Mon, 8 Jan 2001 19:42:42 -0800 (PST) Date: Mon, 8 Jan 2001 19:39:07 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] Diameter correspondences. (fwd) To: mankin@east.isi.edu Cc: Pat Calhoun , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <10101090336.AA22898@maia.east.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I suppose you missed my e-mail, but I agreed that AES was the way to go. Thanks, PatC > Pat, > > To underscore what Randy said, we in IESG are hearing from the > Security ADs that new work should use AES. You can find > some details from Marcus Leech, one of the Sec ADs, > at http://csrc.nist.gov/encryption/aes/rijndael/misc/nissc3.pdf - > up-to-date through October. > > Some pronouncement from IESG about this is in preparation too.I > > Allison > > Hal wrote: > > > NIST has officially made their "recommendation." This will be rubber stamped > > > sometime later this year to make it an official FIPS. But it is considered a > > > done deal. TLS, SMIME and IPSEC all have drafts out on how to use AES in > > > their respective protocols. I don't see any reason to use 3DES (or anything > > > else) in new standards. > > > > Pat wrote: > > Right, so my concern would be to depend on a standard that will probably be > > completed after we expect our work to be done. > > > > We've had similar issues with data modeling. From owner-aaa-bof@merit.edu Tue Jan 9 06:19:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA24705 for ; Tue, 9 Jan 2001 06:19:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B71875DE23; Tue, 9 Jan 2001 06:16:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6CD55DE14; Tue, 9 Jan 2001 06:16:11 -0500 (EST) Received: from sweeperuk.cdsemea.baltimore.com (unknown [193.41.18.2]) by segue.merit.edu (Postfix) with ESMTP id 630775DDD4 for ; Tue, 9 Jan 2001 06:16:10 -0500 (EST) Received: from irlbdc.ie.baltimore.com (unverified) by sweeperuk.cdsemea.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 9 Jan 2001 11:15:02 +0000 Received: by irlbdc.ie.baltimore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 11:15:47 -0000 Message-ID: <3B46C515DDE2D311A70C005004AFCB7063FB80@emeairl2.ie.baltimore.com> From: William Whyte To: aaa-wg@merit.edu Subject: RE: Normative references to AES Date: Tue, 9 Jan 2001 11:22:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > Its not clear to me where in this process we are at this time. The > web site does not appear have the Draft FIPS (which should have been > there in November) and a quick search at www.gpo.gov couldn't find > anything. NIST circulated a mail last night saying that this draft FIPS is "anticipated for release ... in the very near future". > What are the current security experts expectations for the > availability of AES as a normative standard? Although the draft FIPS isn't yet available, it's important to bear in mind that the AES was developed in public so that it would have the public's trust. If NIST were to publish a draft FIPS that was different from Rijndael in any substantive way, it would arouse suspicion and undo all the good work that was done by the process to date. It'd be unwise to ship something as "AES" before the final FIPS issues, but people can implement Rijndael now and have confidence that it'll interoperate with AES. > Do we also need a modes of operation reference or is that something we > can directly specify? The current Modes of Operation FIPS (81) applies only to DES, but is easy to generalize to 128-bit blocks. NIST held a Modes of Operation Workshop in Baltimore in October. Some new and quite clever modes were proposed there, and will be considered for future standardization. NIST's intention is to issue a draft FIPS, AES-ifying the DES modes, very soon, and to consider following it up with the additional modes later. Again, implementing the modes by common-sense extrapolation from the DES modes and putting in the reference later when the FIPS issues should be safe. Cheers, William William Whyte Senior Cryptographer Baltimore Technologies Ltd Parkgate Street Dublin 8 Ireland ****************************************************************************************************************** The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This message and any attachments have been scanned for viruses. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.baltimore.com ****************************************************************************************************************** From owner-aaa-bof@merit.edu Tue Jan 9 06:50:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA25040 for ; Tue, 9 Jan 2001 06:50:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 834E95DE4C; Tue, 9 Jan 2001 06:48:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 69B875DE4B; Tue, 9 Jan 2001 06:48:35 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 3731F5DDAA for ; Tue, 9 Jan 2001 06:48:34 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08787; Tue, 9 Jan 2001 06:48:32 -0500 (EST) Message-Id: <200101091148.GAA08787@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu, mobile-ip@standards.nortelnetworks.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-perkins-aaav6-02.txt Date: Tue, 09 Jan 2001 06:48:32 -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AAA for IPv6 Network Access Author(s) : N. Asokan, P. Flykt, C. Perkins, T. Eklund Filename : draft-perkins-aaav6-02.txt Pages : 28 Date : 08-Jan-01 IPv6 nodes (clients) need a way to offer credentials to a local AAA in order to be granted access to the local network. For IPv6, it will be more efficient and thus reasonable to expect such access controls to be exerted by IPv6 routers, possibly as part of performing their role as DHCPv6 relays. DHCPv6 servers and routers are expected to work in conjunction with AAA servers to determine whether or not the client's credentials are valid. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-aaav6-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-perkins-aaav6-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-perkins-aaav6-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010108124754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perkins-aaav6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-perkins-aaav6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010108124754.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Tue Jan 9 08:24:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA26086 for ; Tue, 9 Jan 2001 08:24:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48BBC5DDE2; Tue, 9 Jan 2001 08:23:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2B1D75DE07; Tue, 9 Jan 2001 08:23:41 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 322FC5DDE2 for ; Tue, 9 Jan 2001 08:23:39 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA03742; Tue, 9 Jan 2001 14:23:38 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA20320; Tue, 9 Jan 2001 14:23:37 +0100 Date: Tue, 9 Jan 2001 14:23:37 +0100 Message-Id: <200101091323.OAA20320@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Erik.Guttman@germany.sun.com Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-reply-to: (message from Erik Guttman on Fri, 5 Jan 2001 18:45:37 +0100 (MET)) Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Erik Guttman writes: Erik> Juergen, Erik> In my opinion we should select the XML solution since it is Erik> simple, and adequate. >> Good to hear that you (as the author of this proposal) find is >> simple and adequate. :-) Erik> I guess I came off sounding smug, sorry :-/ >> We unfortunately did not have any time during the last WG meeting >> to actually debate what is "adequate". Erik> In other words, the goals are: Erik> a. Express data definitions in formal terms, to make it easier Erik> to validate the spec and implementations b. Allow for automating Erik> some of the implementation process c. Allow for definitions to Erik> be used in debugging d. Allow for ability to add definitions for Erik> new extensions Note that it says "validate the spec" which for implies that the formal data definition is part of the normative text and not just an add on. >> Erik's proposal is more an XML version of a repository and focuses >> on things that are easily loaded into an implementation at >> runtime. XML DTD however only specify how XML tags may be >> nested. There is no way to specify in plain XML what is allowed >> between two tags or what is allowed as an attribute >> value. Furthermore, XML DTDs have no concept of version >> handling. Yes, this makes things simple - but will it be adequate >> in say 2 years from now if DIAMETER is a success? (Note that the >> XML folks created XML Schemas because it turns out that a simple >> DTD is not enough to specify data structures precisely enough.) Erik> Well - you can set the values that an entity attribute can have. Erik> And in the case of constrained values of an AVP, I defined an Erik> tag, whereby the xml can enumerate the allowable values. You missed my point. A DTD does not specify what you can put between your XML tags. Is it a number or arbitrary text? If it is a number, what precisely does it mean (is 020 an octal value or a decimal value with a leading 0?) If it is text, which charter set is allowed? ... Erik> I agree with versioning - that is not even addressed with the Erik> XML approach. Can you be more specific what this goal consists Erik> of? It is not discussed in draft-ietf-aaa-issues-04.txt, but we Erik> can add it to our list of goals. Each definition in SMIv2/SPPI and SMIng has a status value associated with it which is used for versioning. A definition can go from current to deprected to obsolete. There are clear rules which changes are allowed to an existing definitions which ensure forward/backward compatibility. It basically boils down to require that a published definition can not semantically change. If you need to make semantic changes, you need to assign a new name. I guess such a strategy to deal with versioning issues is needed for DIAMETER as well since I am sure that some of the AVPs we define today will be recognized as broken in a few years from now. Erik> I have been pushing for an adequate near term solution. The Erik> data modelling 'solution' doesn't necessarily have to appear Erik> before DIAMETER is standardized. My understanding of the requirements is that we want to use the formal notation among other things to help to validate the specs. If free form English text is the normative reference, then there is no benefit from being able to validate the non-normative formal notation. In other words, I want the AVPs and messages defined using the formal notation itself, which implies that the formal notation is part of the DIAMETER standard. >> David's proposal comes yet again from another different angle. Its >> main background is the observation that AVP combinations that can >> be meaningfully combined in a message are actually not well >> defined. Erik> I do not know that this is a very big issue. If DIAMETER Erik> command codes specify what MUST be there and how to interpret Erik> it, other AVPs which are present should not prevent proper Erik> interpretation of the command. Erik> We have been around this point a number of times - there are Erik> good reasons to use the RADIUS approach as it is flexible: Erik> Specify what is required, allow arbitrary ordering and Erik> additional AVP message components. No one has argued for Erik> removing this flexibility, though there has been discussion Erik> about how this would facilitate a formal ABNF for the protocol. There are again two issues here. The first one is a protocol issue, namely whether it is legal so ship additional AVPs with a message. The second one is the question which set of AVPs actually consitute a given message. Even the current specs use a kind of a BNF notation trying to make that clear. But there are issues because the specs do not really say what the semantics of the BNF notation are. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Tue Jan 9 08:47:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA26311 for ; Tue, 9 Jan 2001 08:47:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F2925DEC9; Tue, 9 Jan 2001 08:41:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 814025E186; Tue, 9 Jan 2001 08:40:31 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 46B395DF0C for ; Tue, 9 Jan 2001 08:29:26 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA03914; Tue, 9 Jan 2001 14:29:20 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA20363; Tue, 9 Jan 2001 14:29:19 +0100 Date: Tue, 9 Jan 2001 14:29:19 +0100 Message-Id: <200101091329.OAA20363@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Pat.Calhoun@Eng.Sun.COM Cc: david.durham@intel.com, Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-reply-to: (message from Pat Calhoun on Fri, 5 Jan 2001 13:38:20 -0800 (PST)) Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Pat Calhoun writes: Pat> I want to have a standardized dictionary format, and I want the Pat> message in the DIAMETER specs to be prettier and parsable in some Pat> way by applications. The first part of this statement is a clear to me. And it is my understanding that the XML proposal is primarily targeted to do this. (Although this hardly falls into the category data modeling as I understand the term.) The part "I want the message in the DIAMETER specs to be prettier and parsable in some way by applications" is what causes us problems since the notions of "prettier" and parsable in some way by applications" are really fuzzy. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Tue Jan 9 10:03:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27447 for ; Tue, 9 Jan 2001 10:03:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21BFC5DEE6; Tue, 9 Jan 2001 09:41:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8706B5E261; Tue, 9 Jan 2001 09:34:56 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id DE9685E00A for ; Tue, 9 Jan 2001 09:22:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17315; Tue, 9 Jan 2001 06:22:19 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA17543; Tue, 9 Jan 2001 06:22:18 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA19665; Tue, 9 Jan 2001 06:22:17 -0800 (PST) Date: Tue, 9 Jan 2001 06:18:43 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101091323.OAA20320@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Erik> Well - you can set the values that an entity attribute can have. > Erik> And in the case of constrained values of an AVP, I defined an > Erik> tag, whereby the xml can enumerate the allowable values. > > You missed my point. A DTD does not specify what you can put between > your XML tags. Is it a number or arbitrary text? If it > is a number, what precisely does it mean (is 020 an octal value or a > decimal value with a leading 0?) If it is text, which charter set is > allowed? ... > I believe this MAY be an important point to consider. Historically, RADIUS dictionaries would have a format similar to: ATTRIBUTE attribute-name format identifier then: VALUE attribute-name keyword value So, alot of the validation was done by verifying the format of the attribute. Out of curiosity, how would your proposal make this any different? The validation would be automated? It seems like there is still some checks required. PatC From owner-aaa-bof@merit.edu Tue Jan 9 10:09:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27568 for ; Tue, 9 Jan 2001 10:09:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1EDE05DF82; Tue, 9 Jan 2001 09:42:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8151A5E106; Tue, 9 Jan 2001 09:35:51 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 64AEF5E080 for ; Tue, 9 Jan 2001 09:23:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25584; Tue, 9 Jan 2001 06:23:52 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA17758; Tue, 9 Jan 2001 06:23:51 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA19689; Tue, 9 Jan 2001 06:23:49 -0800 (PST) Date: Tue, 9 Jan 2001 06:20:15 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Pat.Calhoun@eng.sun.com, david.durham@intel.com, Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101091329.OAA20363@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > >>>>> Pat Calhoun writes: > > Pat> I want to have a standardized dictionary format, and I want the > Pat> message in the DIAMETER specs to be prettier and parsable in some > Pat> way by applications. > > The first part of this statement is a clear to me. And it is my > understanding that the XML proposal is primarily targeted to do this. > (Although this hardly falls into the category data modeling as I > understand the term.) > > The part "I want the message in the DIAMETER specs to be prettier and > parsable in some way by applications" is what causes us problems since > the notions of "prettier" and parsable in some way by applications" > are really fuzzy. ok, let me try again (btw, I used prettier for lack of better terms). I do not want to force implementors to cut a paste a section of text in the spec into some tool to figure out what the message consists of. I want it to be clear to the naked eye, while allowing tools to be used. Hope this is clearer (but I am not sure it is :( PatC From owner-aaa-bof@merit.edu Tue Jan 9 10:13:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27659 for ; Tue, 9 Jan 2001 10:13:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D3D15E0E1; Tue, 9 Jan 2001 09:45:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AAC095DFAC; Tue, 9 Jan 2001 09:39:12 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 02A725E21A for ; Tue, 9 Jan 2001 09:27:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18503; Tue, 9 Jan 2001 06:26:57 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA18263; Tue, 9 Jan 2001 06:26:56 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA19732; Tue, 9 Jan 2001 06:26:55 -0800 (PST) Date: Tue, 9 Jan 2001 06:23:21 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Comments on draft-ietf-aaa-solutions-00.txt: Section 6.4.1 To: Tony Johansson Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A5A8708.E9CF65AB@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Tony, Thanks for the comments, and see my answers below. PatC > All, > > In section 6.4.1: > > "A Proxy Server MAY also include the Proxy-State AVP, which is used to > encode local state information. The Proxy-State AVP is guaranteed to > be present in the corresponding response. If the Proxy-State AVP is > present, both the Route-Record and the Proxy-State AVPs MUST be > encapsulated within the Grouped-AVP AVP." > > Why should the Route-Record and the Proxy-State AVP be encapsulated > within a Grouped-AVP AVP? Because a given message MAY include one or more Route-Record and Proxy-State AVPs. Having them grouped will ensure that a server can find its record route (based on the IP address) and the associated proxy-state AVP. This will simplify the Proxy-State, which currently includes an IP address, by making it completely opaque. > > In the draft-calhoun-diameter-17.txt is ONLY one Proxy-State AVP allowed > in a single DIAMETER message, so I don't see why we need to use a > Grouped-AVP or is it now possible to have more the one Proxy-State AVP > in a single message? Correct, and the new spec will allow more than one Proxy-State AVP. I believe this is a much cleaner approach. The idea of one Proxy-State AVP per message was from the RADIUS world, and really complicated the processing on each hop. PatC From owner-aaa-bof@merit.edu Tue Jan 9 10:54:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28433 for ; Tue, 9 Jan 2001 10:53:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6178A5DF20; Tue, 9 Jan 2001 10:32:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7D07E5DE58; Tue, 9 Jan 2001 10:08:23 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 065FF5E164 for ; Tue, 9 Jan 2001 09:47:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09381; Tue, 9 Jan 2001 06:47:10 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA20776; Tue, 9 Jan 2001 06:47:10 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA20152; Tue, 9 Jan 2001 06:47:09 -0800 (PST) Date: Tue, 9 Jan 2001 06:43:35 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: draft-calhoun-diameter-17.txt / DRI capabilities negotiation To: Bob Kopacz Cc: "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 Bob, You raise a very interesting point, and I am struggling to find an answer. In our environment, the proxy only has a set of capabilities, but I understand that in your example, a server may want to only do Mobile IP (for local domains), and everything when it acts as a proxy. So, I suppose we have a couple of options: 1. Leave it as-is. Specify that proxies should advertise all supported extension-ids, and if a message is received for a local realm whose extension is not supported, return the DIAMETER_COMMAND_UNSUPPORTED error code. This, however, seems to eliminate any benefits of the DRI. 2. Enhance the DRI. Each DRI now includes a set of realm names that are locally supported. The extension IDs that are provided are ONLY relevant to the locally supported realms. A separate AVP could be forwarded that states that the server also acts as a proxy for other realms. Therefore, it is still necessary for the servers to have the configured domains behind the proxy. Of course, this begs the question of why not simply advertise all realms that it CAN support, and mark those that are local, and those that are not. This has been discussed a couple of years back, but such a scheme would be problematic, as we would have to handle loops and other error conditions. 3. Eliminate the DRI altogether, and rely solely on error codes. However, this is really problematic in proxy environments, since you don't really know who returned the error code. So, if a proxy returned the error, how does the NAS know it wasn't the home server, and how would it force the message to take a different path. For this reason, I think that the DRI is required, but it must be fixed somehow. Perhaps option 2, or something similar to that, needs to be done. Ideas? PatC From owner-aaa-bof@merit.edu Tue Jan 9 11:33:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA29220 for ; Tue, 9 Jan 2001 11:33:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6F0E5DF11; Tue, 9 Jan 2001 10:40:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D6FF85E07F; Tue, 9 Jan 2001 10:24:57 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 0A3DA5E48F for ; Tue, 9 Jan 2001 09:59:05 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16874; Tue, 9 Jan 2001 06:59:03 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA22338; Tue, 9 Jan 2001 06:59:02 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA20441; Tue, 9 Jan 2001 06:59:01 -0800 (PST) Date: Tue, 9 Jan 2001 06:55:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: draft-ietf-aaa-solutions-01 / "M" bit handling by proxies To: Bob Kopacz Cc: "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 > Hi, > > Question re: "M" bit in AVP header. > > Do proxies handle the "M" bit differently than home > servers and NASes? > > For example, it seems reasonable that a proxy server > which receives an unknown mandatory AVP might want to > pass the AVP along, whereas a NAS or home server would > want to treat this as an error. I agree. So the solutions ID could be change to something like: 9.5.3 What are the correct error responses? If a DIAMETER peer receives an AVP with the "M" bit set, it is the Home server or NAS for the message and it does not recognize the AVP or the service described by the AVP, it MUST reject the request or treat the response as if it were a rejection. When such an even occurs, it is the responsibility of the sender of the message with the "M" bit to rectify the message if it wishes the home server to correctly process the message. In situations where a server receives an unrecognized AVP, or service described in the AVP, with the "M" bit set, it SHOULD NOT treat the event as an error condition and SHOULD proxy the message to the next hop. Does this make sense? PatC > > > The draft-ietf-aaa-solutions-01.txt states the > following: > > > 9.5.3 What are correct error responses? > > > > If a DIAMETER peer receives an AVP with the "M" bit > > set, and it does not recognize the AVP or does not > > support the service described by the AVP, it must > > reject the access request or treat the access response > > as if it were a rejection. > > > From owner-aaa-bof@merit.edu Tue Jan 9 12:47:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00449 for ; Tue, 9 Jan 2001 12:47:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B5395E597; Tue, 9 Jan 2001 12:05:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4F8C15DEFD; Tue, 9 Jan 2001 11:18:31 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id C45065E683 for ; Tue, 9 Jan 2001 10:51:06 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA12472; Tue, 9 Jan 2001 16:50:51 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA21074; Tue, 9 Jan 2001 16:50:51 +0100 Date: Tue, 9 Jan 2001 16:50:51 +0100 Message-Id: <200101091550.QAA21074@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Pat.Calhoun@Eng.Sun.COM Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-reply-to: (message from Pat Calhoun on Tue, 9 Jan 2001 06:18:43 -0800 (PST)) Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Pat Calhoun writes: Pat> Historically, RADIUS dictionaries would have a format similar to: Pat> ATTRIBUTE attribute-name format identifier Pat> then: Pat> VALUE attribute-name keyword value Not sure I understand what you are trying to say here. Pat> So, alot of the validation was done by verifying the format of Pat> the attribute. Out of curiosity, how would your proposal make Pat> this any different? The validation would be automated? It seems Pat> like there is still some checks required. Not sure I understand the question. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Tue Jan 9 12:55:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00605 for ; Tue, 9 Jan 2001 12:55:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 167845DE90; Tue, 9 Jan 2001 12:05:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9F0B65DF7F; Tue, 9 Jan 2001 11:18:50 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9326B5E6D6 for ; Tue, 9 Jan 2001 10:57:03 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23315; Tue, 9 Jan 2001 07:57:01 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA12592; Tue, 9 Jan 2001 07:57:00 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21695; Tue, 9 Jan 2001 07:56:59 -0800 (PST) Date: Tue, 9 Jan 2001 07:53:24 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Pat.Calhoun@eng.sun.com, Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101091550.QAA21074@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > >>>>> Pat Calhoun writes: > > Pat> Historically, RADIUS dictionaries would have a format similar to: > > Pat> ATTRIBUTE attribute-name format identifier > > Pat> then: > > Pat> VALUE attribute-name keyword value > > Not sure I understand what you are trying to say here. > ok, let me try again. Current RADIUS dictionaries have two different types of entries; Attribute definitions, and value definitions. Attribute definitions specify the data type, and the identifier, while a value definition specifies pre-defined values for an attribute. Here is an example: ATTRIBUTE Framed-Protocol Integer 7 VALUE Framed-Protocol PPP 1 VALUE Framed-Protocol SLIP 2 So, the first entry defines the Framed-Protocol attribute, while the last two entries associate values to the attribute. > Pat> So, alot of the validation was done by verifying the format of > Pat> the attribute. Out of curiosity, how would your proposal make > Pat> this any different? The validation would be automated? It seems > Pat> like there is still some checks required. So my point here was that a dictionary contains the data type for an attribute, and when the VALUE section is parsed, the values are validated against the type specified in the attribute definition section. My question was how would this be done any other way? Your e-mail stated that SPPI/SMI* had provisions for this, where XML did not. I was trying to understand how it would make the dictionary better. Hope this makes more sense. PatC > > Not sure I understand the question. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > From owner-aaa-bof@merit.edu Tue Jan 9 13:12:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00833 for ; Tue, 9 Jan 2001 13:12:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98FB55E48E; Tue, 9 Jan 2001 12:46:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 488235E567; Tue, 9 Jan 2001 12:05:06 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 0A5F65DDB0 for ; Tue, 9 Jan 2001 11:18:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07311; Tue, 9 Jan 2001 08:18:03 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA04902; Tue, 9 Jan 2001 08:18:03 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA22143; Tue, 9 Jan 2001 08:18:01 -0800 (PST) Date: Tue, 9 Jan 2001 08:14:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: DISCUSSION REQUESTED: ADIF, Batching, M bit To: Jari Arkko Cc: Stuart A Barkley , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <002101c078f3$54d67220$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Thirdly, I wonder if we select XML as the data description language, is > there any benefit in shipping the accounting records also in XML? > Good question, but aren't we back where we were some time back with ADIF? I think people didn't want to rely on another data modeling scheme for accounting, and just send things straight in AVPs. This makes the parsing much simpler to identify errors. However, I think that specifying a recommended XML or SMI format for the accounting file that is written on the server MAY be a desirable goal. PatC From owner-aaa-bof@merit.edu Tue Jan 9 13:36:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01418 for ; Tue, 9 Jan 2001 13:36:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A96B5DF1F; Tue, 9 Jan 2001 13:03:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1451C5E3DA; Tue, 9 Jan 2001 12:59:28 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B53A55E3D0 for ; Tue, 9 Jan 2001 12:12:07 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15994; Tue, 9 Jan 2001 09:12:06 -0800 (PST) Received: from vayne (muc-isdn-20 [129.157.164.120]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA06933; Tue, 9 Jan 2001 18:12:04 +0100 (MET) Date: Tue, 9 Jan 2001 18:22:31 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101091323.OAA20320@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Juergen, > Erik> Well - you can set the values that an entity attribute can have. > Erik> And in the case of constrained values of an AVP, I defined an > Erik> tag, whereby the xml can enumerate the allowable values. > > You missed my point. A DTD does not specify what you can put between > your XML tags. Is it a number or arbitrary text? I think there is a misunderstanding about what I am proposing in draft-ietf-aaa-solutions-01.txt. The DIAMETER XML I have created is not for representing values - it is for representing supported DIAMETER AVPs. What you put between is a value defined in either the base DIAMETER or extension specification, not arbitrary text. The purpose of the xml file is for creating a dicationary of allowable AVPs and their characteristics - not for representing the data in the dictionaries. > Erik> I agree with versioning - that is not even addressed with the > Erik> XML approach. Can you be more specific what this goal consists > Erik> of? It is not discussed in draft-ietf-aaa-issues-04.txt, but we > Erik> can add it to our list of goals. > > A definition can go from current to deprected to obsolete. > There are clear rules which changes are allowed to an existing > definitions which ensure forward/backward compatibility. It basically > boils down to require that a published definition can not semantically > change. AVPs are identified by an Unsigned32. They are required for particular commands in inflexible ways. I believe an evolution of interpretation or deprecation of AVPs will require new versions of the standards track DIAMETER documents (base protocol or Extensions). Adding new AVPs will require new Extension specifications. Note that this is quite distinct from evolving a data dictionary. As long as a dictionary accurately reflects the specifications it cites, it has the appropriate version. In the XML approach I cite the base protocol and extension document versions. All one would has to do to extend this is 'cut and past' into the XML file. > Note that it says "validate the spec" which for implies that the > formal data definition is part of the normative text and not just an > add on. I agree that the XML version doesn't help with formally validating the spec. I don't see any easy way to improve the verifiability of the DIAMETER spec except (a) to remove the arbitrary ordering of DIAMETER messages. This would allow a formal grammar to be written. And (b) to formally represent what values, flags, error conditions and responses can be expected in all protocol interactions. The working group has not supported (a). DIAMETER is already specified - but not perhaps not as formally as it could be done. Since (b) is really about clarity not about content, we would only really be able to determine whether an alternative was superior by a direct comparison. What I'm suggesting is - if you think that another representation of the DIAMETER protocol would be clearer, please send text. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Tue Jan 9 13:42:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01580 for ; Tue, 9 Jan 2001 13:42:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 740B15E0B9; Tue, 9 Jan 2001 13:08:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4C0BD5DDDD; Tue, 9 Jan 2001 12:42:35 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 57B445DDF5 for ; Tue, 9 Jan 2001 11:56:06 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA15372; Tue, 9 Jan 2001 17:56:02 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA21271; Tue, 9 Jan 2001 17:56:02 +0100 Date: Tue, 9 Jan 2001 17:56:02 +0100 Message-Id: <200101091656.RAA21271@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Pat.Calhoun@eng.sun.com Cc: Pat.Calhoun@eng.sun.com, Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-reply-to: (message from Pat Calhoun on Tue, 9 Jan 2001 07:53:24 -0800 (PST)) Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Pat Calhoun writes: Pat> Current RADIUS dictionaries have two different types of entries; Pat> Attribute definitions, and value definitions. Attribute Pat> definitions specify the data type, and the identifier, while a Pat> value definition specifies pre-defined values for an Pat> attribute. Here is an example: Pat> ATTRIBUTE Framed-Protocol Integer 7 Pat> VALUE Framed-Protocol PPP 1 VALUE Framed-Protocol SLIP 2 Pat> So, the first entry defines the Framed-Protocol attribute, while Pat> the last two entries associate values to the attribute. [...] Pat> So my point here was that a dictionary contains the data type for Pat> an attribute, and when the VALUE section is parsed, the values Pat> are validated against the type specified in the attribute Pat> definition section. Pat> My question was how would this be done any other way? Your e-mail Pat> stated that SPPI/SMI* had provisions for this, where XML did Pat> not. I was trying to understand how it would make the dictionary Pat> better. I probably did not express myself clearly enough (see below). But let me first sketch how this would look like in SMIng: typedef FramedProtocolEnumeration { type Enumeration (ppp(1), slip(2)); description "An enumerated list of framed protocols."; } class FramedProtocol { attribute FramedProtocolEnumeration frameType { description "..."; } description "..."; } The typedef statement introduces a new SMIng data type and the class statement defines an SMIng class with one attribute which uses the new data type. Note that these definitions are not DIAMETER specific and can be used (and reused) in various contexts and with various protocols (SNMP, COPS-PR, DIAMETER, and whatever comes next). Furthermore, note that the FramedProtocolEnumeration is most likely something which should be maintained under IANA control. So the definition goes into an IANA module which you (and anybody else who needs something like this) just import. The only DIAMETER specific mapping of this class to an AVP is in the DIAMETER specific mapping section: diameter { avp FramedProtocolAVP { code 1234; implements FramedProtocol; }; } This assignes the AVP code 1234 to the DIAMETER AVP named FramedProtocolAVP. So is this simpler or better? Well, probably not for just loading a dictionary or for a simple example where you only have few attributes. The benefits of reuse and consistency only become obvious if you look at more complex examples. In the SNMP world, almost everybody uses DisplayString or SnmpAdminString to represent strings. These are SMIv2 specific type definitions which provide reuse without cut & paste. If there would have been no way to introduce things like DisplayString (and later SnmpAdminString when we all became UTF8 ready), then I would be sure that we would have hundreds of slightly different string types. So is there something the SMIng can do which the XML DTD does not do? Yes, and this has to do with the ability to not only verify avps in protocol messages, but to also verify the correctness of the formal notation itself. SMIng has clear and precise rules what is a legal type definition, such as the enumeration above. A simple XML DTD does not have this precision. Look at the following quoted from the solutions draft: This DTD fragment only specifies the nesting order. The stuff between the tags is just #PCDATA. So all this is legal if you validate against this DTD (hopefully I did not make any unwanted typos here): 1 ppp 2 slip slip 2 3 slip So what is the number associated with the name "slip" here? Sure, you can write up rules that address all these issues. BTW, even in the SNMP world, we have systems that do not load SMIv2 MIBs at runtime. Instead, they use tools to convert the data definition (which is trying to be precise and verifable) into an intermediate format which is (a) machine generated and thus safe to expect to be correct and (b) more efficient to parse during runtime. In fact, we wrote a document which proposes an XML representation for SMI definitions for exactly this purpose. So the question really boils down to whether we really want to do data modeling or if all we are looking for is a repository exchange format. The SMIng proposal is targeted on data modeling, providing reuse, versioning, a module concept, a type system, a class system, ... which can also be used as to load definitions at runtime. The XML proposal is primarily targeted to load definitions at runtime, but lacks IMHO features to make sure you can keep the number of AVP and message definitions under control in the longer term. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Tue Jan 9 14:06:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02172 for ; Tue, 9 Jan 2001 14:06:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74D5D5E238; Tue, 9 Jan 2001 13:38:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A8AD5E135; Tue, 9 Jan 2001 13:08:00 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D16D85E024 for ; Tue, 9 Jan 2001 12:34:15 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01327; Tue, 9 Jan 2001 09:34:14 -0800 (PST) Received: from vayne (muc-isdn-20 [129.157.164.120]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA25953; Tue, 9 Jan 2001 18:34:11 +0100 (MET) Date: Tue, 9 Jan 2001 18:44:38 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Pat.Calhoun@eng.sun.com, Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101091656.RAA21271@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.merit.edu id OAA02172 Juergen, > So is there something the SMIng can do which the XML DTD does not do? > Yes, and this has to do with the ability to not only verify avps in > protocol messages, but to also verify the correctness of the formal > notation itself. I agree it is hard to verify the correctness of the XML. But I am not sure you couldn't use the XML to verify data (in protocol messages, in memory, stored on disk, etc). For instance, if the XML lists 3 allowable values for an AVP you can verify whether an AVP uses an allowable value or not. > So the question really boils down to whether we really want to do data > modeling or if all we are looking for is a repository exchange format. What I propose is more like a repository format exchange format :-) Its really just a restating of what is in various specs, in xml. > The SMIng proposal is targeted on data modeling, providing reuse, > versioning, a module concept, a type system, a class system, ... which > can also be used as to load definitions at runtime. The XML proposal > is primarily targeted to load definitions at runtime, but lacks IMHO > features to make sure you can keep the number of AVP and message > definitions under control in the longer term. Why can't we standarize DIAMETER (its current informal spec) and later model it with SMIng? If we find errors in the spec, we can cycle it in the standards process. I think this would be a useful endeavor. Once SMIng notation is standardized, we could begin this process of rewriting the DIAMETER specification with the goal of improving it.  I think providing a data dictionary and a formal specification are two distinct goals. Do you agree? Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Tue Jan 9 14:07:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02206 for ; Tue, 9 Jan 2001 14:07:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A43F05E28C; Tue, 9 Jan 2001 13:38:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 85A835DE64; Tue, 9 Jan 2001 13:08:04 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4916E5E274 for ; Tue, 9 Jan 2001 12:34:34 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01507; Tue, 9 Jan 2001 09:34:32 -0800 (PST) Received: from vayne (muc-isdn-20 [129.157.164.120]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA27862; Tue, 9 Jan 2001 18:34:30 +0100 (MET) Date: Tue, 9 Jan 2001 18:44:57 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Choice of Data Model SMI vs XML vs. UML To: Juergen Schoenwaelder Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <200101091323.OAA20320@henkell.ibr.cs.tu-bs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > >>>>> Erik Guttman writes: > > Erik> Juergen, > > Erik> In my opinion we should select the XML solution since it is > Erik> simple, and adequate. > >> Good to hear that you (as the author of this proposal) find is > >> simple and adequate. :-) > > Erik> I guess I came off sounding smug, sorry :-/ > > >> We unfortunately did not have any time during the last WG meeting > >> to actually debate what is "adequate". > > Erik> In other words, the goals are: > > Erik> a. Express data definitions in formal terms, to make it easier > Erik> to validate the spec and implementations b. Allow for automating > Erik> some of the implementation process c. Allow for definitions to > Erik> be used in debugging d. Allow for ability to add definitions for > Erik> new extensions > > Note that it says "validate the spec" which for implies that the > formal data definition is part of the normative text and not just an > add on. > > >> Erik's proposal is more an XML version of a repository and focuses > >> on things that are easily loaded into an implementation at > >> runtime. XML DTD however only specify how XML tags may be > >> nested. There is no way to specify in plain XML what is allowed > >> between two tags or what is allowed as an attribute > >> value. Furthermore, XML DTDs have no concept of version > >> handling. Yes, this makes things simple - but will it be adequate > >> in say 2 years from now if DIAMETER is a success? (Note that the > >> XML folks created XML Schemas because it turns out that a simple > >> DTD is not enough to specify data structures precisely enough.) > > Erik> Well - you can set the values that an entity attribute can have. > Erik> And in the case of constrained values of an AVP, I defined an > Erik> tag, whereby the xml can enumerate the allowable values. > > You missed my point. A DTD does not specify what you can put between > your XML tags. Is it a number or arbitrary text? If it > is a number, what precisely does it mean (is 020 an octal value or a > decimal value with a leading 0?) If it is text, which charter set is > allowed? ... > > Erik> I agree with versioning - that is not even addressed with the > Erik> XML approach. Can you be more specific what this goal consists > Erik> of? It is not discussed in draft-ietf-aaa-issues-04.txt, but we > Erik> can add it to our list of goals. > > Each definition in SMIv2/SPPI and SMIng has a status value associated > with it which is used for versioning. A definition can go from current > to deprected to obsolete. There are clear rules which changes are > allowed to an existing definitions which ensure forward/backward > compatibility. It basically boils down to require that a published > definition can not semantically change. If you need to make semantic > changes, you need to assign a new name. I guess such a strategy to > deal with versioning issues is needed for DIAMETER as well since I am > sure that some of the AVPs we define today will be recognized as > broken in a few years from now. > > Erik> I have been pushing for an adequate near term solution. The > Erik> data modelling 'solution' doesn't necessarily have to appear > Erik> before DIAMETER is standardized. > > My understanding of the requirements is that we want to use the formal > notation among other things to help to validate the specs. If free > form English text is the normative reference, then there is no benefit > from being able to validate the non-normative formal notation. In > other words, I want the AVPs and messages defined using the formal > notation itself, which implies that the formal notation is part of the > DIAMETER standard. > > >> David's proposal comes yet again from another different angle. Its > >> main background is the observation that AVP combinations that can > >> be meaningfully combined in a message are actually not well > >> defined. > > Erik> I do not know that this is a very big issue. If DIAMETER > Erik> command codes specify what MUST be there and how to interpret > Erik> it, other AVPs which are present should not prevent proper > Erik> interpretation of the command. > > Erik> We have been around this point a number of times - there are > Erik> good reasons to use the RADIUS approach as it is flexible: > Erik> Specify what is required, allow arbitrary ordering and > Erik> additional AVP message components. No one has argued for > Erik> removing this flexibility, though there has been discussion > Erik> about how this would facilitate a formal ABNF for the protocol. > > There are again two issues here. The first one is a protocol issue, > namely whether it is legal so ship additional AVPs with a message. > The second one is the question which set of AVPs actually consitute a > given message. Even the current specs use a kind of a BNF notation > trying to make that clear. But there are issues because the specs do > not really say what the semantics of the BNF notation are. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Tue Jan 9 14:21:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02586 for ; Tue, 9 Jan 2001 14:21:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B1B65E279; Tue, 9 Jan 2001 13:45:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 522235DF93; Tue, 9 Jan 2001 13:09:46 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id CCA535E289 for ; Tue, 9 Jan 2001 12:45:20 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 167564CE46; Tue, 9 Jan 2001 12:45:20 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id MAA14489; Tue, 9 Jan 2001 12:45:15 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id A33E035DC2; Tue, 9 Jan 2001 12:45:14 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Pat Calhoun Cc: Hal Lockhart , "'David Frascone'" , Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [diameter] Diameter correspondences. (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jan 2001 12:45:13 -0500 Message-Id: <20010109174514.A33E035DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message , Pat Calhoun writes : >> > And, if I had to pick an encryption algorithm now, it would be 3DES. >> >> Why not AES? >> >When will NIST offically release AES? I just posted an announcement from NIST about AESto the saag list; NIST says that the draft FIPS will be released "in the very near future". Monitor http://www.nist.gov/aes. --Steve Bellovin From owner-aaa-bof@merit.edu Tue Jan 9 15:23:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04290 for ; Tue, 9 Jan 2001 15:23:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 488275E0F0; Tue, 9 Jan 2001 14:55:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5FA4A5E1C0; Tue, 9 Jan 2001 14:26:19 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 337025E1C0 for ; Tue, 9 Jan 2001 13:52:19 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 93FBE4CE68 for ; Tue, 9 Jan 2001 13:52:15 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA15747 for ; Tue, 9 Jan 2001 13:52:15 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id B6D8635DC2 for ; Tue, 9 Jan 2001 13:52:14 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: aaa-wg@merit.edu Subject: Re: Normative references to AES Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jan 2001 13:52:14 -0500 Message-Id: <20010109185214.B6D8635DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk To follow up on what William Whyte has said, the draft NIST FIPS will be published very soon, followed by a statutory delay for comments before it is final. NIST has also announced a generalization of HMAC (http://www.nist.gov/hmac), work on a key management mechanism (http://www.nist.gov/kms), and will soon announce plans for new modes of operation (http://csrc.nist.gov/encryption/tkmodes.html, within a month). The new modes of operation are likely to be aimed at very high speed encryption (not a concern for AAA), though there may be an integrated encryption/authentication mode. --Steve Bellovin From owner-aaa-bof@merit.edu Tue Jan 9 20:10:01 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA08849 for ; Tue, 9 Jan 2001 20:10:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC9E35DF84; Tue, 9 Jan 2001 19:49:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CB2CE5DF85; Tue, 9 Jan 2001 19:31:12 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 03E225DEF2 for ; Tue, 9 Jan 2001 19:17:00 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 0496474; Tue, 9 Jan 2001 19:17:06 -0500 (EST) Message-ID: <3A5BAA1A.50A452C3@Interlinknetworks.com> Date: Tue, 09 Jan 2001 19:17:30 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu Subject: Re: Choice of Data Model SMI vs XML vs. UML References: <200101091323.OAA20320@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Juergen Schoenwaelder wrote: >... > >> David's proposal comes yet again from another different angle. Its > >> main background is the observation that AVP combinations that can > >> be meaningfully combined in a message are actually not well > >> defined. > > Erik> I do not know that this is a very big issue. If DIAMETER > Erik> command codes specify what MUST be there and how to interpret > Erik> it, other AVPs which are present should not prevent proper > Erik> interpretation of the command. > > Erik> We have been around this point a number of times - there are > Erik> good reasons to use the RADIUS approach as it is flexible: > Erik> Specify what is required, allow arbitrary ordering and > Erik> additional AVP message components. No one has argued for > Erik> removing this flexibility, though there has been discussion > Erik> about how this would facilitate a formal ABNF for the protocol. > > There are again two issues here. The first one is a protocol issue, > namely whether it is legal so ship additional AVPs with a message. > The second one is the question which set of AVPs actually consitute a > given message. Even the current specs use a kind of a BNF notation > trying to make that clear. But there are issues because the specs do > not really say what the semantics of the BNF notation are. >... It's actually worse than that. The presence of the BNF gives one the impression that the permissible contents of each message are specified. But the BNF is not complete. The BNF for both the AA-Request and AA-Answer messages in draft-calhoun-diameter-nasreq-05.txt contain the line: [] But the term is not expanded. The implication might be that any of the AVPs defined in section 6 would do. Section 6, however, is divided into subsections. Some of the subsections, such as section 6.2, "Framed Access Authorization AVPs", and section 6.3, "Non-Framed Access Authorization AVPs", can be inferred to be mutually exclusive, i.e., you would not expect to find an attribute defined in 6.2 and an attribute defined in 6.3 to appear in the same message. But the draft does not state that explicitly. Even if the draft were to state that explicitly, one might then assume that any of the attributes from section 6.2 could be meaningfully combined when providing a framed access service. What, then, would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs were included in the same message? My problem with the BNF is that it appears to specify permissible messages but does not. RADIUS, at least, does not make that pretension. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 9 20:25:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA09077 for ; Tue, 9 Jan 2001 20:25:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDB6B5DFBF; Tue, 9 Jan 2001 20:16:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D18C65E0E5; Tue, 9 Jan 2001 20:03:07 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F41855E16D for ; Tue, 9 Jan 2001 19:48:44 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 0C3D574; Tue, 9 Jan 2001 19:48:52 -0500 (EST) Message-ID: <3A5BB18A.F2877B39@Interlinknetworks.com> Date: Tue, 09 Jan 2001 19:49:14 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman Cc: Juergen Schoenwaelder , Pat.Calhoun@eng.sun.com, aaa-wg@merit.edu Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Erik Guttman wrote: >... > Why can't we standarize DIAMETER (its current informal spec) and later > model it with SMIng? If we find errors in the spec, we can cycle > it in the standards process. I think this would be a useful endeavor. > Once SMIng notation is standardized, we could begin this process of > rewriting the DIAMETER specification with the goal of improving it. >... Question: What if the SMIng model were more restrictive than the original DIAMETER standard? In other words, what if the SMIng model prohibited message contents that the pre-SMIng DIAMETER standard allowed (but were either nonsensical or at least ambiguous) -- like including the Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message? It would be good to avoid having to make incompatible changes like that. Would it make any sense to standardize part of DIAMETER now, like the base protocol and Mobile IP extensions, without data modeling, but delay standardizing the NASREQ extensions until the NASREQ data elements can be modeled? I'm thinking that with NASREQ, we have less time pressure (because of the existence of RADIUS), and so the successor to RADIUS should provide the best platform for future expansion that we can. It may be argued that the NASREQ application is simple enough that data modeling is unnecessary, but I fear that won't always be the case. You ought to be able to encompass more services in the future, such as DSL, broadband, and LAN access. Without data modeling, things are going to get really messy. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 9 22:43:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA12234 for ; Tue, 9 Jan 2001 22:43:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDEA85DD91; Tue, 9 Jan 2001 22:43:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C45345DE11; Tue, 9 Jan 2001 22:43:01 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B10ED5DD91 for ; Tue, 9 Jan 2001 22:43:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24911; Tue, 9 Jan 2001 19:42:56 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA12992; Tue, 9 Jan 2001 19:42:56 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA09224; Tue, 9 Jan 2001 18:53:57 -0800 (PST) Date: Tue, 9 Jan 2001 18:50:21 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Choice of Data Model SMI vs XML vs. UML To: David Spence Cc: Juergen Schoenwaelder , Erik.Guttman@germany.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A5BAA1A.50A452C3@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > What, then, > would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs > were included in the same message? My problem with the BNF is that it > appears to specify permissible messages but does not. RADIUS, at least, > does not make that pretension. I actually do not see why one cannot run both IPX and Appletalk over the same PPP connection. Am I missing something fundamental? In any case, I do agree (and I don't think that anyone has argued this) that the BNF needs to change. However, how drastic must the change be? This is a real question, because if one was to attempt to define all possible combinations, the RFC would be ungodly long (perhaps as an appendix it would be ok). PatC From owner-aaa-bof@merit.edu Tue Jan 9 23:30:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA13399 for ; Tue, 9 Jan 2001 23:30:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50ADE5DE48; Tue, 9 Jan 2001 23:29:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF6D15DF81; Tue, 9 Jan 2001 23:28:35 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id C339C5E1B4 for ; Tue, 9 Jan 2001 23:27:46 -0500 (EST) Received: from gwzpc ([10.64.194.1] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id UAA21758; Tue, 9 Jan 2001 20:26:58 -0800 (PST) Reply-To: From: "Glen Zorn" To: "David Spence" , "Erik Guttman" Cc: "Juergen Schoenwaelder" , , Subject: RE: Choice of Data Model SMI vs XML vs. UML Date: Tue, 9 Jan 2001 20:17:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A5BB18A.F2877B39@Interlinknetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk David Spence [mailto:DSpence@Interlinknetworks.com] writes: > Erik Guttman wrote: > >... > > Why can't we standarize DIAMETER (its current informal spec) and later > > model it with SMIng? If we find errors in the spec, we can cycle > > it in the standards process. I think this would be a useful endeavor. > > Once SMIng notation is standardized, we could begin this process of > > rewriting the DIAMETER specification with the goal of improving it. > >... > > Question: What if the SMIng model were more restrictive than the original > DIAMETER standard? In other words, what if the SMIng model prohibited > message contents that the pre-SMIng DIAMETER standard allowed (but were > either nonsensical or at least ambiguous) -- like including the > Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message? In this case, the model would be broken. AFAIK, it is neither nonsensical nor ambiguous to include both the Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message, since PPP can carry both (and IP, too!) simultaneously. > It would be good to avoid having to make incompatible changes like that. Since the history of SNMP is one of incompatible changes, I fail to see why anything should change now ;-) > > Would it make any sense to standardize part of DIAMETER now, like the base > protocol and Mobile IP extensions, without data modeling, but delay > standardizing the NASREQ extensions until the NASREQ data elements can be > modeled? I'm thinking that with NASREQ, we have less time > pressure (because > of the existence of RADIUS), The reason for the inception of this effort (some 4 years ago) was the inadequacy of RADIUS. I can't see how the situation has improved. > and so the successor to RADIUS should provide > the best platform for future expansion that we can. It may be argued that > the NASREQ application is simple enough that data modeling is unnecessary, > but I fear that won't always be the case. You ought to be able > to encompass > more services in the future, such as DSL, broadband, and LAN access. In the future? RADIUS (or bizarre, usually proprietary, variants thereof) is being used for these things (and more) right now. > Without data modeling, things are going to get really messy. They already have, some time ago. We _do not_ need to spend another three years blathering about silver bullets. > > -- > David Spence email: > DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > > From owner-aaa-bof@merit.edu Wed Jan 10 08:03:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA19394 for ; Wed, 10 Jan 2001 08:03:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 109DC5DDAC; Wed, 10 Jan 2001 08:00:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F01A25DDE8; Wed, 10 Jan 2001 08:00:20 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 43FBB5DDA6 for ; Wed, 10 Jan 2001 08:00:19 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04672; Wed, 10 Jan 2001 05:00:07 -0800 (PST) Received: from stag (d-ehdb03-142-95 [129.157.142.95]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id OAA23535; Wed, 10 Jan 2001 14:00:04 +0100 (MET) Message-ID: <00e201c07b04$8d162be0$5f8e9d81@stag.Germany.Sun.COM> From: "Erik Guttman" To: , "Randy Bush" Cc: "Erik Guttman" Subject: diameter grammar proposal Date: Wed, 10 Jan 2001 13:55:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk Folks, I propose the following section be added to the DIAMETER base spec. This will allow us to specify DIAMETER in a more formal way. This is unfortunately not as formal as a BNF would be, but DIAMETER messages allow for arbitrary ordering of many elements. Still, we need to be able to specify that some elements may appear only once, and some have to appear in fixed positions. I believe this grammar suffices to do this. Please send comments. (Randy, does this hold water?) Erik --------------------------------------------------------------------- 1.3 Notation The DIAMETER protocol is composed of messages which have three components - a message header, a command code and a set of AVPs. Each message type is distinguished by a single command code. Command are specified using the following notation. Command-Code-Name ::= { qual AVP } qual [ qual AVP ] qual < AVP > The symbol # will be replaced by the command Id which is to be placed in the message header. The symbol AVP MAY be replaced by the names of any specific AVP. Elements surrounded by less than, greater than '<' and '>' are FIXED in sequence. For example, the DIAMETER header MUST precede all AVPs. Elements surrounded by set brackets '{' and '}' are REQUIRED to be present in the message. They MAY be in any order within the message provided they do not violate order imposed by message fixed elements in the grammar (which are defined between '<' and '>' brackets.) Elements surrounded by square brackets '[' and ']' are OPTIONAL. AVPs which are listed in this section MAY be included in the message, in any order, provided they do not violate order imposed by fixed message elements in the grammar. AVPs listed in FIXED or REQUIRED sections MUST NOT be considered OPTIONAL as well. An AVP required to appear once in one section MUST NOT, therefor, be included as the result of an 'OPTIONAL AVP' rule. The token 'qual' can be the following: omitted One instance of the following entry is required. '*' Zero or more instances of the following entry are required. '+' One or more of instances of the following entry are required. '?' Zero or one of instances of the following entry are required. Example-Command ::= { User-Name *Host-Name } * [ AVP ] ? < Integrity-Check-Vector > The command defined by the preceding grammar MUST begin with a DIAMETER header, with the command code Id set to 9999999. There follows a User-Name AVP, zero or more Host-Name AVPs and zero or more arbitrary other AVPs (but not User-Name, Host-Name or Integrity-Check-Vector AVPs). The REQUIRED and OPTIONAL AVPs can be permuted into any order, provided that none of them come before the Header. DIAMETER messages which violate the grammar defined for the command code are considered malformed and are rejected. See Section 5.0. From owner-aaa-bof@merit.edu Wed Jan 10 08:16:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA19555 for ; Wed, 10 Jan 2001 08:16:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B4395DDA6; Wed, 10 Jan 2001 08:15:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2BA635DDD0; Wed, 10 Jan 2001 08:15:11 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D75765DDA6 for ; Wed, 10 Jan 2001 08:15:08 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14407; Wed, 10 Jan 2001 05:15:06 -0800 (PST) Received: from stag (d-ehdb03-142-95 [129.157.142.95]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id OAA22127; Wed, 10 Jan 2001 14:15:04 +0100 (MET) Message-ID: <011d01c07b06$a545a900$5f8e9d81@stag.Germany.Sun.COM> From: "Erik Guttman" To: , Subject: proposed new section for DIAMETER base specification Date: Wed, 10 Jan 2001 14:10:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk I am in the process of reworking the diameter specification according to proposals made in the AAA design team. I would like more feedback from implementors and working group participants about some of these changes, as they have received very little feedback. I believe we do not want to add requirements or change the protocol at this point unless there is strong support and a good reason for doing so. Please refer to draft-ietf-aaa-issues-04.txt, section 9.1 and draft-ietf-aaa-solutions-01.txt, section 9.1. The proposed changed text would define 3 flags for the diameter message header. ----------------------------------------------------------- Proposed change to section 2.1 Flags The Message Flags field is five bits, and is currently unused. This field MUST be initialized to zero. is replaced by -> The Message Flags field is five bits. The following bits are assigned: +---+---+---+---+---+ | z | z | E | I | R | +---+---+---+---+---+ 0x10 MUST be zero - this flag bit is reserved for future use. 0x08 MUST be zero - this flag bit is reserved for future use. 0x04 ('E' Expect Reply) The message solicits a response. 0x02 ('I' Interrogation) The message is a Query or a Reply. 0x01 ('R' Response) The message is a response another message. These flags are set depending on the command code used in a DIAMETER message. This enables the type of message to be interpreted, even if the specific command code is not recognized. Command Type Flags Set Indication - - - Request E - - Answer E - R Query E I - Reply E I R A DIAMETER node MUST NOT set these flags in any other combination. A DIAMETER node receiving a message in which these flags are not set appropriately SHOULD NOT reject the message for this reason, but MAY log the event for diagnosis. From owner-aaa-bof@merit.edu Wed Jan 10 09:24:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20680 for ; Wed, 10 Jan 2001 09:24:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6922D5DDEA; Wed, 10 Jan 2001 09:24:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57D265DDE8; Wed, 10 Jan 2001 09:24:06 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 46A785DDC4 for ; Wed, 10 Jan 2001 09:24:05 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25508; Wed, 10 Jan 2001 06:24:01 -0800 (PST) Received: from stag (d-ehdb03-142-95 [129.157.142.95]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id PAA11339; Wed, 10 Jan 2001 15:23:54 +0100 (MET) Message-ID: <012b01c07b10$4314be60$5f8e9d81@stag.Germany.Sun.COM> From: "Erik Guttman" To: , Subject: data type modifications to DIAMETER Date: Wed, 10 Jan 2001 15:18:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk As proposed in draft-ietf-aaa-issues-04.txt and draft-ietf-aaa-solutions-01.txt section 9.2, I am revising the basic data types in DIAMETER. I do not list all the changes in this document - but the implications are the following. 1. Data type changes: Old type New type ------------ ------------- Address Address Data OctetString String OctetString Time Unsigned32 Integer32 Integer32 Integer64 Integer64 Complex Grouped Unsigned32 Unsigned64 Float32 Float64 Float128 2. Scalar quantities (Ids and so on from AVPs) had Integer32 type. Now they have Unsigned32 type. 3. String is now one interpretation of an OctetString. 4. Time is now one interpretation of an Unsigned32 value. 5. The biggest change is the elimination of the 'Complex' data type. Now all AVPs have an 'atomic' data type except for Grouped. Grouped takes as its value a list of AVPs which have to be included (AVP header and all) in exactly the sequence specified. Implications for DIAMETER implementations: The only real change is that Complex data types have been restructured. Code handling AVPs which were previously of type Complex will have to change. Code which handled the previous types will be easily mapped into the new data types (Integer32 -> Unsigned32, Time -> Unsigned32, String -> OctetString) There are some subtle range checking changes to be made (maybe) since scalars are now Unsigned32 where before they were Integer32. Rationale: See draft-ietf-aaa-issues-04.txt. In short, there were several problems with the basic types used by DIAMETER. (1) Some were interpretations (String and Time) not basic scalars. (2) Some were ambiguous (Integer32 used as an unsigned scalar). (3) Not including basic types (floats, mostly) makes future expansion hard. (4) The types specified were incompatible with SMI and SPPI data types. (5) The complex data type made it hard to create a general data model, easily automated parsers and general 'sniffers.' All AVPs should either have atomic values or a list of AVPs as their values. (6) The Grouped-AVP was unnecessarily complex. (7) Complex data types required a 'hack' for fixing the length of certain data fields (such as using 16 bytes for addresses where they could be 4 bytes long). This is no longer necessary. Erik From owner-aaa-bof@merit.edu Wed Jan 10 09:50:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA21009 for ; Wed, 10 Jan 2001 09:50:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 940985DDC4; Wed, 10 Jan 2001 09:49:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F5FB5DE19; Wed, 10 Jan 2001 09:49:12 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 2E5FC5DDC4 for ; Wed, 10 Jan 2001 09:49:11 -0500 (EST) Received: (qmail 24525 invoked by uid 500); 10 Jan 2001 14:50:23 -0000 Date: Wed, 10 Jan 2001 08:50:23 -0600 From: David Frascone To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: DISCUSSION REQUESTED: ADIF, Batching, M bit Message-ID: <20010110085023.H23197@newman.frascone.com> Mail-Followup-To: Pat Calhoun , aaa-wg@merit.edu References: <002101c078f3$54d67220$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 09, 2001 at 08:14:27AM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk > > However, I think that specifying a recommended XML or SMI format for the > accounting file that is written on the server MAY be a desirable goal. > Good idea! That way, the transport model is still clean, and we can also specify an XML model for the accounting records. I think this is the best of both worlds. -Dave From owner-aaa-bof@merit.edu Wed Jan 10 10:33:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21921 for ; Wed, 10 Jan 2001 10:33:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BFA85DDF3; Wed, 10 Jan 2001 10:30:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 76EE05DDF6; Wed, 10 Jan 2001 10:30:26 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 1BB605DDF3 for ; Wed, 10 Jan 2001 10:30:24 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28054; Wed, 10 Jan 2001 07:30:22 -0800 (PST) Received: from stag (d-ehdb03-142-95 [129.157.142.95]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id QAA19223; Wed, 10 Jan 2001 16:30:20 +0100 (MET) Message-ID: <015d01c07b19$8aa8efe0$5f8e9d81@stag.Germany.Sun.COM> From: "Erik Guttman" To: "David Frascone" , Cc: "Erik Guttman" Subject: Fw: diameter grammar proposal Date: Wed, 10 Jan 2001 16:25:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aaa-bof@merit.edu Precedence: bulk Dave, >My problem is: If you list all of the "optional" AVPs, then it seems like >if an AVP is received that is not on the "optional" list, it is an error. I >think listing optional AVPs is problematic. My solution to this problem is to allow the token 'AVP' to stand for *any* AVP. In the example: >> Example-Command ::= >> { User-Name *Host-Name } >> * [ AVP ] >> ? < Integrity-Check-Vector > >> >> The command defined by the preceding grammar MUST begin with a >> DIAMETER header, with the command code Id set to 9999999. There >> follows a User-Name AVP, zero or more Host-Name AVPs and zero or >> more arbitrary other AVPs (but not User-Name, Host-Name or >> Integrity-Check-Vector AVPs). Here 'AVP' could be anything (vendor specified or otherwise) BUT the requirement is that the optional AVP rule cannot include AVPs otherwise specified in REQUIRED or FIXED fields. That allows you to write rules for AVPs which can only occur once, or have to occur in a particular sequence. Erik From owner-aaa-bof@merit.edu Wed Jan 10 11:28:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA22726 for ; Wed, 10 Jan 2001 11:28:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E866E5DDF6; Wed, 10 Jan 2001 11:27:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C58CF5DDF0; Wed, 10 Jan 2001 11:27:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 152B65DDF6 for ; Wed, 10 Jan 2001 11:27:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08559; Wed, 10 Jan 2001 08:27:55 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22942; Wed, 10 Jan 2001 08:27:53 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA22696; Wed, 10 Jan 2001 08:16:28 -0800 (PST) Date: Wed, 10 Jan 2001 08:12:51 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Proposed change to DIAMETER header To: diameter@diameter.org, aaa-wg@merit.edu Cc: Pat.Calhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The method the protocol is currently specified, it requires that an implementation walk through each AVP, looking for the ICV AVP in order to perform the necessary replay and authentication checks. What this means is that there is a significant amount of work required to ensure that the packet is in fact authentic. This does not bode well for denial of service attacks. So I would like to propose adding the ICV-Offset to the DIAMETER header, as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RADIUS PCC=254 | Flags | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICV-Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- [...] [ed: and something like (actual words will change):] ICV-Offset The ICV-Offset contains the number of octets from the start of the DIAMETER header where the ICV AVP can be found. When the ICV is computed, this field MUST be set to zero. If no ICV was added to the packet, the value of the ICV-Offset field MUST be zero. The above change makes it MUCH easier for implementations to authenticate the packet before parsing through all AVPs in the message. Do people think this is a worthwhile change? I believe this will make the protocol less prone to denial of service attacks. Thanks, PatC From owner-aaa-bof@merit.edu Wed Jan 10 11:28:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA22732 for ; Wed, 10 Jan 2001 11:28:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id A10005DE19; Wed, 10 Jan 2001 11:27:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E4175DE05; Wed, 10 Jan 2001 11:27:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A32C65DDF0 for ; Wed, 10 Jan 2001 11:27:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08558 for ; Wed, 10 Jan 2001 08:27:54 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22946 for ; Wed, 10 Jan 2001 08:27:54 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA22447 for ; Wed, 10 Jan 2001 08:05:43 -0800 (PST) Date: Wed, 10 Jan 2001 08:02:07 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: test To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I think I've been dropped from the list, this is a test. PatC From owner-aaa-bof@merit.edu Wed Jan 10 11:29:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA22747 for ; Wed, 10 Jan 2001 11:29:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66EB05DDF0; Wed, 10 Jan 2001 11:28:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 729555DE04; Wed, 10 Jan 2001 11:28:02 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 16F9D5DE33 for ; Wed, 10 Jan 2001 11:27:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06943 for ; Wed, 10 Jan 2001 08:27:57 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22957; Wed, 10 Jan 2001 08:27:56 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21891; Wed, 10 Jan 2001 07:36:51 -0800 (PST) Date: Wed, 10 Jan 2001 07:33:15 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: diameter grammar proposal To: Erik Guttman Cc: pat.calhoun@eng.sun.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <014a01c07b15$d64d6560$5f8e9d81@stag.Germany.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk >I propose the following section be added to the DIAMETER base spec. >This will allow us to specify DIAMETER in a more formal way. This is >unfortunately not as formal as a BNF would be, but DIAMETER messages >allow for arbitrary ordering of many elements. Still, we need to >be able to specify that some elements may appear only once, and some >have to appear in fixed positions. I believe this grammar suffices >to do this. Please send comments. Here are my two cents. I actually really like Erik's proposal. For the most part, the dictionary and how messages are defined in the protocol specs are two separate issues, and I am not sure why we've decided to combine the two. The proposal below is much richer than today's spec, since it allows DIAMETER to defined the message set, while providing information on the number of AVPs that may (or MUST) be present in the message. This type of information is present in RADIUS, and is really lacking in DIAMETER. So here is my proposal. Come out with draft-ietf-aaa-diameter-*00.txt as a WG work item, with the proposed grammar below. Have the WG work out the details of data model, and consider whether the message definition in the specs must follow the accepted grammar. If need be, updated the spoecs as *01.txt. The reason why I want this done is that there is a bakeoff coming up in 1.5 months, and some of us really want specs to write against. As you know, the grammar used does not affect the on-the-wire protocol, so this does not affect the bakeoff. Comments? PatC > >(Randy, does this hold water?) > >Erik >--------------------------------------------------------------------- > >1.3 Notation > > The DIAMETER protocol is composed of messages which have three > components - a message header, a command code and a set of AVPs. > Each message type is distinguished by a single command code. > Command are specified using the following notation. > > Command-Code-Name ::= > { qual AVP } > qual [ qual AVP ] > qual < AVP > > > The symbol # will be replaced by the command Id which is to be > placed in the message header. The symbol AVP MAY be replaced > by the names of any specific AVP. > > Elements surrounded by less than, greater than '<' and '>' are > FIXED in sequence. For example, the DIAMETER header MUST > precede all AVPs. > > Elements surrounded by set brackets '{' and '}' are REQUIRED > to be present in the message. They MAY be in any order within > the message provided they do not violate order imposed by message > fixed elements in the grammar (which are defined between '<' > and '>' brackets.) > > Elements surrounded by square brackets '[' and ']' are OPTIONAL. > AVPs which are listed in this section MAY be included in the > message, in any order, provided they do not violate order imposed > by fixed message elements in the grammar. AVPs listed in FIXED > or REQUIRED sections MUST NOT be considered OPTIONAL as well. > An AVP required to appear once in one section MUST NOT, therefor, > be included as the result of an 'OPTIONAL AVP' rule. > > The token 'qual' can be the following: > > omitted One instance of the following entry is required. > '*' Zero or more instances of the following entry are > required. > '+' One or more of instances of the following entry > are required. > '?' Zero or one of instances of the following entry > are required. > > Example-Command ::= > { User-Name *Host-Name } > * [ AVP ] > ? < Integrity-Check-Vector > > > The command defined by the preceding grammar MUST begin with a > DIAMETER header, with the command code Id set to 9999999. There > follows a User-Name AVP, zero or more Host-Name AVPs and zero or > more arbitrary other AVPs (but not User-Name, Host-Name or > Integrity-Check-Vector AVPs). The REQUIRED and OPTIONAL AVPs > can be permuted into any order, provided that none of them come > before the Header. > > DIAMETER messages which violate the grammar defined for the > command code are considered malformed and are rejected. See > Section 5.0. From owner-aaa-bof@merit.edu Wed Jan 10 11:48:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23025 for ; Wed, 10 Jan 2001 11:48:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 817C55DE03; Wed, 10 Jan 2001 11:45:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6B1465DE1D; Wed, 10 Jan 2001 11:45:39 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2776D5DE03 for ; Wed, 10 Jan 2001 11:45:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19440; Wed, 10 Jan 2001 08:45:37 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA26813; Wed, 10 Jan 2001 08:45:37 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA23376; Wed, 10 Jan 2001 08:45:35 -0800 (PST) Date: Wed, 10 Jan 2001 08:41:58 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Section 2.2.5 To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Does anyone see why section 2.2.5 (tandard DIAMETER Extension AVPs)needs to be in the base protocol? It is problematic, since if some of the extensions do not go through IESG at the same time, the base protocol *could* become obsolete. Anyone object to my removing it? PatC From owner-aaa-bof@merit.edu Wed Jan 10 12:42:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23886 for ; Wed, 10 Jan 2001 12:42:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id A63815DE0A; Wed, 10 Jan 2001 12:42:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 967555DE04; Wed, 10 Jan 2001 12:42:35 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BCB495DDFD for ; Wed, 10 Jan 2001 12:42:34 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id C14E073; Wed, 10 Jan 2001 12:42:41 -0500 (EST) Message-ID: <3A5C9F2B.5A969021@Interlinknetworks.com> Date: Wed, 10 Jan 2001 12:43:07 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Juergen Schoenwaelder , Erik.Guttman@germany.sun.com, aaa-wg@merit.edu Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat Calhoun wrote: > > > What, then, > > would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs > > were included in the same message? My problem with the BNF is that it > > appears to specify permissible messages but does not. RADIUS, at least, > > does not make that pretension. > > I actually do not see why one cannot run both IPX and Appletalk over the same > PPP connection. Am I missing something fundamental? >... Well, of course, you're right. But in some ways it underlines the problem, namely, that there isn't any model that says one way or the other. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed Jan 10 12:56:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24209 for ; Wed, 10 Jan 2001 12:56:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 016125DE29; Wed, 10 Jan 2001 12:56:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF0FF5DE51; Wed, 10 Jan 2001 12:56:11 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 0F4015DE29 for ; Wed, 10 Jan 2001 12:56:11 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id B9C3A73; Wed, 10 Jan 2001 12:56:17 -0500 (EST) Message-ID: <3A5CA25B.97E37802@Interlinknetworks.com> Date: Wed, 10 Jan 2001 12:56:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: Erik Guttman , Juergen Schoenwaelder , Pat.Calhoun@eng.sun.com, aaa-wg@merit.edu Subject: Re: Choice of Data Model SMI vs XML vs. UML References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Glen Zorn wrote: >... > > and so the successor to RADIUS should provide > > the best platform for future expansion that we can. It may be argued that > > the NASREQ application is simple enough that data modeling is unnecessary, > > but I fear that won't always be the case. You ought to be able > > to encompass > > more services in the future, such as DSL, broadband, and LAN access. > > In the future? RADIUS (or bizarre, usually proprietary, variants thereof) > is being used for these things (and more) right now. Precisely! But not in a standard way. And while it isn't in our charter to standardize those things now, we are creating the framework within which future standardization will proceed. The point was that the supposed simplicity of RADIUS cannot be used as an argument that data modeling is not necessary. > > > Without data modeling, things are going to get really messy. > > They already have, some time ago. We _do not_ need to spend another three > years blathering about silver bullets. Agreed. >... -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed Jan 10 12:57:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24251 for ; Wed, 10 Jan 2001 12:57:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2279A5DE5B; Wed, 10 Jan 2001 12:57:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 108C95DE51; Wed, 10 Jan 2001 12:57:35 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id 8BBB85DE16 for ; Wed, 10 Jan 2001 12:57:33 -0500 (EST) Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA07513; Wed, 10 Jan 2001 18:58:30 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" , , Subject: RE: Section 2.2.5 Date: Wed, 10 Jan 2001 18:59:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree, remove it or perhaps leave something like. 2.2.5 Additional DIAMETER Extension AVPs Additional AVPs may be defined in other DIAMETER Extensions. These may be Extension specific or may add some additional feature to the DIAMETER protocol as a whole. However these are not mandatory for the proper hanling of the base protocol. For more information see respective DIAMETER Extension document. /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 10 januari 2001 17:42 >To: aaa-wg@merit.edu; diameter@diameter.org >Subject: Section 2.2.5 > > >Does anyone see why section 2.2.5 (tandard DIAMETER Extension >AVPs)needs to be >in the base protocol? It is problematic, since if some of the extensions do >not go through IESG at the same time, the base protocol *could* become >obsolete. > >Anyone object to my removing it? > >PatC > From owner-aaa-bof@merit.edu Wed Jan 10 13:04:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24482 for ; Wed, 10 Jan 2001 13:04:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D9755DE1A; Wed, 10 Jan 2001 13:01:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 39E525DE16; Wed, 10 Jan 2001 13:01:41 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 157055DE1A for ; Wed, 10 Jan 2001 13:01:39 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA07632; Wed, 10 Jan 2001 13:01:06 -0500 (EST) Date: Wed, 10 Jan 2001 13:01:06 -0500 (EST) From: Mark Eklund To: Erik Guttman Cc: aaa-wg@merit.edu, Randy Bush Subject: Re: diameter grammar proposal In-Reply-To: <00e201c07b04$8d162be0$5f8e9d81@stag.Germany.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk A few questions/comments. 1. I am used to seeing qualifiers after the argument like in regular expressions. For example Host-Name* instead of *Host-Name. This is a personal preference. 2. Why do you need the optional brackets [] when you have the '*' and '?' operators. I.E. what is the difference in *[Host-Name] and *Host-Name? 3. Do you plan to define Grouped-AVP in the specifications? -mark On Wed, 10 Jan 2001, Erik Guttman wrote: > > > Folks, > > I propose the following section be added to the DIAMETER base spec. > This will allow us to specify DIAMETER in a more formal way. This is > unfortunately not as formal as a BNF would be, but DIAMETER messages > allow for arbitrary ordering of many elements. Still, we need to > be able to specify that some elements may appear only once, and some > have to appear in fixed positions. I believe this grammar suffices > to do this. Please send comments. > > (Randy, does this hold water?) > > Erik > --------------------------------------------------------------------- > > 1.3 Notation > > The DIAMETER protocol is composed of messages which have three > components - a message header, a command code and a set of AVPs. > Each message type is distinguished by a single command code. > Command are specified using the following notation. > > Command-Code-Name ::= > { qual AVP } > qual [ qual AVP ] > qual < AVP > > > The symbol # will be replaced by the command Id which is to be > placed in the message header. The symbol AVP MAY be replaced > by the names of any specific AVP. > > Elements surrounded by less than, greater than '<' and '>' are > FIXED in sequence. For example, the DIAMETER header MUST > precede all AVPs. > > Elements surrounded by set brackets '{' and '}' are REQUIRED > to be present in the message. They MAY be in any order within > the message provided they do not violate order imposed by message > fixed elements in the grammar (which are defined between '<' > and '>' brackets.) > > Elements surrounded by square brackets '[' and ']' are OPTIONAL. > AVPs which are listed in this section MAY be included in the > message, in any order, provided they do not violate order imposed > by fixed message elements in the grammar. AVPs listed in FIXED > or REQUIRED sections MUST NOT be considered OPTIONAL as well. > An AVP required to appear once in one section MUST NOT, therefor, > be included as the result of an 'OPTIONAL AVP' rule. > > The token 'qual' can be the following: > > omitted One instance of the following entry is required. > '*' Zero or more instances of the following entry are > required. > '+' One or more of instances of the following entry > are required. > '?' Zero or one of instances of the following entry > are required. > > Example-Command ::= > { User-Name *Host-Name } > * [ AVP ] > ? < Integrity-Check-Vector > > > The command defined by the preceding grammar MUST begin with a > DIAMETER header, with the command code Id set to 9999999. There > follows a User-Name AVP, zero or more Host-Name AVPs and zero or > more arbitrary other AVPs (but not User-Name, Host-Name or > Integrity-Check-Vector AVPs). The REQUIRED and OPTIONAL AVPs > can be permuted into any order, provided that none of them come > before the Header. > > DIAMETER messages which violate the grammar defined for the > command code are considered malformed and are rejected. See > Section 5.0. > > > > > > From owner-aaa-bof@merit.edu Wed Jan 10 13:08:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24565 for ; Wed, 10 Jan 2001 13:08:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A19595DE04; Wed, 10 Jan 2001 13:08:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8FBEC5DDFD; Wed, 10 Jan 2001 13:08:12 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 3CA995DDA5 for ; Wed, 10 Jan 2001 13:08:11 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0AI88K09847; Wed, 10 Jan 2001 12:08:08 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0AI4jC25355; Wed, 10 Jan 2001 12:04:45 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA20579; Wed, 10 Jan 2001 12:08:07 -0600 (CST) Received: from kev (busam66.berkeley.us.am.ericsson.se [138.85.159.216]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id MAA07119; Wed, 10 Jan 2001 12:08:04 -0600 (CST) Message-ID: <002501c07b30$452d0980$91aea8c0@erilab.com> From: "Kevin Purser" To: "Erik Guttman" , , References: <011d01c07b06$a545a900$5f8e9d81@stag.Germany.Sun.COM> Subject: Re: proposed new section for DIAMETER base specification Date: Wed, 10 Jan 2001 10:07:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Erik/All, Just a quick comment... (inline) > > 0x10 MUST be zero - this flag bit is reserved for future use. > 0x08 MUST be zero - this flag bit is reserved for future use. > 0x04 ('E' Expect Reply) The message solicits a response. > 0x02 ('I' Interrogation) The message is a Query or a Reply. > 0x01 ('R' Response) The message is a response another message. > > These flags are set depending on the command code used in a > DIAMETER message. This enables the type of message to be > interpreted, even if the specific command code is not recognized. > > Command Type Flags Set > Indication - - - > Request E - - > Answer E - R > Query E I - > Reply E I R > It seems a bit odd to set the "Expect Reply" bit in a Reply message, and probably an Answer message as well, since neither of which directly solicit a Reply. > A DIAMETER node MUST NOT set these flags in any other combination. > A DIAMETER node receiving a message in which these flags are not > set appropriately SHOULD NOT reject the message for this reason, > but MAY log the event for diagnosis. > > > From owner-aaa-bof@merit.edu Wed Jan 10 13:56:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA25501 for ; Wed, 10 Jan 2001 13:56:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id D32F95DE11; Wed, 10 Jan 2001 13:56:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C3A615DE00; Wed, 10 Jan 2001 13:56:07 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id ACE3C5DDFF for ; Wed, 10 Jan 2001 13:56:06 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA08397; Wed, 10 Jan 2001 14:51:56 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA15824; Wed, 10 Jan 2001 13:56:24 -0500 (EST) From: "Mark Jones" To: "Erik Guttman" , Subject: RE: diameter grammar proposal Date: Wed, 10 Jan 2001 14:03:05 -0500 Message-ID: <008a01c07b37$f6836d80$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <00e201c07b04$8d162be0$5f8e9d81@stag.Germany.Sun.COM> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Erik, Aren't the {} and [] brackets redundant given the 'qual' token definitions? i.e. '*' = Zero or more instances MAY be present in the packet = OPTIONAL AVP '+' = At least one instance MUST be present in the packet = MANDATORY AVP '?' = Zero or one instances MAY be present in the packet = OPTIONAL AVP omitted = Exactly one instance MUST be present in the packet = MANDATORY AVP Regards, Mark > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Erik Guttman > Sent: January 10, 2001 7:55 AM > To: aaa-wg@merit.edu; Randy Bush > Cc: Erik Guttman > Subject: diameter grammar proposal > > > > > Folks, > > I propose the following section be added to the DIAMETER base spec. > This will allow us to specify DIAMETER in a more formal way. This is > unfortunately not as formal as a BNF would be, but DIAMETER messages > allow for arbitrary ordering of many elements. Still, we need to > be able to specify that some elements may appear only once, and some > have to appear in fixed positions. I believe this grammar suffices > to do this. Please send comments. > > (Randy, does this hold water?) > > Erik > --------------------------------------------------------------------- > > 1.3 Notation > > The DIAMETER protocol is composed of messages which have three > components - a message header, a command code and a set of AVPs. > Each message type is distinguished by a single command code. > Command are specified using the following notation. > > Command-Code-Name ::= > { qual AVP } > qual [ qual AVP ] > qual < AVP > > > The symbol # will be replaced by the command Id which is to be > placed in the message header. The symbol AVP MAY be replaced > by the names of any specific AVP. > > Elements surrounded by less than, greater than '<' and '>' are > FIXED in sequence. For example, the DIAMETER header MUST > precede all AVPs. > > Elements surrounded by set brackets '{' and '}' are REQUIRED > to be present in the message. They MAY be in any order within > the message provided they do not violate order imposed by message > fixed elements in the grammar (which are defined between '<' > and '>' brackets.) > > Elements surrounded by square brackets '[' and ']' are OPTIONAL. > AVPs which are listed in this section MAY be included in the > message, in any order, provided they do not violate order imposed > by fixed message elements in the grammar. AVPs listed in FIXED > or REQUIRED sections MUST NOT be considered OPTIONAL as well. > An AVP required to appear once in one section MUST NOT, therefor, > be included as the result of an 'OPTIONAL AVP' rule. > > The token 'qual' can be the following: > > omitted One instance of the following entry is required. > '*' Zero or more instances of the following entry are > required. > '+' One or more of instances of the following entry > are required. > '?' Zero or one of instances of the following entry > are required. > > Example-Command ::= > { User-Name *Host-Name } > * [ AVP ] > ? < Integrity-Check-Vector > > > The command defined by the preceding grammar MUST begin with a > DIAMETER header, with the command code Id set to 9999999. There > follows a User-Name AVP, zero or more Host-Name AVPs and zero or > more arbitrary other AVPs (but not User-Name, Host-Name or > Integrity-Check-Vector AVPs). The REQUIRED and OPTIONAL AVPs > can be permuted into any order, provided that none of them come > before the Header. > > DIAMETER messages which violate the grammar defined for the > command code are considered malformed and are rejected. See > Section 5.0. > > > > > > From owner-aaa-bof@merit.edu Wed Jan 10 16:35:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28958 for ; Wed, 10 Jan 2001 16:35:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D299E5DE24; Wed, 10 Jan 2001 16:34:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C116B5DE05; Wed, 10 Jan 2001 16:34:16 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id F084A5DDFF for ; Wed, 10 Jan 2001 16:34:14 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA09668; Wed, 10 Jan 2001 17:29:39 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA19531; Wed, 10 Jan 2001 16:34:08 -0500 (EST) From: "Mark Jones" To: , Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Wed, 10 Jan 2001 16:40:48 -0500 Message-ID: <008f01c07b4d$ff21d740$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk In DIAMETER, the IPv4 and IPv6 addresses are collapsed into the single Address datatype where the actual IP version is determined from the length. The RADIUS and IPv6 draft (draft-aboba-radius-ipv6-04.txt) appears to take a different approach by using separate AVPs for IPv4 and IPv6 addresses, e.g. Login-IP-Host and Login-IPv6-Host. I was considering whether the DIAMETER approach could also applied in RADIUSv6 since a common approach would simplify the RADIUS-DIAMETER gateway implementation. The RADIUSv6 draft does state that IPv4 and IPv6 attributes MAY be included in the same RADIUS message and the NAS will decide which attributes to use. However, I see no reason why a DIAMETER or RADIUS packet could not contain two instances of the same address AVP: one IPv4 and one IPv6 address. The NAS could still use the same logic to decide which attributes to use for the session. Are there any other issues that would prevent a common approach? Regards, Mark > -----Original Message----- > From: owner-diameter@diameter.org [mailto:owner-diameter@diameter.org]On > Behalf Of Pat Calhoun > Sent: January 10, 2001 9:44 AM > To: diameter@diameter.org > Subject: [diameter] data type modifications to DIAMETER (Fwd) > > > FYI > >----------------Begin Forwarded Message----------------< > > Date: Wed, 10 Jan 2001 15:18:52 +0100 > From: "Erik Guttman" > Subject: data type modifications to DIAMETER > To: diameter@diameter.org, aaa-wg@merit.edu > > > As proposed in draft-ietf-aaa-issues-04.txt and > draft-ietf-aaa-solutions-01.txt section 9.2, I am > revising the basic data types in DIAMETER. > > I do not list all the changes in this document - > but the implications are the following. > > 1. Data type changes: > > Old type New type > ------------ ------------- > Address Address > Data OctetString > String OctetString > Time Unsigned32 > Integer32 Integer32 > Integer64 Integer64 > Complex Grouped > Unsigned32 > Unsigned64 > Float32 > Float64 > Float128 > > 2. Scalar quantities (Ids and so on from AVPs) had Integer32 type. > Now they have Unsigned32 type. > > 3. String is now one interpretation of an OctetString. > > 4. Time is now one interpretation of an Unsigned32 value. > > 5. The biggest change is the elimination of the 'Complex' data > type. Now all AVPs have an 'atomic' data type except for > Grouped. Grouped takes as its value a list of AVPs which > have to be included (AVP header and all) in exactly the > sequence specified. > > Implications for DIAMETER implementations: > > The only real change is that Complex data types have been > restructured. Code handling AVPs which were previously of > type Complex will have to change. > > Code which handled the previous types will be easily mapped > into the new data types (Integer32 -> Unsigned32, Time -> > Unsigned32, String -> OctetString) There are some subtle > range checking changes to be made (maybe) since scalars are now > Unsigned32 where before they were Integer32. > > Rationale: > > See draft-ietf-aaa-issues-04.txt. In short, there were several > problems with the basic types used by DIAMETER. (1) Some were > interpretations (String and Time) not basic scalars. (2) Some > were ambiguous (Integer32 used as an unsigned scalar). (3) Not > including basic types (floats, mostly) makes future expansion > hard. (4) The types specified were incompatible with SMI and > SPPI data types. (5) The complex data type made it hard to > create a general data model, easily automated parsers and > general 'sniffers.' All AVPs should either have atomic values > or a list of AVPs as their values. (6) The Grouped-AVP was > unnecessarily complex. (7) Complex data types required a 'hack' > for fixing the length of certain data fields (such as using 16 > bytes for addresses where they could be 4 bytes long). This is > no longer necessary. > > Erik > > > > >----------------End Forwarded Message----------------< > > From owner-aaa-bof@merit.edu Wed Jan 10 16:39:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA29817 for ; Wed, 10 Jan 2001 16:39:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6BA45DE14; Wed, 10 Jan 2001 16:39:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A5DE85DE05; Wed, 10 Jan 2001 16:39:06 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 580D85DDFF for ; Wed, 10 Jan 2001 16:39:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25339; Wed, 10 Jan 2001 13:38:58 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA22011; Wed, 10 Jan 2001 13:38:57 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA00826; Wed, 10 Jan 2001 13:38:55 -0800 (PST) Date: Wed, 10 Jan 2001 13:35:19 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) To: Mark Jones Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <008f01c07b4d$ff21d740$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I think that the orignal intent of having a dual purpose AVP was to reduce the number of AVPs that would have to be defined. Furthermore, the Implementation Guidelines, which describes the protocol gateway stuff, would have to include text that describes what to do if an IPv4 was found, as opposed to an IPv6 address. Are there any others that have any concerns with the dual purpose AVP approach? PatC From owner-aaa-bof@merit.edu Wed Jan 10 16:55:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA03070 for ; Wed, 10 Jan 2001 16:55:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2B665DE1C; Wed, 10 Jan 2001 16:54:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 84DD45DE16; Wed, 10 Jan 2001 16:54:44 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BD2E15DE05 for ; Wed, 10 Jan 2001 16:54:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27484; Wed, 10 Jan 2001 13:54:40 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA27098; Wed, 10 Jan 2001 13:54:37 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA01183; Wed, 10 Jan 2001 13:54:35 -0800 (PST) Date: Wed, 10 Jan 2001 13:50:59 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: proposed new section for DIAMETER base specification To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > It seems a bit odd to set the "Expect Reply" bit in a Reply message, and > probably an Answer message as well, since neither of which directly solicit > a Reply. Agreed, and the text would actually look like: ---- [...] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RADIUS PCC=254 |r r E I R| Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [...] Flags The Message Flags field is five bits. The following bits are assigned: r(eserved) MUST be zero - this flag bit is reserved for future use. E(xpected Reply) - The message solicits a response. I(nterrogation) - The message is a Query or a Reply. R(esponse) - The message is a response another message. These flags are set depending on the command code used in a DIAMETER message. This enables the type of message to be interpreted, even if the specific command code is not recognized. Command Type Flags Set Indication - - - Request E - - Answer - - R Query E I - Reply - I R A DIAMETER node MUST NOT set these flags in any other combination. A DIAMETER node receiving a message in which these flags are not set appropriately SHOULD NOT reject the message for this reason, but MAY log the event for diagnosis. ---- Any objections? This text was in the solutions I-D (or similar text), and no objections were received. Further, I think that this information is VERY important for proxies, since they need to know when a message is a request or a response (especially important when they do not support the extension, but still wish to route the message). Of course, there is also the question of removing the PCC or not. PatC From owner-aaa-bof@merit.edu Wed Jan 10 16:55:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA03080 for ; Wed, 10 Jan 2001 16:55:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id C3DA65DDFF; Wed, 10 Jan 2001 16:54:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 89A665DE2F; Wed, 10 Jan 2001 16:54:46 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 3BC6E5DDFF for ; Wed, 10 Jan 2001 16:54:42 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA09797; Wed, 10 Jan 2001 17:50:14 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA19930; Wed, 10 Jan 2001 16:54:43 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: , Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Wed, 10 Jan 2001 17:01:24 -0500 Message-ID: <009201c07b50$df796950$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, I understand the rationale of the dual purpose AVP and have no concerns about its use in DIAMETER. I was just suggesting that we consider using the same approach in RADIUSv6 to simplify the gateway implementation. Regards, Mark > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Pat Calhoun > Sent: January 10, 2001 4:35 PM > To: Mark Jones > Cc: aaa-wg@merit.edu; diameter@diameter.org > Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) > > > I think that the orignal intent of having a dual purpose AVP was > to reduce the > number of AVPs that would have to be defined. Furthermore, the > Implementation > Guidelines, which describes the protocol gateway stuff, would > have to include > text that describes what to do if an IPv4 was found, as opposed to an IPv6 > address. > > Are there any others that have any concerns with the dual purpose > AVP approach? > PatC > > > From owner-aaa-bof@merit.edu Wed Jan 10 16:57:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA03156 for ; Wed, 10 Jan 2001 16:57:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9A815DE1D; Wed, 10 Jan 2001 16:57:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C83085DE16; Wed, 10 Jan 2001 16:57:06 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7DE725DE05 for ; Wed, 10 Jan 2001 16:57:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28407; Wed, 10 Jan 2001 13:56:53 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA27801; Wed, 10 Jan 2001 13:56:48 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA01237; Wed, 10 Jan 2001 13:56:46 -0800 (PST) Date: Wed, 10 Jan 2001 13:53:08 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <009201c07b50$df796950$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Oh, I see. You were questioning whether RADIUSv6 should change. That may be harder to do, unless these new attributes have a new type, perhaps Dual-Address, instead of Address. PatC > Pat, > > I understand the rationale of the dual purpose AVP and have no concerns > about its use in DIAMETER. I was just suggesting that we consider using the > same approach in RADIUSv6 to simplify the gateway implementation. > > Regards, > Mark > > > -----Original Message----- > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > Of Pat Calhoun > > Sent: January 10, 2001 4:35 PM > > To: Mark Jones > > Cc: aaa-wg@merit.edu; diameter@diameter.org > > Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) > > > > > > I think that the orignal intent of having a dual purpose AVP was > > to reduce the > > number of AVPs that would have to be defined. Furthermore, the > > Implementation > > Guidelines, which describes the protocol gateway stuff, would > > have to include > > text that describes what to do if an IPv4 was found, as opposed to an IPv6 > > address. > > > > Are there any others that have any concerns with the dual purpose > > AVP approach? > > PatC > > > > > > > From owner-aaa-bof@merit.edu Wed Jan 10 17:04:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA03323 for ; Wed, 10 Jan 2001 17:04:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id E61575DEA1; Wed, 10 Jan 2001 17:03:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D44145DE9E; Wed, 10 Jan 2001 17:03:33 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 8A2C85DE47 for ; Wed, 10 Jan 2001 17:03:32 -0500 (EST) Received: (qmail 27395 invoked by uid 500); 10 Jan 2001 22:04:49 -0000 Date: Wed, 10 Jan 2001 16:04:49 -0600 From: David Frascone To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: proposed new section for DIAMETER base specification Message-ID: <20010110160449.H26737@newman.frascone.com> Mail-Followup-To: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Wed, Jan 10, 2001 at 01:50:59PM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I don't see any need for the PCC now that Diameter is *not* running over UDP. > Of course, there is also the question of removing the PCC or not. From owner-aaa-bof@merit.edu Wed Jan 10 18:18:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA04260 for ; Wed, 10 Jan 2001 18:18:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 262025DDE6; Wed, 10 Jan 2001 18:16:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 11D525DE25; Wed, 10 Jan 2001 18:16:17 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 4647D5DDE6 for ; Wed, 10 Jan 2001 18:16:15 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA10357; Wed, 10 Jan 2001 19:12:02 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA01579; Wed, 10 Jan 2001 18:16:31 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: , Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Wed, 10 Jan 2001 18:23:12 -0500 Message-ID: <009901c07b5c$4cc5e820$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > Oh, I see. You were questioning whether RADIUSv6 should change. > That may be harder to do, unless these new attributes have a new type, > perhaps Dual-Address, instead of Address. > Would new RADIUS attributes for IPv6 addresses still be required if RADIUSv6 were to adopt the dual purpose AVP approach? If, as suggested by the RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6 AVPs, the NAS can still distinguish the IPv4/IPv6 addresses by their length and so can choose the appropriate instance of the address AVP depending on whether its client is IPv4 or IPv6. If there is not a common approach to IPv4/IPv6 address encoding, the DIAMETER-RADIUS gateway must translate, for example, a DIAMETER Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host AVP depending on its length. Not complex. Just tedious. Regards, Mark From owner-aaa-bof@merit.edu Wed Jan 10 18:49:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA04734 for ; Wed, 10 Jan 2001 18:49:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A8325DE2B; Wed, 10 Jan 2001 18:47:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 593CF5DE25; Wed, 10 Jan 2001 18:47:07 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 78FC55DE00 for ; Wed, 10 Jan 2001 18:47:05 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA10504 for ; Wed, 10 Jan 2001 19:42:55 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA01888 for ; Wed, 10 Jan 2001 18:47:24 -0500 (EST) From: "Mark Jones" To: Subject: RE: [diameter] RE: diameter grammar proposal Date: Wed, 10 Jan 2001 18:54:04 -0500 Message-ID: <009f01c07b60$9d22e300$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > If we were to make the above changes, would you object to this > ABNF format in the -00 spec? > No objections here. As you point out, the bake-off is coming up fast so lets go with this for the -00 spec. Regards, Mark From owner-aaa-bof@merit.edu Wed Jan 10 19:11:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05075 for ; Wed, 10 Jan 2001 19:11:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88D2C5DE16; Wed, 10 Jan 2001 19:10:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 61A1E5DE05; Wed, 10 Jan 2001 19:10:37 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1A24A5DE16 for ; Wed, 10 Jan 2001 19:10:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17820; Wed, 10 Jan 2001 16:10:33 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA07484; Wed, 10 Jan 2001 16:10:33 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA04507; Wed, 10 Jan 2001 16:10:24 -0800 (PST) Date: Wed, 10 Jan 2001 16:06:47 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <009901c07b5c$4cc5e820$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Would new RADIUS attributes for IPv6 addresses still be required if RADIUSv6 > were to adopt the dual purpose AVP approach? If, as suggested by the > RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6 AVPs, the NAS > can still distinguish the IPv4/IPv6 addresses by their length and so can > choose the appropriate instance of the address AVP depending on whether its > client is IPv4 or IPv6. > > If there is not a common approach to IPv4/IPv6 address encoding, the > DIAMETER-RADIUS gateway must translate, for example, a DIAMETER > Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host AVP depending > on its length. Not complex. Just tedious. But how would you deal with backward compatibility? This seems especially important given that in a roaming network, you never know whether the home, or the NAS, support v6. PatC From owner-aaa-bof@merit.edu Wed Jan 10 19:50:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05532 for ; Wed, 10 Jan 2001 19:50:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 123475DE51; Wed, 10 Jan 2001 19:47:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F0A125DE4B; Wed, 10 Jan 2001 19:47:24 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D80515DDE8 for ; Wed, 10 Jan 2001 19:47:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26409; Wed, 10 Jan 2001 16:47:22 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA17473; Wed, 10 Jan 2001 16:47:22 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA05621; Wed, 10 Jan 2001 16:47:20 -0800 (PST) Date: Wed, 10 Jan 2001 16:43:43 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: The Identifier field To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk [ed: I hate this cross-posting, but it seems necessary :(] Tony brought up a question some time ago as to the usefulness of the Identifier field. I believe that no justification was provided at the time for the existence of the field. In the process of editing the base protocol, it came to me the reason why such a field may be required. Assume for a moment that we are a NAS, and that two authorization messages are sent for the same user (let's assume for the moment that these are for different services). When either of the responses are received, how would the NAS know to match request and the response. The obvious answer is to require that the NAS walk through the whole message, looking for clues (e.g. service type). This is rather cumbersome. The Identifier field DOES provide such a hint. However, we need to make sure that the Identifier field IS NOT modified in transit towards the home server (as it is done in RADIUS), because there really is no need to do so, and it does complicate the protocol. So I propose keeping the Identifier field, but adding text that it is ONLY of use to the initiator of a request to match up the response. Does this make sense? PatC From owner-aaa-bof@merit.edu Wed Jan 10 20:00:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA05631 for ; Wed, 10 Jan 2001 20:00:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 713625DE4B; Wed, 10 Jan 2001 19:59:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4F80F5DE55; Wed, 10 Jan 2001 19:59:50 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 0DCA85DE4B for ; Wed, 10 Jan 2001 19:59:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10546; Wed, 10 Jan 2001 16:59:48 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA19879; Wed, 10 Jan 2001 16:59:47 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA05879; Wed, 10 Jan 2001 16:59:45 -0800 (PST) Date: Wed, 10 Jan 2001 16:56:08 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Capabilities Negotiation and proxies To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, As discussed a few days ago, a proxy MAY wish to proxy ANY type of message, regardless of the extension. Therefore, the current text in the base protocol does not allow this behavior since it would require that proxies advertise ALL possible extensions. Therefore, I am proposing adding the last paragraph to section 2.5.3. Furthermore, I believe that ALL messages MUST include the extension ID of the particular message. The reason being that a proxy would need to identify a server in the home domain that can handle the message, but it may not recognize the command. Comments? Objections? Proposed Text? PatC 2.5.3 Extension-Id AVP The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to identify a specific DIAMETER extension. This AVP is used in the Device-Reboot-Ind message in order to inform the peer what extensions are locally supported. The Extension-Id MUST also be present in all messages that are defined in a separate DIAMETER specification and have an Extension ID assigned. Each DIAMETER extension draft MUST have an IANA assigned extension Idenfier (see section 8.3). The base protocol does not require an Extension-Id since its support is mandatory. There MAY be more than one Extension-Id AVP within a DIAMETER Device-Reboot-Ind message. The following values are recognized: NASREQ 1 [7] Strong Security 2 [11] Resource Management 3 [29] Mobile-IP 4 [10] Accounting 5 [15] Furthermore, servers acting as Redirect or Proxy servers (see Section 6.0) MAY wish to advertise support for ALL possible extensions. Such servers are then responsible for finding a downstream server that supports the extension of a particular message. This is done by including the Extension-Id AVP with a value of zero (0). From owner-aaa-bof@merit.edu Wed Jan 10 20:13:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA05779 for ; Wed, 10 Jan 2001 20:13:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 77A8D5DE25; Wed, 10 Jan 2001 20:12:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 67A405DE05; Wed, 10 Jan 2001 20:12:41 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 247675DDE8 for ; Wed, 10 Jan 2001 20:12:40 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0B1BfK24495; Wed, 10 Jan 2001 19:11:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0B1BfU01659; Wed, 10 Jan 2001 19:11:41 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA10813; Wed, 10 Jan 2001 19:11:41 -0600 (CST) Received: from ericsson.com (busam50.berkeley.us.am.ericsson.se [138.85.159.200]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA16150; Wed, 10 Jan 2001 19:11:38 -0600 (CST) Message-ID: <3A5D0286.327AA826@ericsson.com> Date: Wed, 10 Jan 2001 16:47:02 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: The Identifier field References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Good point and I think this make sense to keep the Identifier field as state below. BR, /Tony Pat Calhoun wrote: > [ed: I hate this cross-posting, but it seems necessary :(] > > Tony brought up a question some time ago as to the usefulness of the > Identifier field. I believe that no justification was provided at the time for > the existence of the field. In the process of editing the base protocol, it > came to me the reason why such a field may be required. > > Assume for a moment that we are a NAS, and that two authorization messages are > sent for the same user (let's assume for the moment that these are for > different services). When either of the responses are received, how would the > NAS know to match request and the response. The obvious answer is to require > that the NAS walk through the whole message, looking for clues (e.g. service > type). This is rather cumbersome. > > The Identifier field DOES provide such a hint. However, we need to make sure > that the Identifier field IS NOT modified in transit towards the home server > (as it is done in RADIUS), because there really is no need to do so, and it > does complicate the protocol. > > So I propose keeping the Identifier field, but adding text that it is ONLY of > use to the initiator of a request to match up the response. > > Does this make sense? > > PatC From owner-aaa-bof@merit.edu Wed Jan 10 21:01:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA11828 for ; Wed, 10 Jan 2001 21:01:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22A455DDA8; Wed, 10 Jan 2001 21:00:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF7155DE05; Wed, 10 Jan 2001 21:00:11 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 64C1C5DDA8 for ; Wed, 10 Jan 2001 21:00:08 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0B1xt313997 for ; Thu, 11 Jan 2001 03:59:55 +0200 (EET) Received: from esebh11nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Thu, 11 Jan 2001 04:00:06 +0200 Received: by esebh11nok with Internet Mail Service (5.5.2652.78) id ; Thu, 11 Jan 2001 04:00:06 +0200 Message-ID: From: Dongfeng.Jing@nokia.com To: Pat.Calhoun@Eng.Sun.COM, aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [diameter] Capabilities Negotiation and proxies Date: Thu, 11 Jan 2001 03:54:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk why the value of Extension_ID can not use a bit of that Unsigned32. for example : NASREQ 1 Strong Security 2 Resource Management 4 Mobile-IP 8 Accounting 16 dongfeng.jing > -----Original Message----- > From: ext Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: 11. January 2001 8:56 > To: aaa-wg@merit.edu; diameter@diameter.org > Subject: [diameter] Capabilities Negotiation and proxies > > > All, > > As discussed a few days ago, a proxy MAY wish to proxy ANY > type of message, > regardless of the extension. Therefore, the current text in > the base protocol > does not allow this behavior since it would require that > proxies advertise ALL > possible extensions. > > Therefore, I am proposing adding the last paragraph to section 2.5.3. > Furthermore, I believe that ALL messages MUST include the > extension ID of the > particular message. The reason being that a proxy would need > to identify a > server in the home domain that can handle the message, but it > may not recognize > the command. > > Comments? Objections? Proposed Text? > > PatC > > 2.5.3 Extension-Id AVP > > The Extension-Id AVP (AVP Code 258) is of type Unsigned32 > and is used > in order to identify a specific DIAMETER extension. This > AVP is used > in the Device-Reboot-Ind message in order to inform the peer what > extensions are locally supported. The Extension-Id MUST > also be present > in all messages that are defined in a separate DIAMETER > specification > and have an Extension ID assigned. > > Each DIAMETER extension draft MUST have an IANA assigned extension > Idenfier (see section 8.3). The base protocol does not require an > Extension-Id since its support is mandatory. > > There MAY be more than one Extension-Id AVP within a DIAMETER > Device-Reboot-Ind message. The following values are recognized: > > NASREQ 1 [7] > Strong Security 2 [11] > Resource Management 3 [29] > Mobile-IP 4 [10] > Accounting 5 [15] > > Furthermore, servers acting as Redirect or Proxy servers (see > Section 6.0) MAY wish to advertise support for ALL possible > extensions. Such servers are then responsible for finding a > downstream server that supports the extension of a particular > message. This is done by including the Extension-Id AVP with a > value of zero (0). > From owner-aaa-bof@merit.edu Thu Jan 11 05:11:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA29753 for ; Thu, 11 Jan 2001 05:11:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50C0D5DD8C; Thu, 11 Jan 2001 05:10:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 31DC35DE0B; Thu, 11 Jan 2001 05:10:37 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BF6EA5DD8C for ; Thu, 11 Jan 2001 05:10:35 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26364; Thu, 11 Jan 2001 02:10:31 -0800 (PST) Received: from vayne (muc-isdn-11 [129.157.164.111]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id LAA07341; Thu, 11 Jan 2001 11:10:28 +0100 (MET) Date: Thu, 11 Jan 2001 11:20:56 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: diameter grammar proposal To: Mark Eklund Cc: Erik Guttman , aaa-wg@merit.edu, Randy Bush 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 Mark, Thanks for your questions, they helped me see where my grammar proposal was weak. I attempt to strengthen it below. Please let me know if this answers your question and meets our needs. > 1. I am used to seeing qualifiers after the argument like in > regular expressions. For example Host-Name* instead of > *Host-Name. This is a personal preference. The *, ? and + are in the spirit of ABNF (see RFC 2234) rather than as glob or regular expressions. They precede the grammar element they qualify. > 2. Why do you need the optional brackets [] when you have the > '*' and '?' operators. I.E. what is the difference in > *[Host-Name] and *Host-Name? The grammar conventions I proposed were not formally specified. That made it confusing, as you point out. How about the following ABNF for all diameter message definitions: command-def = command-name "::=" diameter-message diameter-name = ALPHA *(ALPHA / DIGIT / "-") command-name = diameter-name ; The command-name has to be Command name, defined in ; the base or exteneded DIAMETER specifications. diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] header = "" fixed = [qual] "<" avp-spec ">" required = [qual] "{" avp-spec "}" optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot evaluate ; to any AVP Name which is included in a fixed or ; required rule. qual = [min] "*" [max] ; Rather than the confusing '?', '+' and '*' ; use ABNF conventions, RFC 2234 section 3.6. ; ; NOTE: "[" and "]" have a different meaning than ; in ABNF (see the optional rule, above). These ; braces cannot be used to express an optional fixed ; rules (such as an optional ICV at the end.) To do ; this, the convention is '0*1fixed'. min = 1*DIGIT ; The minimum number of times the element may be ; present. max = 1*DIGIT ; The maximum number of times the element may be ; present. avp-spec = diameter-name ; The avp-spec has to be an AVP Name, defined in the ; base or extended DIAMETER specifications. avp-name = avp-spec | "AVP" ; The string "AVP" stands for *any* arbitrary AVP Name. This is more restricted than the grammar I described (but did not specify) in my previous email. (1) You can only put fixed rules at the beginning or end of the message. This limits the possible command grammars you can produce, but I think this is OK. (2) You can only specify one AVP per fixed, required or optional rule, where I indicated you could have any number AVPs in them. This will make the grammar specifications more verbose. (3) Since you only have one AVP per rule, you only need the 'qual' outside the braces, which eliminates the ambiguity of my initial proposal (where you could ask "Where do you put the qual? What is the meaning of putting it one place instead of the other? What does it mean if you put it in both places? etc.) The revised 'example' would look like: Example-Command ::= { User-Name } *{ Host-Name } *[ AVP ] 0*1< Integrity-Check-Vector > The command defined by the preceding grammar MUST begin with a DIAMETER header, with the command code Id set to 9999999. There follows a User-Name AVP, zero or more Host-Name AVPs and zero or more arbitrary other AVPs (but not User-Name, Host-Name or Integrity-Check-Vector AVPs). The REQUIRED and OPTIONAL AVPs can be permuted into any order, provided that none of them come before the Header or after the Integrity-Check Vector. > 3. Do you plan to define Grouped-AVP in the specifications? No - Grouped-AVP is going away, to be replaced by a Grouped value. Other email on this was sent to the list with the subject "data type modifications to DIAMETER" Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu Jan 11 05:11:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA29759 for ; Thu, 11 Jan 2001 05:11:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id C62405DE49; Thu, 11 Jan 2001 05:10:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 95D485DE4A; Thu, 11 Jan 2001 05:10:41 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BA4005DE49 for ; Thu, 11 Jan 2001 05:10:37 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26382; Thu, 11 Jan 2001 02:10:35 -0800 (PST) Received: from vayne (muc-isdn-11 [129.157.164.111]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id LAA07751; Thu, 11 Jan 2001 11:10:32 +0100 (MET) Date: Thu, 11 Jan 2001 11:20:59 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: diameter grammar proposal To: Mark Jones Cc: Erik Guttman , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <008a01c07b37$f6836d80$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark, > Aren't the {} and [] brackets redundant given the 'qual' token definitions? > > i.e. > '*' = Zero or more instances MAY be present in the packet = OPTIONAL AVP > '+' = At least one instance MUST be present in the packet = MANDATORY AVP > '?' = Zero or one instances MAY be present in the packet = OPTIONAL AVP > omitted = Exactly one instance MUST be present in the packet = MANDATORY > AVP First - I suggest we get rid of the '+' and '?' qualifiers - they only confuse the issue. I suggest a grammar without them in a separate message sent to the list. Regarding the use of {} and [] for required and optional definitions: It is important to distinguish between AVPs required by a command and those which are optional. For those that are required, we want to say how many have to be there. For those that are optional, we want to leave things open. BUT we have to be sure that by leaving things open we don't allow the 'optional' rules to collide with the 'required' rules. Say you MUST have one and only one 'Foo-AVP' in command X, and there is an option rule, for sticking in any arbitrary AVP. You could evaluate that rule to allow N additional 'Foo-AVP's in the command X message. That is why I want to separate optional and required AVPs in the message specifications. This does NOT directly relate to the use of the term 'Mandatory' in DIAMETER. Mandatory means the 'M' bit is set - which has consequences if the receiver of a message doesn't have the ability to interpret the AVP with the 'M' bit set. This discussion has been pursued in other threads. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu Jan 11 09:19:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03583 for ; Thu, 11 Jan 2001 09:19:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E998E5DDE3; Thu, 11 Jan 2001 09:19:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CF38C5DDB7; Thu, 11 Jan 2001 09:19:11 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 2A2705DD90 for ; Thu, 11 Jan 2001 09:19:10 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0BEJ3p79067; Thu, 11 Jan 2001 09:19:03 -0500 (EST) (envelope-from barney) Date: Thu, 11 Jan 2001 09:19:03 -0500 From: Barney Wolff To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: The Identifier field Message-ID: <20010111091903.A78837@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Wed, Jan 10, 2001 at 04:43:43PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, in RADIUS the id comes back to the originator of a request, and whether it's modified between proxies is not visible to the requester. Why would you want to impose further requirements above that? To be sure, a stateless proxy would have to keep the id unchanged, because it won't notice when the response comes back, but a stateful proxy will, and can therefore obey the requirement while still generating a useful id of its own. You can argue that Proxy-State provides the same opportunity for fast lookup, but the AVP is not in a fixed position, while the id is part of the header. The justification of the field is that it allows the receiver of a response to do an efficient lookup of its request state. That motive stays the same for DIAMETER, and helps proxies as well as NAS's - but only if the proxy can set the id. I see no benefit to disallowing that. There's already an unmodifiable AVP for session-id, and we don't need two. Barney On Wed, Jan 10, 2001 at 04:43:43PM -0800, Pat Calhoun wrote: > [ed: I hate this cross-posting, but it seems necessary :(] > > Tony brought up a question some time ago as to the usefulness of the > Identifier field. I believe that no justification was provided at the time for > the existence of the field. In the process of editing the base protocol, it > came to me the reason why such a field may be required. > > Assume for a moment that we are a NAS, and that two authorization messages are > sent for the same user (let's assume for the moment that these are for > different services). When either of the responses are received, how would the > NAS know to match request and the response. The obvious answer is to require > that the NAS walk through the whole message, looking for clues (e.g. service > type). This is rather cumbersome. > > The Identifier field DOES provide such a hint. However, we need to make sure > that the Identifier field IS NOT modified in transit towards the home server > (as it is done in RADIUS), because there really is no need to do so, and it > does complicate the protocol. > > So I propose keeping the Identifier field, but adding text that it is ONLY of > use to the initiator of a request to match up the response. > > Does this make sense? > > PatC > > From owner-aaa-bof@merit.edu Thu Jan 11 10:23:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA04901 for ; Thu, 11 Jan 2001 10:23:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDFEB5DE28; Thu, 11 Jan 2001 10:23:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CAD075DE41; Thu, 11 Jan 2001 10:23:10 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 4BCE95DE28 for ; Thu, 11 Jan 2001 10:23:09 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA13411; Thu, 11 Jan 2001 11:18:59 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA10527; Thu, 11 Jan 2001 10:23:28 -0500 (EST) From: "Mark Jones" To: "Erik Guttman" Cc: Subject: RE: diameter grammar proposal Date: Thu, 11 Jan 2001 10:30:08 -0500 Message-ID: <00ca01c07be3$60ffe6b0$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Erik, > BUT we have to be sure that by leaving things open we don't allow the > 'optional' rules to collide with the 'required' rules. Where 'optional' rules are those rules which refer to optional AVPs. The rules themselves are NOT optional, correct? > Say you > MUST have one and only one 'Foo-AVP' in command X, and there is an > option rule, for sticking in any arbitrary AVP. You could evaluate > that rule to allow N additional 'Foo-AVP's in the command X message. > I see. You are concerned about conflicting rules. I am still not convinced that ambiguity exists here. I had assumed that all rules MUST be satisfied when evaluating whether a packet is valid. From your example, adding more Foo-AVPs breaks the first rule and therefore would be illegal. > This does NOT directly relate to the use of the term 'Mandatory' in > DIAMETER. Mandatory means the 'M' bit is set - which has consequences > if the receiver of a message doesn't have the ability to interpret the > AVP with the 'M' bit set. This discussion has been pursued in other > threads. > Agreed. Lets never talk of it again :) Regards, Mark From owner-aaa-bof@merit.edu Thu Jan 11 10:29:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05077 for ; Thu, 11 Jan 2001 10:29:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D55B5DE3F; Thu, 11 Jan 2001 10:28:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0BABD5DE39; Thu, 11 Jan 2001 10:28:52 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id B1F1B5DDB7 for ; Thu, 11 Jan 2001 10:28:49 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA15034; Thu, 11 Jan 2001 10:28:11 -0500 (EST) Date: Thu, 11 Jan 2001 10:28:11 -0500 (EST) From: Mark Eklund To: Erik Guttman Cc: Erik Guttman , aaa-wg@merit.edu, Randy Bush Subject: Re: diameter grammar proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Erik, Thanks, that answers my earlier questions. Also, is there a need to support Command Flags like E, I, and R in this specification? -mark On Thu, 11 Jan 2001, Erik Guttman wrote: > Mark, > > Thanks for your questions, they helped me see where my grammar > proposal was weak. I attempt to strengthen it below. Please > let me know if this answers your question and meets our needs. > > > 1. I am used to seeing qualifiers after the argument like in > > regular expressions. For example Host-Name* instead of > > *Host-Name. This is a personal preference. > > The *, ? and + are in the spirit of ABNF (see RFC 2234) rather > than as glob or regular expressions. They precede the grammar > element they qualify. > > > 2. Why do you need the optional brackets [] when you have the > > '*' and '?' operators. I.E. what is the difference in > > *[Host-Name] and *Host-Name? > > The grammar conventions I proposed were not formally specified. That > made it confusing, as you point out. How about the following ABNF for > all diameter message definitions: > > command-def = command-name "::=" diameter-message > > diameter-name = ALPHA *(ALPHA / DIGIT / "-") > > command-name = diameter-name > ; The command-name has to be Command name, defined in > ; the base or exteneded DIAMETER specifications. > > diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] > > header = "" > > fixed = [qual] "<" avp-spec ">" > > required = [qual] "{" avp-spec "}" > > optional = [qual] "[" avp-name "]" > ; The avp-name in the 'optional' rule cannot evaluate > ; to any AVP Name which is included in a fixed or > ; required rule. > > qual = [min] "*" [max] > ; Rather than the confusing '?', '+' and '*' > ; use ABNF conventions, RFC 2234 section 3.6. > ; > ; NOTE: "[" and "]" have a different meaning than > ; in ABNF (see the optional rule, above). These > ; braces cannot be used to express an optional fixed > ; rules (such as an optional ICV at the end.) To do > ; this, the convention is '0*1fixed'. > > min = 1*DIGIT > ; The minimum number of times the element may be > ; present. > > max = 1*DIGIT > ; The maximum number of times the element may be > ; present. > > avp-spec = diameter-name > ; The avp-spec has to be an AVP Name, defined in the > ; base or extended DIAMETER specifications. > > avp-name = avp-spec | "AVP" > ; The string "AVP" stands for *any* arbitrary AVP Name. > > This is more restricted than the grammar I described (but did not specify) > in my previous email. > > (1) You can only put fixed rules at the beginning or end of the message. > This limits the possible command grammars you can produce, but I > think this is OK. > > (2) You can only specify one AVP per fixed, required or optional rule, > where I indicated you could have any number AVPs in them. This > will make the grammar specifications more verbose. > > (3) Since you only have one AVP per rule, you only need the 'qual' > outside the braces, which eliminates the ambiguity of my initial > proposal (where you could ask "Where do you put the qual? What > is the meaning of putting it one place instead of the other? > What does it mean if you put it in both places? etc.) > > The revised 'example' would look like: > > Example-Command ::= > { User-Name } > *{ Host-Name } > *[ AVP ] > 0*1< Integrity-Check-Vector > > > The command defined by the preceding grammar MUST begin with a > DIAMETER header, with the command code Id set to 9999999. There > follows a User-Name AVP, zero or more Host-Name AVPs and zero or > more arbitrary other AVPs (but not User-Name, Host-Name or > Integrity-Check-Vector AVPs). The REQUIRED and OPTIONAL AVPs > can be permuted into any order, provided that none of them come > before the Header or after the Integrity-Check Vector. > > > 3. Do you plan to define Grouped-AVP in the specifications? > > No - Grouped-AVP is going away, to be replaced by a Grouped value. > Other email on this was sent to the list with the subject > > "data type modifications to DIAMETER" > > Erik > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. > E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de > Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com > Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 > > > From owner-aaa-bof@merit.edu Thu Jan 11 11:28:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05876 for ; Thu, 11 Jan 2001 11:28:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 093715DE4A; Thu, 11 Jan 2001 11:28:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E8CAC5DE41; Thu, 11 Jan 2001 11:28:03 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A9A655DE39 for ; Thu, 11 Jan 2001 11:28:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00196; Thu, 11 Jan 2001 08:28:00 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03155; Thu, 11 Jan 2001 08:27:57 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA19473; Thu, 11 Jan 2001 07:01:10 -0800 (PST) Date: Thu, 11 Jan 2001 06:57:31 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Redirect To: diameter@diameter.org, aaa-wg@merit.edu Cc: Pat.Calhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The current base protocol specification states that a redirect server returns a response to the requestor with the error code set to redirect. However, some discussions we have been having recently on this list implies that redirect and proxy servers may not actually support all extensions, and may only support the bare minimum required for packets to be forwarded to the home server. Therefore, I question how such servers would ever know how to set the command code field to the correct response. So, if we really need to support the above case, one of the following needs to be done: 1. Do nothing and require that proxies/redirect servers support extensions (this is a valid requirement). 2. Make sure that the redirect indication is returned in an MRI (Message-Reject-Ind) message. However, one does question how request/responses are matched up properly, and the details of this need to be refined 3. A MUCH more drastic change, and one I am not sure that I like but I am adding for completeness. No longer distingush request from responses, but rather make use of the bits in the message header to distinguish whether the message is a request or a response. So an Access message would have the request mode (when bits are set), or a response (when the bits indicate a response). This *seems* clean, but is a huge change for implementations and the protocol. I think that the simplest is #2 above, but I am opening up this can of worms now to get a feel for how people think their proxies will operate. PatC From owner-aaa-bof@merit.edu Thu Jan 11 11:28:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05883 for ; Thu, 11 Jan 2001 11:28:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5117E5DE52; Thu, 11 Jan 2001 11:28:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 377185DE50; Thu, 11 Jan 2001 11:28:08 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EFCEA5DE5C for ; Thu, 11 Jan 2001 11:28:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00229; Thu, 11 Jan 2001 08:28:02 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03186; Thu, 11 Jan 2001 08:28:01 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA18848; Thu, 11 Jan 2001 06:26:15 -0800 (PST) Date: Thu, 11 Jan 2001 06:22:37 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: The Identifier field To: Barney Wolff Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <20010111091903.A78837@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat, in RADIUS the id comes back to the originator of a request, > and whether it's modified between proxies is not visible to the > requester. Why would you want to impose further requirements > above that? To be sure, a stateless proxy would have to keep > the id unchanged, because it won't notice when the response > comes back, but a stateful proxy will, and can therefore obey > the requirement while still generating a useful id of its own. > > You can argue that Proxy-State provides the same opportunity > for fast lookup, but the AVP is not in a fixed position, while > the id is part of the header. > > The justification of the field is that it allows the receiver of > a response to do an efficient lookup of its request state. That > motive stays the same for DIAMETER, and helps proxies as well as > NAS's - but only if the proxy can set the id. I see no benefit > to disallowing that. There's already an unmodifiable AVP for > session-id, and we don't need two. ok, I can buy that. However, I am not sure that I want to describe how proxies make use of the Identifier field, or should I? I believe that I will simply add text stating that the id is used to match request and replies, and leave it at that. *However* please keep in mind that the ID only is not really that useful. Let's consider a NAS that issues an accounting message with the ID set to 4. As it turns out, it ALSO receives an unsolicited message from a home server with the ID set to 4. Since it is not the originator of the message, then it should attempt to ignore the ID field. So my text was that the ID, the Session-Id and the command-code are used on the NAS to match request and replies. PatC From owner-aaa-bof@merit.edu Thu Jan 11 12:28:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06751 for ; Thu, 11 Jan 2001 12:28:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 881595DFA5; Thu, 11 Jan 2001 12:24:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 344BC5DE55; Thu, 11 Jan 2001 12:24:51 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4C7985DF67 for ; Thu, 11 Jan 2001 12:22:09 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12497; Thu, 11 Jan 2001 09:22:07 -0800 (PST) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA13983; Thu, 11 Jan 2001 18:22:05 +0100 (MET) Date: Thu, 11 Jan 2001 18:32:33 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: diameter grammar proposal To: Mark Eklund Cc: Erik Guttman , 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 > Also, is there a need to support Command Flags like E, I, and R > in this specification? The grammar specification covers AVPs. The flags are specified for all commands (by their type -Ind, -Rqst, -Answer, -Query, -Reply) and go into the DIAMETER header. DIAMETER implementations will have to support those flags. This is useful for reasons pointed out in draft-ietf-aaa-issues-04.txt and Pat's point that proxies can benefit from knowing a message is an Indication, request/query or a reply/answer. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu Jan 11 12:30:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06812 for ; Thu, 11 Jan 2001 12:30:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2E985DECF; Thu, 11 Jan 2001 12:27:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B0ED55DEFD; Thu, 11 Jan 2001 12:27:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 2FEBF5DECF for ; Thu, 11 Jan 2001 12:27:44 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28497; Thu, 11 Jan 2001 09:27:40 -0800 (PST) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA25337; Thu, 11 Jan 2001 18:27:38 +0100 (MET) Date: Thu, 11 Jan 2001 18:38:05 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: diameter grammar proposal To: Mark Jones Cc: Erik Guttman , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <00ca01c07be3$60ffe6b0$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > BUT we have to be sure that by leaving things open we don't allow the > > 'optional' rules to collide with the 'required' rules. > > Where 'optional' rules are those rules which refer to optional AVPs. The > rules themselves are NOT optional, correct? Right. I should've said the rules for 'optional AVPs'. > > Say you > > MUST have one and only one 'Foo-AVP' in command X, and there is an > > option rule, for sticking in any arbitrary AVP. You could evaluate > > that rule to allow N additional 'Foo-AVP's in the command X message. > > > > I see. You are concerned about conflicting rules. I am still not convinced > that ambiguity exists here. I had assumed that all rules MUST be satisfied > when evaluating whether a packet is valid. From your example, adding more > Foo-AVPs breaks the first rule and therefore would be illegal. The current diameter spec (which lists but doesn't constrain AVPs to include) it is possible to put in WHATEVER, including more Foo-AVPs. There is no mechanism to describe as illegal putting in multiple AVPs of a given type (or ordering of AVPs in a message). That is why I am proposing a more formal grammar, which still allows constrained, but still flexible inclusion of semi-arbitrary AVPs and reordering. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu Jan 11 12:54:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07101 for ; Thu, 11 Jan 2001 12:54:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E14A5DE77; Thu, 11 Jan 2001 12:53:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DB2C5DE74; Thu, 11 Jan 2001 12:53:47 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 90D295DE6C for ; Thu, 11 Jan 2001 12:53:45 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0BHoXR22223 for ; Thu, 11 Jan 2001 09:50:33 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: Security proposals for Interim meeting, Feburary 7, 2001 Date: Thu, 11 Jan 2001 09:53:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk So that we can be prepared for our interim meeting on February 7, 2001, I'd like to ask for volunteers to present security proposals. These proposals should be complete in the sense that they describe everything that is required to solve the security issues that we face. The goal of the exercise will be to convince the WG that one or more of the proposals are viable in the real world. Here's a first cut at what is needed for the various proposals: 1. CMS. I'd like to see a proposal on how CMS can be used for both e2e and hop-by-hop security. Also, given this I'd like to understand whether password hiding is still necessary, and if so, why. The proposal should be clear about: a. Whether PKI is required or not, and exactly what infrastructure is needed (CRL servers, offline/online CAs, etc.) b. Efficiency issues (key reuse) c. Code size and implementation availability (can this be implemented on a NAS?) 2. GSS_API. I'd like to see a proposal describing the deployment scenarios in more detail. Issues to discuss further include: a. GSS_API methods that could be supported within the 1 round trip framework (is this only Kerberos V?) b. Proposed mandatory to implement method c. Code size and availability d. Deployment implications 1. Kerberos KDC on the Internet? 2. IAKERB proxies? 3. DNS support for KDC location? 4. Authorization issues 3. IPSEC. Issues to discuss further include: a. Can use of ESP with non-null transform eliminate need for password hiding? b. Can IKE MM cert policy validate biz relationships or is this asking too much? c. Security implications of referral 1. Firewall hole for IPSEC/IKE from any source to AAA server 2. AAA server does packet filtering not firewall 3. Implications for NAS vulnerabilities From owner-aaa-bof@merit.edu Thu Jan 11 13:05:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07276 for ; Thu, 11 Jan 2001 13:05:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97EC95DDD9; Thu, 11 Jan 2001 13:04:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 863A45DDB7; Thu, 11 Jan 2001 13:04:43 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 550915DD95 for ; Thu, 11 Jan 2001 13:04:41 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA14676; Thu, 11 Jan 2001 14:00:21 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA14642; Thu, 11 Jan 2001 13:04:50 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: , Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 13:11:30 -0500 Message-ID: <00fc01c07bf9$ebe30210$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > But how would you deal with backward compatibility? This seems especially > important given that in a roaming network, you never know whether > the home, or the NAS, support v6. > Wouldn't all the RADIUS/DIAMETER servers in the proxy chain will know whether the NAS itself is IPv6 or IPv4 by virtue of (1) in DIAMETER, the length of the NAS-IP-Address AVP, or (2) in RADIUS, presence of the NAS-IP-Address vs NAS-IPv6-Address AVP? It seem unlikely to me that a RADIUS request received from an IPv6 NAS by a dual-stack (v4/v6) RADIUS server would then be proxied unmodified to a legacy IPv4 RADIUS server. Similarly, a RADIUS response received from an IPv6 RADIUS server would not be returned unmodified to a legacy IPv4 NAS. Do you think the dual purpose AVP approach would significantly increase the complexity of the translation being done by a dual-stack RADIUS server? Whether the host requesting service from the NAS actually supports IPv6 is another issue since as the RADIUSv6 draft points out: "Note that a NAS sending a RADIUS Access-Request may not know a-priori whether the host will be using IPv4, IPv6, or both. For example, within PPP, NCP occurs after LCP, so that address assignment will not occur until after RADIUS authentication and authorization has completed. Therefore it is presumed that the IPv6 attributes described in this document MAY be sent along with IPv4-related attributes within the same RADIUS message and that the NAS will decide which attributes to use." Regards, Mark From owner-aaa-bof@merit.edu Thu Jan 11 13:05:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07292 for ; Thu, 11 Jan 2001 13:05:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F5225DDDB; Thu, 11 Jan 2001 13:05:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D3D35DD95; Thu, 11 Jan 2001 13:05:24 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A30965DDB7 for ; Thu, 11 Jan 2001 13:05:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13451; Thu, 11 Jan 2001 10:05:03 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29920; Thu, 11 Jan 2001 10:04:28 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA18825; Thu, 11 Jan 2001 10:04:27 -0800 (PST) Date: Thu, 11 Jan 2001 10:00:48 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001 To: Bernard Aboba Cc: "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 Bernard, Should I assume from your e-mail that hop-by-hop is out in the base spec? I think discounting hop security is a mistake. Should I bring a contribution detailing this method? PatC > So that we can be prepared for our interim meeting on > February 7, 2001, I'd like to ask for volunteers to > present security proposals. These proposals should be > complete in the sense that they describe everything > that is required to solve the security issues that > we face. > > The goal of the exercise will be to convince the > WG that one or more of the proposals are viable in > the real world. > > Here's a first cut at what is needed for the various > proposals: > > 1. CMS. I'd like to see a proposal on how CMS can be > used for both e2e and hop-by-hop security. Also, given > this I'd like to understand whether password hiding is > still necessary, and if so, why. The proposal should > be clear about: > a. Whether PKI is required or not, and exactly > what infrastructure is needed (CRL servers, > offline/online CAs, etc.) > b. Efficiency issues (key reuse) > c. Code size and implementation availability > (can this be implemented on a NAS?) > > 2. GSS_API. I'd like to see a proposal describing > the deployment scenarios in more detail. > Issues to discuss further include: > a. GSS_API methods that could be supported > within the 1 round trip framework (is this > only Kerberos V?) > b. Proposed mandatory to implement method > c. Code size and availability > d. Deployment implications > 1. Kerberos KDC on the Internet? > 2. IAKERB proxies? > 3. DNS support for KDC location? > 4. Authorization issues > > 3. IPSEC. > Issues to discuss further include: > a. Can use of ESP with non-null transform > eliminate need for password hiding? > b. Can IKE MM cert policy validate biz relationships or > is this asking too much? > c. Security implications of referral > 1. Firewall hole for IPSEC/IKE from any source to > AAA server > 2. AAA server does packet filtering not firewall > 3. Implications for NAS vulnerabilities > > > From owner-aaa-bof@merit.edu Thu Jan 11 13:12:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07404 for ; Thu, 11 Jan 2001 13:12:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51EF05DE39; Thu, 11 Jan 2001 13:12:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 409915DDB7; Thu, 11 Jan 2001 13:12:06 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id F12FA5DD95 for ; Thu, 11 Jan 2001 13:12:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17342; Thu, 11 Jan 2001 10:12:01 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA02712; Thu, 11 Jan 2001 10:12:00 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA29082; Thu, 11 Jan 2001 10:11:59 -0800 (PST) Date: Thu, 11 Jan 2001 10:08:22 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <00fc01c07bf9$ebe30210$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Whether the host requesting service from the NAS actually supports IPv6 is > another issue since as the RADIUSv6 draft points out: > > "Note that a NAS sending a RADIUS Access-Request may not know a-priori > whether the host will be using IPv4, IPv6, or both. For example, within > PPP, NCP occurs after LCP, so that address assignment will not occur > until after RADIUS authentication and authorization has completed. > Therefore it is presumed that the IPv6 attributes described in this > document MAY be sent along with IPv4-related attributes within the same > RADIUS message and that the NAS will decide which attributes to use." Right, but chances of getting *something* back from the home server are quite high if two attributes are added, one for each address family, as opposed to inserting an IPv6 in an attribute that the home server expected to be only 32bit in length. Chances it would drop the request in this case, hence increasing the difficulty in troubleshooting. PatC From owner-aaa-bof@merit.edu Thu Jan 11 13:18:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07648 for ; Thu, 11 Jan 2001 13:18:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8DA815DE41; Thu, 11 Jan 2001 13:15:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78D685DDB7; Thu, 11 Jan 2001 13:15:18 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id B47BD5DD95 for ; Thu, 11 Jan 2001 13:15:16 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0BIEDY79894; Thu, 11 Jan 2001 13:14:13 -0500 (EST) (envelope-from barney) Date: Thu, 11 Jan 2001 13:14:13 -0500 From: Barney Wolff To: Bernard Aboba Cc: "Aaa-Wg@Merit. Edu" Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001 Message-ID: <20010111131413.B79807@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from aboba@internaut.com on Thu, Jan 11, 2001 at 09:53:51AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk It may have been pointed out already, but referral imho does not imply that the target is the ultimate server that must itself contain the sensitive user database. The target will be whatever the home domain says is its public face - which if the administrators have any sense, will be a proxy. Even if you attempt to mandate true "end-ness" such that the home server is not a proxy, how could anybody outside the home domain detect a violation? We would be foolish to attempt to legislate against things that cannot be detected or forcibly suppressed. A proxy makes a much better AAA firewall than any general-purpose firewall could ever hope to be. Re IKE-from-anywhere, how does a roaming VPN setup work, if not that? I too wish that IKE were less DoSable, though. Barney On Thu, Jan 11, 2001 at 09:53:51AM -0800, Bernard Aboba wrote: ... > 3. IPSEC. > c. Security implications of referral > 1. Firewall hole for IPSEC/IKE from any source to > AAA server > 2. AAA server does packet filtering not firewall From owner-aaa-bof@merit.edu Thu Jan 11 13:29:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07807 for ; Thu, 11 Jan 2001 13:29:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6596F5DE56; Thu, 11 Jan 2001 13:29:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 548C05DE50; Thu, 11 Jan 2001 13:29:24 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 46C105DDB7 for ; Thu, 11 Jan 2001 13:29:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24194; Thu, 11 Jan 2001 10:29:19 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07355; Thu, 11 Jan 2001 10:29:05 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA04559; Thu, 11 Jan 2001 10:29:04 -0800 (PST) Date: Thu, 11 Jan 2001 10:25:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Preview of new DIAMETER base protocol To: diameter@diameter.org, aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I am making a preview of the next base protocol available at www.diameter.org. This version has not been sent to the secretariat for publication, and is Identified as Alpha 1. Given the number of changes, I though it would be worthwhile getting some review prior to sending it in as a WG work item. It includes: - Changes from the solutions I-D - Lots of additional changes throughout the document as a result of the changes. - Fix to the state machine - etc, etc. It does NOT include: - New ABNF grammar (I thought more comments and careful review of Erik's proposal would be best). - AES security (the current text still includes the MD5 style hiding. I have asked for help with AES, and expect to have something soon). The document can be found at http://www.diameter.org/draft-calhoun-diameter-18.txt, while the diffs (against version 17) are at http://www.diameter.org/diffs-in-18.txt. Although I have reviewed the spec, it is possible that some inconsistencies still exist. So any feedback would be most appreciated. Thanks, PatC From owner-aaa-bof@merit.edu Thu Jan 11 13:33:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07902 for ; Thu, 11 Jan 2001 13:33:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B1F15DE83; Thu, 11 Jan 2001 13:33:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F28715DE8D; Thu, 11 Jan 2001 13:33:21 -0500 (EST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by segue.merit.edu (Postfix) with ESMTP id 60DED5DE83 for ; Thu, 11 Jan 2001 13:33:20 -0500 (EST) Received: from jariws1 (ab16d3hel.dial.kolumbus.fi [212.54.18.16]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id UAA11449; Thu, 11 Jan 2001 20:33:01 +0200 (EET) Message-ID: <00cf01c07bfc$d5ba3820$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Mark Jones" Cc: , References: Subject: Re: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 20:32:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat writes: > Right, but chances of getting *something* back from the home server are quite > high if two attributes are added, one for each address family, as opposed to > inserting an IPv6 in an attribute that the home server expected to be only > 32bit in length. Chances it would drop the request in this case, hence > increasing the difficulty in troubleshooting. Thinking about the major places (e.g. 3g) where DIAMETER could be deployed in the future, I think it would be even reasonable to *require* IPv6 attribute support from all DIAMETER nodes. Which would be rather trivial and different from than supporting IPv6 itself on DIAMETER or the functions of the NAS. Jari From owner-aaa-bof@merit.edu Thu Jan 11 13:41:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07996 for ; Thu, 11 Jan 2001 13:41:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 260AD5DDFB; Thu, 11 Jan 2001 13:41:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1466D5DDB7; Thu, 11 Jan 2001 13:41:22 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id F3F1A5DD95 for ; Thu, 11 Jan 2001 13:41:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29798; Thu, 11 Jan 2001 10:41:17 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA11022; Thu, 11 Jan 2001 10:41:16 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA04902; Thu, 11 Jan 2001 10:41:11 -0800 (PST) Date: Thu, 11 Jan 2001 10:37:33 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] data type modifications to DIAMETER (Fwd) To: Jari Arkko Cc: aaa-wg@merit.edu, diameter@diameter.org, Mark Jones In-Reply-To: "Your message with ID" <200101111926.f0BJQiL23668@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat writes: > >> Right, but chances of getting *something* back from the home server are quite >> high if two attributes are added, one for each address family, as opposed to >> inserting an IPv6 in an attribute that the home server expected to be only >> 32bit in length. Chances it would drop the request in this case, hence >> increasing the difficulty in troubleshooting. > > Thinking about the major places (e.g. 3g) where DIAMETER could be > deployed in the future, I think it would be even reasonable to *require* IPv6 > attribute > support from all DIAMETER nodes. Which would be rather trivial and > different from than supporting IPv6 itself on DIAMETER or the functions > of the NAS. I didn't think that was the original comment (or perhaps I've really misunderstood this from the beginning). I thought the issue was more regarding the RADIUS protocol. v4/v6 support is mandatory in the DIAMETER protocol. Whether a NAS or Server supports either, or both, protocols is irrelevant. All we care about is ensuring that requests and responses are recognized. PatC From owner-aaa-bof@merit.edu Thu Jan 11 13:52:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08123 for ; Thu, 11 Jan 2001 13:52:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5083D5DE50; Thu, 11 Jan 2001 13:52:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 406BA5DDB7; Thu, 11 Jan 2001 13:52:19 -0500 (EST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by segue.merit.edu (Postfix) with ESMTP id 9F5A25DD95 for ; Thu, 11 Jan 2001 13:52:17 -0500 (EST) Received: from jariws1 (ab16d3hel.dial.kolumbus.fi [212.54.18.16]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id UAA17089; Thu, 11 Jan 2001 20:52:12 +0200 (EET) Message-ID: <00d401c07bff$8403eaa0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , , References: Subject: Re: Proposed change to DIAMETER header Date: Thu, 11 Jan 2001 20:51:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk > The method the protocol is currently specified, it requires that an > implementation walk through each AVP, looking for the ICV AVP in order to > perform the necessary replay and authentication checks. What this means is > that there is a significant amount of work required to ensure that the packet > is in fact authentic. This does not bode well for denial of service attacks. > > So I would like to propose adding the ICV-Offset to the DIAMETER header, as > shown below: I don't care that much either way, but I would just note a couple of things: 1) The MAC calculation is in any case heavier than any reasonable ICV attribute seeking operation, so I don't really know if this buys that much. Or perhaps you are simplifying the DIAMETER hardware ICV engine design for the next SPARC station ;-) 2) If I would program a server, I would make a separate small piece of code to look for the ICV for received packets; don't think more than a simple loop is required since the ICV hopefully couldn't be inside any AVP groups, and no XML data dictionaries need to be consulted either. 3) If there's an ICV offset in the header, somebody's going to have to go and check later that it corresponds to the actual place of the attribute. Also, before the ICV is checked we need to ensure it falls within the bounds of the message. Unnecessary complexity. [In any case, I'd rather have statically keyed IPsec as a MUST than the AVP, since that would be useful for encryption as well as integrity, and would benefit more apps at the same time. And again, many DIAMETER uses I see would be in the v6 domain and there IPsec exists anyway...] Jari From owner-aaa-bof@merit.edu Thu Jan 11 14:40:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08933 for ; Thu, 11 Jan 2001 14:40:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8767C5DEE8; Thu, 11 Jan 2001 14:34:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 061B65DE7D; Thu, 11 Jan 2001 14:34:36 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 1EC9D5DE7D for ; Thu, 11 Jan 2001 14:33:58 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id PAA15494; Thu, 11 Jan 2001 15:29:43 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id OAA16813; Thu, 11 Jan 2001 14:34:12 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 14:40:52 -0500 Message-ID: <00ff01c07c06$68110dd0$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, [diameter@diameter.org removed from CC list. Thread concerns RADIUSv6.] > > Right, but chances of getting *something* back from the home > server are quite > high if two attributes are added, one for each address family, as > opposed to > inserting an IPv6 in an attribute that the home server expected to be only > 32bit in length. Chances it would drop the request in this case, hence > increasing the difficulty in troubleshooting. > Yes, I understand the potential problem if a packet containing an IPv6 address AVP arrives at an IPv4 RADIUS server: 1) Using two different AVPs, one for each address family An IPv6 NAS sends an Access-Request containing Foo-IP-Address AVP and Foo-IPv6-Address AVP to the first hop dual-stack RADIUS server. This RADIUS server proxies the request unmodified onto an IPv4 RADIUS server. The IPv4 RADIUS server ignores Foo-IPv6-Address since it has an unknown Type but otherwise processes the request normally. 2) Using two instances of the same AVP, one for each address family An IPv6 NAS sends an Access-Request containing a 4-byte (IPv4) Foo-IP-Address AVP and an 8-byte (IPv6) Foo-IP-Address AVP to the first hop dual-stack RADIUS server. This RADIUS server proxies the request unmodified onto an IPv4 RADIUS server. The IPv4 RADIUS server drops the request on encountering an 8-byte Foo-IP-Address since it expected a 4-byte IPv4 address. Is this the problem you are refering to? Alternatively, the dual-stack RADIUS server filters out the IPv6 AVPs before sending on the request to the IPv4 RADIUS server. In my example (2) above, the dual-stack RADIUS server removes the 8-byte Foo-IP-Address AVP before forwarding the request. The IPv4 RADIUS server just sees the 4-byte (IPv4) Foo-IP-Address AVP and processes the request normally. Regards, Mark From owner-aaa-bof@merit.edu Thu Jan 11 15:06:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09531 for ; Thu, 11 Jan 2001 15:06:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id A56295DEF9; Thu, 11 Jan 2001 15:04:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E16C5DD95; Thu, 11 Jan 2001 15:04:33 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 627205E012 for ; Thu, 11 Jan 2001 14:59:15 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9827573; Thu, 11 Jan 2001 14:59:22 -0500 (EST) Message-ID: <3A5E10AF.B687C688@Interlinknetworks.com> Date: Thu, 11 Jan 2001 14:59:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: Capabilities Negotiation and proxies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Suppose an AAA server acts as home server for some realms and proxy for others. Then what does it advertise? (Assume that as home server it does not support all extensions, but as a routing proxy it is willing to proxy all extensions.) Pat Calhoun wrote: > > All, > > As discussed a few days ago, a proxy MAY wish to proxy ANY type of message, > regardless of the extension. Therefore, the current text in the base protocol > does not allow this behavior since it would require that proxies advertise ALL > possible extensions. > > Therefore, I am proposing adding the last paragraph to section 2.5.3. > Furthermore, I believe that ALL messages MUST include the extension ID of the > particular message. The reason being that a proxy would need to identify a > server in the home domain that can handle the message, but it may not recognize > the command. > > Comments? Objections? Proposed Text? > > PatC > > 2.5.3 Extension-Id AVP > > The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used > in order to identify a specific DIAMETER extension. This AVP is used > in the Device-Reboot-Ind message in order to inform the peer what > extensions are locally supported. The Extension-Id MUST also be present > in all messages that are defined in a separate DIAMETER specification > and have an Extension ID assigned. > > Each DIAMETER extension draft MUST have an IANA assigned extension > Idenfier (see section 8.3). The base protocol does not require an > Extension-Id since its support is mandatory. > > There MAY be more than one Extension-Id AVP within a DIAMETER > Device-Reboot-Ind message. The following values are recognized: > > NASREQ 1 [7] > Strong Security 2 [11] > Resource Management 3 [29] > Mobile-IP 4 [10] > Accounting 5 [15] > > Furthermore, servers acting as Redirect or Proxy servers (see > Section 6.0) MAY wish to advertise support for ALL possible > extensions. Such servers are then responsible for finding a > downstream server that supports the extension of a particular > message. This is done by including the Extension-Id AVP with a > value of zero (0). -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Thu Jan 11 15:23:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09842 for ; Thu, 11 Jan 2001 15:23:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB8175DEF5; Thu, 11 Jan 2001 15:23:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A8C645DEDF; Thu, 11 Jan 2001 15:23:39 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 69CDC5DEDC for ; Thu, 11 Jan 2001 15:23:38 -0500 (EST) Received: from gwzpc ([64.104.42.105] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id MAA03386; Thu, 11 Jan 2001 12:23:00 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Mark Jones" Cc: , Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 12:13:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] writes: > > Would new RADIUS attributes for IPv6 addresses still be > required if RADIUSv6 > > were to adopt the dual purpose AVP approach? Wouldn't this scheme require changes to RADIUS data types? That can't be done... > > If, as suggested by the > > RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6 > AVPs, the NAS > > can still distinguish the IPv4/IPv6 addresses by their length and so can > > choose the appropriate instance of the address AVP depending on > whether its > > client is IPv4 or IPv6. > > > > If there is not a common approach to IPv4/IPv6 address encoding, the > > DIAMETER-RADIUS gateway must translate, for example, a DIAMETER > > Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host > AVP depending > > on its length. Not complex. Just tedious. Such is the life of a gateway :-) > > But how would you deal with backward compatibility? This seems especially > important given that in a roaming network, you never know whether > the home, or > the NAS, support v6. > > PatC > > > From owner-aaa-bof@merit.edu Thu Jan 11 15:44:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA10134 for ; Thu, 11 Jan 2001 15:44:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B75675DF93; Thu, 11 Jan 2001 15:42:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 992045DF92; Thu, 11 Jan 2001 15:42:03 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 4CE6B5DE8A for ; Thu, 11 Jan 2001 15:42:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13095; Thu, 11 Jan 2001 12:42:00 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA16476; Thu, 11 Jan 2001 12:41:55 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA12597; Thu, 11 Jan 2001 12:41:52 -0800 (PST) Date: Thu, 11 Jan 2001 12:38:14 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Capabilities Negotiation and proxies To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A5E10AF.B687C688@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Then it would return the error code stating that the extension was not supported. Furthermore, I sent some text early this week (or was it last week), that would solve this problem, but it was a major change. It would require that all home servers advertise their local domains. The proxy could then use this information to figure out whether the next hop is a proxy, or a home server for a given domain. btw, I am NOT attempting to create a routing protocol for NAIs. This is a one-hop only thing. Still not really sure that I like this approach either, but I am willing to listen to suggestions. PatC From owner-aaa-bof@merit.edu Thu Jan 11 15:49:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA10200 for ; Thu, 11 Jan 2001 15:49:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 01D065DE7F; Thu, 11 Jan 2001 15:45:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B81AC5DE8A; Thu, 11 Jan 2001 15:45:03 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 61CB75DE7F for ; Thu, 11 Jan 2001 15:45:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13074; Thu, 11 Jan 2001 12:44:58 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA17347; Thu, 11 Jan 2001 12:44:57 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA12665; Thu, 11 Jan 2001 12:44:56 -0800 (PST) Date: Thu, 11 Jan 2001 12:41:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) To: gwz@cisco.com Cc: Pat Calhoun , Mark Jones , 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 Calhoun [mailto:Pat.Calhoun@eng.sun.com] writes: > > > > Would new RADIUS attributes for IPv6 addresses still be > > required if RADIUSv6 > > > were to adopt the dual purpose AVP approach? > > Wouldn't this scheme require changes to RADIUS data types? That can't be > done... That's my point, but Mark is envisioning an environment where proxies strip out AVPs based on the next hop's capabilities (see previous e-mail). Of course, this doesn't help too much in environments where a v6 nas talks to a v4/v6 proxy, to a v4 proxy then to a v4/v6 home server. PatC From owner-aaa-bof@merit.edu Thu Jan 11 16:40:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA10927 for ; Thu, 11 Jan 2001 16:40:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C6F7C5DDBA; Thu, 11 Jan 2001 16:40:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AE8225DE5D; Thu, 11 Jan 2001 16:40:19 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 5CBF15DDBA for ; Thu, 11 Jan 2001 16:40:18 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0BLe5U80617; Thu, 11 Jan 2001 16:40:05 -0500 (EST) (envelope-from barney) Date: Thu, 11 Jan 2001 16:40:05 -0500 From: Barney Wolff To: Pat Calhoun Cc: David Spence , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: Capabilities Negotiation and proxies Message-ID: <20010111164005.A80566@mx.databus.com> References: <3A5E10AF.B687C688@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@eng.sun.com on Thu, Jan 11, 2001 at 12:38:14PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Tell us why a requester should know or care whether its "server" is actually a home server or another proxy. IMHO, that would be a really bad thing. We're running into the downside of session-oriented AAA, when the underlying situation is independent transactions. I suggest we simply ignore it - the AAA requester should be configured for the server it talks to "most of the time" and just recover in real time from what should be very rare cases, that a Mandatory AVP, or even a whole extension, is not understood by some roamer's home server. Barney On Thu, Jan 11, 2001 at 12:38:14PM -0800, Pat Calhoun wrote: > Then it would return the error code stating that the extension was not > supported. Furthermore, I sent some text early this week (or was it last > week), that would solve this problem, but it was a major change. It would > require that all home servers advertise their local domains. The proxy could > then use this information to figure out whether the next hop is a proxy, or a > home server for a given domain. > > btw, I am NOT attempting to create a routing protocol for NAIs. This is a > one-hop only thing. > > Still not really sure that I like this approach either, but I am willing to > listen to suggestions. > > PatC > > From owner-aaa-bof@merit.edu Thu Jan 11 17:18:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA11599 for ; Thu, 11 Jan 2001 17:18:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id C42AD5DE6D; Thu, 11 Jan 2001 17:16:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B26615DE66; Thu, 11 Jan 2001 17:16:23 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DDA935DDEF for ; Thu, 11 Jan 2001 17:16:22 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 559F574 for ; Thu, 11 Jan 2001 17:16:30 -0500 (EST) From: "Bob Kopacz" To: "Aaa-Wg" Subject: DIAMETER Base Protocol (Alpha 1) / 2.5.1 Vendor-Name AVP Date: Thu, 11 Jan 2001 17:15:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, The DRI contains a Vendor-Name AVP, which the draft says is so that a Diameter peer might "know which vendor specific attributes may be sent to the peer". Since it is the 32-bit vendor number that appears in the AVP header and in the Diameter header, should the DRI instead include a Vendor-ID AVP which contains the vendor's enterprise code? It seems a vendor ID value would be more directly useful for the above-mentioned purpose. Or if the Vendor-Name AVP is the way to go, should there be a list of vendor name strings so that they can be mapped to known vendors, and an indication if this string is case-sensitive, etc.? The "DIAMETER Base Protocol (Alpha 1)" document says: > 2.5.1 Vendor-Name AVP > > The Vendor-Name AVP (AVP Code 266) is of type > OctetString and is used to inform a DIAMETER peer of the > Vendor Name of the DIAMETER device. This MAY be used in > order to know which vendor specific attributes may be > sent to the peer. It is also envisioned that the > combination of the Vendor-Name and the Firmware-Revision > (section 2.5.2) AVPs MAY provide very useful debugging > information. From owner-aaa-bof@merit.edu Thu Jan 11 17:25:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA11677 for ; Thu, 11 Jan 2001 17:25:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD37A5DE9E; Thu, 11 Jan 2001 17:21:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9AA855DEA5; Thu, 11 Jan 2001 17:21:38 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 21E095DE93 for ; Thu, 11 Jan 2001 17:21:37 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16208; Thu, 11 Jan 2001 14:21:35 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04168; Thu, 11 Jan 2001 14:21:35 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA28320; Thu, 11 Jan 2001 14:21:34 -0800 (PST) Date: Thu, 11 Jan 2001 14:17:55 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: DIAMETER Base Protocol (Alpha 1) / 2.5.1 Vendor-Name AVP To: Bob Kopacz Cc: 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 I have no idea why a name was chosen over the IANA managed value. I agree that using the value that one would find in the Vendor-Id field seems much more reasonable. I think that the name was added for debugging purpose so users (that have no idea what IANA, much less enterprise numbers) can figure out what's at the other end. What do other prefer? Just the ID, or both? Thanks for the great catch! PatC > Hi Pat, > > The DRI contains a Vendor-Name AVP, which the draft says > is so that a Diameter peer might "know which vendor > specific attributes may be sent to the peer". > > Since it is the 32-bit vendor number that appears in the > AVP header and in the Diameter header, should the DRI > instead include a Vendor-ID AVP which contains the > vendor's enterprise code? It seems a vendor ID value > would be more directly useful for the above-mentioned > purpose. > > Or if the Vendor-Name AVP is the way to go, should there > be a list of vendor name strings so that they can be > mapped to known vendors, and an indication if this string > is case-sensitive, etc.? > > The "DIAMETER Base Protocol (Alpha 1)" document says: > > > 2.5.1 Vendor-Name AVP > > > > The Vendor-Name AVP (AVP Code 266) is of type > > OctetString and is used to inform a DIAMETER peer of the > > Vendor Name of the DIAMETER device. This MAY be used in > > order to know which vendor specific attributes may be > > sent to the peer. It is also envisioned that the > > combination of the Vendor-Name and the Firmware-Revision > > (section 2.5.2) AVPs MAY provide very useful debugging > > information. > > From owner-aaa-bof@merit.edu Thu Jan 11 17:28:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA11700 for ; Thu, 11 Jan 2001 17:28:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D0A05DE99; Thu, 11 Jan 2001 17:27:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 89E6B5DE9A; Thu, 11 Jan 2001 17:27:53 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BAF2B5DE99 for ; Thu, 11 Jan 2001 17:27:52 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 232F575 for ; Thu, 11 Jan 2001 17:28:00 -0500 (EST) From: "Bob Kopacz" To: "Aaa-Wg" Subject: DIAMETER Base Protocol (Alpha 1) / 2.4 State Machine Date: Thu, 11 Jan 2001 17:27:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Here's a couple State/Event combinations that are not mentioned in the "2.4 State Machine" section, as to what to do if you receive something other than a DRI in response to your DRI. Case 1: State Event Action New State ----- ----- ------ --------- Wait-DRI Receive MRI (to my DRI*) ? ? *In this case, I guess you recognize that the MRI is in response to your DRI by matching the Identifier. Does action depend on whether MRI is in response to my DRI, or is some out-of-the-blue MRI? I'd guess that, in either case, Action = Clean up & New State = Closed. Case 2: State Event Action New State ----- ----- ------ --------- Wait-DRI Receive message other than ? ? MRI or DRI. I'd guess either Action = Ignore & New State = Wait-DRI, or Action = Clean up & New State = Closed. From owner-aaa-bof@merit.edu Thu Jan 11 17:44:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA11875 for ; Thu, 11 Jan 2001 17:44:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F5CA5DD8D; Thu, 11 Jan 2001 17:43:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5C94C5DDEF; Thu, 11 Jan 2001 17:43:50 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 15AA95DD8D for ; Thu, 11 Jan 2001 17:43:49 -0500 (EST) Received: from gwzpc ([10.64.194.1] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA28550; Thu, 11 Jan 2001 14:37:58 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Mark Jones" , "Pat Calhoun" Cc: Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 14:28:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <00ff01c07c06$68110dd0$2096a8c0@bridgewatersys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Mark Jones [mailto:mjones@bridgewatersystems.com] writes: > Pat, > > [diameter@diameter.org removed from CC list. Thread concerns RADIUSv6.] > > > > > Right, but chances of getting *something* back from the home > > server are quite > > high if two attributes are added, one for each address family, as > > opposed to > > inserting an IPv6 in an attribute that the home server expected > to be only > > 32bit in length. Chances it would drop the request in this case, hence > > increasing the difficulty in troubleshooting. > > > > Yes, I understand the potential problem if a packet containing an IPv6 > address AVP arrives at an IPv4 RADIUS server: > > 1) Using two different AVPs, one for each address family > > An IPv6 NAS sends an Access-Request containing Foo-IP-Address AVP and > Foo-IPv6-Address AVP to the first hop dual-stack RADIUS server. Why does the RADIUS server need to be dual-stack? We're talking attributes here... > This RADIUS > server proxies the request unmodified onto an IPv4 RADIUS server. The IPv4 > RADIUS server ignores Foo-IPv6-Address since it has an unknown Type but > otherwise processes the request normally. > > 2) Using two instances of the same AVP, one for each address family > > An IPv6 NAS sends an Access-Request containing a 4-byte (IPv4) > Foo-IP-Address AVP and an 8-byte (IPv6) Foo-IP-Address AVP to the > first hop > dual-stack RADIUS server. If the 'Foo'=='NAS' in this case, it is prohibited by RFC 2865. > This RADIUS server proxies the request > unmodified > onto an IPv4 RADIUS server. The IPv4 RADIUS server drops the request on > encountering an 8-byte Foo-IP-Address since it expected a 4-byte IPv4 > address. > > Is this the problem you are refering to? > > Alternatively, the dual-stack RADIUS server filters out the IPv6 > AVPs before > sending on the request to the IPv4 RADIUS server. In my example (2) above, > the dual-stack RADIUS server removes the 8-byte Foo-IP-Address AVP before > forwarding the request. The IPv4 RADIUS server just sees the 4-byte (IPv4) > Foo-IP-Address AVP and processes the request normally. I don't think that it matters what version of IP the RADIUS server is running, just what Attributes it supports. The reason why new Attributes were defined is that the kind ofthing you are describing is illegal in RADIUS. > > Regards, > Mark > > > From owner-aaa-bof@merit.edu Thu Jan 11 17:57:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA12051 for ; Thu, 11 Jan 2001 17:57:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id B304D5DE9B; Thu, 11 Jan 2001 17:53:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 692DF5DF0B; Thu, 11 Jan 2001 17:53:00 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 57D535DE98 for ; Thu, 11 Jan 2001 17:52:57 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0BMngR06251; Thu, 11 Jan 2001 14:49:42 -0800 From: "Bernard Aboba" To: "Pat Calhoun" Cc: "Aaa-Wg@Merit. Edu" Subject: RE: Security proposals for Interim meeting, Feburary 7, 2001 Date: Thu, 11 Jan 2001 14:53:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk I wouldn't assume that anything is out. We're just asking people to justify whatever they want to put in :) Contributions welcome. -----Original Message----- From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Thursday, January 11, 2001 10:01 AM To: Bernard Aboba Cc: Aaa-Wg@Merit. Edu Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001 Bernard, Should I assume from your e-mail that hop-by-hop is out in the base spec? I think discounting hop security is a mistake. Should I bring a contribution detailing this method? PatC > So that we can be prepared for our interim meeting on > February 7, 2001, I'd like to ask for volunteers to > present security proposals. These proposals should be > complete in the sense that they describe everything > that is required to solve the security issues that > we face. > > The goal of the exercise will be to convince the > WG that one or more of the proposals are viable in > the real world. > > Here's a first cut at what is needed for the various > proposals: > > 1. CMS. I'd like to see a proposal on how CMS can be > used for both e2e and hop-by-hop security. Also, given > this I'd like to understand whether password hiding is > still necessary, and if so, why. The proposal should > be clear about: > a. Whether PKI is required or not, and exactly > what infrastructure is needed (CRL servers, > offline/online CAs, etc.) > b. Efficiency issues (key reuse) > c. Code size and implementation availability > (can this be implemented on a NAS?) > > 2. GSS_API. I'd like to see a proposal describing > the deployment scenarios in more detail. > Issues to discuss further include: > a. GSS_API methods that could be supported > within the 1 round trip framework (is this > only Kerberos V?) > b. Proposed mandatory to implement method > c. Code size and availability > d. Deployment implications > 1. Kerberos KDC on the Internet? > 2. IAKERB proxies? > 3. DNS support for KDC location? > 4. Authorization issues > > 3. IPSEC. > Issues to discuss further include: > a. Can use of ESP with non-null transform > eliminate need for password hiding? > b. Can IKE MM cert policy validate biz relationships or > is this asking too much? > c. Security implications of referral > 1. Firewall hole for IPSEC/IKE from any source to > AAA server > 2. AAA server does packet filtering not firewall > 3. Implications for NAS vulnerabilities > > > From owner-aaa-bof@merit.edu Thu Jan 11 18:03:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12170 for ; Thu, 11 Jan 2001 18:03:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id E166D5DEBC; Thu, 11 Jan 2001 18:00:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4A3B65DF30; Thu, 11 Jan 2001 18:00:25 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 124295DEA4 for ; Thu, 11 Jan 2001 17:57:24 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0BMs9R06465; Thu, 11 Jan 2001 14:54:09 -0800 From: "Bernard Aboba" To: "Barney Wolff" Cc: "Aaa-Wg@Merit. Edu" Subject: RE: Security proposals for Interim meeting, Feburary 7, 2001 Date: Thu, 11 Jan 2001 14:57:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010111131413.B79807@mx.databus.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >Re IKE-from-anywhere, how does a roaming VPN setup work, if not that? >I too wish that IKE were less DoSable, though. Indeed, a VPN taking connections from anywhere would indeed work like this in terms of the firewall filters. However, we don't see that many people installing servers as VPN termination devices; most seem to use embedded VPN devices, partly due to security concerns. Also in the VPN case, you can assume that the users would have certs from the enterprise that you're offering access to. In the AAA case, the roaming associations are the trusted root CAs. That's very tricky to pull off. From owner-aaa-bof@merit.edu Thu Jan 11 18:13:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12313 for ; Thu, 11 Jan 2001 18:13:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id B27775DE7C; Thu, 11 Jan 2001 18:13:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2D7F5DE7B; Thu, 11 Jan 2001 18:13:00 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 64DF45DE60 for ; Thu, 11 Jan 2001 18:12:59 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA17265; Thu, 11 Jan 2001 19:08:50 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA21049; Thu, 11 Jan 2001 18:13:19 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 18:19:58 -0500 Message-ID: <012901c07c25$03cee9e0$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > Of course, this doesn't help too much in environments where a v6 nas > talks to a v4/v6 proxy, to a v4 proxy then to a v4/v6 home server. > Yes, you're right. The IPv6 AVP filtering definitely fails in this scenario. I've learned my lesson: Don't try to ease the migration by trying to mess with the legacy protocol. Regards, Mark From owner-aaa-bof@merit.edu Thu Jan 11 18:19:01 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12377 for ; Thu, 11 Jan 2001 18:19:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 961675DE66; Thu, 11 Jan 2001 18:15:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8130D5DE71; Thu, 11 Jan 2001 18:15:44 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 639275DE66 for ; Thu, 11 Jan 2001 18:15:43 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA17279; Thu, 11 Jan 2001 19:11:34 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA21075; Thu, 11 Jan 2001 18:16:02 -0500 (EST) From: "Mark Jones" To: Cc: Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) Date: Thu, 11 Jan 2001 18:22:42 -0500 Message-ID: <012c01c07c25$65840940$2096a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Glen, > Why does the RADIUS server need to be dual-stack? We're talking > attributes > here... > I meant that the host on which the RADIUS server was running has both IPv4 and IPv6 connections. This is obviously only relevant if the RADIUS server is manipulating attributes depending on whether the destination is a v4 or v6 host. I now understand where this approach fails in a proxy chain scenario (see my reply to Pat). Regards, Mark From owner-aaa-bof@merit.edu Thu Jan 11 18:25:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12572 for ; Thu, 11 Jan 2001 18:25:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E86F5E027; Thu, 11 Jan 2001 18:23:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 272455E026; Thu, 11 Jan 2001 18:23:49 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D4D335DEE3 for ; Thu, 11 Jan 2001 18:23:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02982; Thu, 11 Jan 2001 15:23:19 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20372; Thu, 11 Jan 2001 15:23:19 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA00458; Thu, 11 Jan 2001 15:23:09 -0800 (PST) Date: Thu, 11 Jan 2001 15:19:30 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] data type modifications to DIAMETER (Fwd) To: Mark Jones Cc: gwz@cisco.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <012c01c07c25$65840940$2096a8c0@bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Glen, > > > Why does the RADIUS server need to be dual-stack? We're talking > > attributes > > here... > > > > I meant that the host on which the RADIUS server was running has both IPv4 > and IPv6 connections. This is obviously only relevant if the RADIUS server > is manipulating attributes depending on whether the destination is a v4 or > v6 host. I now understand where this approach fails in a proxy chain > scenario (see my reply to Pat). > Glen's question was more to the fact that a RADIUS server doesn't have to be dual stack (or support both IP protocols in the kernel). It merely has to be able to support both address families in the server (app layer) implementation. So your use of dual-stack was a little misleading. PatC From owner-aaa-bof@merit.edu Fri Jan 12 04:22:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA20681 for ; Fri, 12 Jan 2001 04:22:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 750045DDB4; Fri, 12 Jan 2001 04:22:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4C7135DDAA; Fri, 12 Jan 2001 04:22:25 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id 5D52A5DDB4 for ; Fri, 12 Jan 2001 04:22:23 -0500 (EST) Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA24138; Fri, 12 Jan 2001 10:23:16 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" , , Subject: RE: Capabilities Negotiation and proxies Date: Fri, 12 Jan 2001 10:24:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, If there MUST be an Extension-Id AVP in all messages defined in other DIAMETER specifications, the the section below: "There MAY be more than one Extension-Id AVP within a DIAMETER Device-Reboot-Ind message. The following values are recognized:" should be changed to: "There MAY be more than one Extension-Id AVP within a DIAMETER message. The following values are recognized:" Since one can for example use Strong Security together with another extension in the same message. B.R. /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 11 januari 2001 01:56 >To: aaa-wg@merit.edu; diameter@diameter.org >Subject: Capabilities Negotiation and proxies > > >All, > >As discussed a few days ago, a proxy MAY wish to proxy ANY type of message, >regardless of the extension. Therefore, the current text in the >base protocol >does not allow this behavior since it would require that proxies >advertise ALL >possible extensions. > >Therefore, I am proposing adding the last paragraph to section 2.5.3. >Furthermore, I believe that ALL messages MUST include the >extension ID of the >particular message. The reason being that a proxy would need to identify a >server in the home domain that can handle the message, but it may >not recognize >the command. > >Comments? Objections? Proposed Text? > >PatC > >2.5.3 Extension-Id AVP > > The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used > in order to identify a specific DIAMETER extension. This AVP is used > in the Device-Reboot-Ind message in order to inform the peer what > extensions are locally supported. The Extension-Id MUST also be present > in all messages that are defined in a separate DIAMETER specification > and have an Extension ID assigned. > > Each DIAMETER extension draft MUST have an IANA assigned extension > Idenfier (see section 8.3). The base protocol does not require an > Extension-Id since its support is mandatory. > > There MAY be more than one Extension-Id AVP within a DIAMETER > Device-Reboot-Ind message. The following values are recognized: > > NASREQ 1 [7] > Strong Security 2 [11] > Resource Management 3 [29] > Mobile-IP 4 [10] > Accounting 5 [15] > > Furthermore, servers acting as Redirect or Proxy servers (see > Section 6.0) MAY wish to advertise support for ALL possible > extensions. Such servers are then responsible for finding a > downstream server that supports the extension of a particular > message. This is done by including the Extension-Id AVP with a > value of zero (0). > From owner-aaa-bof@merit.edu Fri Jan 12 08:55:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA24553 for ; Fri, 12 Jan 2001 08:55:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id DED0F5DDE8; Fri, 12 Jan 2001 08:54:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C30E95DDCD; Fri, 12 Jan 2001 08:54:50 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8FC2B5DDAA for ; Fri, 12 Jan 2001 08:54:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06445; Fri, 12 Jan 2001 05:54:45 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA01611; Fri, 12 Jan 2001 05:54:44 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA21918; Fri, 12 Jan 2001 05:54:43 -0800 (PST) Date: Fri, 12 Jan 2001 05:51:05 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: Capabilities Negotiation and proxies To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org 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 Agreed, but I am still waiting for some level of affirmation from the list that including the Extension Id would benefit proxies that only support forwarding and/or redirecting of messages, and extensions are supported on the home servers. Anyone?? PatC > Hi Pat, > > If there MUST be an Extension-Id AVP in all messages defined in other > DIAMETER specifications, the the section below: > > "There MAY be more than one Extension-Id AVP within a DIAMETER > Device-Reboot-Ind message. The following values are recognized:" > > should be changed to: > > "There MAY be more than one Extension-Id AVP within a DIAMETER message. The > following values are recognized:" > > Since one can for example use Strong Security together with another > extension in the same message. > > B.R. > /Fredrik > > >-----Original Message----- > >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > >Of Pat Calhoun > >Sent: den 11 januari 2001 01:56 > >To: aaa-wg@merit.edu; diameter@diameter.org > >Subject: Capabilities Negotiation and proxies > > > > > >All, > > > >As discussed a few days ago, a proxy MAY wish to proxy ANY type of message, > >regardless of the extension. Therefore, the current text in the > >base protocol > >does not allow this behavior since it would require that proxies > >advertise ALL > >possible extensions. > > > >Therefore, I am proposing adding the last paragraph to section 2.5.3. > >Furthermore, I believe that ALL messages MUST include the > >extension ID of the > >particular message. The reason being that a proxy would need to identify a > >server in the home domain that can handle the message, but it may > >not recognize > >the command. > > > >Comments? Objections? Proposed Text? > > > >PatC > > > >2.5.3 Extension-Id AVP > > > > The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used > > in order to identify a specific DIAMETER extension. This AVP is used > > in the Device-Reboot-Ind message in order to inform the peer what > > extensions are locally supported. The Extension-Id MUST also be present > > in all messages that are defined in a separate DIAMETER specification > > and have an Extension ID assigned. > > > > Each DIAMETER extension draft MUST have an IANA assigned extension > > Idenfier (see section 8.3). The base protocol does not require an > > Extension-Id since its support is mandatory. > > > > There MAY be more than one Extension-Id AVP within a DIAMETER > > Device-Reboot-Ind message. The following values are recognized: > > > > NASREQ 1 [7] > > Strong Security 2 [11] > > Resource Management 3 [29] > > Mobile-IP 4 [10] > > Accounting 5 [15] > > > > Furthermore, servers acting as Redirect or Proxy servers (see > > Section 6.0) MAY wish to advertise support for ALL possible > > extensions. Such servers are then responsible for finding a > > downstream server that supports the extension of a particular > > message. This is done by including the Extension-Id AVP with a > > value of zero (0). > > > From owner-aaa-bof@merit.edu Fri Jan 12 11:34:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA29164 for ; Fri, 12 Jan 2001 11:34:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF9505DEAD; Fri, 12 Jan 2001 11:33:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BD7E95DEAC; Fri, 12 Jan 2001 11:33:18 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 312B95DEA5 for ; Fri, 12 Jan 2001 11:33:15 -0500 (EST) Received: (qmail 15870 invoked by uid 500); 12 Jan 2001 16:35:02 -0000 Date: Fri, 12 Jan 2001 10:35:01 -0600 From: David Frascone To: aaa-wg@merit.edu, diameter@diameter.org Subject: Comments on draft-calhoun-diameter-18.txt Message-ID: <20010112103501.H14405@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Ok, here are my comments. Some are nits, others are what *I* think needs to change. --------- General: The difference between Request/Answer and Query/Reply was never defined. Section 1.0 Introduction Editorial/Nit The "required features" bullets all have a strange voice. They're clauses, but not necessarily noun clauses. The prepositions have to go. For example, I'd change the last one to: - Exchanges resource usage information, which MAY be used for accounting purposes, capacity planning, etc. Section 2.1 Header Format > The base DIAMETER protocol is run over SCTP [26] port 1812. > Implementations MAY send packets from any source port, but MUST be > prepared to receive packets on port 1812. When a request is received, > in order to send a reply, the source and destination ports in the > reply are reversed. Note that the source and destination addresses > used in request and replies MAY be any of the peer's valid IP > addresses. > A given DIAMETER process SHOULD use the same port number to send all > messages to aid in identifying which process sent a given message. > More than one DIAMETER process MAY exist within a single host, so the > sender's port number is needed to discriminate them. Since the servers MUST run on port 1812, their can *not* be multiple servers on a single host. So, I think the second paragraph should be deleted. PCC: Since Diameter no longer runs over UDP, there is no reason to keep PCC for transport-layer RADIUS compatibility. I realize that to keep the words 16 bit (at least) aligned, Diameter will end up with 13 bits of flags, but I think that is better than wasting 8 on a PCC. 2.2.1 AVP Header > The AVP Format is shown below and MUST be sent in network byte order. Nit: It's a run-on (or strangely worded) sentence. *Some* fields must be sent in network byte order (i.e. data may or may not be). So, I think that part needs to be removed from the sentence, and stated in the individual fields that *are* sent in network byte order. AVP Length Nit: "Attribute" and "Invalid" don't need to be capitalized. Perhaps "invalid attribute length" needs to be defined (i.e. zero, less than the maximum header size, greater than the maximum message size, etc) AVP Flags "Home server" is used here, and has not been defined. I think we need to either define "Home server", or use a different name. "Logical destination" is also used to refer to a "Home server" Perhaps this is a better term. 2.2.2 Optional Header Elements > The AVP Header consists of several optional fields. These fields are > only present if their respective bit-flags are enabled. change to: The AVP Header contains one optional field, the Vendor-ID. This field is only present if the 'V' bit is set. 2.2.3 AVP Value Formats "Value field" and "Data field" are used interchangeably. We should pick one. 3.3 Session-Timeout AVP The last line in the section does not need to be there. The zero case was defined in the previous paragraph. 6.4.x Proxy-State The Proxy-Address AVP and Proxy-Info AVP both refer to section 6.4.4 for descriptions of them. There are no descriptions there. 7.1 Hop-by-Hop Security The phrase "similar to the method employed by the RADIUS protocol." should be removed. The only similarity to RADIUS is that the data is encrypted by moving the MD5 hash around. Since we're probably going to be using AES, I think this phrase is unnecessary. 7.1.2.1.1 The payload hiding is not backward compatible with RADIUS. (The encryption algorithm is, but since RADIUS wouldn't know what to do with the packet, I think this sentence is misleading) Ok, I think that's it. Sorry it's so long. I guess I'm more opinionated that I thought. -Dave From owner-aaa-bof@merit.edu Fri Jan 12 17:34:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA06750 for ; Fri, 12 Jan 2001 17:34:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF4985DE93; Fri, 12 Jan 2001 17:31:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 902405DE96; Fri, 12 Jan 2001 17:31:35 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id F014A5DE93 for ; Fri, 12 Jan 2001 17:31:33 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0CMSGR19277 for ; Fri, 12 Jan 2001 14:28:16 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: Meetings during 50th IETF in Minneapolis Date: Fri, 12 Jan 2001 14:31:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk I'm about to submit a request for meeting slots for the AAA WG in Minneapolis. We will meet twice. If you have any agenda items or specific conflicts with other WGs that you would like to avoid, please let me know. - Bernard From owner-aaa-bof@merit.edu Fri Jan 12 17:34:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA06760 for ; Fri, 12 Jan 2001 17:34:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55FB55DEAB; Fri, 12 Jan 2001 17:32:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 42B815DEA4; Fri, 12 Jan 2001 17:32:32 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 05D5E5DEA3 for ; Fri, 12 Jan 2001 17:32:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02913; Fri, 12 Jan 2001 14:32:29 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA20881; Fri, 12 Jan 2001 14:32:28 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA05568; Fri, 12 Jan 2001 14:32:25 -0800 (PST) Date: Fri, 12 Jan 2001 14:28:48 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: Comments on draft-calhoun-diameter-18.txt To: David Frascone Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <20010112103501.H14405@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > The difference between Request/Answer and Query/Reply was never > defined. It is specified in the framework document. > > Section 1.0 Introduction > > Editorial/Nit > The "required features" bullets all have a strange voice. They're > clauses, but not necessarily noun clauses. The prepositions have > to go. For example, I'd change the last one to: > > - Exchanges resource usage information, which MAY be used for > accounting purposes, capacity planning, etc. Thanks, those bullet items did require a rework. > > > Section 2.1 Header Format > > > A given DIAMETER process SHOULD use the same port number to send all > > messages to aid in identifying which process sent a given message. > > More than one DIAMETER process MAY exist within a single host, so the > > sender's port number is needed to discriminate them. > > > Since the servers MUST run on port 1812, their can *not* be multiple > servers on a single host. So, I think the second paragraph should > be deleted. hmmmm.... I am not sure about removing this one. Anyone have an issue with removing it? > > > PCC: > Since Diameter no longer runs over UDP, there is no reason to keep > PCC for transport-layer RADIUS compatibility. > > I realize that to keep the words 16 bit (at least) aligned, Diameter > will end up with 13 bits of flags, but I think that is better than > wasting 8 on a PCC. I would MUCH prefer make the version field be 8 bits and the flags field be 8 bits. Anyone else? > AVP Flags > > "Home server" is used here, and has not been defined. I think > we need to either define "Home server", or use a different name. > "Logical destination" is also used to refer to a "Home server" > Perhaps this is a better term. Home Server will be in the Terminology section of the new Framework document. > 7.1 Hop-by-Hop Security > > The phrase "similar to the method employed by the RADIUS protocol." > should be removed. The only similarity to RADIUS is that the > data is encrypted by moving the MD5 hash around. Since we're probably > going to be using AES, I think this phrase is unnecessary. Well, the app level security, which makes use of shared secrets, are similar to those in RADIUS. However, given that the authentication is much stronger than RADIUS, it probably doesn't do DIAMETER justice. I will remove it. Thanks for your comments! PatC From owner-aaa-bof@merit.edu Fri Jan 12 17:35:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA06775 for ; Fri, 12 Jan 2001 17:35:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 120655DEB6; Fri, 12 Jan 2001 17:33:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F10C85DEB9; Fri, 12 Jan 2001 17:33:32 -0500 (EST) Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by segue.merit.edu (Postfix) with ESMTP id AC2D15DEB6 for ; Fri, 12 Jan 2001 17:33:31 -0500 (EST) Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 17:25:50 -0500 Message-ID: From: "Weiss, Walter" To: Pat Calhoun , David Spence Cc: AAA Working Group Subject: RE: Choice of Data Model SMI vs XML vs. UML Date: Fri, 12 Jan 2001 17:25:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07CE6.9DF2B468" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07CE6.9DF2B468 Content-Type: text/plain; charset="iso-8859-1" I am somewhat baffled by this whole discussion. There is a clear trend to move service intelligence to the edges. The configuration is not limited to user identity, but nearly every aspect network usage from Tunnels to QoS to Security to service access and forwarding rules. Many or all of these will be keyed off of a user profile. With this in mind, what kind of framework do we want that will support all these capabilities. I would submit that a vertical model that assumes that a network edge device will be configured by a large cross-section of protocols (User stuff with Diameter, QoS with COPS, Security with SNMP, and service access with SIP) is doomed to failure because of the implicit inter-relationships between these technologies and the complexity of configuration and management. If the argument is that Diameter is only going to support a very restrictive set of functions, specified with a relatively small set of attributes, I have to agree with sentiment that a data modeling exercise is not worth the effort for this WG. I would also predict that the protocol will be obsolete before it is deployed (per the previous paragraph). If, in contrast, there is an implicit goal in AAA to (eventually) support an extensible set of capabilities, including (but not limited to) those listed above, we face an ever more complex set of relationships between existing and newly defined attributes that MUST be facilitated by structured data (such as objects), reuse (as with inheritance and encapsulation) and well defined relationships between data structures (associations or pointers). If the WG conclude that the previous paragraph is the preferred approach, there have been numerous comments outlining XML's inability to support reuse and relationships as well as other limitations. This leaves us with a two alternatives, SPPI and SMIng. I actually don't have a preference between the two, but I would say if that if this WG is willing to be gated by the standardizing of SMIng than that would be the better choice. If not, SPPI is the less optimal but more immediate alternative that SMIng is supposed to be backward compatible with. regards, -Walter > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Friday, January 05, 2001 10:04 AM > To: David Spence > Cc: AAA Working Group > Subject: Re: Choice of Data Model SMI vs XML vs. UML > > > > 1. SMI Derivative vs. XML > > > > An advantage of using some derivative of SMI over XML is > that the > > "formal specification" can actually be implemented in the edge > > device. This improves interoperability and allows interworking > > between tools that use different protocols. > > > > 2. Which derivative of SMI to use > > > > I don't have strong feelings as to which SMI derivative > is best. We > > chose SPPI for draft-spence-aaa-nas-data-model-00.txt > because it was > > designed for policy provisioning, is compatible with > COPS (more on > > this at item 3, below), and is somewhat more mature > than SMIng (has > > passed WG last call and is ready for IETF last call). > > > > The AAA WG may prefer to be more forward looking and use > SMIng or to > > opt for greater maturity and use SMI v2. > > > > Whatever the WG decides, it MUST be something mature, and > currently work in > progress. > > > 3. Interworking COPS and DIAMETER > > > > If the AAA WG chooses XML or chooses an SMI derivative > for formal > > notation only without providing a protocol mapping, then the > > following problem arises. > > > > Suppose an edge device wishes to provide both network access and > > premium QoS. It would be nice to be able to obtain a single > > admission decision covering both the network access and > the premium > > QoS with a single request. It is troublesome to the ISP > to allocate > > QoS resources and then deny access or to create an > access session and > > then have to terminate it because the QoS request > failed. If the > > edge device has to use DIAMETER to obtain the network access > > admission decision and COPS to obtain the QoS admission > decision, it > > will be very difficult to coordinate the two decisions. If this > > happens, someone might be tempted to doubt the IETF's wisdom in > > standardizing two protocols where one might have sufficed. > > > > Of course, if the two protocols use the same data model, > then the > > problem goes away. Either protocol could be used for > either type of > > request, so the edge device could request the two > related services in > > a single message using either protocol. > > > > But if the two protocols do not use the same data model, then it > > might be a good idea to create an escape mechanism. Could we at > > least define a DIAMETER AVP type of COPS message or COPS > object which > > means, "shell out to the part of the AAA server that understands > > COPS, process this thing and then return"? That way, at > least, the > > two requests could be piggybacked onto the same message > so that a > > sophisticated enough AAA server could process them together. > > Just to be clear, I am not sure how allowing the dictionary > and other config > files), and the documentation to specify message formats in > XML or SMI to > really help interworking of protocols on the wire :( > > The scenario you described above *will* happen, and in the > cases that I've > seen, the local PDP will contact the local DIAMETER server to > retrieve user > profile information, since the information is in the user's > home network and > COPS doesn't do inter-domain. > > > 4. What combinations of attributes make sense? > > > > A problem which RADIUS leaves unaddressed and which so > far has not > > been addressed by DIAMETER is the question of which > attributes can > > and can not be meaningfully combined in a message. Or, > to put it > > another way, which attributes pertain to which services. > Here's an > > example. > > > > The description of the Termination-Action attribute in > RFC 2865 says > > simply, > > > > "This Attribute indicates what action the NAS should > take when the > > specified service is completed. It is only used in > Access-Accept > > packets." > > > > The RFC does not specify which services the attribute > applies to. I > > assume it applies to the Login service. Could it also > apply to the > > Framed service? If I combine it with attributes such as > > Framed-Protocol, Framed-IP-Address, and > Framed-IP-Netmask, what am I > > expecting the NAS to do? > > > > A data model provides an answer to this sort of question > by grouping > > elementary attributes by service. If an attribute applies to a > > service it is included with the service, either directly or by > > association. If an attribute does not apply, then it is > not included > > in that part of the model. Ambiguities are resolved, and > > interoperability is enhanced. > > I agree that the specifications must be clear. If in theNAS > dial-up world > certain ambiguities still exist, then let's fix them in the spec. One > possibility is to make use of different command sets for PPP > and terminal > server. In fact, this would REALLY clean up the extension IMHO. > > PatC > > ------_=_NextPart_001_01C07CE6.9DF2B468 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Choice of Data Model SMI vs XML vs. UML

I am somewhat baffled by this whole discussion. There = is a clear trend to move service intelligence to the edges. The = configuration is not limited to user identity, but nearly every aspect = network usage from Tunnels to QoS to Security to service access and = forwarding rules. Many or all of these will be keyed off of a user = profile.

With this in mind, what kind of framework do we want = that will support all these capabilities. I would submit that a = vertical model that assumes that a network edge device will be = configured by a large cross-section of protocols (User stuff with = Diameter, QoS with COPS, Security with SNMP, and service access with = SIP) is doomed to failure because of the implicit inter-relationships = between these technologies and the complexity of configuration and = management.

If the argument is that Diameter is only going to = support a very restrictive set of functions, specified with a = relatively small set of attributes, I have to agree with sentiment that = a data modeling exercise is not worth the effort for this WG. I would = also predict that the protocol will be obsolete before it is deployed = (per the previous paragraph).

If, in contrast, there is an implicit goal in AAA to = (eventually) support an extensible set of capabilities, including (but = not limited to) those listed above, we face an ever more complex set of = relationships between existing and newly defined attributes that MUST = be facilitated by structured data (such as objects), reuse (as with = inheritance and encapsulation) and well defined relationships between = data structures (associations or pointers).

If the WG conclude that the previous paragraph is the = preferred approach, there have been numerous comments outlining XML's = inability to support reuse and relationships as well as other = limitations. This leaves us with a two alternatives, SPPI and SMIng. I = actually don't have a preference between the two, but I would say if = that if this WG is willing to be gated by the standardizing of SMIng = than that would be the better choice. If not, SPPI is the less optimal = but more immediate alternative that SMIng is supposed to be backward = compatible with.

regards,

-Walter
 
> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: Friday, January 05, 2001 10:04 AM
> To: David Spence
> Cc: AAA Working Group
> Subject: Re: Choice of Data Model SMI vs XML = vs. UML
>
>
> > 1. SMI Derivative vs. XML
> >
> >    An advantage of using = some derivative of SMI over XML is
> that the
> >    "formal = specification" can actually be implemented in the edge
> >    device.  This = improves interoperability and allows interworking
> >    between tools that use = different protocols.
> >
> > 2. Which derivative of SMI to use
> >   
> >    I don't have strong = feelings as to which SMI derivative
> is best.  We
> >    chose SPPI for = draft-spence-aaa-nas-data-model-00.txt
> because it was
> >    designed for policy = provisioning, is compatible with
> COPS (more on
> >    this at item 3, = below),  and is somewhat more mature
> than SMIng (has
> >    passed WG last call and = is ready for IETF last call).
> >   
> >    The AAA WG may prefer to = be more forward looking and use
> SMIng or to
> >    opt for greater maturity = and use SMI v2.
> >
>
> Whatever the WG decides, it MUST be something = mature, and
> currently work in
> progress.
>
> > 3. Interworking COPS and DIAMETER
> >   
> >    If the AAA WG chooses = XML or chooses an SMI derivative
> for formal
> >    notation only without = providing a protocol mapping, then the
> >    following problem = arises.
> >   
> >    Suppose an edge device = wishes to provide both network access and
> >    premium QoS.  It = would be nice to be able to obtain a single
> >    admission decision = covering both the network access and
> the premium
> >    QoS with a single = request.  It is troublesome to the ISP
> to allocate
> >    QoS resources and then = deny access or to create an
> access session and
> >    then have to terminate = it because the QoS request
> failed.  If the
> >    edge device has to use = DIAMETER to obtain the network access
> >    admission decision and = COPS to obtain the QoS admission
> decision, it
> >    will be very difficult = to coordinate the two decisions.  If this
> >    happens, someone might = be tempted to doubt the IETF's wisdom in
> >    standardizing two = protocols where one might have sufficed.
> >   
> >    Of course, if the two = protocols use the same data model,
> then the
> >    problem goes away.  = Either protocol could be used for
> either type of
> >    request, so the edge = device could request the two
> related services in
> >    a single message using = either protocol.
> >   
> >    But if the two protocols = do not use the same data model, then it
> >    might be a good idea to = create an escape mechanism.  Could we at
> >    least define a DIAMETER = AVP type of COPS message or COPS
> object which
> >    means, "shell out = to the part of the AAA server that understands
> >    COPS, process this thing = and then return"?  That way, at
> least, the
> >    two requests could be = piggybacked onto the same message
> so that a
> >    sophisticated enough AAA = server could process them together.
>
> Just to be clear, I am not sure how allowing = the dictionary
> and other config
> files), and the documentation to specify = message formats in
> XML or SMI to
> really help interworking of protocols on the = wire :(
>
> The scenario you described above *will* happen, = and in the
> cases that I've
> seen, the local PDP will contact the local = DIAMETER server to
> retrieve user
> profile information, since the information is = in the user's
> home network and
> COPS doesn't do inter-domain. >
> > 4. What combinations of attributes make = sense?
> >   
> >    A problem which RADIUS = leaves unaddressed and which so
> far has not
> >    been addressed by = DIAMETER is the question of which
> attributes can
> >    and can not be = meaningfully combined in a message.  Or,
> to put it
> >    another way, which = attributes pertain to which services.
>  Here's an
> >    example.
> >   
> >    The description of the = Termination-Action attribute in
> RFC 2865 says
> >    simply,
> >   
> >       = "This Attribute indicates what action the NAS should
> take when the
> >       = specified service is completed.  It is only used in
> Access-Accept
> >       = packets."
> >       =
> >    The RFC does not specify = which services the attribute
> applies to.  I
> >    assume it applies to the = Login service.  Could it also
> apply to the
> >    Framed service?  If = I combine it with attributes such as
> >    Framed-Protocol, = Framed-IP-Address, and
> Framed-IP-Netmask, what am I
> >    expecting the NAS to = do?
> >   
> >    A data model provides an = answer to this sort of question
> by grouping
> >    elementary attributes by = service.  If an attribute applies to a
> >    service it is included = with the service, either directly or by
> >    association.  If an = attribute does not apply, then it is
> not included
> >    in that part of the = model.  Ambiguities are resolved, and
> >    interoperability is = enhanced.
>
> I agree that the specifications must be clear. = If in theNAS
> dial-up world
> certain ambiguities still exist, then let's fix = them in the spec. One
> possibility is to make use of different command = sets for PPP
> and terminal
> server. In fact, this would REALLY clean up the = extension IMHO.
>
> PatC
>
>

------_=_NextPart_001_01C07CE6.9DF2B468-- From owner-aaa-bof@merit.edu Sun Jan 14 03:39:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA28882 for ; Sun, 14 Jan 2001 03:39:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF1265DDC1; Sun, 14 Jan 2001 03:39:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A0A7F5DDC7; Sun, 14 Jan 2001 03:39:25 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id B7E775DDC1 for ; Sun, 14 Jan 2001 03:39:23 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0E8ZwR01596 for ; Sun, 14 Jan 2001 00:35:58 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: Clarification of discussion on Data Models Date: Sun, 14 Jan 2001 00:39:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk There seems to be some confusion about what exactly we are trying to do with Data Modelling. I would like to try to clarify one or two things. It seems to me that DIAMETER, in its present form, can be used to transmit attributes containing SPPI, SMIng, SMI, XML or any other chosen format by defining an octet-string attribute to encapsulate these formats. As a result I don't think the discussion is about whether we can encode SPPI, SMIng, SMI, XML or anything else in attributes. We can do this. Secondly, I don't think this debate is about the DIAMETER wire protocol. I say this because I haven't noticed anyone suggesting that we change the wire protocol to make it more compatible with any of the above formats. So what are we discussing, exactly? The design team discussion took off from some observations made about difficulties encountered in RADIUS. The RADIUS Tunnel attributes, though they constituted only a relatively modest departure from the previous attribute set, could not easily be accomodated by many implementations. UI code had to be re-written; dictionary formats had to be extended; packet sniffers had to be updated, etc. Since the whole idea of the RADIUS dictionary was to enable addition of new attributes without such code changes, this seemed to expose a RADIUS limitation that was likely to only get worse with time. The issue was deemed serious enough to be worth fixing in DIAMETER. So a problem that the design team took on was to find a way of increasing the flexiblity of the DIAMETER dictionary so that you really could add attributes, even more complicated ones, without having to change code. Note that the goal wasn't to be able to express attributes of infinite complexity, but merely to be able to express the most complicated attributes that we believed would appear within the problem domain. Secondly, there was a discussion of how the DIAMETER protocol itself should be defined. The BNF notation introduced in the drafts didn't seem entirely satisfactory, so the question was how this could be improved. Note that the goal wasn't to change the protocol, merely to more rigourously define the protocol as it exists. Erik Guttman, Juergen Schoenwaelder, and David Spence have taken on these problems and come up with potential solutions. So in evaluating these solutions it's worthwhile to compare them against the problem space. To my mind, in this exercise, as in everything else we do, our goal is NOT to figure out how much functionality we can cram into DIAMETER. It is to figure out the simplest, most elegant solution that can get the job done. RADIUS, as limited as it is, is very widely deployed because of its simplicity, and as a result may prove exceedingly difficult to dislodge. You cannot defeat a lightweight, highly mobile guerilla army during monsoon season by bringing in heavy armour -- you'll just get stuck in the mud. You've got to be lightweight and mobile yourself. From owner-aaa-bof@merit.edu Mon Jan 15 00:55:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA13564 for ; Mon, 15 Jan 2001 00:55:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E3C05DD8E; Mon, 15 Jan 2001 00:54:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 577775DD91; Mon, 15 Jan 2001 00:54:46 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id 547B15DD8E for ; Mon, 15 Jan 2001 00:54:45 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id D08A51E074; Mon, 15 Jan 2001 00:54:44 -0500 (EST) Received: from smb.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id AAA21110; Mon, 15 Jan 2001 00:54:37 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 7912535DCC; Sun, 14 Jan 2001 22:19:16 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Pat Calhoun Cc: Bernard Aboba , "Aaa-Wg@Merit. Edu" Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Jan 2001 22:19:16 -0500 Message-Id: <20010115031916.7912535DCC@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message , Pat Calhoun write s: >Bernard, > >Should I assume from your e-mail that hop-by-hop is out in the base spec? I >think discounting hop security is a mistake. Should I bring a contribution >detailing this method? Not at all. In fact, the GSS-API and IPsec solutions are almost pure hop-by-hop. (I say "almost" because I could probably construct an end-to-end Kerberos solution, if the proxies forwarded TGT requests to a distant Kerberos server.) --Steve Bellovin, http:/www.research.att.com/~smb From owner-aaa-bof@merit.edu Mon Jan 15 02:09:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA14380 for ; Mon, 15 Jan 2001 02:09:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 885EC5DDB0; Mon, 15 Jan 2001 02:09:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 758F25DDF9; Mon, 15 Jan 2001 02:09:14 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id E2F005DDB0 for ; Mon, 15 Jan 2001 02:09:11 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA29699; Mon, 15 Jan 2001 12:34:54 +0530 (IST) From: Kaushik Narayan Message-Id: <200101150704.MAA29699@cisco.com> Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001 To: smb@research.att.com (Steven M. Bellovin) Date: Mon, 15 Jan 2001 12:34:54 +0530 (IST) Cc: Pat.Calhoun@eng.sun.com (Pat Calhoun), aboba@internaut.com (Bernard Aboba), aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) In-Reply-To: <20010115031916.7912535DCC@smb.research.att.com> from "Steven M. Bellovin" at Jan 14, 2001 10:19:16 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk hi! Actually the kerberos solution provides both end-to-end and and hop-by-hop. The TGT and service principal requests would be sent directly from the Diameter client (NAS or first proxy) to the homerealm KDC. In case of TGT, Diameter client sends request to local KDC which would be relayed to remote KDC. For service principal ticket, Diameter client sends request (KRB_TGS_REQ/KRB_TGS_REP) directly to remote realm KDC, proxies don't relay tickets. The key negotiation (KRB_AP_REQ/KRB_AP_REP) messages carried in the Diameter AVPs and would be forwared by proxies. The kerberos solution can create security associations between any end-to-end diameter peers or adjacent diameter peers. kaushik! > > In message , Pat Calhoun write > s: > >Bernard, > > > >Should I assume from your e-mail that hop-by-hop is out in the base spec? I > >think discounting hop security is a mistake. Should I bring a contribution > >detailing this method? > > Not at all. In fact, the GSS-API and IPsec solutions are almost pure > hop-by-hop. (I say "almost" because I could probably construct an > end-to-end Kerberos solution, if the proxies forwarded TGT requests to a > distant Kerberos server.) > > > --Steve Bellovin, http:/www.research.att.com/~smb > > > > From owner-aaa-bof@merit.edu Tue Jan 16 06:24:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA16152 for ; Tue, 16 Jan 2001 06:24:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 457775DD8C; Tue, 16 Jan 2001 06:23:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2371F5DDA0; Tue, 16 Jan 2001 06:23:48 -0500 (EST) Received: from ness.sophia.Sema.fr (ness.sophia.sema.fr [195.101.208.115]) by segue.merit.edu (Postfix) with ESMTP id 960E35DD8C for ; Tue, 16 Jan 2001 06:23:45 -0500 (EST) Received: from sopmes01.sophia.sema.fr (sopmes01.sophia.sema.fr) by ness.sophia.Sema.fr (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 16 Jan 2001 12:20:24 +0100 Received: from palmier.sema.fr (palmier.sophia.sema.fr [172.23.126.156]) by sopmes01.sophia.sema.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DBM4CBBM; Tue, 16 Jan 2001 12:31:01 +0100 Message-Id: <5.0.2.1.0.20010116122113.00aac380@mailserver> X-Sender: azh@mailserver X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 16 Jan 2001 12:22:11 +0100 To: "Bernard D. Aboba" From: Alain Zahm Subject: Re: Making the hard choices on AAA security Cc: aaa-wg@merit.edu In-Reply-To: References: <20010104002815.A48730@mx.databus.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello,

I haven't been active since now on that list. Being involved in AAA activity within my company, and following that thread I have a deeper question on security issues then:
do we need to foresee the handling of delivery denial in DIAMETER? In other words: do we need to ask a server signing the result of a request? I understand that might be considered heavy but could become important in wholesales area.

If the answer is yes then I think we'll have to think specifying security at DIAMETER level.


At 23:19 03/01/01 -0800, you wrote:
The question of the day is:

"How simple can we make this and still solve
the problem?"

> One solution to this problem is the use of
> GSSAPI for end-to-end security for diameter.
> I have been investigating this since the San
> Deigo meeting. The use of GSSAPI would mean
> that implementations need not bind the AAA
> security to a particular mechanism.

A few questions:

a. How would GSSAPI work if you need more than
a single round trip? I assume we would carry
the GSSAPI tokens in the AAA request/response
messages, no? Is the restriction to a single
round-trip important or not?

b. What is the mandatory to implement GSSAPI
method for DIAMETER? KerbV?

c. Assuming we do this, are we done? In other
words, can we assume we *always* have at least
e2e authentication/integrity protection turned
on, and therefore don't need any hop-by-hop
security? Or do we need password hiding because
we may not always have confidentiality or
hop-by-hop auth/integrity because we don't
cover enough of the message with e2e?

How simple can we make this and still solve
the problem?


-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Wednesday, January 03, 2001 8:22 PM
To: Aaa-Wg@Merit. Edu
Subject: Making the hard choices on AAA security


In the spirit of the AAA WG, which has always chosen
to tackle the hard problems early, I would like to
pose the following question:

"What is the minimum security functionality that we
need to meet the requirements?"

Notice, I didn't ask:

"How much security functionality can we cram in?"

In discussing security there may be an assumption
that we can have lots of security options.

For example, we might make shared secret
mandatory, throw in various options on hop-by-hop
(IPSEC, SSL), and for good measure specify a
couple of ways to do e2e security (CMS, Kerberos).

Therein lies the road to h*ll.

As Jeff Case has so eloquently stated, optional
features are bad. You have to implement them
because someone else might want to use them,
but you can never be guaranteed to reap the benefits.

I'd rather have one strong mandatory mechanism than
one weak mandatory one and an optional strong
mechanism.

So, the question is "what must we have?"

I think the case has been made that e2e security
is needed in *some* circumstances. Not all
circumstances -- for example, if you use
referal you don't need it.

Can we live with *one* e2e mechanism being
the *only* security mechanism we support?
If so, which one? If not, why won't this be
adequate?

And if we do this, can we get rid of the
RADIUS password-hiding mechanism?

If you think that we need hop by hop security
too, how many of *those* mechanisms do we need?
Can we live with *one* of those? Which one?

If you think that IPSEC alone will magically
sole our hop by hop security problems, think
about this:

a. IPSEC transport mode is not very widely
deployed today. In fact, I know of no RADIUS
deployment running over IPSEC.

b. Specifying IPSEC doesn't guarantee
instant interoperability. It's taken quite a
while to get interoperability between
L2TP/IPSEC implementations.

To summarize:

"There is no silver bullet, only hard choices".
Alain Zahm

SEMA GROUP TELECOMS
R&D Technical Director

Route des Lucioles - Les Algorithmes - Pythagore A
BP 279 - 06905 Sophia Antipolis Cedex
Phone: +33 (0)4 93 95 40 66
Mobile: +33 (0)6 89 87 12 49
Mailto: alain.zahm@sema.fr
PGP Key Fingerprint: F468 A906 F511 BFF7 CC8E 5F7C 5B42 2C06 B0C0 EF6B
Web: www.semagroup.com
www.semagroup.com/telecoms From owner-aaa-bof@merit.edu Tue Jan 16 06:40:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA16358 for ; Tue, 16 Jan 2001 06:40:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 13B2C5DDAD; Tue, 16 Jan 2001 06:40:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EB7C05DDA4; Tue, 16 Jan 2001 06:40:14 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id C11F85DDA0 for ; Tue, 16 Jan 2001 06:40:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08147; Tue, 16 Jan 2001 06:40:13 -0500 (EST) Message-Id: <200101161140.GAA08147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-proto-eval-02.txt Date: Tue, 16 Jan 2001 06:40:12 -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Authentication, Authorization, and Accounting:Protocol Evaluation Author(s) : D. Mitton et al. Filename : draft-ietf-aaa-proto-eval-02.txt Pages : 91 Date : 15-Jan-01 This document represents the process and findings of the AAA WG panel evaluating protocols proposed against the AAA Network Access Require- ments [AAAReqts]. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-proto-eval-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-proto-eval-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-proto-eval-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010115092131.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-aaa-proto-eval-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-aaa-proto-eval-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010115092131.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Tue Jan 16 11:28:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20441 for ; Tue, 16 Jan 2001 11:28:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7DE35DDB6; Tue, 16 Jan 2001 11:28:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A87F15DDB5; Tue, 16 Jan 2001 11:28:16 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A86705DD98 for ; Tue, 16 Jan 2001 11:28:15 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id A99ED75; Tue, 16 Jan 2001 11:28:23 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "Aaa-Wg" Subject: DIAMETER Base Protocol (Alpha 1)" draft / Minor Comments Date: Tue, 16 Jan 2001 11:27:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, Here's some further minor comments on the "DIAMETER Base Protocol (Alpha 1)" draft. Section 2.2.4.1 Example AVP with a Grouped value type -------------------------------------------------------- This section gives an example of a Grouped-AVP which includes the User-Name AVP and the Host-IP-Address AVP. Since the Host-IP-Address AVP is only present in the DRI packet (according to section 2.5.4 Host-IP-Address AVP), and since User-Name cannot be present in a DRI, maybe the example should be revamped to a non-conflicting group of AVPs. Section 2.3.1 "Host-Name AVP" ----------------------------- The Host-Name AVP defines the value as being the "sender's" identity, and later as the identity of the "originator" of the Diameter message. One could, like I did, interpret "sender" and "originator" as the peer who sent this packet, treating Host-Name AVP as a "Peer-Name" AVP, where each server in a proxy chain replaced the AVP value with his name. But the Host-Name seems to identify the original sender and not necessarily the immediate sender which may be a proxy. This might be stated explicitly, else a proxy implementation may replace the Host-Name AVP from a received packet with a Host-Name AVP identifying himself, before forwarding the packet to the next hop Diameter server. Maybe some explicit clarifying text could be added, e.g: "This AVP identifies the endpoint which originated the Diameter message, i.e. the NAS, home server, or broker. Proxy servers do not modify this AVP". 3.1 Session-Id AVP ------------------- An email (not mine) from a while back asked some questions about the Session-ID AVP, i.e. "How is this encoded? All ASCII? A mix of null-terminated strings and numbers in network byte order? Something else?" I think the answer was all ASCII, in network byte order, but this hasn't made its way into the document. Section 8.4 ------------ Section 8.4 is inconsistent with section 5.2. Section 8.4 states: As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines the values 0-8. ... The values defined in section 5.2 are no longer 0-8. Minor Typos/etc: ---------------- Section 6.1 Realm-Based Message Routing, 2nd paragragh: <<<<<<<<<<<<<< DIAMETER message, by using a DNIS or ANY to Routing-Realm association >>>>>>>>>>>>>> DIAMETER message, by using a DNIS or ANI to Routing-Realm association Section 6.2.1 Proxy and Redirect Server handling of requests <<<<<<<<<<<<<< contains the identities of the server the message must be >>>>>>>>>>>>>> contains the identities of the server(s) the message must be 6.3 Redirect Server, 2nd paragraph: <<<<<<<<<<<<<< DIAMETER server that could satisfy the message. The home servers are encoded in one or more Redirect-Host-Address. If the Redirect-Host- >>>>>>>>>>>>>> DIAMETER servers that could satisfy the message. The home servers are encoded in one or more Redirect-Host-Address AVPs. If the Redirect-Host- 6.4 Proxy Server, 4th paragraph: <<<<<<< at Date + 1307 <<<<<<< [\email\draft-~2.txt + 1310] intensive purposes, stateful servers terminate an upstream "session", >>>>>>> at Date + 1307 >>>>>>> [\ietf\dr03c4~1.txt + 1310] intents and purposes, stateful servers terminate an upstream "session", From owner-aaa-bof@merit.edu Tue Jan 16 11:44:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20688 for ; Tue, 16 Jan 2001 11:44:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1441D5DDD5; Tue, 16 Jan 2001 11:44:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 039785DDB9; Tue, 16 Jan 2001 11:44:28 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 00E3A5DDD0 for ; Tue, 16 Jan 2001 11:44:27 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E9FE674; Tue, 16 Jan 2001 11:44:35 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "Aaa-Wg" Subject: DIAMETER Base Protocol (18-Alpha 1)" draft / 5.0 Error Reporting Date: Tue, 16 Jan 2001 11:44:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, When reading section 5.0 "Error Reporting" in the "DIAMETER Base Protocol (Alpha 1)" draft, I came up with a number of questions about the handling of a bad reply message, which probably means I'm missing something basic. Maybe some clarifications could be added to this section. I fear I'm all wet here, but here's some questions: Case 1: NAS -> HomeServer. NAS detects error. ----------------------------------------------- We have a NAS talking directly to his Home Server; no proxies are involved. The NAS originates a valid *-Request. The HomeServer sends a positive *-Answer which the NAS considers erroneous (e.g. the *-Answer packet is syntactically incorrect; or the *-Answer packet is syntactically correct but contains an AVP with an inappropriate value). I assume that an MRI is intended as a response not just to bad *-Request and *-Ind packets, but also to bad *-Answer packets. The NAS, I think, would send an MRI back to the home server with an appropriate Result-Code. If the MRI serves no other purpose, it can at least make its way into the home server's log file, as an aid to those investigating why sessions aren't being set up. If the home server maintains session state, he considers this to be an active session, since he sent a positive reply. Is the MRI sufficient to stimulate the home server to release this active session, or should the NAS also (or instead) send a Session-Terminate-Request? (The MRI may not contain enough information for the home server to make a determination as to the fate of this session. For example, if the MRI was in response to the home server's positive AA-Answer, the home server can release the session. If the MRI was in response to the home server's Session-Terminate-Ind, then the home server wouldn't release the session. But the MRI doesn't indicate the home server's offending packet. The home server also doesn't know if the Identifier value is his or the NAS's). According to the table in section 5.0, an MRI can be sent only if the error is of type "Unknown Command". If so, what can the NAS send to the Home Server if the error is of type "Unknown AVP", "Bad AVP Value", or "Extension Error"? According to the table, the NAS should send some extension-specific error response, but I don't see any candidates that can be sent in response to a bad reply. Does the NAS behave differently if he receives a bad negative reply rather than a bad positive reply? (e.g. forego sending the MRI) Case 2: NAS -> RoutingProxy -> HomeServer. NAS detects error. --------------------------------------------------------------- Same as case 1, but with a proxy in the middle: The NAS originates a valid *-Request. The HomeServer sends a positive *-Answer, which passes through the proxy ok, but which the NAS considers erroneous. Assuming the NAS sent an MRI, what does the proxy do with it? It seems like the proxy would want to route the MRI to the home server, since the MRI was most likely a response to something the home server sent, and not to something the proxy sent (the proxy likely couldn't determine who was at fault anyway, so would just forward the MRI in all cases and let the humans figure out what went wrong). However, if the proxy routes on Extension Id, he may be unable to route the MRI, which lacks identification of the offending extension. (I'm referring to Section 6.2.1 "Proxy and Redirect Server handling of requests", which says "It is possible for a routing entry to have a different destination based on the extension identifier of the message. This field is typically used as a secondary key field in routing table lookups."). Here's a thought: Rename the Unrecognized-Command-Code AVP to the "Failed-Command-Code AVP", and change its value to contain the Command Code that was being processed when the error was detected, be it recognized or not. Include this new AVP in all MRI messages. The Result-Code value tells you if the command was unrecognized. This seems useful when debugging and tracing. And in this case the proxy can now determine the extension of the offending packet and route the NAS's MRI accordingly. Case 3: NAS -> RoutingProxy -> HomeServer. PROXY detects error. ----------------------------------------------------------------- Similar to case 1, but with a proxy in the middle: The NAS originates a valid *-Request. The HomeServer sends a positive *-Answer which the PROXY considers erroneous. Here the proxy might want to generate two messages, one to the NAS and one to the home server. The proxy would do what the NAS would do in Case 2: send an MRI to the home server. The proxy would turn the home server's positive answer into a negative answer, replace the Result-Code AVP, and send it on to the NAS. When the NAS receives a negative reply to some request, there is a Result-Code AVP which indicates the error, but there isn't an indication of who originally generated the error, i.e. some proxy along the path, or the home server. It would be useful to know which machine originated the negative Result-Code AVP. It most cases this is indicated by the Host-Name AVP, but in this case the Host-Name is the home server while the proxy detected the error. So a new "Error-Detecting-Server-Name" AVP (not a good name) could be useful. The AVP would contain the name of the machine which originated the failure Reply-Code value, useful in tracing and debugging. This new AVP immediately points the technical staff to the offended (possibly misconfigured) server. Also, if the NAS knew that a negative answer came from some proxy, he might try a different route to the home server; but if the home server originated the reject, well then give up. If the proxy receives a flawed negative reply from the home server, rather than a flawed positive reply, does he act differently? For example, only override the home server's Result-Code value if it was 2xxx SUCCESS; forego sending the MRI to the home server. Out-of-Range Result-Code values: -------------------------------- Section 5.2 "Result-Code AVP" defines classes of error codes in the range 1xxx-5xxx. What does a receiver do when receiving a Result-Code value outside of the defined ranges? I'm guessing an out-of-range Result-Code value would be treated as a 5xxx (Permanent failure). Should an MRI or error log entry be generated? Should a Result-Code value of zero be treated as a 2xxx (Success) for compatibility with existing Diameter implementations? From owner-aaa-bof@merit.edu Tue Jan 16 12:05:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21125 for ; Tue, 16 Jan 2001 12:05:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26C2E5DE07; Tue, 16 Jan 2001 12:01:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 097A25DE0A; Tue, 16 Jan 2001 12:01:51 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 8D0975DE07 for ; Tue, 16 Jan 2001 12:01:49 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0GGveR27326; Tue, 16 Jan 2001 08:57:41 -0800 From: "Bernard Aboba" To: "Alain Zahm" Cc: Subject: RE: Making the hard choices on AAA security Date: Tue, 16 Jan 2001 09:01:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C07F9A.E31E0360" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <5.0.2.1.0.20010116122113.00aac380@mailserver> Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C07F9A.E31E0360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an Access-Reject should never be changed to an Access-Accept. A good question is how this could be enforced, using any of the solutions that have been proposed. ------=_NextPart_000_001E_01C07F9A.E31E0360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A=20 proxy can change an Access-Accept into an Access-Reject under the guise = of=20 "policy". However, an Access-Reject should never be changed to an = Access-Accept.=20 A good question is how this could be enforced, using any of the = solutions that=20 have been proposed.
------=_NextPart_000_001E_01C07F9A.E31E0360-- From owner-aaa-bof@merit.edu Tue Jan 16 12:14:01 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21271 for ; Tue, 16 Jan 2001 12:14:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 10B655DD98; Tue, 16 Jan 2001 12:13:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F25425DDB9; Tue, 16 Jan 2001 12:13:40 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id 2EBDF5DD98 for ; Tue, 16 Jan 2001 12:13:39 -0500 (EST) Received: by balinese.baltimore.ie; id RAA21087; Tue, 16 Jan 2001 17:13:38 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma020962; Tue, 16 Jan 01 17:13:04 GMT Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA10540; Tue, 16 Jan 2001 17:13:04 GMT Message-ID: <3A648124.103B5EEC@baltimore.ie> Date: Tue, 16 Jan 2001 17:13:08 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: Alain Zahm , aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk > Bernard Aboba wrote: > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an > Access-Reject should never be changed to an Access-Accept. A good question is how this could be > enforced, using any of the solutions that have been proposed. Not sure it could, but if the original Access-Accept is not encrypted (if it is, I'm off home), I'd guess you'd have to invent a new AVP "Access-Accept-Override" or somesuch. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Tue Jan 16 16:24:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA25729 for ; Tue, 16 Jan 2001 16:24:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id C414C5DE27; Tue, 16 Jan 2001 16:23:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B0B9D5DE22; Tue, 16 Jan 2001 16:23:45 -0500 (EST) Received: from rock2 (rock2.apogeenet.com [63.119.238.75]) by segue.merit.edu (Postfix) with ESMTP id 1EBD65DE1A for ; Tue, 16 Jan 2001 16:23:44 -0500 (EST) Received: from postoffice.apogeenet.com ([10.30.0.90]) by rock2 (8.10.0/8.10.0) with ESMTP id f0GLLIv26133 for ; Tue, 16 Jan 2001 16:21:29 -0500 (EST) Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 16:23:34 -0500 Message-ID: From: Abhi Deshmukh To: "'aaa-wg@merit.edu'" Subject: Self Describing record formats for multiple (non-network-access) usage types ... Date: Tue, 16 Jan 2001 16:23:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello: I have been looking at the AAA related documents for record formats and I have an idea to share about the formats. Is there a thought in the AAA WG of having self describing records in the overall AAA framework ?. This would allow other known unknown and not invented usage records to be accomodated in the AAA framework. This way, if the transport issues are resolved, new usage types would not present a challenge to the record format. Also having a AAA framework that accomodates other usage types (other than end user network access) would be beneficial. I have some ideas on this thought process. If this thought is-being or has-been dicussed, then perhaps I missed it. Is there any place that I should be looking ? Any useful pointers ? Thanks for your time. - Abhi Deshmukh PS: I also looked at an Internet Draft (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt) but did not this issue listed explicitly. From owner-aaa-bof@merit.edu Tue Jan 16 16:42:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA25995 for ; Tue, 16 Jan 2001 16:42:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id A98C25DE08; Tue, 16 Jan 2001 16:42:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D4585DE0A; Tue, 16 Jan 2001 16:42:00 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id EE4C95DE08 for ; Tue, 16 Jan 2001 16:41:58 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id QAA17471 for ; Tue, 16 Jan 2001 16:47:42 -0500 (EST) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma017435; Tue, 16 Jan 01 16:47:17 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id QAA07571 for ; Tue, 16 Jan 2001 16:41:31 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 16:41:31 -0500 Message-ID: From: "Nelson, David" To: "'aaa-wg@merit.edu'" Subject: draft-ietf-aaa-proto-eval.02.txt Date: Tue, 16 Jan 2001 16:41:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08005.16A64A84" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08005.16A64A84 Content-Type: text/plain; charset="iso-8859-1" In reviewing draft-ietf-aaa-proto-eval.02.txt, I noticed one tense change that escaped the editor's notice. In Section 1.1, 3rd paragraph, last sentence, "is" should be "was". The corrected text should then read: The goal was to have a first draft available prior to the July 14, 2000 submission deadline for IETF 48. A goal that was achieved. You might also change my affiliation from "Cabletron" to "Enterasys Networks, Inc." in the document header and in Section 1.3, Members Statements. The split out of Enterasys from Cabletron occurred between the formation of the AAA Eval Team and the publication of this Internet Draft. In general, the clean up of this document is very well done, IMHO. Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C08005.16A64A84 Content-Type: text/html; charset="iso-8859-1" draft-ietf-aaa-proto-eval.02.txt

In reviewing draft-ietf-aaa-proto-eval.02.txt, I noticed one tense
change that escaped the editor's notice.  In Section 1.1, 3rd paragraph,
last sentence, "is" should be "was".  The corrected text should then read:

        The goal was to have a first draft available prior to the July 14,
        2000 submission deadline for IETF 48.

A goal that was achieved.

You might also change my affiliation from "Cabletron" to "Enterasys Networks,
Inc." in the document header and in Section 1.3, Members Statements.  The
split out of Enterasys from Cabletron occurred between the formation of the
AAA Eval Team and the publication of this Internet Draft.

In general, the clean up of this document is very well done, IMHO.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com
 

------_=_NextPart_001_01C08005.16A64A84-- From owner-aaa-bof@merit.edu Tue Jan 16 17:19:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26479 for ; Tue, 16 Jan 2001 17:19:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C81AE5DE03; Tue, 16 Jan 2001 17:16:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B4B0C5DDE3; Tue, 16 Jan 2001 17:16:29 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 6315A5DE15 for ; Tue, 16 Jan 2001 17:16:28 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA20034; Tue, 16 Jan 2001 17:22:10 -0500 (EST) Received: from cnc-exc1.ctron.com(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma019983; Tue, 16 Jan 01 17:22:01 -0500 Received: from cnc-exc1.ctron.com (localhost [127.0.0.1]) by cnc-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CYZXXD4B; Tue, 16 Jan 2001 17:16:10 -0500 Received: from 10.8.9.70 by cnc-exc1.ctron.com (InterScan E-Mail VirusWall NT); Tue, 16 Jan 2001 17:16:10 -0500 (Eastern Standard Time) Message-ID: <3A64C6F6.5CC2BCB0@enterasys.com> Date: Tue, 16 Jan 2001 17:11:02 -0500 From: David Harrington Reply-To: dbh@enterasys.com Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Abhi Deshmukh Cc: "'aaa-wg@merit.edu'" Subject: Re: Self Describing record formats for multiple (non-network-access) usage types ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk What types of usage did you have in mind? SNMP is the standard that is typically used to monitor network activity. dbh Abhi Deshmukh wrote: > > Hello: > > I have been looking at the AAA related documents for record formats and I > have an idea to share about the formats. > > Is there a thought in the AAA WG of having self describing records in the > overall AAA framework ?. This would allow other known unknown and not > invented usage records to be accomodated in the AAA framework. This way, if > the transport issues are resolved, new usage types would not present a > challenge to the record format. Also having a AAA framework that accomodates > other usage types (other than end user network access) would be beneficial. > > I have some ideas on this thought process. If this thought is-being or > has-been dicussed, then perhaps I missed it. Is there any place that I > should be looking ? Any useful pointers ? > > Thanks for your time. > > - Abhi Deshmukh > > PS: I also looked at an Internet Draft > (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt) but did not > this issue listed explicitly. -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-aaa-bof@merit.edu Wed Jan 17 04:05:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA04507 for ; Wed, 17 Jan 2001 04:05:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F73C5DDA2; Wed, 17 Jan 2001 04:03:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 132125DDE3; Wed, 17 Jan 2001 04:03:28 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id D5BCA5DDA2 for ; Wed, 17 Jan 2001 04:03:24 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA07618; Wed, 17 Jan 2001 13:12:14 +0530 (IST) From: Kaushik Narayan Message-Id: <200101170742.NAA07618@cisco.com> Subject: Re: Making the hard choices on AAA security To: aboba@internaut.com (Bernard Aboba) Date: Wed, 17 Jan 2001 13:12:14 +0530 (IST) Cc: Alain.Zahm@sema.fr (Alain Zahm), aaa-wg@merit.edu In-Reply-To: from "Bernard Aboba" at Jan 16, 2001 09:01:17 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk bernard, hi! There are two issues here 1> End-to-End Integrity Protection of the header - Actually the Kerberized Radius draft integrity protects some Radius header attributes (like Radius code) on an end-to-end basis which means that a fraudelent proxy cannot modify the Radius code. Moreover since the end-to-end MIC is compulsory there protection against deletion of the MIC itself. The end-to-end MIC would be generated using the end-to-end Kerberos session keys. The same behaviour would be present in Kerberized diameter proposal. 2> Protection against generation of an ACCESS-ACCEPT by a fraudelent proxy - A fraudelent proxy can actually generate an unsolicited access-accept. The Kerberos draft would provide protection against this since the diameter authentication exchange would carry the Kerberos key exchange messages (KRB_AP_REQ/KRB_AP_REP) and Kerberos would perform a mutual service authentication based on messages. Since the service principal is per server, only the homeserver would be able to generate a valid KRB_AP_REP message, this would mean any unsolicited ACCESS-ACCEPT/ ACCESS-REJECT generated by an fraudelent proxy would contain an invalid KRB_AP_REP messages and the Kerberos mutual authentication would fail automatically. kaushik! > > This is a multi-part message in MIME format. > > ------=_NextPart_000_001E_01C07F9A.E31E0360 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > A proxy can change an Access-Accept into an Access-Reject under the guise of > "policy". However, an Access-Reject should never be changed to an > Access-Accept. A good question is how this could be enforced, using any of > the solutions that have been proposed. > > ------=_NextPart_000_001E_01C07F9A.E31E0360 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Dus-ascii"> > > >
size=3D2>A=20 > proxy can change an Access-Accept into an Access-Reject under the guise = > of=20 > "policy". However, an Access-Reject should never be changed to an = > Access-Accept.=20 > A good question is how this could be enforced, using any of the = > solutions that=20 > have been proposed.
> > ------=_NextPart_000_001E_01C07F9A.E31E0360-- > > > From owner-aaa-bof@merit.edu Wed Jan 17 08:11:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA07322 for ; Wed, 17 Jan 2001 08:11:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B5FF5DDE3; Wed, 17 Jan 2001 08:11:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAF635DDB4; Wed, 17 Jan 2001 08:11:23 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 63FB95DD9A for ; Wed, 17 Jan 2001 08:11:22 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA09880; Wed, 17 Jan 2001 05:11:35 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0HDBLo28282; Wed, 17 Jan 2001 05:11:21 -0800 (PST) Received: from pacific101.com ([206.163.170.240]) by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id FAA28387; Wed, 17 Jan 2001 05:10:54 -0800 (PST) Received: from host [209.206.4.175] by pacific101.com with ESMTP (SMTPD32-5.05) id A7B7A0027A; Wed, 17 Jan 2001 05:01:43 -0800 From: "Victor Barret" Subject: Candidate #7629 To: join39d@cisco.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Wed, 17 Jan 2001 07:53:06 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-Id: <200101170502539.SM01240@host> Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Candidate,

You have been selected for a complimentary listing in the International Executive Guild Registry=2E Inclusion is limited to Executives,
Entrepreneurs, Business Owners and Professionals=2E

The International Executive Guild's 2001 - 2002 edition will be
published in two different formats; the searchable CD-ROM and Online
Registry=2E The CD-ROM is searchable by over twenty parameters, with
thousands of complete profiles of highly accomplished individuals from virtually every industry=2E

Since inclusion can be considered recognition of your career position, each candidate is evaluated in keeping with high standards of individual<= br> achievement=2E The International Executive Guild looks for experts in
= their respective field=2E

We look forward to your inclusion and appearance in the International
= Executive Guild's Registry=2E Best for your continued success=2E

International Executive Guild
Listing Department

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-aaa-bof@merit.edu Wed Jan 17 09:28:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA08317 for ; Wed, 17 Jan 2001 09:28:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23D995DE01; Wed, 17 Jan 2001 09:28:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 125F05DE00; Wed, 17 Jan 2001 09:28:03 -0500 (EST) Received: from rock2 (rock2.apogeenet.com [63.119.238.75]) by segue.merit.edu (Postfix) with ESMTP id D31545DD9A for ; Wed, 17 Jan 2001 09:28:01 -0500 (EST) Received: from postoffice.apogeenet.com ([10.30.0.90]) by rock2 (8.10.0/8.10.0) with ESMTP id f0HEPQv27507; Wed, 17 Jan 2001 09:25:36 -0500 (EST) Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 09:27:47 -0500 Message-ID: From: Abhi Deshmukh To: "'aaa-wg@merit.edu'" Cc: "'dbh@enterasys.com'" Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... Date: Wed, 17 Jan 2001 09:27:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk As we know, SNMP is commonly used at the network element level for a variety of purposes including configuration and usage information (RMON2). There are a class of apps like Streaming servers, Web Servers, Caching Servers, Proxies, load balancers, and other service-specific apps that use log files, etc to store their usage related information. These apps do not have SNMP support. How do we plan on accomodating these usage records in the AAA framework ? - Abhi > -----Original Message----- > From: David Harrington [mailto:dbh@enterasys.com] > Sent: Tuesday, January 16, 2001 5:11 PM > To: Abhi Deshmukh > Cc: 'aaa-wg@merit.edu' > Subject: Re: Self Describing record formats for multiple > (non-network-access) usage types ... > > > What types of usage did you have in mind? > SNMP is the standard that is typically used to monitor > network activity. > > dbh > > Abhi Deshmukh wrote: > > > > Hello: > > > > I have been looking at the AAA related documents for record > formats and I > > have an idea to share about the formats. > > > > Is there a thought in the AAA WG of having self describing > records in the > > overall AAA framework ?. This would allow other known > unknown and not > > invented usage records to be accomodated in the AAA > framework. This way, if > > the transport issues are resolved, new usage types would > not present a > > challenge to the record format. Also having a AAA framework > that accomodates > > other usage types (other than end user network access) > would be beneficial. > > > > I have some ideas on this thought process. If this thought > is-being or > > has-been dicussed, then perhaps I missed it. Is there any > place that I > > should be looking ? Any useful pointers ? > > > > Thanks for your time. > > > > - Abhi Deshmukh > > > > PS: I also looked at an Internet Draft > > > (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt) but did not > this issue listed explicitly. -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-aaa-bof@merit.edu Wed Jan 17 12:44:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11356 for ; Wed, 17 Jan 2001 12:44:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49DEE5DE1F; Wed, 17 Jan 2001 12:44:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 389375DE1C; Wed, 17 Jan 2001 12:44:14 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id A3FCA5DDE8 for ; Wed, 17 Jan 2001 12:44:12 -0500 (EST) Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA03568 for ; Wed, 17 Jan 2001 18:45:05 +0100 From: "Fredrik Johansson" To: "AAA Listan" Subject: Comments on draft-calhoun-diameter-18.txt Date: Wed, 17 Jan 2001 18:46:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Found a type in section 8.2. The Command Codes that are specified within this specification should be 257, 259, 274-276 Compare section 8.2 with 2.1 /Fredrik 8.2 Command Code Values As defined in section 2.1, the Command Code field has an associated value maintained by IANA. Values 0-255 are reserved for backward RADIUS compatibility, and values 256, 259, 174, 275 and 276 are defined in this specification. The remaining values are available for assignment via Designated Expert [12]. 2.1 ... Command-Code The Command-Code field is four octets, and is used in order to communicate the command associated with the message. The 32-bit address space is managed by IANA (see section 8.2). The following Command Codes are currently defined in the DIAMETER base protocol: Command-Name Abbrev. Code Reference -------------------------------------------------------- Device-Reboot-Ind DRI 257 2.5 Message-Reject-Ind MRI 259 5.1 Session-Termination-Ind STI 274 3.5.1 Session-Termination- STR 275 3.5.2 Request Session-Termination- STA 276 3.5.3 Answer ---------------------------------------------------------------------------- ------- Fredrik Johansson W: +46 (0)8 725 5916 Interactive People Unplugged M: +46 (0)70 786 5035 mailto:fredrik.johansson@ipunplugged.com http://www.ipunplugged.com From owner-aaa-bof@merit.edu Wed Jan 17 12:58:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11616 for ; Wed, 17 Jan 2001 12:58:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id B525E5DED1; Wed, 17 Jan 2001 12:55:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1E8485DE3F; Wed, 17 Jan 2001 12:55:52 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8F9D85DED1 for ; Wed, 17 Jan 2001 12:53:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22786; Wed, 17 Jan 2001 09:53:33 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07591; Wed, 17 Jan 2001 09:53:31 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA28140; Wed, 17 Jan 2001 09:52:55 -0800 (PST) From: Pat Calhoun Message-Id: <200101171752.JAA28140@nasnfs.eng.sun.com> Date: Wed, 17 Jan 2001 09:51:15 -0800 To: "Fredrik Johansson" , "AAA Listan" Reply-To: Subject: Re: Comments on draft-calhoun-diameter-18.txt X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks for the catch. I will make sure that this is corrected in the draft-ietf-aaa version. Thanks, PatC >Hi > >Found a type in section 8.2. The Command Codes that are specified within >this specification should be 257, 259, 274-276 >Compare section 8.2 with 2.1 > >/Fredrik > >8.2 Command Code Values > > As defined in section 2.1, the Command Code field has an associated > value maintained by IANA. Values 0-255 are reserved for backward > RADIUS compatibility, and values 256, 259, 174, 275 and 276 are > defined in this specification. The remaining values are available for > assignment via Designated Expert [12]. > > >2.1 >... > Command-Code > The Command-Code field is four octets, and is used in order to > communicate the command associated with the message. The 32-bit > address space is managed by IANA (see section 8.2). The following > Command Codes are currently defined in the DIAMETER base protocol: > > Command-Name Abbrev. Code Reference > -------------------------------------------------------- > Device-Reboot-Ind DRI 257 2.5 > Message-Reject-Ind MRI 259 5.1 > Session-Termination-Ind STI 274 3.5.1 > Session-Termination- STR 275 3.5.2 > Request > Session-Termination- STA 276 3.5.3 > Answer > > > >---------------------------------------------------------------------------- >------- >Fredrik Johansson W: +46 (0)8 725 5916 >Interactive People Unplugged M: +46 (0)70 786 5035 >mailto:fredrik.johansson@ipunplugged.com >http://www.ipunplugged.com > > From owner-aaa-bof@merit.edu Wed Jan 17 15:02:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14294 for ; Wed, 17 Jan 2001 15:02:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id D78FB5DE00; Wed, 17 Jan 2001 15:00:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B95175DDE4; Wed, 17 Jan 2001 15:00:16 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 6F2335DD93 for ; Wed, 17 Jan 2001 15:00:14 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0HK0DK29695; Wed, 17 Jan 2001 14:00:13 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0HK0Cr04001; Wed, 17 Jan 2001 14:00:12 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA25074; Wed, 17 Jan 2001 14:00:12 -0600 (CST) Received: from ericsson.com (busam67.berkeley.us.am.ericsson.se [138.85.159.217]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA24197; Wed, 17 Jan 2001 14:00:09 -0600 (CST) Message-ID: <3A65F9EB.39C1004C@ericsson.com> Date: Wed, 17 Jan 2001 12:00:43 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat.Calhoun@Eng.Sun.COM Cc: AAA Listan Subject: Re: Comments on draft-calhoun-diameter-18.txt References: <200101171752.JAA28140@nasnfs.eng.sun.com> Content-Type: multipart/alternative; boundary="------------80984F94A685E63D2B999697" Sender: owner-aaa-bof@merit.edu Precedence: bulk --------------80984F94A685E63D2B999697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pat, I think this one starts to look really good, just a couple of comments. section 2.4 State Machine, page 16: I think the typo is made on the second row from the top (this has been sent earlier on the list by some one else): New State should be Wait-DRI not Open. >>>>> State Event Action New State ----- ----- ------ --------- ... Initial Receive transport level Send DRI Open connection request from a DIAMETER peer. Should be: <<<<<< State Event Action New State ----- ----- ------ --------- ... Initial Receive transport level Send DRI Wait-DRI connection request from a DIAMETER peer. Section 6.7 Loop Detection, page 30: It is clear that you should reply with an Answer on Request and a Reply on a Query with the Result-Code AVP set to DIAMETER_LOOP_DETECTED, but what about an Indication? To me the most logical thing would be to send back an MRI. Is that the right assumption... BR, /Tony --------------80984F94A685E63D2B999697 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pat,

I think this one starts to look really good, just a couple of comments.

section 2.4 State Machine, page 16:

I think the typo is made on the second  row from the top (this has been sent earlier on the list by some one else): New State should be Wait-DRI not Open.

>>>>>
State     Event                          Action    New State
-----     -----                          ------    ---------
...

Initial   Receive transport level        Send DRI  Open
          connection request from a
          DIAMETER peer.

Should be:
<<<<<<
State     Event                          Action    New State
-----     -----                          ------    ---------
...

Initial   Receive transport level        Send DRI  Wait-DRI
          connection request from a
          DIAMETER peer.

Section 6.7 Loop Detection, page 30:

It is clear that you should reply with an Answer on Request and a Reply on a Query with the Result-Code AVP set to DIAMETER_LOOP_DETECTED, but what about an Indication? To me the most logical thing would be to send back an MRI. Is that the right assumption...

BR,

/Tony --------------80984F94A685E63D2B999697-- From owner-aaa-bof@merit.edu Wed Jan 17 15:14:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14505 for ; Wed, 17 Jan 2001 15:14:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD3E35DD9E; Wed, 17 Jan 2001 15:14:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A34B05DD9A; Wed, 17 Jan 2001 15:14:25 -0500 (EST) Received: from rock2 (rock2.apogeenet.com [63.119.238.75]) by segue.merit.edu (Postfix) with ESMTP id 1E8695DD93 for ; Wed, 17 Jan 2001 15:14:24 -0500 (EST) Received: from postoffice.apogeenet.com ([10.30.0.90]) by rock2 (8.10.0/8.10.0) with ESMTP id f0HKBxv29252 for ; Wed, 17 Jan 2001 15:12:10 -0500 (EST) Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 15:14:20 -0500 Message-ID: From: Abhi Deshmukh To: "'aaa-wg@merit.edu'" Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... Date: Wed, 17 Jan 2001 15:14:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I haven't had an answer from this mailing list to the following question. Does that mean a "NO" ??? Your feedback is very important. - Abhi -----Original Message----- From: Abhi Deshmukh [mailto:Abhi.Deshmukh@apogeenet.com] Sent: Wednesday, January 17, 2001 9:28 AM To: 'aaa-wg@merit.edu' Cc: 'dbh@enterasys.com' Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... As we know, SNMP is commonly used at the network element level for a variety of purposes including configuration and usage information (RMON2). There are a class of apps like Streaming servers, Web Servers, Caching Servers, Proxies, load balancers, and other service-specific apps that use log files, etc to store their usage related information. These apps do not have SNMP support. How do we plan on accomodating these usage records in the AAA framework ? - Abhi > -----Original Message----- > From: David Harrington [mailto:dbh@enterasys.com] > Sent: Tuesday, January 16, 2001 5:11 PM > To: Abhi Deshmukh > Cc: 'aaa-wg@merit.edu' > Subject: Re: Self Describing record formats for multiple > (non-network-access) usage types ... > > > What types of usage did you have in mind? > SNMP is the standard that is typically used to monitor > network activity. > > dbh > > Abhi Deshmukh wrote: > > > > Hello: > > > > I have been looking at the AAA related documents for record > formats and I > > have an idea to share about the formats. > > > > Is there a thought in the AAA WG of having self describing > records in the > > overall AAA framework ?. This would allow other known > unknown and not > > invented usage records to be accomodated in the AAA > framework. This way, if > > the transport issues are resolved, new usage types would > not present a > > challenge to the record format. Also having a AAA framework > that accomodates > > other usage types (other than end user network access) > would be beneficial. > > > > I have some ideas on this thought process. If this thought > is-being or > > has-been dicussed, then perhaps I missed it. Is there any > place that I > > should be looking ? Any useful pointers ? > > > > Thanks for your time. > > > > - Abhi Deshmukh > > > > PS: I also looked at an Internet Draft > > > (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt) but did not > this issue listed explicitly. -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-aaa-bof@merit.edu Wed Jan 17 15:35:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15216 for ; Wed, 17 Jan 2001 15:35:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 256055DE9C; Wed, 17 Jan 2001 15:32:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D6695DE3F; Wed, 17 Jan 2001 15:32:00 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 2C4DF5DDE4 for ; Wed, 17 Jan 2001 15:31:58 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA01440 for ; Wed, 17 Jan 2001 15:36:13 -0500 (EST) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma001428; Wed, 17 Jan 01 15:35:17 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id PAA06126 for ; Wed, 17 Jan 2001 15:29:32 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 15:29:32 -0500 Message-ID: From: "Nelson, David" To: "'aaa-wg@merit.edu'" Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... Date: Wed, 17 Jan 2001 15:29:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C080C4.316A6318" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C080C4.316A6318 Content-Type: text/plain; charset="iso-8859-1" Abhi Deshmukh writes... > I haven't had an answer from this mailing list to the following question. > Does that mean a "NO" ??? Your feedback is very important. > There are a class of apps like Streaming servers, Web Servers, Caching > Servers, Proxies, load balancers, and other service-specific apps that > use log files, etc to store their usage related information. These apps > do not have SNMP support. How do we plan on accommodating these usage > records in the AAA framework ? The AAA Working Group Charter states, in part: (see http://www.ietf.org/html.charters/aaa-charter.html) The Authentication, Authorization and Accounting Working Group focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. Requirements were gathered from NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. How do the applications you mention fit into this scope of work? I ask this not in a cynical fashion, but simply to clarify the nature of the applications you mention and their relation to our work. We are working on AAA to meet specific requirements (NASREQ, MOBILE IP, and ROAMOPS), not a generalized, all-purpose AAA service. Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C080C4.316A6318 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Self Describing record formats for multiple = (non-network-acce ss) usage types ...

Abhi Deshmukh writes...

> I haven't had an answer from this mailing list = to the following question.
> Does that mean a "NO" ??? Your = feedback is very important.

> There are a class of apps like Streaming = servers, Web Servers, Caching
> Servers, Proxies, load balancers, and other = service-specific apps that
> use log files, etc to store their usage related = information. These apps
> do not have SNMP support. How do we plan on = accommodating these usage
> records in the AAA framework ?

The AAA Working Group Charter states, in part:
(see http://www.ietf.org/html.charters/aaa-charter.html= )

The Authentication, Authorization and Accounting = Working Group focused on
the development of requirements for Authentication, = Authorization and
Accounting as applied to network access. = Requirements were gathered from
NASREQ, MOBILE IP, and ROAMOPS Working Groups as = well as TIA 45.6.

How do the applications you mention fit into this = scope of work?  I ask
this not in a cynical fashion, but simply to clarify = the nature of the
applications you mention and their relation to our = work.  We are working on
AAA to meet specific requirements (NASREQ, MOBILE = IP, and ROAMOPS), not a
generalized, all-purpose AAA service.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) = 684-1368
E-mail: dnelson@enterasys.com

------_=_NextPart_001_01C080C4.316A6318-- From owner-aaa-bof@merit.edu Wed Jan 17 15:49:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15537 for ; Wed, 17 Jan 2001 15:49:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id A27E35DE69; Wed, 17 Jan 2001 15:45:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 892435DE58; Wed, 17 Jan 2001 15:45:44 -0500 (EST) Received: from rock2 (rock2.apogeenet.com [63.119.238.75]) by segue.merit.edu (Postfix) with ESMTP id 1D2205DE51 for ; Wed, 17 Jan 2001 15:45:43 -0500 (EST) Received: from postoffice.apogeenet.com ([10.30.0.90]) by rock2 (8.10.0/8.10.0) with ESMTP id f0HKgWv29452; Wed, 17 Jan 2001 15:42:43 -0500 (EST) Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 15:44:53 -0500 Message-ID: From: Abhi Deshmukh To: "'Nelson, David'" , "'aaa-wg@merit.edu'" Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... Date: Wed, 17 Jan 2001 15:44:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com] Sent: Wednesday, January 17, 2001 3:30 PM To: 'aaa-wg@merit.edu' Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... >The AAA Working Group Charter states, in part: >(see http://www.ietf.org/html.charters/aaa-charter.html) >The Authentication, Authorization and Accounting Working Group focused on >the development of requirements for Authentication, Authorization and >Accounting as applied to network access. Requirements were gathered from >NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. >How do the applications you mention fit into this scope of work? I am trying to see if the AAA transport framework can be used to send accounting info (available from usage records) in a peered Content Delivery Network scenario (peered CDN). http://www.content-peering.org In particular the attributes of usage records in this case would be different than RADIUS, Mobile IP, etc. If the AAA transport can accomodate different record formats, then the AAA framework will be very attractive for *adoption* for billing systems for various services. One way to accomodate known and unknown record formats is to have the payload records describe themself. This way the transport can accomodate *any* usage record. I however understand the AAA framework is not meant to be all purpose. I was trying to see if there was a thought process along the lines of extending the AAA transport to accomodate "other" usage types. Thanks for your time. - Abhi From owner-aaa-bof@merit.edu Wed Jan 17 15:55:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15664 for ; Wed, 17 Jan 2001 15:55:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id B28E85DE71; Wed, 17 Jan 2001 15:53:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 945905DE6E; Wed, 17 Jan 2001 15:53:33 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 884975DE5B for ; Wed, 17 Jan 2001 15:53:32 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 99A1F72; Wed, 17 Jan 2001 15:53:40 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "Aaa-Wg" Subject: DIAMETER Base Protocol (18-Alpha 1) draft / Identifier Date: Wed, 17 Jan 2001 15:53:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, Dave Spence passed me some notes he had made some time back, suggesting that the references the Identifier field could be clarified. Here is my take on Dave's suggestions: - - - Here's what Diameter-18 (Alpha 1) has to say: Identifier The Identifier field is four octets, and aids in matching requests and replies. The sender MUST ensure that the identifier in a message is locally unique (to the sender) at any given time, and MAY attempt to ensure that the number is unique across reboots. The identifier is normally a monotonically increasing number, whose start value was randomly generated. DIAMETER servers should consider a message to be unique by examining the source address, source port, Session-Id and Identifier field of the message. Suggestion: Distinguish between the requirement for the Identifier field in request messages versus reply messages. Discussion: The first sentence of Diameter-18 says that the Identifier field aids in matching requests and replies. The second sentence says that the sender MUST ensure that the identifier in a message is locally unique (to the sender). But this second statement only applies to requests. It is incorrect for responses. For responses, the Identifier should presumably be copied from the Identifier field of the corresponding request. That isn't stated here, and not all of the specific response specifications state this either. Suggestion: Indicate that a proxy is required to manufacture his own Identifier value when forwarding a request, and is required to replace the originally received Identifier when returning a response. Discussion: As to the Identifier being unique with respect to the sender, the fourth sentence of Diameter-18 clarifies that "sender" means "source address and source port". This implies that the proxy should overwrite the value of the Identifier field when forwarding. Now that responses need to be returned back down the request path but in reverse (NAI-based message routing by proxies was removed between diameter-17 and diameter-18), having the proxies change the Identifier field will help them match responses to requests. State stored in the proxy or in the Proxy-State AVP can be used to correctly replace the Identifier field as the response is returned back down the chain. All this mechanism should be specified in the protocol. - - - Historical note-- draft-calhoun-diameter-17.txt gave routing proxies the option of NAI-based message routing, which allowed a response to be returned through a different path. This meant that a routing proxy, when forwarding a request, could not meet the requirements, whether he overwrote the originally received Identifier or not. (!) When returning the response through a different proxy, overwriting the value of the Identifier field by a proxy in the Request path could result in cases where the NAS receives a response whose Identifier does not match that sent in the NAS's request. Firstly, The overwritten Identifier field would not help the proxy receiving the response at all, but presumably it doesn't need to be helped because any state it needs will not be in its memory but must be retrieved from the Proxy-State AVP (which must have the format it expects). Secondly, there may be more than one proxy in the chain, and different numbers of proxies on the way out than on the way back. Then the "send it back a different way" mechanism is broken. There is just no way to get the Identifier field right in the copy of the response that gets sent to the NAS. So in that case, the right thing to do would have been for proxies not to change the Identifier field. But this violates the sender's unique-Identifier requirement. From owner-aaa-bof@merit.edu Wed Jan 17 15:55:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15680 for ; Wed, 17 Jan 2001 15:55:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1CC65DE39; Wed, 17 Jan 2001 15:53:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 750015DE87; Wed, 17 Jan 2001 15:53:50 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id E4C405DE6E for ; Wed, 17 Jan 2001 15:53:47 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA03800; Wed, 17 Jan 2001 15:59:25 -0500 (EST) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma003778; Wed, 17 Jan 01 15:58:51 -0500 Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id PAA08426; Wed, 17 Jan 2001 15:53:06 -0500 (EST) Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 15:53:06 -0500 Message-ID: From: "Nelson, David" To: "'Abhi Deshmukh'" , "'aaa-wg@merit.edu'" Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... Date: Wed, 17 Jan 2001 15:53:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C080C7.7D7B878E" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C080C7.7D7B878E Content-Type: text/plain; charset="iso-8859-1" Abhi Deshmukh writes... > One way to accommodate known and unknown record formats is to have the > payload records describe themselves. This way the transport can accommodate > *any* usage record. > I however understand the AAA framework is not meant to be all purpose. I was > trying to see if there was a thought process along the lines of extending > the AAA transport to accommodate "other" usage types. Certainly the DIAMETER protocol, currently under development in the AAA WG, is extensible, and could very likely be adapted for the use you envision, by specifying the needed extensions to the DIAMETER base document, possibly leveraging the proposed DIAMETER Accounting extensions. Whether standardizing such extensions would be fodder for the AAA WG is another question, of course. Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C080C7.7D7B878E Content-Type: text/html; charset="iso-8859-1" RE: Self Describing record formats for multiple (non-network-acce ss) usage types ...

Abhi Deshmukh writes...

> One way to accommodate known and unknown record formats is to have the
> payload records describe themselves. This way the transport can accommodate
> *any* usage record.

> I however understand the AAA framework is not meant to be all purpose. I was
> trying to see if there was a thought process along the lines of extending
> the AAA transport to accommodate "other" usage types.

Certainly the DIAMETER protocol, currently under development in the AAA WG,
is extensible, and could very likely be adapted for the use you envision,
by specifying the needed extensions to the DIAMETER base document, possibly
leveraging the proposed DIAMETER Accounting extensions.

Whether standardizing such extensions would be fodder for the AAA WG is
another question, of course.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com


------_=_NextPart_001_01C080C7.7D7B878E-- From owner-aaa-bof@merit.edu Wed Jan 17 17:18:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17591 for ; Wed, 17 Jan 2001 17:18:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id BCE375DFC0; Wed, 17 Jan 2001 17:16:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 731305DF12; Wed, 17 Jan 2001 17:16:06 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EFA055DF4B for ; Wed, 17 Jan 2001 17:15:56 -0500 (EST) Received: from purol.East.Sun.COM ([129.148.9.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15520; Wed, 17 Jan 2001 14:15:52 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA01370; Wed, 17 Jan 2001 17:15:51 -0500 (EST) Date: Wed, 17 Jan 2001 17:15:47 -0500 (EST) From: Steven Glass - Solaris Software Reply-To: Steven Glass - Solaris Software Subject: Re: Making the hard choices on AAA security To: stephen.farrell@baltimore.ie Cc: Bernard Aboba , Alain Zahm , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A648124.103B5EEC@baltimore.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > Bernard Aboba wrote: > > > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be > > enforced, using any of the solutions that have been proposed. > > Not sure it could... Maybe not from the solutions proposed, but the most straight-forward way to do this (IMHO) is the way it's done in mobile ip. We have a hash for verifying the registration message wasn't altered in flight (among others). If the home agent says registration is OK, the mobile node needs to verify the hash. The foreign agent (analogous to the proxy in our model) could deny the registration after seeing the home agent's OK, changing the reply code, but in this way it can't say a denied registration is actually approved since it can't generate the correct hash. Yes, this means there has to be some sort of secret already setup between the "approver" and "receiver"... Cheers, Steve From owner-aaa-bof@merit.edu Wed Jan 17 17:29:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17770 for ; Wed, 17 Jan 2001 17:29:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FD035DE8A; Wed, 17 Jan 2001 17:28:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4D6CB5DE84; Wed, 17 Jan 2001 17:28:49 -0500 (EST) Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id 3B8E05DE22 for ; Wed, 17 Jan 2001 17:28:48 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Wed, 17 Jan 2001 17:20:43 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZLK0B3FC; Wed, 17 Jan 2001 17:20:42 -0500 Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id C22AA1CF; Wed, 17 Jan 2001 17:20:42 -0500 Message-Id: <4.3.2.7.2.20010117170939.00e016f0@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Jan 2001 17:21:37 -0500 To: aaa-wg@merit.edu, ietf-web@ietf.org From: "David Mitton" Subject: AAA-WG Archive access change Cc: "David Mitton" , Bernard Aboba , Randy Bush , "Wijnen, Bert (Bert)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk Our mailing list host has changed the way the list archiving is accessed. Please discontinue using the archive URL mentioned on the AAA-WG web page. And now use the following: http://www.merit.edu/mail.archives/aaa-wg/ Thanks. The older URL works for now, but will be removed. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct ServiceWare, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Thu Jan 18 02:55:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA26764 for ; Thu, 18 Jan 2001 02:55:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7879F5DE21; Thu, 18 Jan 2001 02:55:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E22955DE59; Thu, 18 Jan 2001 02:55:00 -0500 (EST) Received: from unipamplona.edu.co (r198h34.telecom.com.co [200.21.198.34]) by segue.merit.edu (Postfix) with SMTP id C82405DD91; Thu, 18 Jan 2001 02:54:41 -0500 (EST) Received: from libero.it by unipamplona.edu.co (SMI-8.6/SMI-SVR4) id DAA06879; Thu, 18 Jan 2001 03:14:26 -0500 From: Subject: Obtain Biotech IPOs! 52 Date: Thu, 18 Jan 2001 02:51:12 Message-Id: <630.824581.405696@libero.it> Reply-To: emed11@libero.it Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk

Help Beta Test Our Site and Be Eligible to Purchase Shares of Future IPOs In Which We Participate**

eMedsecurities has selected you as a possible participant to help test our online stock-trading engine for knowledge-based investing in the life sciences. For your cooperation, you will be eligible to purchase shares of future IPOs in which we participate, for as long as you maintain your account with us. This is limited to only 50 qualified testers!  Request More Information.**

eMedsecurities… The Cure for the Common Portfolio!

eMedsecurities provides you with a wealth of information, all compiled in a single, easy-to-use resource.  Learn about new research and upcoming treatments for muscular dystrophy, multiple sclerosis, Parkinson's disease, Huntington's chorea and much more.  Obtain critical investment information about the companies that are developing these treatments.  eMedsecurities empowers you to make more informed investment decisions. Request More Information.**

Participation in eMedsecurities’ Beta Test allows you:

  • Eligibility to purchase shares of IPOs in which eMedsecurities participates for as long as you maintain your account**

  • Valuable research of the entire product pipeline of companies, including stages of clinical development, by industry or specific disease

  • Useful information about industry trends, recent developments and upcoming IPOs

  • Commitment to customer service featuring our Live Customer Service Online

  • Dedication to fast trade executions at the best possible price.

The following guidelines will explain what we expect from an eMedsecurities Beta Tester:

  • Open a funded eMedsecurities account

  • Visit our online trading site once a week

  • Execute trades through our web site in accordance with your normal practice

  • Submit feedback to eMedsecurities' development team through a questionnaire sent via email

  • Provide us with additional feedback regarding the site as needed.

The test is limited to only 50 Beta Testers so sign up now to be considered!  Request More Information.**

Please note:  All applications for the Beta Test must be submitted by January 24, 2001 to be considered.

Please be advised that your information will stay in our proprietary database and will not be sold, traded, given or otherwise provided to outside vendors.  We respect your privacy.

 

By submitting your information, you implicitly state that this is something that interests you and that you
agree to receive periodic emails from eMedsecurities.

Research indicated that you might benefit from our offer.  To be removed instantly and permanently from our database, simply click here.  We respect all removal requests.

** Restrictions Apply:  Beta test not open to residents of:  HI, IL, MI, MN, MS, NE, NH, TN, TX.   Initial Public Offerings are considered speculative investments and as such may not be appropriate for every investor. If an investor chooses to participate in IPOs, there are certain restrictions that apply:  Flipping- The first time an investor sells his/her shares within the first 30 days the issue is trading in the secondary market, that investor will not be allocated shares for the next 90 days following the sale.  The second time that investor “flips”, they will not be allocated IPO shares for 180 days.  The third time that investor “flips”, they lose their IPO allocations permanently.  Transferring shares- If the investor transfers IPO shares out of their account within the first 30 days the issue is trading in the secondary market, they will permanently lose their IPO allocations.  Beta investors will be chosen from all the applicants based on their income, net worth and investing experience.  IPO shares will only be allocated from transactions in which eMedsecurities participates in the underwriting. A0008-1-A2
From owner-aaa-bof@merit.edu Thu Jan 18 03:54:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA27703 for ; Thu, 18 Jan 2001 03:54:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id B64CA5DE43; Thu, 18 Jan 2001 03:53:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 93F975DE2D; Thu, 18 Jan 2001 03:53:36 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id EA6885DD8F for ; Thu, 18 Jan 2001 03:53:34 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA04239; Thu, 18 Jan 2001 00:53:32 -0800 (PST) Received: from vayne (muc-isdn-7 [129.157.164.107]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id JAA27341; Thu, 18 Jan 2001 09:53:30 +0100 (MET) Date: Thu, 18 Jan 2001 10:03:57 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: Self Describing record formats for multiple (non-network-access) usage types ... To: Abhi Deshmukh Cc: "'aaa-wg@merit.edu'" , erik.guttman@germany.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 Abhi, You wrote: > In particular the attributes of usage records in this case would be > different than RADIUS, Mobile IP, etc. If the AAA transport can > accomodate different record formats, then the AAA framework will be > very attractive for *adoption* for billing systems for various services. DIAMETER data, represented by AVPs, is grouped in commands. Both the commands and the AVPs are accompanied by centrally assigned identifiers for all standardized extensions to the protocol. Two compliant implementations of the protocol will be able to recognize known commands and data, as well as unknown, non-implemented formats, as such. Vendor extensions allow for non-standard messages to be sent. In order to make progress with AAA standardization, the working group narrowed its focus. This does not mean that DIAMETER extensions couldn't be written for other purposes than network access. It is up to you to figure out what your requirements are and to assess whether DIAMETER, SNMP or whatever best fulfill them. > One way to accomodate known and unknown record formats is to have the > payload records describe themself. This way the transport can accomodate > *any* usage record. Self describing data records alone do not achieve much. Labeling a record format as having fields with particular data types does not allow the record to be *interpreted.* Correct interpretation requires common rules (a protocol) to be implemented by communicating parties so they know *what to do* with the data when they get it. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu Jan 18 05:04:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA28782 for ; Thu, 18 Jan 2001 05:04:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 620485DE8E; Thu, 18 Jan 2001 05:03:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5084D5DE8C; Thu, 18 Jan 2001 05:03:09 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 62CCE5DE8B for ; Thu, 18 Jan 2001 05:03:03 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0IA32d04932 for ; Thu, 18 Jan 2001 11:03:02 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 18 11:03:46 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 18 Jan 2001 11:03:01 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE56@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat.Calhoun@Eng.Sun.COM'" , "'aaa-wg@merit.edu'" Subject: DIAMETER Base Protocol (Alpha 1) - Comments Date: Thu, 18 Jan 2001 11:02:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Here is a small contribution to your document, which I think is basically a great piece of work for DIAMETER. Section 1.0 ----------- In the second last paragraph, we have: "Given that the server MAY send unsocilited messages to clients, it is possible for the server to also issue authentication requests." Shouldn't it be AA-Challenge-Ind instead of authentication requests? Should we make this document as independant as possible from the extension specifics, or do we want to keep this close relationship between the base and extension protocols? The thing is that we often read about authentication messages and so on in this document, which I don't think really belong here, right? Instead, this document should specify something as generic as a framework offering sessions in the implementing servers with certain APIs and caracteristics. What do you think? Section 2.0 - par.5 ------------------- "Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular extension/application of DIAMETER." I think this sentence is confusing me. Are you trying to show the real trigger for the session release, the STR (as in section 3.5.2), or the reasons why an STR could have been sent? It seems to me that the "Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular extension/application of DIAMETER." part is more related to original reasons why an STR has been sent. Also, it is confusing to read "authorized service time in the Session-Timeout AVP" when you can also refer to the reason that the "authorization-lifetime-AVP" might have time-out as well, which I assume would trigger an STR. I need more info from you if you want me to propose something else. Section 2.1 ----------- While looking at the DIAMETER header format, it came to me that it might be cleaner to put the Vendor-ID before the Command-Code, since the Command-Code is worthless without the Vendor-ID and finding it first would make more sense. And then I thought, since we might remove the PCC and add more flags, shouldn't we add a flag indicating if a Vendor-ID is present at all in the message, just like in the AVP header? And since we are there, maybe we could put a 2 bit indicator (0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3: reserved) for the Extension-ID or Vendor-ID when present in the message (referring to ML on "Capabilities Negotiation and proxies"), which then would mean that the command-code is per Extension-ID and Vendor-ID base, completely independent of the Base protocol command-code. Maybe an AVP for the command-code field would be a better idea, because it could include the indicator bits and also could be used in a MRI in the Failed-AVP AVP, making obsolete the Un! recognized-Command-Code AVP which lacks the information on the Vendor-ID AVP and Extension-ID. Section 2.2.3 - par.1 --------------------- "... seven data types" should be replaced with "the following data types", since we actually have 10 and it might keep changing. Section 2.2.5 ------------- It would be more useful, at least for me, to have a list of attributes sorted by name, instead AVP codes, which are meaningless to human normal reading. Section 2.5 - par.1 ------------------- "...the Device-Reboot-Ind message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting DIAMETER messages." Please, could you tell me briefly why we need to send all IP addresses of the device? I guess it is because the device is not registered into a DNS and we want to build an internal DNS inside the DIAMETER server along with the Host-Name AVP for message routing, right? Should we have a dynamic or static DNS in the server? And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of the Vendor-ID AVP in the DRI. Section 5.0 ----------- The list of Error Types is a bit confusing with the one found in section 5.1 for MRI. I think it needs some rework. I can´t still figure out exactly how it should be, so maybe I'll come up with something later. Section 5.1.2 ------------- I mentioned some ideas about this in the comments of section 2.1 Section 5.2.2 ------------- All other Result-Code starts a x001, so I thought it should also starts at 2001, instead of 2000. Section 5.2.4 ------------- "...but MAY be able to satisfy the request in the future." What does this mean exactly? Does it mean that a server should be able to resend the request in a few minutes without any specific changes to the message besides the timestamp for example? Should it be regarded as temporary congestion? If it is the case, then maybe we should think of moving the DIAMETER_AUTHENTICATION_REJECTED and DIAMETER_CONTRACTING_AVPS to the permanent failure section. I think that permanent result codes should be used in the rejected message even if the originating server can change AVPs in the message which has been rejected the first time for some reasons such as unsupported mandatory AVPs, because it is no longer the same message anyway, and the first message was really considered as a permanent failure in this particular period of time. Section 7.1.2 ------------- The 3rd paragraph should be removed. Section 10.0 ------------ About the shared secret, maybe we should also mention that it is used by the Encrypted-Payload AVP? /Martin From owner-aaa-bof@merit.edu Thu Jan 18 05:19:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA29239 for ; Thu, 18 Jan 2001 05:19:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DD155DD8F; Thu, 18 Jan 2001 05:16:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D7C25DE59; Thu, 18 Jan 2001 05:16:23 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id 60FB05DD8F for ; Thu, 18 Jan 2001 05:16:21 -0500 (EST) Received: by balinese.baltimore.ie; id KAA04481; Thu, 18 Jan 2001 10:16:20 GMT Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma004450; Thu, 18 Jan 01 10:16:16 GMT Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA30193; Thu, 18 Jan 2001 10:16:15 GMT Message-ID: <3A66C275.449DF740@baltimore.ie> Date: Thu, 18 Jan 2001 10:16:21 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Steven Glass - Solaris Software Cc: Bernard Aboba , Alain Zahm , aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Steven Glass - Solaris Software wrote: > > > > > > > > Bernard Aboba wrote: > > > > > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an > > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be > > > enforced, using any of the solutions that have been proposed. > > > > Not sure it could... > > Maybe not from the solutions proposed... Just for clarity, CMS, Kerberos and any other self-respecting e2e security solution will offer e2e data integrity. The "not sure" etc. refers to allowing one type of change and preventing/detecting another, not to simple integrity. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Thu Jan 18 05:26:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA29299 for ; Thu, 18 Jan 2001 05:26:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21F015DE59; Thu, 18 Jan 2001 05:25:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 12DBB5DE58; Thu, 18 Jan 2001 05:25:58 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id AB1B85DE56 for ; Thu, 18 Jan 2001 05:25:56 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0IAPtd23410 for ; Thu, 18 Jan 2001 11:25:55 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 18 11:26:39 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 18 Jan 2001 11:25:54 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE57@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat.Calhoun@Eng.Sun.COM'" , "'aaa-wg@merit.edu'" Subject: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 Date: Thu, 18 Jan 2001 11:22:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Comments making no sense to you are most probably related to my ignorance... However, I'd appreciate you help me out on this. Section 3.0 - par.2 ------------------- It is weird to me that we refer to an Authorization-Lifetime AVP in the Base Protocol without having any authorization message in it. Now we have the Session-Timeout AVP and the Authorization-Lifetime AVP which are somehow competing together. Should the Authorization-Lifetime AVP be included in a specific extension, such as NASREQ, or is it because it might be used by several extensions without any specific meaning to the base protocol itself, which happens to be pretty much the same as the Session-Timeout AVP? My understanding is that there is not much to do with the Authorization-Lifetime AVP in the base protocol, since the action to take upon its expiration is defined in the NASREQ extension anyway, which is very specific. I guess that something more generic would be a Session-Timeout AVP which could trigger an STI when it expires that could lead to another re-authentication or something else in order to avoid the session to terminate right away. Then the NASREQ extension! could possibly override that meaning by defining its own Authorization-Lifetime AVP which would trigger a more efficient an AA-Challenge-Ind instead. Section 3.2 and 3.3 ------------------- Can the server return a bigger value? What the value 0 means? The same as if it was not there? Which one has priority? Section 3.5 ----------- "Since the Session-Id is typically tied to a particular service (i.e. Mobile IP, NASREQ, etc), the session termination messages are used to request that the service tied to the Session Id be terminated." It seems to be against last paragraph of section 3.1, which is "Note that a Session-Id MAY be used by more than one extension (e.g. authentication for a specific service and accounting, both of which have separate extensions). Section 3.5.2 ------------- What the Resource-Owner-NAI AVP used for in the STR? Is it for routing? I guess not, since the User-Name AVP is present. Can it be used in the server for any particular reason I don't see, since I think the active session should be aware of what's going on within itself, right? Section 3.5.3 ------------- What is the purpose of the STA, since the session in the server and in the proxies should be released after the STR? What can the NAS or the server do if the STR is rejected and the resources are already released in the DIAMETER client and the proxies? Section 3.5.4 ------------- AVP Code 293 From owner-aaa-bof@merit.edu Thu Jan 18 06:39:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA00457 for ; Thu, 18 Jan 2001 06:39:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6ED465DDA7; Thu, 18 Jan 2001 06:39:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E2875DE56; Thu, 18 Jan 2001 06:39:30 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 89AD55DDA7 for ; Thu, 18 Jan 2001 06:39:28 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0IBdRC03122 for ; Thu, 18 Jan 2001 12:39:27 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 18 12:39:27 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 18 Jan 2001 12:39:26 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE58@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'stephen.farrell@baltimore.ie'" , Steven Glass - Solaris Software Cc: Bernard Aboba , Alain Zahm , aaa-wg@merit.edu Subject: RE: Making the hard choices on AAA security Date: Thu, 18 Jan 2001 12:38:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Steven, Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e, using the Strong Security extension of course, which would prevent proxies to play around with its content when not allowed by the server? Martin -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] Sent: Thursday, January 18, 2001 11:16 AM To: Steven Glass - Solaris Software Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu Subject: Re: Making the hard choices on AAA security Steven Glass - Solaris Software wrote: > > > > > > > > Bernard Aboba wrote: > > > > > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an > > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be > > > enforced, using any of the solutions that have been proposed. > > > > Not sure it could... > > Maybe not from the solutions proposed... Just for clarity, CMS, Kerberos and any other self-respecting e2e security solution will offer e2e data integrity. The "not sure" etc. refers to allowing one type of change and preventing/detecting another, not to simple integrity. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Thu Jan 18 07:52:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA01391 for ; Thu, 18 Jan 2001 07:52:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 58E8D5DE0C; Thu, 18 Jan 2001 07:49:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3A47F5DE6A; Thu, 18 Jan 2001 07:49:50 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 1B9D85DE0C for ; Thu, 18 Jan 2001 07:49:44 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0ICnhd02434 for ; Thu, 18 Jan 2001 13:49:43 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 18 13:50:27 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 18 Jan 2001 13:49:41 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE59@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Erik Guttman'" , Abhi Deshmukh , "'aaa-wg@merit.edu'" Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... Date: Thu, 18 Jan 2001 13:49:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Abhi, Maybe the discussion on this ML "Choice of Data Model SMI vs XML vs. UML)" could give you a better idea of what is being discussed about an AAA dictionnary at the moment. I am not sure exactly where that discussion is going (SMIng???), but I'd like to see it going towards what you want as well, which I think is defining new attributes (AVPs) in a flexible way at run-time and being able to output them for accounting purposes, for example, as is to an accounting server. Since the logging format and the accounting format is no longer ADIF, I'm not sure what to expect besides the dumping of AVPs at the moment. Refer to ML "DISCUSSION REQUESTED: ADIF, Batching, M bit" for the following comment: > However, I think that specifying a recommended XML or SMI format for the > accounting file that is written on the server MAY be a desirable goal. Hope it helps, Martin -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] Sent: Thursday, January 18, 2001 10:04 AM To: Abhi Deshmukh Cc: 'aaa-wg@merit.edu'; erik.guttman@germany.sun.com Subject: RE: Self Describing record formats for multiple (non-network-access) usage types ... Abhi, You wrote: > In particular the attributes of usage records in this case would be > different than RADIUS, Mobile IP, etc. If the AAA transport can > accomodate different record formats, then the AAA framework will be > very attractive for *adoption* for billing systems for various services. DIAMETER data, represented by AVPs, is grouped in commands. Both the commands and the AVPs are accompanied by centrally assigned identifiers for all standardized extensions to the protocol. Two compliant implementations of the protocol will be able to recognize known commands and data, as well as unknown, non-implemented formats, as such. Vendor extensions allow for non-standard messages to be sent. In order to make progress with AAA standardization, the working group narrowed its focus. This does not mean that DIAMETER extensions couldn't be written for other purposes than network access. It is up to you to figure out what your requirements are and to assess whether DIAMETER, SNMP or whatever best fulfill them. > One way to accomodate known and unknown record formats is to have the > payload records describe themself. This way the transport can accomodate > *any* usage record. Self describing data records alone do not achieve much. Labeling a record format as having fields with particular data types does not allow the record to be *interpreted.* Correct interpretation requires common rules (a protocol) to be implemented by communicating parties so they know *what to do* with the data when they get it. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Thu Jan 18 10:26:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA04696 for ; Thu, 18 Jan 2001 10:26:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00A305DE82; Thu, 18 Jan 2001 10:25:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DAD935DE81; Thu, 18 Jan 2001 10:25:54 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id C72B75DE7D for ; Thu, 18 Jan 2001 10:25:52 -0500 (EST) Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA12397 for ; Thu, 18 Jan 2001 16:26:45 +0100 From: "Fredrik Johansson" To: "AAA Listan" Subject: Comments on draft-calhoun-diameter-18.txt Date: Thu, 18 Jan 2001 16:28:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C0816B.AD7CB990" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C0816B.AD7CB990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The is missing in the table in section 2.2.5 /Fredrik ---------------------------------------------------------------------------- ------- Fredrik Johansson W: +46 (0)8 725 5916 Interactive People Unplugged M: +46 (0)70 786 5035 mailto:fredrik.johansson@ipunplugged.com http://www.ipunplugged.com ------=_NextPart_000_000C_01C0816B.AD7CB990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 <Grouped-AVP> is missing in the table in section = 2.2.5
 
/Fredrik
 
 
----------------------------------------------------------------= -------------------
Fredrik=20 Johansson          &nbs= p;         W:=20 +46 (0)8 725 5916
Interactive People=20 Unplugged     M: +46 (0)70 786 5035
mailto:fredrik.johansso= n@ipunplugged.com
http://www.ipunplugged.com
 
 
------=_NextPart_000_000C_01C0816B.AD7CB990-- From owner-aaa-bof@merit.edu Thu Jan 18 15:52:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11461 for ; Thu, 18 Jan 2001 15:52:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D20F5E151; Thu, 18 Jan 2001 15:29:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DBBD75E4FE; Thu, 18 Jan 2001 15:25:50 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9FEDA5DF39 for ; Thu, 18 Jan 2001 15:12:45 -0500 (EST) Received: from purol.East.Sun.COM ([129.148.9.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20230; Thu, 18 Jan 2001 12:12:39 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id PAA04884; Thu, 18 Jan 2001 15:12:38 -0500 (EST) Date: Thu, 18 Jan 2001 15:12:33 -0500 (EST) From: Steven Glass - Solaris Software Reply-To: Steven Glass - Solaris Software Subject: RE: Making the hard choices on AAA security To: "Martin Julien (ECE)" Cc: "'stephen.farrell@baltimore.ie'" , Steven Glass - Solaris Software , Bernard Aboba , Alain Zahm , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE58@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Steven, > > Could we possibly think of allowing the Result-Code AVP to be encrypted for > e2e, using the Strong Security extension of course, which would prevent > proxies to play around with its content when not allowed by the server? > > Martin Sure, why not? (If you're asking for a mobileip-centric viewpoint, I don't see why this would generate any issues). In this case, if a proxy decided it wanted to deny (even if only based on the _unencrypted_ portion of the answer it got back from the AAA server), it could always throw away [x-bits of] the packet, and generate it's own reply - e.g. "error 666: I didn't like the AAA server's tone". This means some wasted cycles on securing the e2e piece at the AAA server, but that possibility will never go away. Whenever there's a proxy involved, there's always going to have to be non-e2e encrypted bits in the AAA server's response (if only based on likely policies at the proxy), and Proxy decisions can always be made based on that info. Cheers, Steve > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > Sent: Thursday, January 18, 2001 11:16 AM > To: Steven Glass - Solaris Software > Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu > Subject: Re: Making the hard choices on AAA security > > > > > Steven Glass - Solaris Software wrote: > > > > > > > > > > > > Bernard Aboba wrote: > > > > > > > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an > > > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be > > > > enforced, using any of the solutions that have been proposed. > > > > > > Not sure it could... > > > > Maybe not from the solutions proposed... > > Just for clarity, CMS, Kerberos and any other self-respecting > e2e security solution will offer e2e data integrity. The "not > sure" etc. refers to allowing one type of change and > preventing/detecting another, not to simple integrity. > > Stephen. > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Thu Jan 18 16:44:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12477 for ; Thu, 18 Jan 2001 16:44:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1DC25DE93; Thu, 18 Jan 2001 16:29:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 01C435DF21; Thu, 18 Jan 2001 16:13:36 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 101B75DF24 for ; Thu, 18 Jan 2001 15:45:46 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 450A272; Thu, 18 Jan 2001 15:45:54 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "Aaa-Wg" Subject: DIAMETER Base Protocol (18-Alpha 1) draft / MRI Date: Thu, 18 Jan 2001 15:45:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, Here are some questions on the DIAMETER Base Protocol (18-Alpha 1) draft. The gist of what follows is: (a) the draft's phrase "Extension Response + Result-Code" is ambiguous, and (b) There may be error conditions where an MRI can't be sent, yet no appropriate extension response is available. 5.0 Error Reporting -------------------- The draft says: "Extension Response + Result-Code" indicates that the appropriate Response to the message MUST be sent with the Result-Code AVP set to a value that enables the peer to understand the nature of the problem. Problem 1: The phrase "Extension Response + Result-Code" is ambiguous. Does "Extension Response + Result-Code" mean "a response with an extension-specific command code", or "a response specified by the extension, but which may be an MRI"? If the first meaning, perhaps the draft-18's text could be clarified by adding the following sentence to the paragraph: The Response has an extension-specific command code. - - - Draft-18 specifies a more limited role for the MRI message. That is, between draft-17 and draft-18, some of the 'X's in the following table from section 5.0 have shifted from the "Send Message-Reject-Ind" column into the "Extension Response + Result-Code" column. Draft-17 said: > Error Type Ignore Message Send Extension > Message-Reject-Ind Response + > Result-Code > Bad Message X > Unknown Command X > Unknown AVP X > Bad Value X > Extension Error X Draft-18-Alpha 1 says: > Error Type Ignore Message Send Extension > Message-Reject-Ind Response + > Result-Code > Bad Message X > Unknown Command X > Unknown AVP X > Bad AVP Value X > Extension Error X This shift to an extension-specific response is probably because a proxy which routes on Diameter extension wouldn't know how to route an MRI. Problem 2: Assuming that "Extension Response + Result-Code" means "a response with an extension-specific command code", it seems like the MRI is limited to dealing with (a) DRI errors and (b) Unknown Command errors. But some recent mailing list questions suggest that there may be error conditions other than (a) or (b), where no appropriate extension response is available. [One of the emails I am referring to is the "DIAMETER Base Protocol (18-Alpha 1)" draft / 5.0 Error Reporting" email of 16-Jan-2001, suggesting that a receiver of a reply packet which contains a bad AVP may want to send an MRI. Another is the "Re: Comments on draft-calhoun-diameter-18.txt" email of 17-Jan-2001, suggesting that an MRI is a candidate to recover from a looped proxy chain.] -------------------------------------------------------------- Bob Kopacz mailto:bkopacz@interlinknetworks.com Interlink Networks, Inc. http://www.interlinknetworks.com [Tel] 734-821-1230 From owner-aaa-bof@merit.edu Thu Jan 18 17:29:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13211 for ; Thu, 18 Jan 2001 17:29:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EEEC5DDE0; Thu, 18 Jan 2001 17:12:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 022035E042; Thu, 18 Jan 2001 16:57:14 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B76455E474 for ; Thu, 18 Jan 2001 16:49:36 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E446772; Thu, 18 Jan 2001 16:49:44 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "Aaa-Wg" Subject: Comment on DIAMETER Base Protocol / Port 1812 Date: Thu, 18 Jan 2001 16:48:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, The Diameter base drafts say: "The base DIAMETER protocol is run over SCTP [26] port 1812." I'm not sure 1812 is a given; the draft might better say "The base DIAMETER protocol is run over SCTP [26] port [TBD]." Discussion: ----------- IANA's "well known port numbers" currently assign port 1812 to RADIUS/UDP and RADIUS/TCP. Specifically, IANA's entry for port 1812 is: > Port Assignments: > > Keyword Decimal Description Refrences > ------- ------- ----------- --------- > [...] > radius 1812/tcp RADIUS Carl Rigney > radius 1812/udp RADIUS Carl Rigney When I look over IANA's other assigned ports, it seems their consistent notion is that the port is associated with exactly one application. So assigning 1812 to both Radius and Diameter would result in the unusual: > Port Assignments: > > Keyword Decimal Description Refrences > ------- ------- ----------- --------- > [...] > radius 1812/tcp RADIUS Carl Rigney > radius 1812/udp RADIUS Carl Rigney > diameter 1812/tcp DIAMETER Pat Calhoun <...> > diameter 1812/sctp DIAMETER Pat Calhoun <...> > # So I'm guessing that Diameter would end up with a brand new port number (and that PCC will be eliminated). -------------------------------------------------------------- Bob Kopacz mailto:bkopacz@interlinknetworks.com Interlink Networks, Inc. http://www.interlinknetworks.com [Tel] 734-821-1230 From owner-aaa-bof@merit.edu Thu Jan 18 17:47:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13551 for ; Thu, 18 Jan 2001 17:47:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17A185E2B9; Thu, 18 Jan 2001 17:40:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 749895DF40; Thu, 18 Jan 2001 17:30:18 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 1ABF95E08B for ; Thu, 18 Jan 2001 17:17:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09340; Thu, 18 Jan 2001 14:17:13 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA28734; Thu, 18 Jan 2001 14:17:11 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id KAA20317; Thu, 18 Jan 2001 10:01:52 -0800 (PST) From: Pat Calhoun Message-Id: <200101181801.KAA20317@nasnfs.eng.sun.com> Date: Thu, 18 Jan 2001 10:00:21 -0800 To: "Martin Julien (ECE)" , "Steven Glass - Solaris Software" , "'stephen.farrell@baltimore.ie'" Cc: , "Alain Zahm" , "Bernard Aboba" Reply-To: Subject: RE: Making the hard choices on AAA security X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk For proxies that wish to maintain state information, not having access to the result code would be a problem. Perhaps e2e authenticated, but not encrypted. PatC >Steven, > >Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e, >using the Strong Security extension of course, which would prevent proxies to >play around with its content when not allowed by the server? > >Martin > >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] >Sent: Thursday, January 18, 2001 11:16 AM >To: Steven Glass - Solaris Software >Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu >Subject: Re: Making the hard choices on AAA security > > > > >Steven Glass - Solaris Software wrote: >> >> > >> > >> > > Bernard Aboba wrote: >> > > >> > > A proxy can change an Access-Accept into an Access-Reject under the guise >of "policy". However, an >> > > Access-Reject should never be changed to an Access-Accept. A good question >is how this could be >> > > enforced, using any of the solutions that have been proposed. >> > >> > Not sure it could... >> >> Maybe not from the solutions proposed... > >Just for clarity, CMS, Kerberos and any other self-respecting >e2e security solution will offer e2e data integrity. The "not >sure" etc. refers to allowing one type of change and >preventing/detecting another, not to simple integrity. > >Stephen. > >-- >____________________________________________________________ >Stephen Farrell >Baltimore Technologies, tel: (direct line) +353 1 881 6716 >39 Parkgate Street, fax: +353 1 881 7000 >Dublin 8. mailto:stephen.farrell@baltimore.ie >Ireland http://www.baltimore.com > From owner-aaa-bof@merit.edu Thu Jan 18 17:59:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13763 for ; Thu, 18 Jan 2001 17:59:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6CB355DFF4; Thu, 18 Jan 2001 17:31:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3FA6B5DDD8; Thu, 18 Jan 2001 17:22:44 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9F7A95E296 for ; Thu, 18 Jan 2001 17:05:58 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E42F772 for ; Thu, 18 Jan 2001 17:06:06 -0500 (EST) From: "Bob Kopacz" To: "Aaa-Wg" Subject: Diameter SCTP-vs-TCP Transport Issues Date: Thu, 18 Jan 2001 17:05:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Here are some Diameter transport issues. I'm not sure if this is better targeted as comments on the "AAA Problem Statements" or the "DIAMETER Base Protocol (18-Alpha 1)" draft. It's been stated that the AAA Solutions paper and the Diameter base document need to address and specify the transport mappings, e.g. which end initiates a connection, re-establishing dropped connections, whether long idle connections may be dropped. Here are some issues to include on this list, if not already there: It looks like Diameter may be transported over TCP rather than SCTP. If so: 1. Because of the firewall problem (firewalls on the path between two Diameter peers may not recognize the new SCTP protocol type in the IP header, and may discard the SCTP packets), is it a valid notion for a NAS or AAA Server to attempt an SCTP connection to a Diameter peer, and to fall back to TCP upon failure; the thought being that the firewall is hosing SCTP packets or that the peer's SCTP service is not running? 2. Where the Diameter specification relies on the more robust SCTP transport layer, compensations need to be made for features that SCTP provides that TCP does not provide. As one tiny example, SCTP provides a heartbeat; so the Diameter ULP might try to set up TCP to run its keepalive timer. The Diameter specification needs to indicate the places where it needs to drive certain transports in a specific manner. 3. The DRI carries multiple IP addresses associated with the sender, I assume for SCTP's multi-homed host support. Since Diameter/TCP peers will communicate using a single IP address at each end, would a DRI for a TCP peer eliminate these unusable alternate addresses? Or is there some unstated notion that these alternate peer IP addresses would somehow be used over TCP transports? From owner-aaa-bof@merit.edu Thu Jan 18 18:56:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA14679 for ; Thu, 18 Jan 2001 18:56:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51A935E0BB; Thu, 18 Jan 2001 18:33:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 32D365E034; Thu, 18 Jan 2001 17:58:11 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C8F175E0B5 for ; Thu, 18 Jan 2001 17:34:25 -0500 (EST) Received: from purol.East.Sun.COM ([129.148.9.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19226; Thu, 18 Jan 2001 14:33:41 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA16848; Thu, 18 Jan 2001 17:33:40 -0500 (EST) Date: Thu, 18 Jan 2001 17:33:36 -0500 (EST) From: Steven Glass - Solaris Software Reply-To: Steven Glass - Solaris Software Subject: RE: Making the hard choices on AAA security To: Pat.Calhoun@eng.sun.com Cc: "Martin Julien (ECE)" , Steven Glass - Solaris Software , "'stephen.farrell@baltimore.ie'" , aaa-wg@merit.edu, Alain Zahm , Bernard Aboba In-Reply-To: "Your message with ID" <200101181801.KAA20317@nasnfs.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > For proxies that wish to maintain state information, not having access > to the result code would be a problem. > > Perhaps e2e authenticated, but not encrypted. This is the foundation of my point, and of course Pat said it better than I. I took it as a given that if the AAA response is e2e encrypted, the approval info has to be some place else for the proxy to see! Cheers, Steve From owner-aaa-bof@merit.edu Thu Jan 18 19:20:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15059 for ; Thu, 18 Jan 2001 19:20:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 268A15DF87; Thu, 18 Jan 2001 19:06:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2DF695DEF2; Thu, 18 Jan 2001 18:39:55 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id CB51E5E01C for ; Thu, 18 Jan 2001 18:16:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15995; Thu, 18 Jan 2001 15:16:20 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13607; Thu, 18 Jan 2001 15:16:18 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08118; Thu, 18 Jan 2001 15:15:48 -0800 (PST) From: Pat Calhoun Message-Id: <200101182315.PAA08118@nasnfs.eng.sun.com> Date: Thu, 18 Jan 2001 15:13:57 -0800 To: "Bob Kopacz" , "Pat Calhoun" Cc: "Aaa-Wg" Reply-To: Subject: Re: Comment on DIAMETER Base Protocol / Port 1812 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk >Hi Pat, > >The Diameter base drafts say: > > "The base DIAMETER protocol is run over SCTP [26] port 1812." > >I'm not sure 1812 is a given; the draft might better say > > "The base DIAMETER protocol is run over SCTP [26] port [TBD]." Until I do get a port number, you are correct. However, a port number needs to be specified at the moment for interoperability. > > >Discussion: >----------- >IANA's "well known port numbers" currently assign port 1812 >to RADIUS/UDP and RADIUS/TCP. Specifically, IANA's entry >for port 1812 is: > >> Port Assignments: >> >> Keyword Decimal Description Refrences >> ------- ------- ----------- --------- >> [...] >> radius 1812/tcp RADIUS Carl Rigney >> radius 1812/udp RADIUS Carl Rigney > > >When I look over IANA's other assigned ports, it seems their >consistent notion is that the port is associated with exactly >one application. So assigning 1812 to both Radius and Diameter >would result in the unusual: I am not sure this is correct, but I must admit that having port 1812 for TCP reserved for RADIUS is very odd. I seriously doubt that IANA would allow such waste to occur. Perhaps this is an error, and I will look into this. > >> Port Assignments: >> >> Keyword Decimal Description Refrences >> ------- ------- ----------- --------- >> [...] >> radius 1812/tcp RADIUS Carl Rigney >> radius 1812/udp RADIUS Carl Rigney >> diameter 1812/tcp DIAMETER Pat Calhoun <...> >> diameter 1812/sctp DIAMETER Pat Calhoun <...> >> # > >So I'm guessing that Diameter would end up with a brand new port >number (and that PCC will be eliminated). Yes, the PCC will be eliminated (in fact, I thought I had in -18). PatC From owner-aaa-bof@merit.edu Thu Jan 18 19:21:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA15073 for ; Thu, 18 Jan 2001 19:21:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C1DA5DE8D; Thu, 18 Jan 2001 19:06:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4671A5E01C; Thu, 18 Jan 2001 18:40:01 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E559A5DF85 for ; Thu, 18 Jan 2001 18:18:09 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08008; Thu, 18 Jan 2001 15:18:07 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13979; Thu, 18 Jan 2001 15:18:05 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08137; Thu, 18 Jan 2001 15:17:33 -0800 (PST) From: Pat Calhoun Message-Id: <200101182317.PAA08137@nasnfs.eng.sun.com> Date: Thu, 18 Jan 2001 15:15:45 -0800 To: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" , "'Pat.Calhoun@Eng.Sun.COM'" Reply-To: Subject: Re: DIAMETER Base Protocol (Alpha 1) - Comments X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Martin, Thanks for the great comments. I am travelling at the moment, and will address these tomorrow (just want to make sure that you don't think I am ignoring this e-mail). PatC >Pat, > >Here is a small contribution to your document, which I think is basically a >great piece of work for DIAMETER. > > >Section 1.0 >----------- >In the second last paragraph, we have: >"Given that the server MAY send unsocilited messages to clients, it is possible >for the server to also issue authentication requests." >Shouldn't it be AA-Challenge-Ind instead of authentication requests? > >Should we make this document as independant as possible from the extension >specifics, or do we want to keep this close relationship between the base and >extension protocols? The thing is that we often read about authentication >messages and so on in this document, which I don't think really belong here, >right? Instead, this document should specify something as generic as a framework >offering sessions in the implementing servers with certain APIs and >caracteristics. What do you think? > >Section 2.0 - par.5 >------------------- >"Session state (associated with a Session-Id) MUST be freed upon receipt of the >Session-Termination-Request, Session-Termination-Answer, expiration of >authorized service time in the Session-Timeout AVP, and according to rules >established in a particular extension/application of DIAMETER." > >I think this sentence is confusing me. Are you trying to show the real trigger >for the session release, the STR (as in section 3.5.2), or the reasons why an >STR could have been sent? It seems to me that the "Session-Termination-Answer, >expiration of authorized service time in the Session-Timeout AVP, and according >to rules established in a particular extension/application of DIAMETER." part is >more related to original reasons why an STR has been sent. Also, it is confusing >to read "authorized service time in the Session-Timeout AVP" when you can also >refer to the reason that the "authorization-lifetime-AVP" might have time-out as >well, which I assume would trigger an STR. I need more info from you if you want >me to propose something else. > >Section 2.1 >----------- >While looking at the DIAMETER header format, it came to me that it might be >cleaner to put the Vendor-ID before the Command-Code, since the Command-Code is >worthless without the Vendor-ID and finding it first would make more sense. And >then I thought, since we might remove the PCC and add more flags, shouldn't we >add a flag indicating if a Vendor-ID is present at all in the message, just like >in the AVP header? And since we are there, maybe we could put a 2 bit indicator >(0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3: reserved) for the >Extension-ID or Vendor-ID when present in the message (referring to ML on >"Capabilities Negotiation and proxies"), which then would mean that the >command-code is per Extension-ID and Vendor-ID base, completely independent of >the Base protocol command-code. Maybe an AVP for the command-code field would be >a better idea, because it could include the indicator bits and also could be >used in a MRI in the Failed-AVP AVP, making obsolete the Un! >recognized-Command-Code AVP which lacks the information on the Vendor-ID AVP and >Extension-ID. > >Section 2.2.3 - par.1 >--------------------- >"... seven data types" should be replaced with "the following data types", since >we actually have 10 and it might keep changing. > >Section 2.2.5 >------------- >It would be more useful, at least for me, to have a list of attributes sorted by >name, instead AVP codes, which are meaningless to human normal reading. > >Section 2.5 - par.1 >------------------- >"...the Device-Reboot-Ind message MUST contain one Host-IP-Address AVP for each >potential IP address that MAY be locally used when transmitting DIAMETER >messages." > >Please, could you tell me briefly why we need to send all IP addresses of the >device? I guess it is because the device is not registered into a DNS and we >want to build an internal DNS inside the DIAMETER server along with the >Host-Name AVP for message routing, right? Should we have a dynamic or static DNS >in the server? > >And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name >AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of the >Vendor-ID AVP in the DRI. > >Section 5.0 >----------- >The list of Error Types is a bit confusing with the one found in section 5.1 for >MRI. I think it needs some rework. I can´t still figure out exactly how it >should be, so maybe I'll come up with something later. > >Section 5.1.2 >------------- >I mentioned some ideas about this in the comments of section 2.1 > >Section 5.2.2 >------------- >All other Result-Code starts a x001, so I thought it should also starts at 2001, >instead of 2000. > >Section 5.2.4 >------------- >"...but MAY be able to satisfy the request in the future." >What does this mean exactly? Does it mean that a server should be able to resend >the request in a few minutes without any specific changes to the message besides >the timestamp for example? Should it be regarded as temporary congestion? If it >is the case, then maybe we should think of moving the >DIAMETER_AUTHENTICATION_REJECTED and DIAMETER_CONTRACTING_AVPS to the permanent >failure section. I think that permanent result codes should be used in the >rejected message even if the originating server can change AVPs in the message >which has been rejected the first time for some reasons such as unsupported >mandatory AVPs, because it is no longer the same message anyway, and the first >message was really considered as a permanent failure in this particular period >of time. > >Section 7.1.2 >------------- >The 3rd paragraph should be removed. > >Section 10.0 >------------ >About the shared secret, maybe we should also mention that it is used by the >Encrypted-Payload AVP? > >/Martin > From owner-aaa-bof@merit.edu Fri Jan 19 02:49:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA21582 for ; Fri, 19 Jan 2001 02:49:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BDCA5DDA1; Fri, 19 Jan 2001 02:46:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 556385DDDD; Fri, 19 Jan 2001 02:46:17 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id C14395DDA1 for ; Fri, 19 Jan 2001 02:46:15 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0J7kFC25997 for ; Fri, 19 Jan 2001 08:46:15 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jan 19 08:46:59 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 19 Jan 2001 08:46:22 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE5B@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat.Calhoun@Eng.Sun.COM'" , "'aaa-wg@merit.edu'" Subject: AAA-WG: RE: Making the hard choices on AAA security Date: Fri, 19 Jan 2001 08:46:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document? Martin -----Original Message----- From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Thursday, January 18, 2001 7:00 PM To: Martin Julien (ECE); Steven Glass - Solaris Software; 'stephen.farrell@baltimore.ie' Cc: aaa-wg@merit.edu; Alain Zahm; Bernard Aboba Subject: RE: Making the hard choices on AAA security For proxies that wish to maintain state information, not having access to the result code would be a problem. Perhaps e2e authenticated, but not encrypted. PatC >Steven, > >Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e, >using the Strong Security extension of course, which would prevent proxies to >play around with its content when not allowed by the server? > >Martin > >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] >Sent: Thursday, January 18, 2001 11:16 AM >To: Steven Glass - Solaris Software >Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu >Subject: Re: Making the hard choices on AAA security > > > > >Steven Glass - Solaris Software wrote: >> >> > >> > >> > > Bernard Aboba wrote: >> > > >> > > A proxy can change an Access-Accept into an Access-Reject under the guise >of "policy". However, an >> > > Access-Reject should never be changed to an Access-Accept. A good question >is how this could be >> > > enforced, using any of the solutions that have been proposed. >> > >> > Not sure it could... >> >> Maybe not from the solutions proposed... > >Just for clarity, CMS, Kerberos and any other self-respecting >e2e security solution will offer e2e data integrity. The "not >sure" etc. refers to allowing one type of change and >preventing/detecting another, not to simple integrity. > >Stephen. > >-- >____________________________________________________________ >Stephen Farrell >Baltimore Technologies, tel: (direct line) +353 1 881 6716 >39 Parkgate Street, fax: +353 1 881 7000 >Dublin 8. mailto:stephen.farrell@baltimore.ie >Ireland http://www.baltimore.com > From owner-aaa-bof@merit.edu Fri Jan 19 04:07:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA22935 for ; Fri, 19 Jan 2001 04:07:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0FEA65DD97; Fri, 19 Jan 2001 04:06:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC99D5DDC1; Fri, 19 Jan 2001 04:06:31 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 590FE5DD97 for ; Fri, 19 Jan 2001 04:06:30 -0500 (EST) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26614; Fri, 19 Jan 2001 01:06:21 -0800 (PST) Received: from germany.sun.com (muc-isdn-15 [129.157.164.115]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with ESMTP id KAA10532; Fri, 19 Jan 2001 10:06:19 +0100 (MET) Message-ID: <3A6805FE.9B2350F@germany.sun.com> Date: Fri, 19 Jan 2001 10:16:46 +0100 From: Erik Guttman Reply-To: Erik.Guttman@sun.com Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: de-DE, fr-FR, en MIME-Version: 1.0 To: Fredrik Johansson Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com Subject: AAA-WG: Re: Comments on draft-calhoun-diameter-18.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk > Fredrik Johansson wrote: > > The is missing in the table in section 2.2.5 Its definition is missing too. This is *intentional*. Grouped-AVP has been replaced by the Grouped value type. This has several advantages over a Grouped AVP. (1) we can get rid of the 'Complex' data type so that all AVP values are either well defined types or a sequence of AVPs, which are themselves well defined. (2) We do not have open ended groups, (bags of AVPs) but rather defined sequences of AVPs, all of which MUST be there in the defined order. (3) This makes it much easier to specify DIAMETER formally and to ensure interoperability. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n SHORT msgs: 01728655497@d2-message.de Sr Staff Engineer, Sun Microsystems Email: erik.guttman@sun.com Eichhoelzelstr. 7, 74915 Waibstadt Germany Phone: +49 172 865 5497 From owner-aaa-bof@merit.edu Fri Jan 19 09:07:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA27769 for ; Fri, 19 Jan 2001 09:07:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id D987B5DE4F; Fri, 19 Jan 2001 09:07:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE2A05DE56; Fri, 19 Jan 2001 09:07:40 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 270345DE4F for ; Fri, 19 Jan 2001 09:07:39 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0JE7CC29689 for ; Fri, 19 Jan 2001 15:07:12 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jan 19 15:07:07 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 19 Jan 2001 15:07:15 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE60@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat.Calhoun@Eng.Sun.COM'" , "'aaa-wg@merit.edu'" , "'stephen.farrell@baltimore.ie'" Subject: AAA-WG: RE: Making the hard choices on AAA security Date: Fri, 19 Jan 2001 15:02:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA27769 Pat, Stephen, I guess the easy answer to this is to use signed-only CMS-Data AVP, allowing the Result-Code AVP to be protected (P flag set) in the case of rejection only from a Home or Proxy server, right? Then, in the case where the Home server accept the request, the proxy could still reject it based on local policies. However, I don´t think it fits into a clean solution. Another thread in this ML talks about MRI and Result-Codes from Extension Reply/Answer, and I need to figure out where it is going before coming up with something better. Also, if I think of an example in which the request is rejected and the Result-Code AVP authenticated by a CMS-Data AVP, I wonder if the proxy could still remove the CMS-Data AVP and replace the Result-Code AVP for a successful answer? I guess, in the case of e2e security, the originating servers should always be expecting a CMS-Data AVP from servers which are located on the other side of untrusted proxies, otherwise messages could be an indication of fraudulent activities. I think there can not be more than 1 CMS-Data AVP per message, which means that it would be difficult to mix signed-only and encrypted data. Since there is nothing in the Base and Extension protocols about it (as far as I know), maybe some clarification in the Strong Security Extension would be needed. I guess the servers need to define some special information in their routing table about trusted and untrusted servers and local policies for handling the validation of the messages. I might be missing some fundamental knowledge here, so I'd appreciate if you could answer this. I think I understand the requirement of simplicity and lightweight... ;-) Martin -----Original Message----- From: Martin Julien (ECE) [mailto:Martin.Julien@ece.ericsson.se] Sent: Friday, January 19, 2001 8:46 AM To: 'Pat.Calhoun@Eng.Sun.COM'; 'aaa-wg@merit.edu' Subject: AAA-WG: RE: Making the hard choices on AAA security I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document? Martin -----Original Message----- From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] Sent: Thursday, January 18, 2001 7:00 PM To: Martin Julien (ECE); Steven Glass - Solaris Software; 'stephen.farrell@baltimore.ie' Cc: aaa-wg@merit.edu; Alain Zahm; Bernard Aboba Subject: RE: Making the hard choices on AAA security For proxies that wish to maintain state information, not having access to the result code would be a problem. Perhaps e2e authenticated, but not encrypted. PatC >Steven, > >Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e, >using the Strong Security extension of course, which would prevent proxies to >play around with its content when not allowed by the server? > >Martin > >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] >Sent: Thursday, January 18, 2001 11:16 AM >To: Steven Glass - Solaris Software >Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu >Subject: Re: Making the hard choices on AAA security > > > > >Steven Glass - Solaris Software wrote: >> >> > >> > >> > > Bernard Aboba wrote: >> > > >> > > A proxy can change an Access-Accept into an Access-Reject under the guise >of "policy". However, an >> > > Access-Reject should never be changed to an Access-Accept. A good question >is how this could be >> > > enforced, using any of the solutions that have been proposed. >> > >> > Not sure it could... >> >> Maybe not from the solutions proposed... > >Just for clarity, CMS, Kerberos and any other self-respecting >e2e security solution will offer e2e data integrity. The "not >sure" etc. refers to allowing one type of change and >preventing/detecting another, not to simple integrity. > >Stephen. > >-- >____________________________________________________________ >Stephen Farrell >Baltimore Technologies, tel: (direct line) +353 1 881 6716 >39 Parkgate Street, fax: +353 1 881 7000 >Dublin 8. mailto:stephen.farrell@baltimore.ie >Ireland http://www.baltimore.com > From owner-aaa-bof@merit.edu Fri Jan 19 11:07:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00355 for ; Fri, 19 Jan 2001 11:07:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 287F95DEDC; Fri, 19 Jan 2001 11:06:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 135EF5DDC7; Fri, 19 Jan 2001 11:06:06 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id B82CE5DEDB for ; Fri, 19 Jan 2001 11:06:04 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0JG65R14225 for ; Fri, 19 Jan 2001 10:06:05 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 19 Jan 2001 10:06:02 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Fri, 19 Jan 2001 10:06:02 -0600 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032132E9@daeis07nok> From: Basavaraj.Patil@nokia.com To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: BURP BOF Date: Fri, 19 Jan 2001 10:01:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk A BOF on Basic User Registration Protocol (BURP) Charter: The vision of pervasive computing also includes constantly being connected and the ability to access the Internet or the enterprise over the Internet. Mobile computing solutions based on protocols such as Mobile IP offer seamless and continuous connectivity for users. However a lot of roadwarriors and other types of users access the network from places like airports, hotels, malls and sports complexes. These environments may offer access to the network over wireless LANs or via Ethernet LAN ports or other mediums. In such scenarios, DHCP can provide configuration information (e.g., giving a valid address etc.), but there is no standard way for service providers to obtain user information to perform AAA functions. For users who do not have Mobile IP clients on their devices but would like to access the network, they need to register and be authenticated by the local network service provider before being authorized to use the resources. The intent of this proposal is to develop an application layer registration protocol that allows a user to register in the local network by providing identity and authentication information to the local network which then uses a AAA infrastructure to validate the user, charge him and, authorize use of resources. We would like to request a BOF on a "Basic User Registration Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis. The objective of the BOF will be to -- Detail the scope of the proposal and applicable scenarios -- Chart a course and an action plan (including milestones and deliverables) for BURP. -- Investigate the impact on existing AAA protocols and make it flexible to support various authentication schemes. The goal will be to define a standard UNI for environments in which neither PPP nor Mobile IP is required but AAA interaction is essential. The basic principle will include: -- The solution being a client-server application layer protocol -- Is applicable to both IPv4 and IPv6. -- User interacts only with a local Registration Agent (RA), which may reside on any node in the Network Domain. -- It should work with any configuration protocol, such as DHCP, IPv6 stateless autoconfiguration, and manual configuration. -- Protects RA from replay attacks. -- Provide information on and control of network usage. -- Interacts with routers/policers to limit packets forwarding based on a user's Service Level Specification (may be optional or may interwork with standard policy protocols). -- Defines an RA-to-AAA interface ----------------------------------------------------------------------- To subscribe to the mailing list for discussion on this topic, please follow these instructions: To subscribe, send mail to urp-request@research.telcordia.com, and use "subscribe" for the subject line. To unsubscribe, send mail to urp-request@research.telcordia.com, and use "unsubscribe" for the subject line. To contribute to the list, send mail to urp@research.telcordia.com. For additional help, send mail to urp-request@research.telcordia.com and use "help" for the subject line. From owner-aaa-bof@merit.edu Fri Jan 19 12:14:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01749 for ; Fri, 19 Jan 2001 12:14:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64C415DEBA; Fri, 19 Jan 2001 12:14:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 539BD5DEB6; Fri, 19 Jan 2001 12:14:17 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3E07A5DEB3 for ; Fri, 19 Jan 2001 12:14:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26786; Fri, 19 Jan 2001 09:14:05 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA17815; Fri, 19 Jan 2001 09:09:59 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA12456; Fri, 19 Jan 2001 09:09:53 -0800 (PST) Date: Fri, 19 Jan 2001 09:06:08 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ... To: Abhi Deshmukh Cc: "'Nelson, David'" , "'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 Just got back from out of town, so I appologize for the latency. It is possible to make use of AAA for other accounting purposes. What I would recommend is to come up with a set of requirements in an Internet-Draft, and then figure out whether DIAMETER is the protocol that meets your requirements (if memory serves, there already is an I-D on CDN accounting). The biggest issue at that point is to find a home for this work. The AAA WG has a fairly focused charter, and that shouldn't be changed since our work is of high priority. Perhaps a BOF in Minn would be one alternative. PatC > > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, January 17, 2001 3:30 PM > To: 'aaa-wg@merit.edu' > Subject: RE: Self Describing record formats for multiple (non-network-acce > ss) usage types ... > > >The AAA Working Group Charter states, in part: > >(see http://www.ietf.org/html.charters/aaa-charter.html) > >The Authentication, Authorization and Accounting Working Group focused on > >the development of requirements for Authentication, Authorization and > >Accounting as applied to network access. Requirements were gathered from > >NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. > > >How do the applications you mention fit into this scope of work? > > I am trying to see if the AAA transport framework can be used to send > accounting info (available from usage records) in a peered Content Delivery > Network scenario (peered CDN). http://www.content-peering.org > > In particular the attributes of usage records in this case would be > different > than RADIUS, Mobile IP, etc. If the AAA transport can accomodate different > record formats, then the AAA framework will be very attractive for > *adoption* for billing systems for various services. > > One way to accomodate known and unknown record formats is to have the > payload records describe themself. This way the transport can accomodate > *any* usage record. > > I however understand the AAA framework is not meant to be all purpose. I was > trying to see if there was a thought process along the lines of extending > the AAA transport to accomodate "other" usage types. > > Thanks for your time. > > - Abhi > From owner-aaa-bof@merit.edu Fri Jan 19 13:37:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA03574 for ; Fri, 19 Jan 2001 13:37:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 521FD5DDDF; Fri, 19 Jan 2001 13:37:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3E7A15DDD7; Fri, 19 Jan 2001 13:37:38 -0500 (EST) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by segue.merit.edu (Postfix) with ESMTP id 0DA545DDAF for ; Fri, 19 Jan 2001 13:37:37 -0500 (EST) Received: from matt.ipverse.com (lsanca1-ar5-208-160.dsl.gtei.net [4.33.208.160]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C5SX7PAT; Fri, 19 Jan 2001 10:37:35 -0800 Message-Id: <5.0.2.1.2.20010119103608.02192790@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 19 Jan 2001 10:37:38 -0800 To: Basavaraj.Patil@nokia.com, aaa-wg@merit.edu, diameter@diameter.org From: Matt Holdrege Subject: Re: [AAA-WG]: BURP BOF Cc: urp@research.telcordia.com In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B032132E9@daeis07nok> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Is there some reason that the intrinsic registration method in SIP is not satisfactory? If there is, then you should identify it in your BOF description. At 08:01 AM 1/19/2001, Basavaraj.Patil@nokia.com wrote: > > >A BOF on Basic User Registration Protocol (BURP) > > >Charter: > >The vision of pervasive computing also includes constantly being >connected and the ability to access the Internet or the enterprise >over the Internet. Mobile computing solutions based on protocols such >as Mobile IP offer seamless and continuous connectivity for >users. However a lot of roadwarriors and other types >of users access the network from places like airports, hotels, malls >and sports complexes. These environments may offer access to the >network over wireless LANs or via Ethernet LAN ports or other >mediums. In such scenarios, >DHCP can provide configuration information (e.g., giving a valid >address etc.), but there is no standard way for service providers to >obtain user information to perform AAA functions. For users >who do not have Mobile IP clients on their devices but would like to >access the network, they need to register and be authenticated by the >local network service provider before being authorized to use the >resources. The intent of this proposal is to develop an application >layer registration protocol that allows a user to register in the >local network by providing identity and authentication information >to the local network which then uses a AAA infrastructure to validate >the user, charge him and, authorize use of resources. > >We would like to request a BOF on a "Basic User Registration >Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis. >The objective of the BOF will be to >-- Detail the scope of the proposal and applicable scenarios > >-- Chart a course and an action plan (including milestones >and deliverables) for BURP. > >-- Investigate the impact on existing AAA protocols and make it >flexible to support various authentication schemes. > >The goal will be to define a standard UNI for environments in which >neither PPP nor Mobile IP is required but AAA interaction is >essential. The basic principle will include: > > -- The solution being a client-server application layer protocol > > -- Is applicable to both IPv4 and IPv6. > > -- User interacts only with a local Registration Agent (RA), which > may reside on any node in the Network Domain. > > -- It should work with any configuration protocol, such as DHCP, IPv6 > stateless autoconfiguration, and manual configuration. > > -- Protects RA from replay attacks. > > -- Provide information on and control of network usage. > > -- Interacts with routers/policers to limit packets forwarding based on a > user's Service Level Specification (may be optional or may > interwork with standard policy protocols). > > -- Defines an RA-to-AAA interface > >----------------------------------------------------------------------- > >To subscribe to the mailing list for discussion on this topic, please >follow these instructions: > >To subscribe, send mail to urp-request@research.telcordia.com, and >use "subscribe" for the subject line. > >To unsubscribe, send mail to urp-request@research.telcordia.com, and >use "unsubscribe" for the subject line. > >To contribute to the list, send mail to urp@research.telcordia.com. > >For additional help, send mail to urp-request@research.telcordia.com >and use "help" for the subject line. > > From owner-aaa-bof@merit.edu Fri Jan 19 15:57:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06491 for ; Fri, 19 Jan 2001 15:57:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EDB05DDC7; Fri, 19 Jan 2001 15:57:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E2385DDB2; Fri, 19 Jan 2001 15:57:29 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id C6F5C5DDAF for ; Fri, 19 Jan 2001 15:57:27 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0JKrCR17608; Fri, 19 Jan 2001 12:53:12 -0800 From: "Bernard Aboba" To: Cc: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Re: Self Describing record formats for multiple (non-network-access) usage types Date: Fri, 19 Jan 2001 12:57:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk >I have been looking at the AAA related documents for record formats and I >have an idea to share about the formats. Do you have an idea to share relating to defining a record format, or relating to carriage of a record format? >Is there a thought in the AAA WG of having self describing records in the >overall AAA framework ?. At one point, there was discussion of using DIAMETER for carriage of record formats, rather than just AVPs. However, for the goals of the AAA WG, this did not seem essential, and so the WG consensus has been to remove support for the ADIF record format from the protocol. >This would allow other known unknown and not invented usage records to be >accomodated in the AAA framework. There are many ways to transport record formats. To figure out which one of them is useful, you need to have a requirements document laying out what the transport has to do. >This way, if the transport issues are resolved, new usage types would not present a >challenge to the record format. Also having a AAA framework that accomodates >other usage types (other than end user network access) would be beneficial. Transport issues are in practice the crux of the problem. You have to think about what kinds of security you need to provide, how reliable the transport needs to be, etc. Once you've got that all figured out, then you have a way of deciding if DIAMETER is right for you. >I have some ideas on this thought process. If this thought is-being or >has-been dicussed, then perhaps I missed it. Is there any place that I >should be looking ? Any useful pointers ? I'd suggest looking at the following documents: http://www.ietf.org/rfc/rfc2924.txt http://www.ietf.org/rfc/rfc2975.txt http://www.ietf.org/internet-drafts/draft-aboba-roamops-adif-00.txt (just submitted) From owner-aaa-bof@merit.edu Fri Jan 19 16:19:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA06912 for ; Fri, 19 Jan 2001 16:19:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 280125DEA2; Fri, 19 Jan 2001 16:16:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 164205DE75; Fri, 19 Jan 2001 16:16:48 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B19C35DDAF for ; Fri, 19 Jan 2001 16:16:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05340; Fri, 19 Jan 2001 13:16:45 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18652; Fri, 19 Jan 2001 13:16:44 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA17951; Fri, 19 Jan 2001 13:16:42 -0800 (PST) Date: Fri, 19 Jan 2001 13:12:58 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1)" draft / Minor Comments To: Bob Kopacz Cc: Pat Calhoun , 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 Bob, Thanks for taking the time to review the I-D and providing great feedback. My responses are inline below. PatC > Hi Pat, > > Here's some further minor comments on the "DIAMETER Base > Protocol (Alpha 1)" draft. > > > Section 2.2.4.1 Example AVP with a Grouped value type > -------------------------------------------------------- > > This section gives an example of a Grouped-AVP which includes > the User-Name AVP and the Host-IP-Address AVP. Since the > Host-IP-Address AVP is only present in the DRI packet > (according to section 2.5.4 Host-IP-Address AVP), and since > User-Name cannot be present in a DRI, maybe the example should > be revamped to a non-conflicting group of AVPs. Yes, good catch. Eliminating the User-Name AVP fixes the problem. > > > Section 2.3.1 "Host-Name AVP" > ----------------------------- > > The Host-Name AVP defines the value as being the "sender's" > identity, and later as the identity of the "originator" of the > Diameter message. > > One could, like I did, interpret "sender" and "originator" as > the peer who sent this packet, treating Host-Name AVP as a > "Peer-Name" AVP, where each server in a proxy chain replaced the > AVP value with his name. > > But the Host-Name seems to identify the original sender and > not necessarily the immediate sender which may be a proxy. This > might be stated explicitly, else a proxy implementation may > replace the Host-Name AVP from a received packet with a > Host-Name AVP identifying himself, before forwarding the packet > to the next hop Diameter server. > > Maybe some explicit clarifying text could be added, e.g: > > "This AVP identifies the endpoint which originated the > Diameter message, i.e. the NAS, home server, or broker. > Proxy servers do not modify this AVP". Fixed (and thanks for the text!) > > > 3.1 Session-Id AVP > ------------------- > > An email (not mine) from a while back asked some questions about > the Session-ID AVP, i.e. "How is this encoded? All ASCII? A mix > of null-terminated strings and numbers in network byte order? > Something else?" > > I think the answer was all ASCII, in network byte order, but > this hasn't made its way into the document. check, now specifies UTF-8 encoding. > > > Section 8.4 > ------------ > > Section 8.4 is inconsistent with section 5.2. Section 8.4 > states: > > As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines > the values 0-8. ... > > The values defined in section 5.2 are no longer 0-8. wow... can't believe I missed that one. > > > Minor Typos/etc: > ---------------- again, thanks for these as well. From owner-aaa-bof@merit.edu Fri Jan 19 16:38:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07225 for ; Fri, 19 Jan 2001 16:38:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB92C5DDC6; Fri, 19 Jan 2001 16:38:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C9A365DDB2; Fri, 19 Jan 2001 16:38:03 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A466B5DDAF for ; Fri, 19 Jan 2001 16:38:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20565; Fri, 19 Jan 2001 13:38:00 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23399; Fri, 19 Jan 2001 13:38:00 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA18434; Fri, 19 Jan 2001 13:37:33 -0800 (PST) Date: Fri, 19 Jan 2001 13:33:49 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (18-Alpha 1)" draft / 5.0 Error Reporting To: Bob Kopacz Cc: Pat Calhoun , 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 > Hi Pat, > > When reading section 5.0 "Error Reporting" in the "DIAMETER Base > Protocol (Alpha 1)" draft, I came up with a number of questions > about the handling of a bad reply message, which probably means > I'm missing something basic. > > Maybe some clarifications could be added to this section. I would not be surprised that some clarifications are required. > > I fear I'm all wet here, but here's some questions: > > > Case 1: NAS -> HomeServer. NAS detects error. > ----------------------------------------------- > > We have a NAS talking directly to his Home Server; no proxies > are involved. The NAS originates a valid *-Request. The > HomeServer sends a positive *-Answer which the NAS considers > erroneous (e.g. the *-Answer packet is syntactically incorrect; > or the *-Answer packet is syntactically correct but contains an > AVP with an inappropriate value). > > I assume that an MRI is intended as a response not just to bad > *-Request and *-Ind packets, but also to bad *-Answer packets. correct. > > The NAS, I think, would send an MRI back to the home server with > an appropriate Result-Code. If the MRI serves no other purpose, > it can at least make its way into the home server's log file, as > an aid to those investigating why sessions aren't being set up. correct. Also keep in mind that Dave Mitton also suggested adding a third message to "ack" the reply. This is not something that we've ever discussed in the DIAMETER list, but we should also consider such a scheme. > > If the home server maintains session state, he considers this to > be an active session, since he sent a positive reply. Is the > MRI sufficient to stimulate the home server to release this > active session, or should the NAS also (or instead) send a > Session-Terminate-Request? (The MRI may not contain enough > information for the home server to make a determination as to > the fate of this session. For example, if the MRI was in > response to the home server's positive AA-Answer, the home > server can release the session. If the MRI was in response to > the home server's Session-Terminate-Ind, then the home server > wouldn't release the session. But the MRI doesn't indicate the > home server's offending packet. The home server also doesn't > know if the Identifier value is his or the NAS's). > > According to the table in section 5.0, an MRI can be sent only > if the error is of type "Unknown Command". If so, what can the > NAS send to the Home Server if the error is of type "Unknown > AVP", "Bad AVP Value", or "Extension Error"? According to the > table, the NAS should send some extension-specific error > response, but I don't see any candidates that can be sent in > response to a bad reply. So the spirit of the draft is that if there are no appropriate message to be sent to return an error, an MRI is used. Again, see my above on Dave's proposal, which would solve this problem in a cleaner way. > > Does the NAS behave differently if he receives a bad negative > reply rather than a bad positive reply? (e.g. forego sending the > MRI) Good question. Ideally, an MRI would be similar to how ICMP works, but I am not sure that this solves all problems. So, if the above example were used the MRI would have to be used as a real response to a reply. Now I am even more convinced that Dave had a great idea. > > > Case 2: NAS -> RoutingProxy -> HomeServer. NAS detects error. > --------------------------------------------------------------- > > Same as case 1, but with a proxy in the middle: The NAS > originates a valid *-Request. The HomeServer sends a positive > *-Answer, which passes through the proxy ok, but which the NAS > considers erroneous. > > Assuming the NAS sent an MRI, what does the proxy do with it? > > It seems like the proxy would want to route the MRI to the home > server, since the MRI was most likely a response to something > the home server sent, and not to something the proxy sent (the > proxy likely couldn't determine who was at fault anyway, so > would just forward the MRI in all cases and let the humans > figure out what went wrong). > > However, if the proxy routes on Extension Id, he may be unable > to route the MRI, which lacks identification of the offending > extension. (I'm referring to Section 6.2.1 "Proxy and Redirect > Server handling of requests", which says "It is possible for a > routing entry to have a different destination based on the > extension identifier of the message. This field is typically > used as a secondary key field in routing table lookups."). > > Here's a thought: Rename the Unrecognized-Command-Code AVP to > the "Failed-Command-Code AVP", and change its value to > contain the Command Code that was being processed when the error > was detected, be it recognized or not. Include this new AVP in > all MRI messages. The Result-Code value tells you if the > command was unrecognized. This seems useful when debugging and > tracing. And in this case the proxy can now determine the > extension of the offending packet and route the NAS's MRI > accordingly. Very good suggestion. It requires minimal changes, and solves a real problem. > > > Case 3: NAS -> RoutingProxy -> HomeServer. PROXY detects error. > ----------------------------------------------------------------- > > Similar to case 1, but with a proxy in the middle: The NAS > originates a valid *-Request. The HomeServer sends a positive > *-Answer which the PROXY considers erroneous. > > Here the proxy might want to generate two messages, one to the > NAS and one to the home server. The proxy would do what the NAS > would do in Case 2: send an MRI to the home server. The proxy > would turn the home server's positive answer into a negative > answer, replace the Result-Code AVP, and send it on to the NAS. I am not sure that I really like this. This just really stresses the need for the three way message (of type -Ind, I would think). This would allow the NAS to send it, and indicate whether an error had been added by a middle proxy, or if it didn't like the message. This seems to keep the proxies as dumb as we can. > > When the NAS receives a negative reply to some request, there is > a Result-Code AVP which indicates the error, but there isn't an > indication of who originally generated the error, i.e. some > proxy along the path, or the home server. > > It would be useful to know which machine originated the negative > Result-Code AVP. It most cases this is indicated by the > Host-Name AVP, but in this case the Host-Name is the home server > while the proxy detected the error. > > So a new "Error-Detecting-Server-Name" AVP (not a good name) > could be useful. The AVP would contain the name of the machine > which originated the failure Reply-Code value, useful in tracing > and debugging. This new AVP immediately points the technical > staff to the offended (possibly misconfigured) server. hmmm... someone brought up the point of how to identify the server that set the Result-Code AVP. Again, I think that this is a great suggestion and will include it, since it solves a real problem. > > Also, if the NAS knew that a negative answer came from some > proxy, he might try a different route to the home server; > but if the home server originated the reject, well then give up. > > If the proxy receives a flawed negative reply from the home > server, rather than a flawed positive reply, does he act > differently? For example, only override the home server's > Result-Code value if it was 2xxx SUCCESS; forego sending the MRI > to the home server. Well, see my comment above on the proxy sending MRIs, but I agree that if an error is already set, further proxies MUST NOT change the value, and simply treat it as a failed request. > > > Out-of-Range Result-Code values: > -------------------------------- > > Section 5.2 "Result-Code AVP" defines classes of error codes in > the range 1xxx-5xxx. > > What does a receiver do when receiving a Result-Code value > outside of the defined ranges? > > I'm guessing an out-of-range Result-Code value would be treated > as a 5xxx (Permanent failure). Should an MRI or error log entry > be generated? This is probably a good assumption, and I will add clarifications to the text. > Should a Result-Code value of zero be treated as > a 2xxx (Success) for compatibility with existing Diameter > implementations? I do not think this is necessary. PatC From owner-aaa-bof@merit.edu Fri Jan 19 16:53:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07459 for ; Fri, 19 Jan 2001 16:53:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1145D5DDAF; Fri, 19 Jan 2001 16:53:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ABD6D5DDB2; Fri, 19 Jan 2001 16:52:59 -0500 (EST) Received: from rock2 (rock2.apogeenet.com [63.119.238.75]) by segue.merit.edu (Postfix) with ESMTP id CD97D5DDAF for ; Fri, 19 Jan 2001 16:52:57 -0500 (EST) Received: from postoffice.apogeenet.com ([10.30.0.90]) by rock2 (8.10.0/8.10.0) with ESMTP id f0JLk3v06308; Fri, 19 Jan 2001 16:46:18 -0500 (EST) Received: by postoffice.apogeenet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 16:48:00 -0500 Message-ID: From: Abhi Deshmukh To: "'Bernard Aboba'" , Abhi Deshmukh Cc: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: An idea on Self describing accounting streams ..... Date: Fri, 19 Jan 2001 16:47:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk > From: Bernard Aboba [mailto:aboba@internaut.com] >Subject: [AAA-WG]: Re: Self Describing record formats for multiple >(non-network-access) usage types > Do you have an idea to share relating to defining a record format, or > relating to carriage of a record format? The main idea is to accommodate *any* usage type for *any* kind of service. If the transfer mechanism is agnostic of the attributes and format of the usage record, then this allows the transfer to be extensible and attractive for wide adoption. Let me know what you think. - Abhi Here is the basic idea on self describing accounting streams: 0. A receiver would connect to the sender. This would include some sort of authentication. 1. Sender sends structure of information that it wishes to sends So for example if it wanted to send Web usage information, It would say, "I have four fields to send" the first field is a long that means the end user's IP address the second field is a string that means the URL that was accessed the third field is a long64 that means number of bytes accessed the fourth field is a timestamp that means the time this URL was accessed. The meaning is encoded in a number and is called a catalog. There are many such catalog ids (hundreds) available to mean different things like packets, sessions, whether cached, and so on This is almost like a binary DTD for an XML document. 2. Receiver accepts the structure and sends an ack to the sender 3. From this point on the sender can send the accounting usage records according to the format specified in 1 and acked in 2. 4. For efficiency, the structure of Information may not be duplicated in each accounting payload packet. 5. I have some extensions to the above idea for a. filters - If a receiver is interested in a subset of data, then it can send a filter spec - this allows the sender to send only information that receiver is interested in, saving bandwidth. b. fault-tolerance - Handle failure in sender and receiver c load-balancing - Have multiple receivers load balance a single stream of accounting info 6. A sender could be sending accounting streams to many receivers. 7. I have done some dry runs on many usage types include Web services, Caching services, and others and I have been able to use the above idea with all of them. 8. The underlying transport could be TCP or UDP. 9. Streams could be compressed using standard compression algorithms. 10. Encryption of usage records could also be supported. 11. Personally I prefer tunneling encrypted/compressed records on top of HTTP - this allows flexibility in transfer through firewalls on the public/private network. - Abhi -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Friday, January 19, 2001 3:57 PM To: Abhi.Deshmukh@apogeenet.com Cc: Aaa-Wg@Merit. Edu Subject: [AAA-WG]: Re: Self Describing record formats for multiple (non-network-access) usage types >I have been looking at the AAA related documents for record formats and I >have an idea to share about the formats. Do you have an idea to share relating to defining a record format, or relating to carriage of a record format? >Is there a thought in the AAA WG of having self describing records in the >overall AAA framework ?. At one point, there was discussion of using DIAMETER for carriage of record formats, rather than just AVPs. However, for the goals of the AAA WG, this did not seem essential, and so the WG consensus has been to remove support for the ADIF record format from the protocol. >This would allow other known unknown and not invented usage records to be >accomodated in the AAA framework. There are many ways to transport record formats. To figure out which one of them is useful, you need to have a requirements document laying out what the transport has to do. >This way, if the transport issues are resolved, new usage types would not present a >challenge to the record format. Also having a AAA framework that accomodates >other usage types (other than end user network access) would be beneficial. Transport issues are in practice the crux of the problem. You have to think about what kinds of security you need to provide, how reliable the transport needs to be, etc. Once you've got that all figured out, then you have a way of deciding if DIAMETER is right for you. >I have some ideas on this thought process. If this thought is-being or >has-been dicussed, then perhaps I missed it. Is there any place that I >should be looking ? Any useful pointers ? I'd suggest looking at the following documents: http://www.ietf.org/rfc/rfc2924.txt http://www.ietf.org/rfc/rfc2975.txt http://www.ietf.org/internet-drafts/draft-aboba-roamops-adif-00.txt (just submitted) From owner-aaa-bof@merit.edu Fri Jan 19 16:57:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07537 for ; Fri, 19 Jan 2001 16:57:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 782475DDD7; Fri, 19 Jan 2001 16:56:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6814B5DDD1; Fri, 19 Jan 2001 16:56:51 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2C5915DDB2 for ; Fri, 19 Jan 2001 16:56:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03875; Fri, 19 Jan 2001 13:56:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA02665; Fri, 19 Jan 2001 13:56:44 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA18832; Fri, 19 Jan 2001 13:56:41 -0800 (PST) Date: Fri, 19 Jan 2001 13:52:53 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt To: Tony Johansson Cc: Pat.Calhoun@eng.sun.com, AAA Listan In-Reply-To: "Your message with ID" <3A65F9EB.39C1004C@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Hi Pat, > > I think this one starts to look really good, just a couple of comments. > > section 2.4 State Machine, page 16: > > I think the typo is made on the second row from the top (this has been sent > earlier on the list by some one else): New State should be Wait-DRI not Open. > >>>>> > State Event Action New State > ----- ----- ------ --------- > ... > > Initial Receive transport level Send DRI Open > connection request from a > DIAMETER peer. > > Should be: > <<<<<< > State Event Action New State > ----- ----- ------ --------- > ... > > Initial Receive transport level Send DRI Wait-DRI > connection request from a > DIAMETER peer. hmmm.... I could have sworn that I fixed this problem, but apparently not :( > > Section 6.7 Loop Detection, page 30: > > It is clear that you should reply with an Answer on Request and a Reply on a > Query with the Result-Code AVP set to DIAMETER_LOOP_DETECTED, but what about > an Indication? To me the most logical thing would be to send back an MRI. Is > that the right assumption... Correct. Section 5.1 states that the MRI is to be sent when: 2. An error is found in a message for which there is no appropriate response. PatC From owner-aaa-bof@merit.edu Fri Jan 19 17:07:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA07751 for ; Fri, 19 Jan 2001 17:07:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99E865DED7; Fri, 19 Jan 2001 17:05:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 80EB75DEF2; Fri, 19 Jan 2001 17:05:15 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4113E5DED7 for ; Fri, 19 Jan 2001 17:05:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09675; Fri, 19 Jan 2001 14:05:12 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05135; Fri, 19 Jan 2001 14:05:08 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA18942; Fri, 19 Jan 2001 14:05:04 -0800 (PST) Date: Fri, 19 Jan 2001 14:01:20 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (18-Alpha 1) draft / Identifier To: Bob Kopacz Cc: Pat Calhoun , 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 > Hi Pat, > > Dave Spence passed me some notes he had made some time back, > suggesting that the references the Identifier field could be > clarified. > > Here is my take on Dave's suggestions: > > - - - > > Here's what Diameter-18 (Alpha 1) has to say: > > Identifier > The Identifier field is four octets, and aids in matching > requests and replies. The sender MUST ensure that the identifier > in a message is locally unique (to the sender) at any given > time, and MAY attempt to ensure that the number is unique across > reboots. The identifier is normally a monotonically increasing > number, whose start value was randomly generated. DIAMETER > servers should consider a message to be unique by examining the > source address, source port, Session-Id and Identifier field of > the message. > > > Suggestion: Distinguish between the requirement for the Identifier > field in request messages versus reply messages. > > Discussion: The first sentence of Diameter-18 says that the > Identifier field aids in matching requests and replies. The second > sentence says that the sender MUST ensure that the identifier in a > message is locally unique (to the sender). But this second > statement only applies to requests. It is incorrect for responses. > For responses, the Identifier should presumably be copied from the > Identifier field of the corresponding request. That isn't stated > here, and not all of the specific response specifications state this > either. Correct, I will fix the text. > Suggestion: Indicate that a proxy is required to manufacture his own > Identifier value when forwarding a request, and is required to > replace the originally received Identifier when returning a > response. > > Discussion: As to the Identifier being unique with respect to the > sender, the fourth sentence of Diameter-18 clarifies that "sender" > means "source address and source port". This implies that the proxy > should overwrite the value of the Identifier field when forwarding. > > Now that responses need to be returned back down the request path > but in reverse (NAI-based message routing by proxies was removed > between diameter-17 and diameter-18), having the proxies change the > Identifier field will help them match responses to requests. State > stored in the proxy or in the Proxy-State AVP can be used to > correctly replace the Identifier field as the response is returned > back down the chain. > > All this mechanism should be specified in the protocol. Yes, I do agree, and this text belongs somewhere in section 6, where proxying is discussed. > > - - - > > > Historical note-- > > draft-calhoun-diameter-17.txt gave routing proxies the option of > NAI-based message routing, which allowed a response to be returned > through a different path. This meant that a routing proxy, when > forwarding a request, could not meet the requirements, whether he > overwrote the originally received Identifier or not. (!) > > When returning the response through a different proxy, > overwriting the value of the Identifier field by a proxy in the > Request path could result in cases where the NAS receives a response > whose Identifier does not match that sent in the NAS's request. > > Firstly, The overwritten Identifier field would not help the > proxy receiving the response at all, but presumably it doesn't > need to be helped because any state it needs will not be in its > memory but must be retrieved from the Proxy-State AVP (which > must have the format it expects). > > Secondly, there may be more than one proxy in the chain, and > different numbers of proxies on the way out than on the way back. > Then the "send it back a different way" mechanism is broken. There > is just no way to get the Identifier field right in the copy of the > response that gets sent to the NAS. So in that case, the right > thing to do would have been for proxies not to change the Identifier > field. But this violates the sender's unique-Identifier requirement. > yes, I agree that proxies would not be able to change the Identifier field if the reverse path was different. Since this is no longer supported (to simplify the protocol), this problem no longer exists. Thanks to you and Dave for pointing this out. PatC From owner-aaa-bof@merit.edu Fri Jan 19 17:34:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA08197 for ; Fri, 19 Jan 2001 17:34:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82A2F5DDE1; Fri, 19 Jan 2001 17:32:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6E1035DEC4; Fri, 19 Jan 2001 17:32:30 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 55F065DDE1 for ; Fri, 19 Jan 2001 17:32:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26830; Fri, 19 Jan 2001 14:32:27 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25693; Fri, 19 Jan 2001 14:32:25 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA24413; Fri, 19 Jan 2001 14:32:24 -0800 (PST) Date: Fri, 19 Jan 2001 14:28:40 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments To: "Martin Julien (ECE)" Cc: "'Pat.Calhoun@Eng.Sun.COM'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE56@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.merit.edu id RAA08197 > Here is a small contribution to your document, which I think is basically a > great piece of work for DIAMETER. Thanks, and I appreciate the comments below. Please see my comments inline. PatC > > > Section 1.0 > ----------- > In the second last paragraph, we have: > "Given that the server MAY send unsocilited messages to clients, it is > possible for the server to also issue authentication requests." Shouldn't it > be AA-Challenge-Ind instead of authentication requests? > > Should we make this document as independant as possible from the extension > specifics, or do we want to keep this close relationship between the base > and extension protocols? The thing is that we often read about > authentication messages and so on in this document, which I don't think > really belong here, right? Instead, this document should specify something > as generic as a framework offering sessions in the implementing servers with > certain APIs and caracteristics. What do you think? Correct, and perhaps the quote paragraph needs to be changed to exclude references to authentication requests. The individual extensions should concern themselves with such text. If we agree on this, then I believe it does provide a better framework, and less coupling. Comments? > > Section 2.0 - par.5 > ------------------- > "Session state (associated with a Session-Id) MUST be freed upon receipt of > the Session-Termination-Request, Session-Termination-Answer, expiration of > authorized service time in the Session-Timeout AVP, and according to rules > established in a particular extension/application of DIAMETER." > > I think this sentence is confusing me. Are you trying to show the real > trigger for the session release, the STR (as in section 3.5.2), or the > reasons why an STR could have been sent? It seems to me that the > "Session-Termination-Answer, expiration of authorized service time in the > Session-Timeout AVP, and according to rules established in a particular > extension/application of DIAMETER." part is more related to original reasons > why an STR has been sent. Also, it is confusing to read "authorized service > time in the Session-Timeout AVP" when you can also refer to the reason that > the "authorization-lifetime-AVP" might have time-out as well, which I assume > would trigger an STR. I need more info from you if you want me to propose > something else. I think that the confusion is largely in the quoted text. What the above attempts to state is that servers that maintain state needs to relinquish such state when: 1. A Session-Termination-Request is received, 2. A Session-Termination-Answer is received, 3. The session has timed out (which does NOT require sending any termination messages), or 4. Any other rules specified in extensions. Does this help? If so, I can itemize each condition in the draft. I think this would read better anyway. > > Section 2.1 > ----------- > While looking at the DIAMETER header format, it came to me that it might be > cleaner to put the Vendor-ID before the Command-Code, since the Command-Code > is worthless without the Vendor-ID and finding it first would make more > sense. And then I thought, since we might remove the PCC and add more flags, > shouldn't we add a flag indicating if a Vendor-ID is present at all in the > message, just like in the AVP header? And since we are there, maybe we could > put a 2 bit indicator (0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3: > reserved) for the Extension-ID or Vendor-ID when present in the message > (referring to ML on "Capabilities Negotiation and proxies"), which then > would mean that the command-code is per Extension-ID and Vendor-ID base, > completely independent of the Base protocol command-code. Maybe an AVP for > the command-code field would be a better idea, because it could include the > indicator bits and also could be used in a MRI in the Failed-AVP AVP, making > obsolete the Un! recognized-Command-Code AVP which lacks the information on > the Vendor-ID AVP and Extension-ID. hmmm... This is a good comment, but I would like to solicit comments from other DIAMETER developers (and other people that also generally care). For this reason I am also adding the diameter mailing list, > > Section 2.2.3 - par.1 > --------------------- > "... seven data types" should be replaced with "the following data types", > since we actually have 10 and it might keep changing. yes, good suggestion. > > Section 2.2.5 > ------------- > It would be more useful, at least for me, to have a list of attributes > sorted by name, instead AVP codes, which are meaningless to human normal > reading. that works for me. Anyone object? > > Section 2.5 - par.1 > ------------------- > "...the Device-Reboot-Ind message MUST contain one Host-IP-Address AVP for > each potential IP address that MAY be locally used when transmitting > DIAMETER messages." > > Please, could you tell me briefly why we need to send all IP addresses of > the device? I guess it is because the device is not registered into a DNS > and we want to build an internal DNS inside the DIAMETER server along with > the Host-Name AVP for message routing, right? Should we have a dynamic or > static DNS in the server? It was intended to fully support SCTP, which inherently supports multi-homed servers. > > And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name > AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of > the Vendor-ID AVP in the DRI. So, if I understand, you are arguing in favor of the Vendor-ID, correct? Any objections? > > Section 5.0 > ----------- > The list of Error Types is a bit confusing with the one found in section 5.1 > for MRI. I think it needs some rework. I can´t still figure out exactly how > it should be, so maybe I'll come up with something later. Are the classes what you find troubling? > > Section 5.1.2 > ------------- > I mentioned some ideas about this in the comments of section 2.1 > > Section 5.2.2 > ------------- > All other Result-Code starts a x001, so I thought it should also starts at > 2001, instead of 2000. ok... consistency is good. > > Section 5.2.4 > ------------- > "...but MAY be able to satisfy the request in the future." > What does this mean exactly? Does it mean that a server should be able to > resend the request in a few minutes without any specific changes to the > message besides the timestamp for example? Should it be regarded as > temporary congestion? It is intended to contain errors that occur due to some temporary condition, and the request can be tried again later. I am not sure how to express "future". A timestamp may not really help, since the server may not know when the administrator will free up some disk space (as an example). > If it is the case, then maybe we should think of > moving the DIAMETER_AUTHENTICATION_REJECTED and DIAMETER_CONTRACTING_AVPS to > the permanent failure section. I think that permanent result codes should be > used in the rejected message even if the originating server can change AVPs > in the message which has been rejected the first time for some reasons such > as unsupported mandatory AVPs, because it is no longer the same message > anyway, and the first message was really considered as a permanent failure > in this particular period of time. yes, you are right. I will move these. > > Section 7.1.2 > ------------- > The 3rd paragraph should be removed. that darned cut and paste problem again :) > > Section 10.0 > ------------ > About the shared secret, maybe we should also mention that it is used by the > Encrypted-Payload AVP? Absolutely. Again, great comments. Looking forward to continuing some of these topics... From owner-aaa-bof@merit.edu Fri Jan 19 17:37:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA08235 for ; Fri, 19 Jan 2001 17:37:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E7145DDF4; Fri, 19 Jan 2001 17:36:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6D3215DDD1; Fri, 19 Jan 2001 17:36:33 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2E2255DDB2 for ; Fri, 19 Jan 2001 17:36:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29577; Fri, 19 Jan 2001 14:36:28 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA27091; Fri, 19 Jan 2001 14:36:27 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA24480; Fri, 19 Jan 2001 14:36:06 -0800 (PST) Date: Fri, 19 Jan 2001 14:32:12 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt To: Fredrik Johansson Cc: AAA Listan 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 > The is missing in the table in section 2.2.5 > I think Erik addressed this one, but I am no longer sure. Grouped is now a data type, much like Unsigned32 and OctetString. So, AVPs MAY be of type Grouped, as opposed to a single Generic AVP that can contain an arbitrary set of AVPs. I think the new approach is a much cleaner approach. PatC From owner-aaa-bof@merit.edu Fri Jan 19 17:53:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA08550 for ; Fri, 19 Jan 2001 17:53:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 147B05DE75; Fri, 19 Jan 2001 17:53:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 02E765DDD1; Fri, 19 Jan 2001 17:53:21 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B7EBF5DDB2 for ; Fri, 19 Jan 2001 17:53:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10437; Fri, 19 Jan 2001 14:53:18 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA00855; Fri, 19 Jan 2001 14:53:16 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA24870; Fri, 19 Jan 2001 14:53:15 -0800 (PST) Date: Fri, 19 Jan 2001 14:49:31 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: "Martin Julien (ECE)" Cc: "'Pat.Calhoun@Eng.Sun.COM'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE57@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat, > > Comments making no sense to you are most probably related to my ignorance... > However, I'd appreciate you help me out on this. and responses making no sense to you are most probably related to my ignorance... :) > > > Section 3.0 - par.2 > ------------------- > It is weird to me that we refer to an Authorization-Lifetime AVP in the Base > Protocol without having any authorization message in it. Now we have the > Session-Timeout AVP and the Authorization-Lifetime AVP which are somehow > competing together. No, they aren't intended to compete. Dave Mitton was the one that had come up with the Authorization-Lifetime AVP in the solutions I-D. The Authentication-Lifetime specifies how long before a re-auth should occur. The Session-Time, on the other hand, states how long the session can occur. After Session-Time, a session MUST be torn down. > Should the Authorization-Lifetime AVP be included in a > specific extension, such as NASREQ, or is it because it might be used by > several extensions without any specific meaning to the base protocol itself, > which happens to be pretty much the same as the Session-Timeout AVP? My > understanding is that there is not much to do with the > Authorization-Lifetime AVP in the base protocol, since the action to take > upon its expiration is defined in the NASREQ extension anyway, which is very > specific. The reason why it is in the base protocol is to reduce duplicate AVPs in extensions. I environ that all access methods will require some session lifetime, so since it is used in many extensions, it seems appropriate to put it in the base protocol. > I guess that something more generic would be a Session-Timeout AVP > which could trigger an STI when it expires that could lead to another > re-authentication or something else in order to avoid the session to > terminate right away. Then the NASREQ extension! > could possibly override that meaning by defining its own > Authorization-Lifetime AVP which would trigger a more efficient an > AA-Challenge-Ind instead. Please read the above intended definitions of both AVPs and tell me if additional changes are still required. Perhaps the actual definition of both AVPs need some work. Is this sufficient? > > Section 3.2 and 3.3 > ------------------- > Can the server return a bigger value? bigger than what? > What the value 0 means? The same as if it was not there? > Which one has priority? 0 and not present are the same. They mean infinity (and I fixed the text in Authorization-Lifetime) > > Section 3.5 > ----------- > "Since the Session-Id is typically tied to a particular service (i.e. Mobile > IP, NASREQ, etc), the session termination messages are used to request that > the service tied to the Session Id be terminated." > > It seems to be against last paragraph of section 3.1, which is "Note that a > Session-Id MAY be used by more than one extension (e.g. authentication for a > specific service and accounting, both of which have separate extensions). hmmmm.... I believe that section 3.5 should state that the Extension-Id is used to identify which service should be terminated. Does this make more sense? > > Section 3.5.2 > ------------- > What the Resource-Owner-NAI AVP used for in the STR? Is it for routing? I > guess not, since the User-Name AVP is present. Can it be used in the server > for any particular reason I don't see, since I think the active session > should be aware of what's going on within itself, right? If the home server wishes for the NAS to reliquish resources, then the User-name AVP doesn't really help since it would cause the packet to get routed to the home server (loop). So something is needed for the message to get routed to the NAS, and I envisioned was that the AVP would be used for routing purposes (and eventually get to the NAS). > > Section 3.5.3 > ------------- > What is the purpose of the STA, since the session in the server and in the > proxies should be released after the STR? What can the NAS or the server do > if the STR is rejected and the resources are already released in the > DIAMETER client and the proxies? The STA acks the STR. The sender of the STR should wait until the STA is received before releases resources. > > Section 3.5.4 > ------------- > AVP Code 293 oops Thanks! PatC From owner-aaa-bof@merit.edu Fri Jan 19 18:21:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA09085 for ; Fri, 19 Jan 2001 18:21:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F6EF5DDB2; Fri, 19 Jan 2001 18:20:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 685695DDD1; Fri, 19 Jan 2001 18:20:09 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 48A7C5DDB2 for ; Fri, 19 Jan 2001 18:20:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26165; Fri, 19 Jan 2001 15:20:05 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA07213; Fri, 19 Jan 2001 15:20:04 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA25319; Fri, 19 Jan 2001 15:20:02 -0800 (PST) Date: Fri, 19 Jan 2001 15:16:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (18-Alpha 1) draft / MRI To: Bob Kopacz Cc: Pat Calhoun , 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 > Hi Pat, > > Here are some questions on the DIAMETER Base Protocol (18-Alpha 1) > draft. The gist of what follows is: > > (a) the draft's phrase "Extension Response + Result-Code" is ambiguous, and > > (b) There may be error conditions where an MRI can't be sent, yet no > appropriate extension response is available. ok. > > > > 5.0 Error Reporting > -------------------- > > The draft says: > > "Extension Response + Result-Code" indicates that the appropriate > Response to the message MUST be sent with the Result-Code AVP set to > a value that enables the peer to understand the nature of the > problem. > > Problem 1: The phrase "Extension Response + Result-Code" is > ambiguous. Does "Extension Response + Result-Code" mean "a response > with an extension-specific command code", or "a response specified > by the extension, but which may be an MRI"? If the first meaning, > perhaps the draft-18's text could be clarified by adding the > following sentence to the paragraph: > > The Response has an extension-specific command code. great suggestion. > > - - - > > Draft-18 specifies a more limited role for the MRI message. That > is, between draft-17 and draft-18, some of the 'X's in the following > table from section 5.0 have shifted from the "Send > Message-Reject-Ind" column into the "Extension Response + > Result-Code" column. > > Draft-17 said: > > > Error Type Ignore Message Send Extension > > Message-Reject-Ind Response + > > Result-Code > > Bad Message X > > Unknown Command X > > Unknown AVP X > > Bad Value X > > Extension Error X > > Draft-18-Alpha 1 says: > > > Error Type Ignore Message Send Extension > > Message-Reject-Ind Response + > > Result-Code > > Bad Message X > > Unknown Command X > > Unknown AVP X > > Bad AVP Value X > > Extension Error X > > This shift to an extension-specific response is probably because a > proxy which routes on Diameter extension wouldn't know how to route > an MRI. correct. > > Problem 2: Assuming that "Extension Response + Result-Code" means "a > response with an extension-specific command code", it seems like the > MRI is limited to dealing with (a) DRI errors and (b) Unknown > Command errors. But some recent mailing list questions suggest that > there may be error conditions other than (a) or (b), where no > appropriate extension response is available. Actually, I believe the MRI is used for: - Negative ack of any DRI, *-Answer or *-Response message, and - Unknown command code > > [One of the emails I am referring to is the "DIAMETER Base Protocol > (18-Alpha 1)" draft / 5.0 Error Reporting" email of 16-Jan-2001, > suggesting that a receiver of a reply packet which contains a bad > AVP may want to send an MRI. Another is the "Re: Comments on > draft-calhoun-diameter-18.txt" email of 17-Jan-2001, suggesting that > an MRI is a candidate to recover from a looped proxy chain.] hmmmm... no I believe the above conditions are the only ones that require MRI support. PatC From owner-aaa-bof@merit.edu Fri Jan 19 19:22:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10176 for ; Fri, 19 Jan 2001 19:22:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72F6C5DEAA; Fri, 19 Jan 2001 19:21:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 62B0A5DEA8; Fri, 19 Jan 2001 19:21:41 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E7D8F5DE06 for ; Fri, 19 Jan 2001 19:21:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17127; Fri, 19 Jan 2001 16:21:38 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA22701; Fri, 19 Jan 2001 16:21:36 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA26764; Fri, 19 Jan 2001 16:21:35 -0800 (PST) Date: Fri, 19 Jan 2001 16:17:51 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Alpha 2 of base protocol available To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Given the number of comments I've received in the past week, I decided to make an Alpha 2 version available for review. The document, and associated diff file, are available at the diameter web site (www.diameter.org). There are still some pending questions in a few threads, so I expect a third alpha before I send it off to the secretariat. Thanks to all those that provided the great feedback! PatC From owner-aaa-bof@merit.edu Fri Jan 19 19:25:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10213 for ; Fri, 19 Jan 2001 19:25:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id D358F5DEB6; Fri, 19 Jan 2001 19:25:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C3FD35DEA8; Fri, 19 Jan 2001 19:25:19 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8CF9A5DE06 for ; Fri, 19 Jan 2001 19:25:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06617; Fri, 19 Jan 2001 16:25:14 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA23297; Fri, 19 Jan 2001 16:25:13 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA01979; Fri, 19 Jan 2001 16:25:12 -0800 (PST) Date: Fri, 19 Jan 2001 16:21:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt To: Fredrik Johansson Cc: AAA Listan 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 > Hi > > Found a type in section 8.2. The Command Codes that are specified within > this specification should be 257, 259, 274-276 > Compare section 8.2 with 2.1 check. Thanks, PatC From owner-aaa-bof@merit.edu Mon Jan 22 10:26:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA28715 for ; Mon, 22 Jan 2001 10:26:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9165C5DDAA; Mon, 22 Jan 2001 10:26:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7300D5DDAB; Mon, 22 Jan 2001 10:26:31 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id B96D05DDAA for ; Mon, 22 Jan 2001 10:26:29 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0MFQSd20024 for ; Mon, 22 Jan 2001 16:26:28 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 22 16:27:17 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 22 Jan 2001 16:26:27 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 Date: Mon, 22 Jan 2001 16:25:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Thanks for your answers. See my comments. /Martin > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Friday, January 19, 2001 11:50 PM > To: Martin Julien (ECE) > Cc: 'Pat.Calhoun@Eng.Sun.COM'; 'aaa-wg@merit.edu' > Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments > Section 3.0 > > > > Section 3.0 - par.2 > > ------------------- > > It is weird to me that we refer to an > Authorization-Lifetime AVP in the Base > > Protocol without having any authorization message in it. > Now we have the > > Session-Timeout AVP and the Authorization-Lifetime AVP > which are somehow > > competing together. > > No, they aren't intended to compete. Dave Mitton was the one > that had come up > with the Authorization-Lifetime AVP in the solutions I-D. The > Authentication-Lifetime specifies how long before a re-auth > should occur. The > Session-Time, on the other hand, states how long the session > can occur. After > Session-Time, a session MUST be torn down. > > > Should the Authorization-Lifetime AVP be included in a > > specific extension, such as NASREQ, or is it because it > might be used by > > several extensions without any specific meaning to the base > protocol itself, > > which happens to be pretty much the same as the > Session-Timeout AVP? My > > understanding is that there is not much to do with the > > Authorization-Lifetime AVP in the base protocol, since the > action to take > > upon its expiration is defined in the NASREQ extension > anyway, which is very > > specific. > The reason why it is in the base protocol is to reduce > duplicate AVPs in > extensions. I environ that all access methods will require > some session > lifetime, so since it is used in many extensions, it seems > appropriate to put > it in the base protocol. > > > I guess that something more generic would be a Session-Timeout AVP > > which could trigger an STI when it expires that could lead > to another > > re-authentication or something else in order to avoid the session to > > terminate right away. Then the NASREQ extension! > > could possibly override that meaning by defining its own > > Authorization-Lifetime AVP which would trigger a more efficient an > > AA-Challenge-Ind instead. > > Please read the above intended definitions of both AVPs and tell me if > additional changes are still required. Perhaps the actual > definition of both > AVPs need some work. Is this sufficient? I think I understand the roles of the Authorization-Lifetime AVP and the Session-Timeout AVP. However, the Session-Timeout AVP is also used by the Mobile-IP extension protocol for the registration keys time-out, which seems to be quite similar to what is required by NAS for re-authentication/re-authorization. Should the Mobile-IP extension also refer to the Authorization-Lifetime AVP instead of the Session-Timeout AVP? Should the Session-Timeout also trigger a STI? Should we be expecting the Proxies to release resources automatically when the Session-Timeout AVP has been reached? Otherwise, what really happens when the Session-Timeout AVP expires and a session must be torn down in a AAAH and the proxies? > > > > Section 3.2 and 3.3 > > ------------------- > > Can the server return a bigger value? > > bigger than what? I was simply wondering if it was allowed for the AAAH to return a bigger value then the one that was sent as a hint from the DIAMETER client? > > What the value 0 means? The same as if it was not there? > > Which one has priority? > 0 and not present are the same. They mean infinity (and I > fixed the text in > Authorization-Lifetime) > > > > > Section 3.5 > > ----------- > > "Since the Session-Id is typically tied to a particular > service (i.e. Mobile > > IP, NASREQ, etc), the session termination messages are used > to request that > > the service tied to the Session Id be terminated." > > > > It seems to be against last paragraph of section 3.1, which > is "Note that a > > Session-Id MAY be used by more than one extension (e.g. > authentication for a > > specific service and accounting, both of which have > separate extensions). > > hmmmm.... I believe that section 3.5 should state that the > Extension-Id is > used to identify which service should be terminated. Does > this make more sense? I guess you meant a Session-ID and an Extension-ID? Yes, that would be OK. > > Section 3.5.2 > > ------------- > > What the Resource-Owner-NAI AVP used for in the STR? Is it > for routing? I > > guess not, since the User-Name AVP is present. Can it be > used in the server > > for any particular reason I don't see, since I think the > active session > > should be aware of what's going on within itself, right? > > If the home server wishes for the NAS to reliquish resources, then the > User-name AVP doesn't really help since it would cause the > packet to get > routed to the home server (loop). So something is needed for > the message to > get routed to the NAS, and I envisioned was that the AVP > would be used for > routing purposes (and eventually get to the NAS). Then, are you telling me that the message routing can be done using other AVPs than the Routing-Realm AVP and the User-Name AVP? Also, is it really needed in the STR, which is sent from the access device to the Home AAA? > > > > Section 3.5.3 > > ------------- > > What is the purpose of the STA, since the session in the > server and in the > > proxies should be released after the STR? What can the NAS > or the server do > > if the STR is rejected and the resources are already released in the > > DIAMETER client and the proxies? > > The STA acks the STR. The sender of the STR should wait until > the STA is > received before releases resources. The paragraph 3.5.2 says: "Upon receipt of the STR, the Home DIAMETER Server SHOULD release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary." That's the reason why I asked about the STA. Now you're telling me that it should be the STA that should trigger the release of resources, right? From owner-aaa-bof@merit.edu Mon Jan 22 10:40:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29068 for ; Mon, 22 Jan 2001 10:40:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3B2F5DDAB; Mon, 22 Jan 2001 10:40:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C72745DDBC; Mon, 22 Jan 2001 10:40:08 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B1D005DDAB for ; Mon, 22 Jan 2001 10:40:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25128; Mon, 22 Jan 2001 07:40:03 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA07626; Mon, 22 Jan 2001 07:40:00 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12680; Mon, 22 Jan 2001 07:39:53 -0800 (PST) Date: Mon, 22 Jan 2001 07:38:43 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat, > > Thanks for your answers. See my comments. > > /Martin > > > -----Original Message----- > > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > > Sent: Friday, January 19, 2001 11:50 PM > > To: Martin Julien (ECE) > > Cc: 'Pat.Calhoun@Eng.Sun.COM'; 'aaa-wg@merit.edu' > > Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments > > Section 3.0 > > > > > > Section 3.0 - par.2 > > > ------------------- > > > It is weird to me that we refer to an > > Authorization-Lifetime AVP in the Base > > > Protocol without having any authorization message in it. > > Now we have the > > > Session-Timeout AVP and the Authorization-Lifetime AVP > > which are somehow > > > competing together. > > > > No, they aren't intended to compete. Dave Mitton was the one > > that had come up > > with the Authorization-Lifetime AVP in the solutions I-D. The > > Authentication-Lifetime specifies how long before a re-auth > > should occur. The > > Session-Time, on the other hand, states how long the session > > can occur. After > > Session-Time, a session MUST be torn down. > > > > > Should the Authorization-Lifetime AVP be included in a > > > specific extension, such as NASREQ, or is it because it > > might be used by > > > several extensions without any specific meaning to the base > > protocol itself, > > > which happens to be pretty much the same as the > > Session-Timeout AVP? My > > > understanding is that there is not much to do with the > > > Authorization-Lifetime AVP in the base protocol, since the > > action to take > > > upon its expiration is defined in the NASREQ extension > > anyway, which is very > > > specific. > > The reason why it is in the base protocol is to reduce > > duplicate AVPs in > > extensions. I environ that all access methods will require > > some session > > lifetime, so since it is used in many extensions, it seems > > appropriate to put > > it in the base protocol. > > > > > I guess that something more generic would be a Session-Timeout AVP > > > which could trigger an STI when it expires that could lead > > to another > > > re-authentication or something else in order to avoid the session to > > > terminate right away. Then the NASREQ extension! > > > could possibly override that meaning by defining its own > > > Authorization-Lifetime AVP which would trigger a more efficient an > > > AA-Challenge-Ind instead. > > > > Please read the above intended definitions of both AVPs and tell me if > > additional changes are still required. Perhaps the actual > > definition of both > > AVPs need some work. Is this sufficient? > > I think I understand the roles of the Authorization-Lifetime AVP and the > Session-Timeout AVP. However, the Session-Timeout AVP is also used by the > Mobile-IP extension protocol for the registration keys time-out, which seems > to be quite similar to what is required by NAS for > re-authentication/re-authorization. Should the Mobile-IP extension also > refer to the Authorization-Lifetime AVP instead of the Session-Timeout AVP? Correct, and perhaps re-using the Session-Timeout was overloading the AVP. Either Authorization-Lifetime should be used for the keys, or some new AVP that is more specific to the keys. > > Should the Session-Timeout also trigger a STI? Should we be expecting the > Proxies to release resources automatically when the Session-Timeout AVP has > been reached? Otherwise, what really happens when the Session-Timeout AVP > expires and a session must be torn down in a AAAH and the proxies? ok, so in the RADIUS world, it is implicit. No additional signaling is required. Once the session times out, all nodes simply free resources. Of course, there is no STI in RADIUS. So, what should we do? Maintain the RADIUS model, or explicit signaling? Comments? > > > Section 3.2 and 3.3 > > > ------------------- > > > Can the server return a bigger value? > > > > bigger than what? > > I was simply wondering if it was allowed for the AAAH to return a bigger > value then the one that was sent as a hint from the DIAMETER client? Ah, good question. Again, in the RADIUS world, the RADIUS server can return pretty much what it wants. A hint from a client does not imply a maximum, so I believe that the server should be able to return anything it wants. Other comments on this one? Anyone disagree? > > > > > > Section 3.5 > > > ----------- > > > "Since the Session-Id is typically tied to a particular > > service (i.e. Mobile > > > IP, NASREQ, etc), the session termination messages are used > > to request that > > > the service tied to the Session Id be terminated." > > > > > > It seems to be against last paragraph of section 3.1, which > > is "Note that a > > > Session-Id MAY be used by more than one extension (e.g. > > authentication for a > > > specific service and accounting, both of which have > > separate extensions). > > > > hmmmm.... I believe that section 3.5 should state that the > > Extension-Id is > > used to identify which service should be terminated. Does > > this make more sense? > > I guess you meant a Session-ID and an Extension-ID? Yes, that would be OK. correct. > > > > Section 3.5.2 > > > ------------- > > > What the Resource-Owner-NAI AVP used for in the STR? Is it > > for routing? I > > > guess not, since the User-Name AVP is present. Can it be > > used in the server > > > for any particular reason I don't see, since I think the > > active session > > > should be aware of what's going on within itself, right? > > > > If the home server wishes for the NAS to reliquish resources, then the > > User-name AVP doesn't really help since it would cause the > > packet to get > > routed to the home server (loop). So something is needed for > > the message to > > get routed to the NAS, and I envisioned was that the AVP > > would be used for > > routing purposes (and eventually get to the NAS). > > Then, are you telling me that the message routing can be done using other > AVPs than the Routing-Realm AVP and the User-Name AVP? Also, is it really > needed in the STR, which is sent from the access device to the Home AAA? In the STR no, only in the STI. Can anyone think of a better mechanism? I really don't know of a better way to do this. > > > > > > > Section 3.5.3 > > > ------------- > > > What is the purpose of the STA, since the session in the > > server and in the > > > proxies should be released after the STR? What can the NAS > > or the server do > > > if the STR is rejected and the resources are already released in the > > > DIAMETER client and the proxies? > > > > The STA acks the STR. The sender of the STR should wait until > > the STA is > > received before releases resources. > > The paragraph 3.5.2 says: > > "Upon receipt of the STR, the Home DIAMETER Server SHOULD release all > resources for the session indicated by the Session-Id AVP. Any intermediate > server in the Proxy-Chain MAY also release any resources, if necessary." > > That's the reason why I asked about the STA. Now you're telling me that it > should be the STA that should trigger the release of resources, right? I will clean up the text. The sender of the STR cleans up after receiving the STA, while the receiver of the STR cleans up while receiving the STR. PatC From owner-aaa-bof@merit.edu Mon Jan 22 10:49:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29209 for ; Mon, 22 Jan 2001 10:49:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7130C5DE01; Mon, 22 Jan 2001 10:45:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 488F55DF60; Mon, 22 Jan 2001 10:45:48 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 343A85DE01 for ; Mon, 22 Jan 2001 10:45:46 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0MFjPK14695; Mon, 22 Jan 2001 10:45:25 -0500 (EST) (envelope-from barney) Date: Mon, 22 Jan 2001 10:45:25 -0500 From: Barney Wolff To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 Message-ID: <20010122104524.A14651@mx.databus.com> References: <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, Jan 22, 2001 at 04:25:09PM +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk Why does DIAMETER need to specify such within-node behavior? Is any of it visible outside the node? Barney Wolff On Mon, Jan 22, 2001 at 04:25:09PM +0100, Martin Julien (ECE) wrote: > > > > > > Section 3.5.3 > > > ------------- > > > What is the purpose of the STA, since the session in the > > server and in the > > > proxies should be released after the STR? What can the NAS > > or the server do > > > if the STR is rejected and the resources are already released in the > > > DIAMETER client and the proxies? > > > > The STA acks the STR. The sender of the STR should wait until > > the STA is > > received before releases resources. > > The paragraph 3.5.2 says: > > "Upon receipt of the STR, the Home DIAMETER Server SHOULD release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary." > > That's the reason why I asked about the STA. Now you're telling me that it should be the STA that should trigger the release of resources, right? > From owner-aaa-bof@merit.edu Mon Jan 22 11:19:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA29792 for ; Mon, 22 Jan 2001 11:19:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BFD75DE3B; Mon, 22 Jan 2001 11:16:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78D5B5DDC3; Mon, 22 Jan 2001 11:16:28 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 2F1875DE3B for ; Mon, 22 Jan 2001 11:16:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24573; Mon, 22 Jan 2001 08:16:22 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21433; Mon, 22 Jan 2001 08:16:21 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA13108; Mon, 22 Jan 2001 08:16:19 -0800 (PST) Date: Mon, 22 Jan 2001 08:15:26 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: Barney Wolff Cc: "Martin Julien (ECE)" , "'Pat Calhoun'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <20010122104524.A14651@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Why does DIAMETER need to specify such within-node behavior? > Is any of it visible outside the node? If state is released implicitly, then a sentence explaining the purpose of the Session-Timeout AVP is sufficient. However, if explicit signaling is used to release resources, then it is visible outside the node. PatC From owner-aaa-bof@merit.edu Mon Jan 22 11:28:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA29937 for ; Mon, 22 Jan 2001 11:28:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 475065DDC3; Mon, 22 Jan 2001 11:28:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2EFC75DDD9; Mon, 22 Jan 2001 11:28:19 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 2DD985DDC3 for ; Mon, 22 Jan 2001 11:28:13 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0MGSBC16816 for ; Mon, 22 Jan 2001 17:28:12 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon Jan 22 17:28:16 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 22 Jan 2001 17:28:11 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE66@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Date: Mon, 22 Jan 2001 17:26:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Please, see some minor comments inline. Thanks, Martin > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Friday, January 19, 2001 11:29 PM > > > > > > Section 2.0 - par.5 > > ------------------- > > "Session state (associated with a Session-Id) MUST be freed > upon receipt of > > the Session-Termination-Request, > Session-Termination-Answer, expiration of > > authorized service time in the Session-Timeout AVP, and > according to rules > > established in a particular extension/application of DIAMETER." > > > > I think this sentence is confusing me. Are you trying to > show the real > > trigger for the session release, the STR (as in section > 3.5.2), or the > > reasons why an STR could have been sent? It seems to me that the > > "Session-Termination-Answer, expiration of authorized > service time in the > > Session-Timeout AVP, and according to rules established in > a particular > > extension/application of DIAMETER." part is more related to > original reasons > > why an STR has been sent. Also, it is confusing to read > "authorized service > > time in the Session-Timeout AVP" when you can also refer to > the reason that > > the "authorization-lifetime-AVP" might have time-out as > well, which I assume > > would trigger an STR. I need more info from you if you want > me to propose > > something else. > > I think that the confusion is largely in the quoted text. > What the above > attempts to state is that servers that maintain state needs > to relinquish such > state when: 1. A Session-Termination-Request is received, > 2. A Session-Termination-Answer is received, > 3. The session has timed out (which does NOT require sending > any termination > messages), or > 4. Any other rules specified in extensions. > > Does this help? If so, I can itemize each condition in the > draft. I think this > would read better anyway. Yes, but it would help if you could also clarify the fact that resources in proxies and DIAMETER clients should be released only when a STA is received, and released in the Home AAA when a STA is about to be sent (or STR received). > > > > Section 2.5 - par.1 > > ------------------- > > "...the Device-Reboot-Ind message MUST contain one > Host-IP-Address AVP for > > each potential IP address that MAY be locally used when transmitting > > DIAMETER messages." > > > > Please, could you tell me briefly why we need to send all > IP addresses of > > the device? I guess it is because the device is not > registered into a DNS > > and we want to build an internal DNS inside the DIAMETER > server along with > > the Host-Name AVP for message routing, right? Should we > have a dynamic or > > static DNS in the server? > > It was intended to fully support SCTP, which inherently > supports multi-homed > servers. Which means that it is suggested for a DIAMETER server to maintain a dynamic "DNS" containing all the IP addresses of the clients for SCTP to support multi-homing? This is then an AVP which is transport dependent, right? Should it really be an AVP Mandatory (M), as it is right now? > > Section 5.2.4 > > ------------- > > "...but MAY be able to satisfy the request in the future." > > What does this mean exactly? Does it mean that a server > should be able to > > resend the request in a few minutes without any specific > changes to the > > message besides the timestamp for example? Should it be regarded as > > temporary congestion? > > It is intended to contain errors that occur due to some > temporary condition, > and the request can be tried again later. I am not sure how to express > "future". A timestamp may not really help, since the server > may not know when > the administrator will free up some disk space (as an example). > > > If it is the case, then maybe we should think of > > moving the DIAMETER_AUTHENTICATION_REJECTED and > DIAMETER_CONTRACTING_AVPS to > > the permanent failure section. I think that permanent > result codes should be > > used in the rejected message even if the originating server > can change AVPs > > in the message which has been rejected the first time for > some reasons such > > as unsupported mandatory AVPs, because it is no longer the > same message > > anyway, and the first message was really considered as a > permanent failure > > in this particular period of time. > yes, you are right. I will move these. It seems that you have missed the DIAMETER_AUTHENTICATION_REJECTED one. From owner-aaa-bof@merit.edu Mon Jan 22 11:50:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00473 for ; Mon, 22 Jan 2001 11:50:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC3235DF4C; Mon, 22 Jan 2001 11:47:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CADB65DF4A; Mon, 22 Jan 2001 11:47:45 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 03D435DF48 for ; Mon, 22 Jan 2001 11:47:43 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0MGlhC27134 for ; Mon, 22 Jan 2001 17:47:43 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jan 22 17:48:32 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 22 Jan 2001 17:47:42 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE67@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 Date: Mon, 22 Jan 2001 17:46:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, See comments inline. Martin > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Monday, January 22, 2001 4:39 PM > > > > > Section 3.5.2 > > > > ------------- > > > > What the Resource-Owner-NAI AVP used for in the STR? Is it > > > for routing? I > > > > guess not, since the User-Name AVP is present. Can it be > > > used in the server > > > > for any particular reason I don't see, since I think the > > > active session > > > > should be aware of what's going on within itself, right? > > > > > > If the home server wishes for the NAS to reliquish > resources, then the > > > User-name AVP doesn't really help since it would cause the > > > packet to get > > > routed to the home server (loop). So something is needed for > > > the message to > > > get routed to the NAS, and I envisioned was that the AVP > > > would be used for > > > routing purposes (and eventually get to the NAS). > > > > Then, are you telling me that the message routing can be > done using other > > AVPs than the Routing-Realm AVP and the User-Name AVP? > Also, is it really > > needed in the STR, which is sent from the access device to > the Home AAA? > > In the STR no, only in the STI. Can anyone think of a better > mechanism? I > really don't know of a better way to do this. Shouldn't we use the Routing-Realm AVP in order to reach the access device? Then, would you obsolete the Resource-Owner-NAI AVP, or do you see any further need for it? My understanding was that the Routing-Realm AVP was the destination of the message, as it is routed through the network, and the Host-Name AVP the originator of the message, which should never change during the message transit to its final destination. However, what could cause problems is the fact that some proxies might modify the Routing-Realm AVP in transit, right? From owner-aaa-bof@merit.edu Mon Jan 22 11:52:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00514 for ; Mon, 22 Jan 2001 11:52:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id C42175DF41; Mon, 22 Jan 2001 11:49:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AA3835DF1A; Mon, 22 Jan 2001 11:49:09 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 485FB5DF41 for ; Mon, 22 Jan 2001 11:49:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29367; Mon, 22 Jan 2001 08:49:05 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA27706; Mon, 22 Jan 2001 08:49:05 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA13553; Mon, 22 Jan 2001 08:49:03 -0800 (PST) Date: Mon, 22 Jan 2001 08:48:10 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE66@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat, > > Please, see some minor comments inline. as are mine... PatC > > > Section 2.0 - par.5 > > > ------------------- > > > "Session state (associated with a Session-Id) MUST be freed > > upon receipt of > > > the Session-Termination-Request, > > Session-Termination-Answer, expiration of > > > authorized service time in the Session-Timeout AVP, and > > according to rules > > > established in a particular extension/application of DIAMETER." > > > > > > I think this sentence is confusing me. Are you trying to > > show the real > > > trigger for the session release, the STR (as in section > > 3.5.2), or the > > > reasons why an STR could have been sent? It seems to me that the > > > "Session-Termination-Answer, expiration of authorized > > service time in the > > > Session-Timeout AVP, and according to rules established in > > a particular > > > extension/application of DIAMETER." part is more related to > > original reasons > > > why an STR has been sent. Also, it is confusing to read > > "authorized service > > > time in the Session-Timeout AVP" when you can also refer to > > the reason that > > > the "authorization-lifetime-AVP" might have time-out as > > well, which I assume > > > would trigger an STR. I need more info from you if you want > > me to propose > > > something else. > > > > I think that the confusion is largely in the quoted text. > > What the above > > attempts to state is that servers that maintain state needs > > to relinquish such > > state when: 1. A Session-Termination-Request is received, > > 2. A Session-Termination-Answer is received, > > 3. The session has timed out (which does NOT require sending > > any termination > > messages), or > > 4. Any other rules specified in extensions. > > > > Does this help? If so, I can itemize each condition in the > > draft. I think this > > would read better anyway. > > Yes, but it would help if you could also clarify the fact that resources in > proxies and DIAMETER clients should be released only when a STA is received, > and released in the Home AAA when a STA is about to be sent (or STR > received). ok. > > > > > > > > Section 2.5 - par.1 > > > ------------------- > > > "...the Device-Reboot-Ind message MUST contain one > > Host-IP-Address AVP for > > > each potential IP address that MAY be locally used when transmitting > > > DIAMETER messages." > > > > > > Please, could you tell me briefly why we need to send all > > IP addresses of > > > the device? I guess it is because the device is not > > registered into a DNS > > > and we want to build an internal DNS inside the DIAMETER > > server along with > > > the Host-Name AVP for message routing, right? Should we > > have a dynamic or > > > static DNS in the server? > > > > It was intended to fully support SCTP, which inherently > > supports multi-homed > > servers. > > Which means that it is suggested for a DIAMETER server to maintain a dynamic > "DNS" containing all the IP addresses of the clients for SCTP to support > multi-homing? This is then an AVP which is transport dependent, right? > Should it really be an AVP Mandatory (M), as it is right now? AAA servers should not be DNS servers. This is really an implementation issue, and the internals of the server shouldn't be discussed, IMHO. Yes, I think 'M' is correct. > > > > > Section 5.2.4 > > > ------------- > > > "...but MAY be able to satisfy the request in the future." > > > What does this mean exactly? Does it mean that a server > > should be able to > > > resend the request in a few minutes without any specific > > changes to the > > > message besides the timestamp for example? Should it be regarded as > > > temporary congestion? > > > > It is intended to contain errors that occur due to some > > temporary condition, > > and the request can be tried again later. I am not sure how to express > > "future". A timestamp may not really help, since the server > > may not know when > > the administrator will free up some disk space (as an example). > > > > > If it is the case, then maybe we should think of > > > moving the DIAMETER_AUTHENTICATION_REJECTED and > > DIAMETER_CONTRACTING_AVPS to > > > the permanent failure section. I think that permanent > > result codes should be > > > used in the rejected message even if the originating server > > can change AVPs > > > in the message which has been rejected the first time for > > some reasons such > > > as unsupported mandatory AVPs, because it is no longer the > > same message > > > anyway, and the first message was really considered as a > > permanent failure > > > in this particular period of time. > > yes, you are right. I will move these. > > It seems that you have missed the DIAMETER_AUTHENTICATION_REJECTED one. I will check. Thanks, PatC From owner-aaa-bof@merit.edu Mon Jan 22 12:12:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00955 for ; Mon, 22 Jan 2001 12:12:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64C175DDD9; Mon, 22 Jan 2001 12:11:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4F4845DE34; Mon, 22 Jan 2001 12:11:57 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3182F5DDD9 for ; Mon, 22 Jan 2001 12:11:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22062; Mon, 22 Jan 2001 09:11:52 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA02452; Mon, 22 Jan 2001 09:11:47 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA13899; Mon, 22 Jan 2001 09:11:39 -0800 (PST) Date: Mon, 22 Jan 2001 09:10:46 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE67@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat, > > See comments inline. > > Martin > > > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > > Sent: Monday, January 22, 2001 4:39 PM > > > > > > > Section 3.5.2 > > > > > ------------- > > > > > What the Resource-Owner-NAI AVP used for in the STR? Is it > > > > for routing? I > > > > > guess not, since the User-Name AVP is present. Can it be > > > > used in the server > > > > > for any particular reason I don't see, since I think the > > > > active session > > > > > should be aware of what's going on within itself, right? > > > > > > > > If the home server wishes for the NAS to reliquish > > resources, then the > > > > User-name AVP doesn't really help since it would cause the > > > > packet to get > > > > routed to the home server (loop). So something is needed for > > > > the message to > > > > get routed to the NAS, and I envisioned was that the AVP > > > > would be used for > > > > routing purposes (and eventually get to the NAS). > > > > > > Then, are you telling me that the message routing can be > > done using other > > > AVPs than the Routing-Realm AVP and the User-Name AVP? > > Also, is it really > > > needed in the STR, which is sent from the access device to > > the Home AAA? > > > > In the STR no, only in the STI. Can anyone think of a better > > mechanism? I > > really don't know of a better way to do this. > > Shouldn't we use the Routing-Realm AVP in order to reach the access device? > Then, would you obsolete the Resource-Owner-NAI AVP, or do you see any > further need for it? > > My understanding was that the Routing-Realm AVP was the destination of the > message, as it is routed through the network, and the Host-Name AVP the > originator of the message, which should never change during the message > transit to its final destination. However, what could cause problems is the > fact that some proxies might modify the Routing-Realm AVP in transit, right? I didn't think that Routing-Realm would pin point a particular NAS, but rather the domain that it happens to be in. Isn't this your understanding as well? PatC From owner-aaa-bof@merit.edu Mon Jan 22 13:20:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02360 for ; Mon, 22 Jan 2001 13:20:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA2C85DF35; Mon, 22 Jan 2001 13:19:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B86725DF33; Mon, 22 Jan 2001 13:19:09 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id A06765DE45 for ; Mon, 22 Jan 2001 13:19:08 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id NAA00723; Mon, 22 Jan 2001 13:24:52 -0500 (EST) Received: from cnc-exc1.ctron.com(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma000646; Mon, 22 Jan 01 13:23:46 -0500 Received: from cnc-exc1.ctron.com (localhost [127.0.0.1]) by cnc-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D1KM8XQY; Mon, 22 Jan 2001 13:17:58 -0500 Received: from 10.8.9.185 by cnc-exc1.ctron.com (InterScan E-Mail VirusWall NT); Mon, 22 Jan 2001 13:17:57 -0500 (Eastern Standard Time) Message-ID: <3A6C782B.EBC47599@enterasys.com> Date: Mon, 22 Jan 2001 13:12:59 -0500 From: David Harrington Reply-To: dbh@enterasys.com Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Pat Calhoun Cc: Bob Kopacz , Aaa-Wg Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) / 2.5.1 Vendor-Name AVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, I prefer the use of the enterprise ID. It is concise and factual. It should be satisfactual. Applications can provide the translation to English for those that need it. dbh Pat Calhoun wrote: > > I have no idea why a name was chosen over the IANA managed value. I agree that > using the value that one would find in the Vendor-Id field seems much more > reasonable. I think that the name was added for debugging purpose so users > (that have no idea what IANA, much less enterprise numbers) can figure out > what's at the other end. > > What do other prefer? Just the ID, or both? > > Thanks for the great catch! > > PatC > > Hi Pat, > > > > The DRI contains a Vendor-Name AVP, which the draft says > > is so that a Diameter peer might "know which vendor > > specific attributes may be sent to the peer". > > > > Since it is the 32-bit vendor number that appears in the > > AVP header and in the Diameter header, should the DRI > > instead include a Vendor-ID AVP which contains the > > vendor's enterprise code? It seems a vendor ID value > > would be more directly useful for the above-mentioned > > purpose. > > > > Or if the Vendor-Name AVP is the way to go, should there > > be a list of vendor name strings so that they can be > > mapped to known vendors, and an indication if this string > > is case-sensitive, etc.? > > > > The "DIAMETER Base Protocol (Alpha 1)" document says: > > > > > 2.5.1 Vendor-Name AVP > > > > > > The Vendor-Name AVP (AVP Code 266) is of type > > > OctetString and is used to inform a DIAMETER peer of the > > > Vendor Name of the DIAMETER device. This MAY be used in > > > order to know which vendor specific attributes may be > > > sent to the peer. It is also envisioned that the > > > combination of the Vendor-Name and the Firmware-Revision > > > (section 2.5.2) AVPs MAY provide very useful debugging > > > information. > > > > -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-aaa-bof@merit.edu Mon Jan 22 13:30:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02579 for ; Mon, 22 Jan 2001 13:30:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BF525DE14; Mon, 22 Jan 2001 13:29:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E6D065DE1F; Mon, 22 Jan 2001 13:29:48 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 71DCB5DE14 for ; Mon, 22 Jan 2001 13:29:47 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0MIThH15281; Mon, 22 Jan 2001 13:29:43 -0500 (EST) (envelope-from barney) Date: Mon, 22 Jan 2001 13:29:43 -0500 From: Barney Wolff To: Pat Calhoun Cc: Barney Wolff , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 Message-ID: <20010122132943.B15144@mx.databus.com> References: <20010122104524.A14651@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@eng.sun.com on Mon, Jan 22, 2001 at 08:15:26AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk I was commenting on language specifying when the server & proxy must release resources (STR/STA). I don't believe that has to be specified. All that needs to be said is that a server must respond to STR with STA and a proxy must pass an STA back to its client. Specifying exactly when internal resources get released is overkill, unless it has consequences on visible behavior. IMHO. Barney On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote: > > Why does DIAMETER need to specify such within-node behavior? > > Is any of it visible outside the node? > > If state is released implicitly, then a sentence explaining the purpose of the > Session-Timeout AVP is sufficient. However, if explicit signaling is used to > release resources, then it is visible outside the node. > > PatC > From owner-aaa-bof@merit.edu Mon Jan 22 13:34:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02736 for ; Mon, 22 Jan 2001 13:34:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23A2F5DEDF; Mon, 22 Jan 2001 13:33:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1126F5DEA4; Mon, 22 Jan 2001 13:33:13 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E786A5DE1F for ; Mon, 22 Jan 2001 13:33:11 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01056; Mon, 22 Jan 2001 10:32:32 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23417; Mon, 22 Jan 2001 10:31:29 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA15478; Mon, 22 Jan 2001 10:31:27 -0800 (PST) Date: Mon, 22 Jan 2001 10:30:29 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: Barney Wolff Cc: Pat Calhoun , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <20010122132943.B15144@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Ah, sorry for the misunderstanding. I do agree. Does anyone object? PatC > I was commenting on language specifying when the server & proxy > must release resources (STR/STA). I don't believe that has to > be specified. All that needs to be said is that a server > must respond to STR with STA and a proxy must pass an STA back > to its client. Specifying exactly when internal resources get > released is overkill, unless it has consequences on visible > behavior. IMHO. > > Barney > > On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote: > > > Why does DIAMETER need to specify such within-node behavior? > > > Is any of it visible outside the node? > > > > If state is released implicitly, then a sentence explaining the purpose of the > > Session-Timeout AVP is sufficient. However, if explicit signaling is used to > > release resources, then it is visible outside the node. > > > > PatC > > From owner-aaa-bof@merit.edu Tue Jan 23 02:34:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA16003 for ; Tue, 23 Jan 2001 02:34:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FF1B5DD94; Tue, 23 Jan 2001 02:31:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2757F5DE0B; Tue, 23 Jan 2001 02:31:29 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 7600A5DD94 for ; Tue, 23 Jan 2001 02:31:27 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0N7VQC02297 for ; Tue, 23 Jan 2001 08:31:26 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Tue Jan 23 08:31:29 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 23 Jan 2001 08:31:25 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE69@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 Date: Tue, 23 Jan 2001 08:31:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk See enclosed comments. > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Monday, January 22, 2001 6:11 PM > > > > > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > > > Sent: Monday, January 22, 2001 4:39 PM > > > > > > > > > Section 3.5.2 > > > > > > ------------- > > > > > > What the Resource-Owner-NAI AVP used for in the STR? Is it > > > > > for routing? I > > > > > > guess not, since the User-Name AVP is present. Can it be > > > > > used in the server > > > > > > for any particular reason I don't see, since I think the > > > > > active session > > > > > > should be aware of what's going on within itself, right? > > > > > > > > > > If the home server wishes for the NAS to reliquish > > > resources, then the > > > > > User-name AVP doesn't really help since it would cause the > > > > > packet to get > > > > > routed to the home server (loop). So something is needed for > > > > > the message to > > > > > get routed to the NAS, and I envisioned was that the AVP > > > > > would be used for > > > > > routing purposes (and eventually get to the NAS). > > > > > > > > Then, are you telling me that the message routing can be > > > done using other > > > > AVPs than the Routing-Realm AVP and the User-Name AVP? > > > Also, is it really > > > > needed in the STR, which is sent from the access device to > > > the Home AAA? > > > > > > In the STR no, only in the STI. Can anyone think of a better > > > mechanism? I > > > really don't know of a better way to do this. > > > > Shouldn't we use the Routing-Realm AVP in order to reach > the access device? > > Then, would you obsolete the Resource-Owner-NAI AVP, or do > you see any > > further need for it? > > > > My understanding was that the Routing-Realm AVP was the > destination of the > > message, as it is routed through the network, and the > Host-Name AVP the > > originator of the message, which should never change during > the message > > transit to its final destination. However, what could cause > problems is the > > fact that some proxies might modify the Routing-Realm AVP > in transit, right? > > I didn't think that Routing-Realm would pin point a > particular NAS, but rather > the domain that it happens to be in. Isn't this your > understanding as well? > > PatC > That was my initial understanding until I find out that the Destination-NAI AVP was removed from the Base Protocol. Now, I'm wondering how a re-authentication message can reach the same Host-Server if there is no Destination-NAI AVP in which put the Host-Name AVP of the Home AAA received in the first Authentication response? I thought possible to have several Home servers for the same realm, but since the Destination-NAI AVP was gone, I thought that it would not be possible anymore, unless they all share information about the user session. Could someone help me on that? From owner-aaa-bof@merit.edu Tue Jan 23 05:19:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA18694 for ; Tue, 23 Jan 2001 05:19:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id A74225DDBC; Tue, 23 Jan 2001 05:18:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F9125DDC9; Tue, 23 Jan 2001 05:18:19 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id D253B5DDBC for ; Tue, 23 Jan 2001 05:18:17 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0NAIGC14541 for ; Tue, 23 Jan 2001 11:18:16 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 23 11:18:17 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 23 Jan 2001 11:18:17 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE6A@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , Barney Wolff , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Date: Tue, 23 Jan 2001 11:18:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Barney, I understand you point and I totally agree with you. However, could you please help me with the following scenario? I'd like to know if you would consider it a problem related to the configuration of the Home-AAA server (using policies) or the access device, if the Session-Timeout is reached and forces the servers to release the session? In the case that the timeout is reached in the access device, I could assume that a STR would be sent to the Home-AAA to stop accounting and release the resources in the proxies and the Home-AAA server. However, in the case where the timeout expires in the Home-AAA server, should it stop accounting and release the session immediately, even though you might not be sure that the service has really been terminated in the access device? Also, you might end-up receiving a STR in the Home-AAA with a no longer valid session-ID, right? IMHO, I think DIAMETER should give the tools for assuring user (service) session integrity for the whole network. I! hope it is clearer. BR, Martin > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Monday, January 22, 2001 7:30 PM > To: Barney Wolff > Cc: Pat Calhoun; Martin Julien (ECE); 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments > Section 3.0 > > > Ah, sorry for the misunderstanding. I do agree. Does anyone object? > > PatC > > I was commenting on language specifying when the server & proxy > > must release resources (STR/STA). I don't believe that has to > > be specified. All that needs to be said is that a server > > must respond to STR with STA and a proxy must pass an STA back > > to its client. Specifying exactly when internal resources get > > released is overkill, unless it has consequences on visible > > behavior. IMHO. > > > > Barney > > > > On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote: > > > > Why does DIAMETER need to specify such within-node behavior? > > > > Is any of it visible outside the node? > > > > > > If state is released implicitly, then a sentence > explaining the purpose of the > > > Session-Timeout AVP is sufficient. However, if explicit > signaling is used to > > > release resources, then it is visible outside the node. > > > > > > PatC > > > > > > From owner-aaa-bof@merit.edu Tue Jan 23 05:52:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA19145 for ; Tue, 23 Jan 2001 05:52:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id C15285DF24; Tue, 23 Jan 2001 05:49:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A45AA5DF21; Tue, 23 Jan 2001 05:49:45 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 2C3E25DE0F for ; Tue, 23 Jan 2001 05:49:00 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0NAmtd25599 for ; Tue, 23 Jan 2001 11:48:55 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jan 23 11:49:44 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Tue, 23 Jan 2001 11:48:55 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE6B@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat.Calhoun@eng.sun.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: DIAMETER Base Protocol (Alpha 1) - Comments section 6.0 Date: Tue, 23 Jan 2001 11:48:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, Some more comments on Alpha1, which I think are still valid for Alpha2. I was waiting before posting it, but since we have already started the discussion about my comments on section 6.2.1 in another thread, I thought I could give it a try. Martin Section 6.2.1 ------------- If more than one server is found in the routing table, should the message be sent to all the servers? According to the previous revision of this document, the message should be sent to only one of the servers (refer to section 6.3.1 of draft-calhoun-diameter-17.txt) If so, I wonder how the routing of re-authentication messages from the NAS to the same Home server could occur again for the same session-ID? I thought the no-longer-existing Destination-NAI AVP was meant to identify precisely a destination server within a realm of servers and used as the main key for routing? Also, I guess the caching of the Home server proposed in the previous version of this document is no longer recommended to short-cut the redirect server? Neither the use of the Session-Timeout AVP? Section 6.4.2 ------------- "...last Route-Record AVP matches one of its addresses." Should we replace addresses by Local FQDN, since the Route-Record AVP contains FQDN only? Section 6.4.4 ------------- Why do we have to specify an address in the Proxy-State if it can not be used for routing anyway? Could we replace it with an Host-Name (FQDN) to make it more consistent with some other AVPs? Section 6.4.7 ------------- Is the Routing-Realm AVP enough to route a message to a server where a session-ID is already started? I thought the no-longer-existing Destination-NAI AVP was meant to identify precisely a destination server within a realm of servers and used as the main key for routing? Section 6.7 ----------- "If an AVP with the local host's identity..." I guess you meant the local host FQDN, as would be used in the Host-Name AVP if a message would origin ate from that proxy? From owner-aaa-bof@merit.edu Tue Jan 23 07:49:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA20840 for ; Tue, 23 Jan 2001 07:49:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 912E05DDF2; Tue, 23 Jan 2001 07:45:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7EF605DDCD; Tue, 23 Jan 2001 07:45:49 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id A2BA55DDC9 for ; Tue, 23 Jan 2001 07:45:46 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA24045; Tue, 23 Jan 2001 18:15:10 +0530 (IST) From: Kaushik Narayan Message-Id: <200101231245.SAA24045@cisco.com> Subject: [AAA-WG]: Re: AAA-WG: RE: Making the hard choices on AAA security To: Martin.Julien@ece.ericsson.se ("Martin Julien (ECE)") Date: Tue, 23 Jan 2001 18:15:10 +0530 (IST) Cc: Pat.Calhoun@Eng.Sun.COM ('Pat.Calhoun@Eng.Sun.COM'), aaa-wg@merit.edu ('aaa-wg@merit.edu') In-Reply-To: <577066326047D41180AC00508B955DDA01D7FE5B@eestqnt104.es.eu.ericsson.se> from "Martin Julien (ECE)" at Jan 19, 2001 08:46:13 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk hi! End to End security would require three basic components 1> AVP integrity protection - Select AVPs that need to be inspected by intermediate hops but need to be protected against modification by intermediate proxies can be integrity protected. The MIC on these AVPs would be generated using the end to end key. 2> AVP encryption - Select AVPs that need to be encrypted can be encrypted end to end using the end to end key. 3> e2e authetication - I am not sure whether per AVP authentication (or Grouped-AVP) would be very efficient since authentication tokens need to be generated and need to carried back and forth. Infact if the end to end peers are authenticated and they use a negotiated key to secure AVPs there wouldnot be a need to authenticate individual AVPs. There would be only a need to mutually authenticate the key negotiation exchange (initial Request-Response) between the end to end diameter peers. kaushik! > > I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document? > > Martin > > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM] > Sent: Thursday, January 18, 2001 7:00 PM > To: Martin Julien (ECE); Steven Glass - Solaris Software; > 'stephen.farrell@baltimore.ie' > Cc: aaa-wg@merit.edu; Alain Zahm; Bernard Aboba > Subject: RE: Making the hard choices on AAA security > > > For proxies that wish to maintain state information, not having access > to the result code would be a problem. > > Perhaps e2e authenticated, but not encrypted. > > PatC > >Steven, > > > >Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e, > >using the Strong Security extension of course, which would prevent proxies to > >play around with its content when not allowed by the server? > > > >Martin > > > >-----Original Message----- > >From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie] > >Sent: Thursday, January 18, 2001 11:16 AM > >To: Steven Glass - Solaris Software > >Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu > >Subject: Re: Making the hard choices on AAA security > > > > > > > > > >Steven Glass - Solaris Software wrote: > >> > >> > > >> > > >> > > Bernard Aboba wrote: > >> > > > >> > > A proxy can change an Access-Accept into an Access-Reject under the guise > >of "policy". However, an > >> > > Access-Reject should never be changed to an Access-Accept. A good question > >is how this could be > >> > > enforced, using any of the solutions that have been proposed. > >> > > >> > Not sure it could... > >> > >> Maybe not from the solutions proposed... > > > >Just for clarity, CMS, Kerberos and any other self-respecting > >e2e security solution will offer e2e data integrity. The "not > >sure" etc. refers to allowing one type of change and > >preventing/detecting another, not to simple integrity. > > > >Stephen. > > > >-- > >____________________________________________________________ > >Stephen Farrell > >Baltimore Technologies, tel: (direct line) +353 1 881 6716 > >39 Parkgate Street, fax: +353 1 881 7000 > >Dublin 8. mailto:stephen.farrell@baltimore.ie > >Ireland http://www.baltimore.com > > > > > From owner-aaa-bof@merit.edu Tue Jan 23 09:35:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA22653 for ; Tue, 23 Jan 2001 09:35:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B1395DE0E; Tue, 23 Jan 2001 09:34:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49F5B5DDFE; Tue, 23 Jan 2001 09:34:31 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id B80985DDC9 for ; Tue, 23 Jan 2001 09:34:29 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0NERxa20049; Tue, 23 Jan 2001 09:27:59 -0500 (EST) (envelope-from barney) Date: Tue, 23 Jan 2001 09:27:59 -0500 From: Barney Wolff To: "Martin Julien (ECE)" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Message-ID: <20010123092758.A19972@mx.databus.com> References: <577066326047D41180AC00508B955DDA01D7FE6A@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <577066326047D41180AC00508B955DDA01D7FE6A@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Tue, Jan 23, 2001 at 11:18:11AM +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk Ah, the famous "NAS caught fire" problem. This is (part of) what makes server-based resource management hard. The only solution that makes sense to me is periodic reassurance from the NAS that the session is still in progress (aka Interim Accounting). After enough time without such assurance, the server has to consider the resources held by the session to be free again. You'll see in the Solutions draft discussion of soft state and hard state - one can use different solutions for "loose" resources such as IP addresses from a pool and "tight" resources such as the number of concurrent logins allowed a single user. I *hate* server-based resource management, but sometimes bosses and marketeers insist. Barney On Tue, Jan 23, 2001 at 11:18:11AM +0100, Martin Julien (ECE) wrote: > Barney, > > I understand you point and I totally agree with you. However, could you please help me with the following scenario? I'd like to know if you would consider it a problem related to the configuration of the Home-AAA server (using policies) or the access device, if the Session-Timeout is reached and forces the servers to release the session? In the case that the timeout is reached in the access device, I could assume that a STR would be sent to the Home-AAA to stop accounting and release the resources in the proxies and the Home-AAA server. However, in the case where the timeout expires in the Home-AAA server, should it stop accounting and release the session immediately, even though you might not be sure that the service has really been terminated in the access device? Also, you might end-up receiving a STR in the Home-AAA with a no longer valid session-ID, right? IMHO, I think DIAMETER should give the tools for assuring user (service) session integrity for the whole network.! I! > hope it is clearer. From owner-aaa-bof@merit.edu Tue Jan 23 10:22:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23689 for ; Tue, 23 Jan 2001 10:22:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADDDD5DE12; Tue, 23 Jan 2001 10:22:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9CF385DDFE; Tue, 23 Jan 2001 10:22:20 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 47E5E5DE0F for ; Tue, 23 Jan 2001 10:22:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27460; Tue, 23 Jan 2001 07:22:09 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11687; Tue, 23 Jan 2001 07:22:08 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27516; Tue, 23 Jan 2001 07:22:06 -0800 (PST) Date: Tue, 23 Jan 2001 07:21:15 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 To: Barney Wolff Cc: "Martin Julien (ECE)" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010123092758.A19972@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Barney, So do you agree then that it is possible for entities to simply free their resources once the timeout has been reached, without the need for explicit signaling? If the NAS decides to issue the STR, an error will be returned stating that the session does not exist, at which point it will realize that the timeout has occured, and free resources anyways. So is this a problem? PatC From owner-aaa-bof@merit.edu Tue Jan 23 10:33:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23919 for ; Tue, 23 Jan 2001 10:33:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 179225DE37; Tue, 23 Jan 2001 10:31:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 062BB5DE36; Tue, 23 Jan 2001 10:31:18 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A3BDE5DE21 for ; Tue, 23 Jan 2001 10:31:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01027; Tue, 23 Jan 2001 07:31:12 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA12864; Tue, 23 Jan 2001 07:31:12 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27594; Tue, 23 Jan 2001 07:31:10 -0800 (PST) Date: Tue, 23 Jan 2001 07:30:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE69@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > That was my initial understanding until I find out that the Destination-NAI > AVP was removed from the Base Protocol. Now, I'm wondering how a > re-authentication message can reach the same Host-Server if there is no > Destination-NAI AVP in which put the Host-Name AVP of the Home AAA received > in the first Authentication response? I thought possible to have several > Home servers for the same realm, but since the Destination-NAI AVP was gone, > I thought that it would not be possible anymore, unless they all share > information about the user session. Could someone help me on that? sigh. Well I guess in my haste to remove support for different reverse path routing, I removed an AVP that had additional uses. So, it looks like Destination-NAI needs to be put back in, but with a much more limited set of functionality. It will now ONLY be used to identify the host within the domain. The Routing-Realm AVP is still used to identify the Domain, and once a server identifies that the message made it to the destination realm, the Destination-NAI is used to route to a specific host. This means that the Resource-Owner-NAI is gone. This seems to work for reverse re-auth *and* termination messages. Comments? PatC From owner-aaa-bof@merit.edu Tue Jan 23 10:41:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24039 for ; Tue, 23 Jan 2001 10:41:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF2035DE39; Tue, 23 Jan 2001 10:39:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B39F25DE60; Tue, 23 Jan 2001 10:39:19 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AF6D15DE39 for ; Tue, 23 Jan 2001 10:38:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00743 for ; Tue, 23 Jan 2001 07:38:38 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14086 for ; Tue, 23 Jan 2001 07:38:37 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27694 for ; Tue, 23 Jan 2001 07:38:36 -0800 (PST) Date: Tue, 23 Jan 2001 07:37:44 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Proposed ABNF message definition To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I would like to solicit comments on modifying the first round of DIAMETER specs as WG documents to make use of Erik's proposed ABNF format. These are MUCH better than what is currently in the document, and we can always change them to a different format in a future revision. Any objections before I move forward with the changes? PatC From owner-aaa-bof@merit.edu Tue Jan 23 11:30:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24912 for ; Tue, 23 Jan 2001 11:30:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE21D5DE3A; Tue, 23 Jan 2001 11:29:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 91EE05DE32; Tue, 23 Jan 2001 11:29:50 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 2D34F5DE21 for ; Tue, 23 Jan 2001 11:29:49 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0NGTYw20722; Tue, 23 Jan 2001 11:29:34 -0500 (EST) (envelope-from barney) Date: Tue, 23 Jan 2001 11:29:33 -0500 From: Barney Wolff To: Pat Calhoun Cc: Barney Wolff , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Message-ID: <20010123112933.A20613@mx.databus.com> References: <20010123092758.A19972@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 23, 2001 at 07:21:15AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk I think it's a little more complex. A session-limiting timeout from server to NAS should certainly provoke an STR from the server when the time runs out. The only time a node would silently drop a session is when a server has sent a session-timeout at the start, and fails to hear anything from the NAS after a well-chosen interval. That could be some increment over the interim accounting interval, if interim accounting is in use, or the session timeout, if that was specified. That silent drop assumes the server has no way to signal or probe the NAS, as was true for RADIUS. With DIAMETER, a server in that state should send an STR towards the NAS rather than just silently drop its resources, as long as such an STR is allowed. That's a no-lose step - if the NAS has silently restarted, the server will get some response indicating that. If the NAS is dead, the server will get a response from a proxy, or at least time out after a relatively short wait. I can imagine cases where it's more complex yet, when part of the chain is DIAMETER and part is RADIUS. There we need a way for a proxy to say "cannot translate". I'm sorry if I've been unclear in expression, or just muddled in thinking. Saying that we don't need to specify WHEN a node frees resources was not intended to imply that a DIAMETER peer should be silent when its partner fails to send an expected request or response. Barney On Tue, Jan 23, 2001 at 07:21:15AM -0800, Pat Calhoun wrote: > Barney, > > So do you agree then that it is possible for entities to simply free their > resources once the timeout has been reached, without the need for explicit > signaling? If the NAS decides to issue the STR, an error will be returned > stating that the session does not exist, at which point it will realize that > the timeout has occured, and free resources anyways. > > So is this a problem? > > PatC > From owner-aaa-bof@merit.edu Tue Jan 23 11:41:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25086 for ; Tue, 23 Jan 2001 11:41:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 055A75DE32; Tue, 23 Jan 2001 11:40:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E7F7D5DE2D; Tue, 23 Jan 2001 11:40:51 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9883D5DE20 for ; Tue, 23 Jan 2001 11:40:50 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22423; Tue, 23 Jan 2001 08:40:46 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA15010; Tue, 23 Jan 2001 08:40:46 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA28169; Tue, 23 Jan 2001 08:40:44 -0800 (PST) Date: Tue, 23 Jan 2001 08:39:50 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 To: Barney Wolff Cc: Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010123112933.A20613@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Cool, I think we are nearly there. One more question. Who initiates the STR? Should it be the NAS, or the home server. We need to provide some guidelines to reduce the changes of such messages crossing through the network. PatC From owner-aaa-bof@merit.edu Tue Jan 23 12:44:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26366 for ; Tue, 23 Jan 2001 12:44:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A6BB5DE2D; Tue, 23 Jan 2001 12:44:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ECE735DE20; Tue, 23 Jan 2001 12:44:06 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 16D075DDF1 for ; Tue, 23 Jan 2001 12:44:06 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D075F72; Tue, 23 Jan 2001 12:44:14 -0500 (EST) Message-ID: <3A6DC2FF.C8F4328C@Interlinknetworks.com> Date: Tue, 23 Jan 2001 12:44:31 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Barney Wolff , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat Calhoun wrote: > > Cool, I think we are nearly there. One more question. Who initiates the STR? > Should it be the NAS, or the home server. We need to provide some guidelines > to reduce the changes of such messages crossing through the network. > > PatC I guess I'm confused as to where "there" is. I hear Barney and Martin aguing for explicit signalling and Pat arguing that timeouts themselves should terminate sessions without the need for signalling. Personally, I think that all terminations should be explicitly signalled. We need to carefully consider all of the possible collision scenarios. Not signalling doesn't really simplify things. For example, the home server may time out just as the NAS is simultaneously sending a re-auth. (I realize the NAS should have sent the re-auth earlier, but delays do happen.) When the home server receives the re-auth, it gets confused because it has already released state. If the home server had sent an STI and waited for an STR, then things like the re-auth collision could be handled better. To get this right, we really need to specify a session state table. That's more work, but it's part of making a good standard. I also have a comment on the idea of including an Extension-ID AVP in STRs and STIs. I can understand the desire to be able to terminate subsessions of a complex session, but DIAMETER doesn't really support subsessions. I can also understand the need to free some resources within a session without terminating the entire session. But to do that, you need real resource management, and DIAMETER doesn't do that either. I don't think trying to do pseudo-resouce management through the use of the Extension-ID AVP is a particularly good idea. The Extension-ID does not really indicate resources, nor does it precisely indicate applications either. Instead it simply indicates which subsets of DIAMETER are being used in the protocol exchange. So what would it mean if a server receives an STR (or STI) specifying some Session-ID and the NASREQ Extension-ID, but not the Strong-Crypto Extension-ID which was also used in establishing the session? Or if a server receives an STR specifying the Accounting Extension-ID but not the NASREQ Extension-ID (although maybe we've decided to include accounting in the service extensions)? Anyway, I think if we want to do resource management, then we should figure out how to do resource management and not try to slap together a quick fix that uses the wrong data element for the wrong purpose. Personally, I would be quite happy if we left the STRs and STIs the way they are and let them terminate an entire session -- all resources and state associated with a Session-ID. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 13:29:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27134 for ; Tue, 23 Jan 2001 13:29:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id E4F725DE36; Tue, 23 Jan 2001 13:29:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D37665DE26; Tue, 23 Jan 2001 13:29:27 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 577B55DDF1 for ; Tue, 23 Jan 2001 13:29:26 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0NITIs21226; Tue, 23 Jan 2001 13:29:18 -0500 (EST) (envelope-from barney) Date: Tue, 23 Jan 2001 13:29:18 -0500 From: Barney Wolff To: Pat Calhoun Cc: Barney Wolff , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Message-ID: <20010123132918.A21181@mx.databus.com> References: <20010123112933.A20613@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@eng.sun.com on Tue, Jan 23, 2001 at 08:39:50AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk I'd say the NAS does it, as it should have the primary timing responsibility. The server's timing is to avoid getting stuck in a state, and can be quite coarse, or nonexistent if the server does not track session state. If the server had the primary timing responsibility, we wouldn't need the session-timout avp at all, as it could just decide to terminate the session when it wants to. But I think that's a poor use of server cycles. Barney On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > Cool, I think we are nearly there. One more question. Who initiates the STR? > Should it be the NAS, or the home server. We need to provide some guidelines > to reduce the changes of such messages crossing through the network. > > PatC > > From owner-aaa-bof@merit.edu Tue Jan 23 13:49:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27413 for ; Tue, 23 Jan 2001 13:49:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 75F6D5DEC9; Tue, 23 Jan 2001 13:46:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 600AA5DED0; Tue, 23 Jan 2001 13:46:35 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0D65B5DEC9 for ; Tue, 23 Jan 2001 13:46:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07520; Tue, 23 Jan 2001 10:43:31 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA11827; Tue, 23 Jan 2001 09:56:12 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA29312; Tue, 23 Jan 2001 09:56:09 -0800 (PST) Date: Tue, 23 Jan 2001 09:55:02 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 To: David Spence Cc: Pat Calhoun , Barney Wolff , "Martin Julien (ECE)" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A6DC2FF.C8F4328C@Interlinknetworks.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: > > > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > Should it be the NAS, or the home server. We need to provide some guidelines > > to reduce the changes of such messages crossing through the network. > > > > PatC > > I guess I'm confused as to where "there" is. I hear Barney and Martin > aguing for explicit signalling and Pat arguing that timeouts themselves > should terminate sessions without the need for signalling. ok, perhaps I didn't make myself that clear. I am in agreement with Barney and Martin, which led to my question. > > Personally, I think that all terminations should be explicitly signalled. > We need to carefully consider all of the possible collision scenarios. Not > signalling doesn't really simplify things. For example, the home server may > time out just as the NAS is simultaneously sending a re-auth. (I realize > the NAS should have sent the re-auth earlier, but delays do happen.) When > the home server receives the re-auth, it gets confused because it has > already released state. If the home server had sent an STI and waited for > an STR, then things like the re-auth collision could be handled better. To > get this right, we really need to specify a session state table. That's > more work, but it's part of making a good standard. So, if I understand correctly, a new state table needs to be provided to show the state transitions of a session, correct? Any comment on who should initiate the STR or STI? Could we say that if a session is terminated due to a session timeout, the NAS does it. However, if the home server does not receive the STR within session timeout + fudge factor, then it should send the STI. Of course, either peer is entitled to send the STR at any time prior to the session timeout. does this work? > > I also have a comment on the idea of including an Extension-ID AVP in STRs > and STIs. I can understand the desire to be able to terminate subsessions > of a complex session, but DIAMETER doesn't really support subsessions. I > can also understand the need to free some resources within a session without > terminating the entire session. But to do that, you need real resource > management, and DIAMETER doesn't do that either. I don't think trying to do > pseudo-resouce management through the use of the Extension-ID AVP is a > particularly good idea. The Extension-ID does not really indicate > resources, nor does it precisely indicate applications either. Instead it > simply indicates which subsets of DIAMETER are being used in the protocol > exchange. So what would it mean if a server receives an STR (or STI) > specifying some Session-ID and the NASREQ Extension-ID, but not the > Strong-Crypto Extension-ID which was also used in establishing the session? > Or if a server receives an STR specifying the Accounting Extension-ID but > not the NASREQ Extension-ID (although maybe we've decided to include > accounting in the service extensions)? Good argument against extension ID in STRs. > > Anyway, I think if we want to do resource management, then we should figure > out how to do resource management and not try to slap together a quick fix > that uses the wrong data element for the wrong purpose. Personally, I would > be quite happy if we left the STRs and STIs the way they are and let them > terminate an entire session -- all resources and state associated with a > Session-ID. ok, that works for me as well, since it is the easiest (both in terms of documentation as well as implementation). PatC From owner-aaa-bof@merit.edu Tue Jan 23 13:50:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27441 for ; Tue, 23 Jan 2001 13:50:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC3885DE3F; Tue, 23 Jan 2001 13:48:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A5C9B5DE60; Tue, 23 Jan 2001 13:48:21 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B834E5DE3F for ; Tue, 23 Jan 2001 13:48:20 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 4D57072; Tue, 23 Jan 2001 13:48:29 -0500 (EST) Message-ID: <3A6DD20B.B387F097@Interlinknetworks.com> Date: Tue, 23 Jan 2001 13:48:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff Cc: Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 References: <20010123112933.A20613@mx.databus.com> <20010123132918.A21181@mx.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Actually, both the NAS and the home server have to run a timer. The home server has to because he's the one who cares and he wants to enforce his policy. The NAS has to because it is possible that the home server will be (temporarily) unreachable from the NAS at the time the timeout is to occur. The NAS has an interest in running the timer because if the home organization will refuse to pay for a longer session than the timeout specifies, then the NAS wants to make sure it doesn't provide a longer session. This means that both parties will timeout approximately simultaneously so a termination collision is likely. No problem. The home server is expecting an STR in response to its STI, so if it receives the STR generated by the NAS' timeout, its happy. The rule for the NAS is: ignore an STI received in STR-sent state. So the NAS avoids sending a second STR. The home server will send STA in response to STR and everyone is happy. Barney Wolff wrote: > > I'd say the NAS does it, as it should have the primary timing > responsibility. The server's timing is to avoid getting stuck in > a state, and can be quite coarse, or nonexistent if the server > does not track session state. > > If the server had the primary > timing responsibility, we wouldn't need the session-timout avp at > all, as it could just decide to terminate the session when it wants > to. But I think that's a poor use of server cycles. > > Barney > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > Should it be the NAS, or the home server. We need to provide some guidelines > > to reduce the changes of such messages crossing through the network. > > > > PatC > > > > -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 13:53:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27503 for ; Tue, 23 Jan 2001 13:53:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5EA555DE4E; Tue, 23 Jan 2001 13:52:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3AE795DE4B; Tue, 23 Jan 2001 13:52:42 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 8D3B75DE4A for ; Tue, 23 Jan 2001 13:52:40 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5EB2A72; Tue, 23 Jan 2001 13:52:49 -0500 (EST) Message-ID: <3A6DD30F.33776BEF@Interlinknetworks.com> Date: Tue, 23 Jan 2001 13:53:03 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Barney Wolff , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk See comments interspersed below. Pat Calhoun wrote: > > > Pat Calhoun wrote: > > > > > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > > Should it be the NAS, or the home server. We need to provide some guidelines > > > to reduce the changes of such messages crossing through the network. > > > > > > PatC > > > > I guess I'm confused as to where "there" is. I hear Barney and Martin > > aguing for explicit signalling and Pat arguing that timeouts themselves > > should terminate sessions without the need for signalling. > > ok, perhaps I didn't make myself that clear. I am in agreement with Barney and > Martin, which led to my question. Good. Now I understand. > > > > > Personally, I think that all terminations should be explicitly signalled. > > We need to carefully consider all of the possible collision scenarios. Not > > signalling doesn't really simplify things. For example, the home server may > > time out just as the NAS is simultaneously sending a re-auth. (I realize > > the NAS should have sent the re-auth earlier, but delays do happen.) When > > the home server receives the re-auth, it gets confused because it has > > already released state. If the home server had sent an STI and waited for > > an STR, then things like the re-auth collision could be handled better. To > > get this right, we really need to specify a session state table. That's > > more work, but it's part of making a good standard. > > So, if I understand correctly, a new state table needs to be provided to show > the state transitions of a session, correct? > > Any comment on who should initiate the STR or STI? Could we say that if a > session is terminated due to a session timeout, the NAS does it. However, if > the home server does not receive the STR within session timeout + fudge > factor, then it should send the STI. Of course, either peer is entitled to > send the STR at any time prior to the session timeout. > > does this work? See my reply of a few minutes ago to Barney Wolff for an informal description of how I think it should work. > > > > > I also have a comment on the idea of including an Extension-ID AVP in STRs > > and STIs. I can understand the desire to be able to terminate subsessions > > of a complex session, but DIAMETER doesn't really support subsessions. I > > can also understand the need to free some resources within a session without > > terminating the entire session. But to do that, you need real resource > > management, and DIAMETER doesn't do that either. I don't think trying to do > > pseudo-resouce management through the use of the Extension-ID AVP is a > > particularly good idea. The Extension-ID does not really indicate > > resources, nor does it precisely indicate applications either. Instead it > > simply indicates which subsets of DIAMETER are being used in the protocol > > exchange. So what would it mean if a server receives an STR (or STI) > > specifying some Session-ID and the NASREQ Extension-ID, but not the > > Strong-Crypto Extension-ID which was also used in establishing the session? > > Or if a server receives an STR specifying the Accounting Extension-ID but > > not the NASREQ Extension-ID (although maybe we've decided to include > > accounting in the service extensions)? > > Good argument against extension ID in STRs. > > > > > Anyway, I think if we want to do resource management, then we should figure > > out how to do resource management and not try to slap together a quick fix > > that uses the wrong data element for the wrong purpose. Personally, I would > > be quite happy if we left the STRs and STIs the way they are and let them > > terminate an entire session -- all resources and state associated with a > > Session-ID. > > ok, that works for me as well, since it is the easiest (both in terms of > documentation as well as implementation). > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 13:53:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27526 for ; Tue, 23 Jan 2001 13:53:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 445EB5DDF1; Tue, 23 Jan 2001 13:53:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1697D5DE51; Tue, 23 Jan 2001 13:53:01 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C4E9F5DDF1 for ; Tue, 23 Jan 2001 13:52:56 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19445; Tue, 23 Jan 2001 10:52:51 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA24023; Tue, 23 Jan 2001 10:52:50 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA00568; Tue, 23 Jan 2001 10:52:38 -0800 (PST) Date: Tue, 23 Jan 2001 10:51:46 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 To: David Spence Cc: Barney Wolff , Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A6DD20B.B387F097@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Simple state machine. I like it. PatC > Actually, both the NAS and the home server have to run a timer. The home > server has to because he's the one who cares and he wants to enforce his > policy. The NAS has to because it is possible that the home server will be > (temporarily) unreachable from the NAS at the time the timeout is to occur. > The NAS has an interest in running the timer because if the home > organization will refuse to pay for a longer session than the timeout > specifies, then the NAS wants to make sure it doesn't provide a longer > session. > > This means that both parties will timeout approximately simultaneously so a > termination collision is likely. No problem. The home server is expecting > an STR in response to its STI, so if it receives the STR generated by the > NAS' timeout, its happy. The rule for the NAS is: ignore an STI received in > STR-sent state. So the NAS avoids sending a second STR. The home server > will send STA in response to STR and everyone is happy. > > Barney Wolff wrote: > > > > I'd say the NAS does it, as it should have the primary timing > > responsibility. The server's timing is to avoid getting stuck in > > a state, and can be quite coarse, or nonexistent if the server > > does not track session state. > > > > If the server had the primary > > timing responsibility, we wouldn't need the session-timout avp at > > all, as it could just decide to terminate the session when it wants > > to. But I think that's a poor use of server cycles. > > > > Barney > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > > Should it be the NAS, or the home server. We need to provide some guidelines > > > to reduce the changes of such messages crossing through the network. > > > > > > PatC > > > > > > > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 14:03:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA27720 for ; Tue, 23 Jan 2001 14:03:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 447895DE51; Tue, 23 Jan 2001 14:00:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 00BB45DE4B; Tue, 23 Jan 2001 14:00:20 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id B68B25DE55 for ; Tue, 23 Jan 2001 14:00:16 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0NJ05g21492; Tue, 23 Jan 2001 14:00:05 -0500 (EST) (envelope-from barney) Date: Tue, 23 Jan 2001 14:00:05 -0500 From: Barney Wolff To: David Spence Cc: Barney Wolff , Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Message-ID: <20010123140004.A21418@mx.databus.com> References: <20010123112933.A20613@mx.databus.com> <20010123132918.A21181@mx.databus.com> <3A6DD20B.B387F097@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A6DD20B.B387F097@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Tue, Jan 23, 2001 at 01:48:43PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk I do not think the home server has to run a fine-grained timer, or any timer at all if it is not doing resource management. It can do fine-grained timing, if it's anal, but we MUST NOT :) make it a MUST. Barney On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote: > Actually, both the NAS and the home server have to run a timer. The home > server has to because he's the one who cares and he wants to enforce his > policy. The NAS has to because it is possible that the home server will be > (temporarily) unreachable from the NAS at the time the timeout is to occur. > The NAS has an interest in running the timer because if the home > organization will refuse to pay for a longer session than the timeout > specifies, then the NAS wants to make sure it doesn't provide a longer > session. > > This means that both parties will timeout approximately simultaneously so a > termination collision is likely. No problem. The home server is expecting > an STR in response to its STI, so if it receives the STR generated by the > NAS' timeout, its happy. The rule for the NAS is: ignore an STI received in > STR-sent state. So the NAS avoids sending a second STR. The home server > will send STA in response to STR and everyone is happy. > > Barney Wolff wrote: > > > > I'd say the NAS does it, as it should have the primary timing > > responsibility. The server's timing is to avoid getting stuck in > > a state, and can be quite coarse, or nonexistent if the server > > does not track session state. > > > > If the server had the primary > > timing responsibility, we wouldn't need the session-timout avp at > > all, as it could just decide to terminate the session when it wants > > to. But I think that's a poor use of server cycles. > > > > Barney > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > > Should it be the NAS, or the home server. We need to provide some guidelines > > > to reduce the changes of such messages crossing through the network. > > > > > > PatC > > > > > > > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 14:06:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA27768 for ; Tue, 23 Jan 2001 14:06:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6BED5DE5D; Tue, 23 Jan 2001 14:04:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 93B2F5DE5B; Tue, 23 Jan 2001 14:04:14 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 55BB95DE55 for ; Tue, 23 Jan 2001 14:04:13 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 2219173; Tue, 23 Jan 2001 14:04:22 -0500 (EST) Message-ID: <3A6DD5C3.A2E2E27A@Interlinknetworks.com> Date: Tue, 23 Jan 2001 14:04:35 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff Cc: Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 References: <20010123112933.A20613@mx.databus.com> <20010123132918.A21181@mx.databus.com> <3A6DD20B.B387F097@Interlinknetworks.com> <20010123140004.A21418@mx.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I'm o.k. with making it a MUST for the NAS and a MAY for the home server. If the protocol is specified as I've proposed, it should work either way. Barney Wolff wrote: > > I do not think the home server has to run a fine-grained timer, > or any timer at all if it is not doing resource management. > It can do fine-grained timing, if it's anal, but we MUST NOT :) > make it a MUST. > > Barney > > On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote: > > Actually, both the NAS and the home server have to run a timer. The home > > server has to because he's the one who cares and he wants to enforce his > > policy. The NAS has to because it is possible that the home server will be > > (temporarily) unreachable from the NAS at the time the timeout is to occur. > > The NAS has an interest in running the timer because if the home > > organization will refuse to pay for a longer session than the timeout > > specifies, then the NAS wants to make sure it doesn't provide a longer > > session. > > > > This means that both parties will timeout approximately simultaneously so a > > termination collision is likely. No problem. The home server is expecting > > an STR in response to its STI, so if it receives the STR generated by the > > NAS' timeout, its happy. The rule for the NAS is: ignore an STI received in > > STR-sent state. So the NAS avoids sending a second STR. The home server > > will send STA in response to STR and everyone is happy. > > > > Barney Wolff wrote: > > > > > > I'd say the NAS does it, as it should have the primary timing > > > responsibility. The server's timing is to avoid getting stuck in > > > a state, and can be quite coarse, or nonexistent if the server > > > does not track session state. > > > > > > If the server had the primary > > > timing responsibility, we wouldn't need the session-timout avp at > > > all, as it could just decide to terminate the session when it wants > > > to. But I think that's a poor use of server cycles. > > > > > > Barney > > > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > > > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > > > Should it be the NAS, or the home server. We need to provide some guidelines > > > > to reduce the changes of such messages crossing through the network. > > > > > > > > PatC > > > > > > > > > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: (734) 821-1203 > > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > > Ann Arbor, MI 48108 > > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 14:07:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA27787 for ; Tue, 23 Jan 2001 14:07:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA3165DE4B; Tue, 23 Jan 2001 14:07:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B86A05DE4A; Tue, 23 Jan 2001 14:07:20 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 932015DE30 for ; Tue, 23 Jan 2001 14:07:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01397; Tue, 23 Jan 2001 11:06:56 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA28188; Tue, 23 Jan 2001 11:06:55 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA00800; Tue, 23 Jan 2001 11:06:40 -0800 (PST) Date: Tue, 23 Jan 2001 11:05:46 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 To: David Spence Cc: Barney Wolff , Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A6DD5C3.A2E2E27A@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Good, so NAS MUST sent STR, home server MAY sent STI. race conditions are handled by the NAS. I'll have text written up later today to represent the session state machine. PatC > I'm o.k. with making it a MUST for the NAS and a MAY for the home server. > If the protocol is specified as I've proposed, it should work either way. > > Barney Wolff wrote: > > > > I do not think the home server has to run a fine-grained timer, > > or any timer at all if it is not doing resource management. > > It can do fine-grained timing, if it's anal, but we MUST NOT :) > > make it a MUST. > > > > Barney > > > > On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote: > > > Actually, both the NAS and the home server have to run a timer. The home > > > server has to because he's the one who cares and he wants to enforce his > > > policy. The NAS has to because it is possible that the home server will be > > > (temporarily) unreachable from the NAS at the time the timeout is to occur. > > > The NAS has an interest in running the timer because if the home > > > organization will refuse to pay for a longer session than the timeout > > > specifies, then the NAS wants to make sure it doesn't provide a longer > > > session. > > > > > > This means that both parties will timeout approximately simultaneously so a > > > termination collision is likely. No problem. The home server is expecting > > > an STR in response to its STI, so if it receives the STR generated by the > > > NAS' timeout, its happy. The rule for the NAS is: ignore an STI received in > > > STR-sent state. So the NAS avoids sending a second STR. The home server > > > will send STA in response to STR and everyone is happy. > > > > > > Barney Wolff wrote: > > > > > > > > I'd say the NAS does it, as it should have the primary timing > > > > responsibility. The server's timing is to avoid getting stuck in > > > > a state, and can be quite coarse, or nonexistent if the server > > > > does not track session state. > > > > > > > > If the server had the primary > > > > timing responsibility, we wouldn't need the session-timout avp at > > > > all, as it could just decide to terminate the session when it wants > > > > to. But I think that's a poor use of server cycles. > > > > > > > > Barney > > > > > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > > > > > Cool, I think we are nearly there. One more question. Who initiates the STR? > > > > > Should it be the NAS, or the home server. We need to provide some guidelines > > > > > to reduce the changes of such messages crossing through the network. > > > > > > > > > > PatC > > > > > > > > > > > > > > > > -- > > > David Spence email: DSpence@Interlinknetworks.com > > > Interlink Networks, Inc. phone: (734) 821-1203 > > > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > > > Ann Arbor, MI 48108 > > > U.S.A. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-bof@merit.edu Tue Jan 23 14:50:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28636 for ; Tue, 23 Jan 2001 14:50:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 137675DED8; Tue, 23 Jan 2001 14:48:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 020335DED5; Tue, 23 Jan 2001 14:48:19 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 765B95DE61 for ; Tue, 23 Jan 2001 14:48:18 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NJmEK26019; Tue, 23 Jan 2001 13:48:14 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NJiYr22662; Tue, 23 Jan 2001 13:44:34 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA19946; Tue, 23 Jan 2001 13:48:11 -0600 (CST) Received: from ericsson.com (busam70.berkeley.us.am.ericsson.se [138.85.159.220]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA12039; Tue, 23 Jan 2001 13:48:08 -0600 (CST) Message-ID: <3A6DE01C.A7794FB5@ericsson.com> Date: Tue, 23 Jan 2001 11:48:44 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: "'aaa-wg@merit.edu'" , Martin.Julien@ece.ericsson.se Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, See comments embedded.... BR, /Tony Pat Calhoun wrote: > > That was my initial understanding until I find out that the Destination-NAI > > AVP was removed from the Base Protocol. Now, I'm wondering how a > > re-authentication message can reach the same Host-Server if there is no > > Destination-NAI AVP in which put the Host-Name AVP of the Home AAA received > > in the first Authentication response? I thought possible to have several > > Home servers for the same realm, but since the Destination-NAI AVP was gone, > > I thought that it would not be possible anymore, unless they all share > > information about the user session. Could someone help me on that? > sigh. Well, first of all the Destination-NAI AVP was never intended to be used as described above, right?!. The Host-Name contains the originating host (i.e. the NAS or the FA) and the Host-Name AVP was copied into the Destination-NAI AVP for the return trip. The Destination-NAI AVP was then used to route the reply message back to the originating host. Correct ? > > > Well I guess in my haste to remove support for different reverse path routing, > I removed an AVP that had additional uses. What additional uses do you recall ? > So, it looks like Destination-NAI > needs to be put back in, but with a much more limited set of functionality. It > will now ONLY be used to identify the host within the domain. The > Routing-Realm AVP is still used to identify the Domain, and once a server > identifies that the message made it to the destination realm, the > Destination-NAI is used to route to a specific host. I'm not sure that I understand why we need this. Is it to allow a NAS or an FA to always target the same home AAA server in case there is more then one? Furthermore, could you please tell me why this is really needed and if so, be a little bit more specific how this should be done. I'm under the assumption that if you have more than one AAA server in the same domain, you would have access to a shared database, thus a re-authentication arriving at a different home AAA server can be handled. Correct? Or is there any reason to argue otherwise? > > > This means that the Resource-Owner-NAI is gone. > > This seems to work for reverse re-auth *and* termination messages. > > Comments? > > PatC From owner-aaa-bof@merit.edu Tue Jan 23 14:58:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28754 for ; Tue, 23 Jan 2001 14:58:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 58DFD5DF3C; Tue, 23 Jan 2001 14:55:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 391225DE91; Tue, 23 Jan 2001 14:55:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 508F45DF32 for ; Tue, 23 Jan 2001 14:55:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01889; Tue, 23 Jan 2001 11:55:45 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA11572; Tue, 23 Jan 2001 11:55:44 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA01693; Tue, 23 Jan 2001 11:55:42 -0800 (PST) Date: Tue, 23 Jan 2001 11:54:51 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: Tony Johansson Cc: Pat Calhoun , "'aaa-wg@merit.edu'" , Martin.Julien@ece.ericsson.se In-Reply-To: "Your message with ID" <3A6DE01C.A7794FB5@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > sigh. > > Well, first of all the Destination-NAI AVP was never intended to be used as > described above, right?!. The Host-Name contains the originating host (i.e. > the NAS or the FA) and the Host-Name AVP was copied into the Destination-NAI > AVP for the return trip. The Destination-NAI AVP was then used to route the > reply message back to the originating host. Correct ? correct, it was used for inter-domain routing. > > > > > > > Well I guess in my haste to remove support for different reverse path routing, > > I removed an AVP that had additional uses. > > What additional uses do you recall ? see below. > > > So, it looks like Destination-NAI > > needs to be put back in, but with a much more limited set of functionality. It > > will now ONLY be used to identify the host within the domain. The > > Routing-Realm AVP is still used to identify the Domain, and once a server > > identifies that the message made it to the destination realm, the > > Destination-NAI is used to route to a specific host. > > I'm not sure that I understand why we need this. Is it to allow a NAS or an > FA to always target the same home AAA server in case there is more then one? > Furthermore, could you please tell me why this is really needed and if so, > be a little bit more specific how this should be done. I'm under the > assumption that if you have more than one AAA server in the same domain, you > would have access to a shared database, thus a re-authentication arriving at > a different home AAA server can be handled. Correct? Or is there any reason > to argue otherwise? There are two uses that I can think of, both of which involve home server initiated messages: - The home server wishes to send an STI to the NAS, to force the session to be disconnected, and - The home server wishes to send a re-auth request to the NAS. Is this clearer? PatC From owner-aaa-bof@merit.edu Tue Jan 23 15:03:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA28910 for ; Tue, 23 Jan 2001 15:03:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D3A15DED4; Tue, 23 Jan 2001 15:01:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0C5835DEB8; Tue, 23 Jan 2001 15:01:15 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BE0225DEB0 for ; Tue, 23 Jan 2001 15:01:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14473; Tue, 23 Jan 2001 12:01:10 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13542; Tue, 23 Jan 2001 12:01:09 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA01774; Tue, 23 Jan 2001 12:01:07 -0800 (PST) Date: Tue, 23 Jan 2001 12:00:16 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: Pat Calhoun Cc: Tony Johansson , "'aaa-wg@merit.edu'" , Martin.Julien@ece.ericsson.se 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 Re-reading this, it isn't that clear that I fully communicated the use of the proposed new AVP. See more below. > > There are two uses that I can think of, both of which involve home server > initiated messages: - The home server wishes to send an STI to the NAS, to > force the session to be disconnected, and - The home server wishes to send a > re-auth request to the NAS. > The existing proxying techniques are still used, and we are not proposing changing these. However, some AVP must be set to identify the actual NAS (or server) within the domain. This new AVP would ONLY be used to identify a NAS (or server) within a domain. PatC From owner-aaa-bof@merit.edu Tue Jan 23 16:06:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00110 for ; Tue, 23 Jan 2001 16:06:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7520B5DD99; Tue, 23 Jan 2001 16:05:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 620905DDFE; Tue, 23 Jan 2001 16:05:50 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id D5A295DD99 for ; Tue, 23 Jan 2001 16:05:48 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NL5lK19214; Tue, 23 Jan 2001 15:05:47 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NL27r11951; Tue, 23 Jan 2001 15:02:07 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA23722; Tue, 23 Jan 2001 15:05:44 -0600 (CST) Received: from ericsson.com (busam57.berkeley.us.am.ericsson.se [138.85.159.207]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA13533; Tue, 23 Jan 2001 15:05:41 -0600 (CST) Message-ID: <3A6DF243.9D280B44@ericsson.com> Date: Tue, 23 Jan 2001 13:06:12 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: "'aaa-wg@merit.edu'" , Martin.Julien@ece.ericsson.se Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, True, for the cases of home server initiated messages, like STI and re-auth request to the NAS, we do need some thing to route the message to the right NAS or FA and the AVP for that is the Resource-Owner-NAI AVP. Correct? If the idea here is only to change the name from Resource-Owner-NAI AVP to Destination-NAI AVP, it is fine with me. Furthermore, just as clarification, if the case is to change the Resource-Owner-NAI AVP to the Destination-NAI AVP it should stated in the text that the Destination-NAI AVP should ONLY be used for messages originated from the AAA server. Correct? BR, /Tony Pat Calhoun wrote: > Re-reading this, it isn't that clear that I fully communicated the use of the > proposed new AVP. See more below. > > > There are two uses that I can think of, both of which involve home server > > initiated messages: - The home server wishes to send an STI to the NAS, to > > force the session to be disconnected, and - The home server wishes to send a > > re-auth request to the NAS. > > > The existing proxying techniques are still used, and we are not proposing > changing these. However, some AVP must be set to identify the actual NAS (or > server) within the domain. This new AVP would ONLY be used to identify a NAS > (or server) within a domain. > > PatC From owner-aaa-bof@merit.edu Tue Jan 23 16:11:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00228 for ; Tue, 23 Jan 2001 16:11:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE58D5DE54; Tue, 23 Jan 2001 16:11:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ADC1B5DE4A; Tue, 23 Jan 2001 16:11:11 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 44DA85DDFE for ; Tue, 23 Jan 2001 16:11:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01991; Tue, 23 Jan 2001 13:11:06 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23434; Tue, 23 Jan 2001 13:11:04 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA02809; Tue, 23 Jan 2001 13:11:02 -0800 (PST) Date: Tue, 23 Jan 2001 13:10:10 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 To: Tony Johansson Cc: Pat Calhoun , "'aaa-wg@merit.edu'" , Martin.Julien@ece.ericsson.se In-Reply-To: "Your message with ID" <3A6DF243.9D280B44@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Hi Pat, > > True, for the cases of home server initiated messages, like STI and re-auth > request to the NAS, we do need some thing to route the message to the right > NAS or FA and the AVP for that is the Resource-Owner-NAI AVP. Correct? If > the idea here is only to change the name from Resource-Owner-NAI AVP to > Destination-NAI AVP, it is fine with me. yes, the issue is that the REsource-Owner-NAI is tied to ST* messages. We need something that can be used with re-auth as well. Destination-NAI is one name we could use. > > Furthermore, just as clarification, if the case is to change the > Resource-Owner-NAI AVP to the Destination-NAI AVP it should stated in the > text that the Destination-NAI AVP should ONLY be used for messages > originated from the AAA server. Correct? Correct. If that is the case, perhaps NAS-NAI is more appropriate. PatC From owner-aaa-bof@merit.edu Tue Jan 23 17:59:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA02009 for ; Tue, 23 Jan 2001 17:59:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F5DD5DDE0; Tue, 23 Jan 2001 17:58:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C61B5DE4A; Tue, 23 Jan 2001 17:58:57 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 27BFD5DDE0 for ; Tue, 23 Jan 2001 17:58:56 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NMwtK01986; Tue, 23 Jan 2001 16:58:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NMtFr10131; Tue, 23 Jan 2001 16:55:15 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29377; Tue, 23 Jan 2001 16:58:53 -0600 (CST) Received: from ericsson.com (busam57.berkeley.us.am.ericsson.se [138.85.159.207]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA15741; Tue, 23 Jan 2001 16:58:50 -0600 (CST) Message-ID: <3A6E0CC6.402CDC47@ericsson.com> Date: Tue, 23 Jan 2001 14:59:18 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: "'aaa-wg@merit.edu'" , Martin.Julien@ece.ericsson.se Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I would prefer Destination-NAI AVP or something similar, thus a more general name, which works well for both a NAS (with re-auth and ST* messages) or an FA (with ST* messages). BR, /Tony Pat Calhoun wrote: > > Hi Pat, > > > > True, for the cases of home server initiated messages, like STI and re-auth > > request to the NAS, we do need some thing to route the message to the right > > NAS or FA and the AVP for that is the Resource-Owner-NAI AVP. Correct? If > > the idea here is only to change the name from Resource-Owner-NAI AVP to > > Destination-NAI AVP, it is fine with me. > > yes, the issue is that the REsource-Owner-NAI is tied to ST* messages. We need > something that can be used with re-auth as well. Destination-NAI is one name > we could use. > > > > > Furthermore, just as clarification, if the case is to change the > > Resource-Owner-NAI AVP to the Destination-NAI AVP it should stated in the > > text that the Destination-NAI AVP should ONLY be used for messages > > originated from the AAA server. Correct? > > Correct. If that is the case, perhaps NAS-NAI is more appropriate. > > PatC -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_ Tony Johansson Mobile Networking Research Ericsson Inc. mobile: +1 510 305 6108 2100 Shattuck Avenue Berkeley, CA, 94704 mailto:tony.johansson@ericsson.com _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_ From owner-aaa-bof@merit.edu Tue Jan 23 19:22:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA03406 for ; Tue, 23 Jan 2001 19:22:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id BAA2C5DE5B; Tue, 23 Jan 2001 19:22:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A9E365DE4A; Tue, 23 Jan 2001 19:22:05 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 89D865DE2B for ; Tue, 23 Jan 2001 19:22:04 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11525 for ; Tue, 23 Jan 2001 16:21:59 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16703 for ; Tue, 23 Jan 2001 16:21:58 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA06541 for ; Tue, 23 Jan 2001 16:21:57 -0800 (PST) Date: Tue, 23 Jan 2001 16:21:05 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: DIAMETER Sessions State Machine To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, At Dave Spence's request, I've put together a state machine that would explain how sessions are created, and terminated, and how the various ST* messages are used. I know that Barney typically doesn't like server internals to be discussed, but Dave thought it would be necessary in the spec. Here is what I've come up with, and I would solicit comments on whether it is considered useful in the base protocol spec (again, this is not new functionality, but rather clarification to ease interoperability). 3.1 State Machine This section contains a finite state machine, representing the life cycle of DIAMETER sessions, and MUST be observed by all DIAMETER implementations. The term Service-Specific below refers to a message defined in a DIAMETER extension (e.g. Mobile IP, NASREQ). State Event Action New State ----- ----- ------ --------- Idle Client or Device Requests send serv. Pending access specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed response Pending Successful Service-Specific Grant Open Authorization response Access received Open Authorization-Lifetime expires send serv. Open specific auth req Open Successful Service-Specific Extend Open Authorization response Access received Open Failed Service-Specific Discon. Cleanup Authorization response user/device received. Open Session-Timeout Expires on send STR Discon NAS Open Session-Timeout Expires on send STI Discon home AAA server Discon STI Received ignore Discon Discon STR Received Discon. Cleanup user/device Discon STA Received Discon. Cleanup user/device When the Cleanup action is invoked, the DIAMETER node SHOULD attempt to release all resources for the particular session. From owner-aaa-bof@merit.edu Tue Jan 23 19:51:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA03938 for ; Tue, 23 Jan 2001 19:51:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 581EB5DE5E; Tue, 23 Jan 2001 19:51:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 463165DE4A; Tue, 23 Jan 2001 19:51:09 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 9C6795DE2B for ; Tue, 23 Jan 2001 19:51:07 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0O0p5I23140; Tue, 23 Jan 2001 19:51:05 -0500 (EST) (envelope-from barney) Date: Tue, 23 Jan 2001 19:51:05 -0500 From: Barney Wolff To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER Sessions State Machine Message-ID: <20010123195104.A23027@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 23, 2001 at 04:21:05PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk A few comments. 1. I have no problem with the state machine as it describes required externally-visible actions. I'd put releasing resources as "may wish to" (note lower case) rather than SHOULD, and Cleanup as an action, not a state, but I won't be fanatic about it. 2. A state machine description that does not include all combinations of events x states is incomplete. For example, it is valid (for the NAS) to receive STI in Open, and action is required. Some other combinations are not valid, but something needs to be specified, especially if a state transition should result. 3. If I'm not mistaken you've overloaded "auth" as both authentication and authorization. I sure wish we had terms that could not be so confounded. 4. Role-independent description makes me a little nervous. A NAS should certainly treat an incoming access-request quite differently than a server, and having one FSM description buries this fundamental difference in the notion of "successfully processed". Barney On Tue, Jan 23, 2001 at 04:21:05PM -0800, Pat Calhoun wrote: > All, > > At Dave Spence's request, I've put together a state machine that would explain > how sessions are created, and terminated, and how the various ST* messages are > used. I know that Barney typically doesn't like server internals to be > discussed, but Dave thought it would be necessary in the spec. > > Here is what I've come up with, and I would solicit comments on whether it is > considered useful in the base protocol spec (again, this is not new > functionality, but rather clarification to ease interoperability). > > 3.1 State Machine > > This section contains a finite state machine, representing the life > cycle of DIAMETER sessions, and MUST be observed by all DIAMETER > implementations. The term Service-Specific below refers to a message > defined in a DIAMETER extension (e.g. Mobile IP, NASREQ). > > State Event Action New State > ----- ----- ------ --------- > Idle Client or Device Requests send serv. Pending > access specific > auth req > > Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed response > > Pending Successful Service-Specific Grant Open > Authorization response Access > received > > Open Authorization-Lifetime expires send serv. Open > specific > auth req > > Open Successful Service-Specific Extend Open > Authorization response Access > received > > Open Failed Service-Specific Discon. Cleanup > Authorization response user/device > received. > > Open Session-Timeout Expires on send STR Discon > NAS > > Open Session-Timeout Expires on send STI Discon > home AAA server > > Discon STI Received ignore Discon > > Discon STR Received Discon. Cleanup > user/device > > Discon STA Received Discon. Cleanup > user/device > > When the Cleanup action is invoked, the DIAMETER node SHOULD attempt > to release all resources for the particular session. > > From owner-aaa-bof@merit.edu Tue Jan 23 20:04:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA04173 for ; Tue, 23 Jan 2001 20:04:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 669F65DE2B; Tue, 23 Jan 2001 20:02:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 503715DE6D; Tue, 23 Jan 2001 20:02:32 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id DFC685DE2B for ; Tue, 23 Jan 2001 20:02:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22567; Tue, 23 Jan 2001 17:02:26 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA24137; Tue, 23 Jan 2001 16:56:35 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA07435; Tue, 23 Jan 2001 16:56:29 -0800 (PST) Date: Tue, 23 Jan 2001 16:55:37 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: DIAMETER Sessions State Machine To: Barney Wolff Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010123195104.A23027@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > A few comments. > > 1. I have no problem with the state machine as it > describes required externally-visible actions. I'd put > releasing resources as "may wish to" (note lower case) > rather than SHOULD, and Cleanup as an action, not a state, > but I won't be fanatic about it. check. SHOULD->MAY, and cleanup as an action. > > 2. A state machine description that does not include all > combinations of events x states is incomplete. For example, > it is valid (for the NAS) to receive STI in Open, and action > is required. Some other combinations are not valid, but > something needs to be specified, especially if a state > transition should result. OOps, missed the STI :( I do not see any other valid combinations, so perhaps a statement that anything outside the state machine is an error (as opposed to listing every possible error condition)? > > 3. If I'm not mistaken you've overloaded "auth" as both > authentication and authorization. I sure wish we had > terms that could not be so confounded. Not really. I see authorization as granting access. Authentication is a means towards authorization (in some cases). > > 4. Role-independent description makes me a little nervous. > A NAS should certainly treat an incoming access-request > quite differently than a server, and having one FSM > description buries this fundamental difference in the > notion of "successfully processed". I hated this one as well, but it was the ONLY line that was NAS specific. I will look at changing it so it is cleaner, but I had to have two (nearly identical) state machines. Thanks, PatC > > Barney > > On Tue, Jan 23, 2001 at 04:21:05PM -0800, Pat Calhoun wrote: > > All, > > > > At Dave Spence's request, I've put together a state machine that would explain > > how sessions are created, and terminated, and how the various ST* messages are > > used. I know that Barney typically doesn't like server internals to be > > discussed, but Dave thought it would be necessary in the spec. > > > > Here is what I've come up with, and I would solicit comments on whether it is > > considered useful in the base protocol spec (again, this is not new > > functionality, but rather clarification to ease interoperability). > > > > 3.1 State Machine > > > > This section contains a finite state machine, representing the life > > cycle of DIAMETER sessions, and MUST be observed by all DIAMETER > > implementations. The term Service-Specific below refers to a message > > defined in a DIAMETER extension (e.g. Mobile IP, NASREQ). > > > > State Event Action New State > > ----- ----- ------ --------- > > Idle Client or Device Requests send serv. Pending > > access specific > > auth req > > > > Idle Service-Specific authorization send serv. Open > > request received, and specific > > successfully processed response > > > > Pending Successful Service-Specific Grant Open > > Authorization response Access > > received > > > > Open Authorization-Lifetime expires send serv. Open > > specific > > auth req > > > > Open Successful Service-Specific Extend Open > > Authorization response Access > > received > > > > Open Failed Service-Specific Discon. Cleanup > > Authorization response user/device > > received. > > > > Open Session-Timeout Expires on send STR Discon > > NAS > > > > Open Session-Timeout Expires on send STI Discon > > home AAA server > > > > Discon STI Received ignore Discon > > > > Discon STR Received Discon. Cleanup > > user/device > > > > Discon STA Received Discon. Cleanup > > user/device > > > > When the Cleanup action is invoked, the DIAMETER node SHOULD attempt > > to release all resources for the particular session. > > > > From owner-aaa-bof@merit.edu Wed Jan 24 09:04:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16315 for ; Wed, 24 Jan 2001 09:04:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 61FC15DE47; Wed, 24 Jan 2001 09:03:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49F895DEA0; Wed, 24 Jan 2001 09:03:26 -0500 (EST) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by segue.merit.edu (Postfix) with ESMTP id 9A8665DE47 for ; Wed, 24 Jan 2001 09:03:22 -0500 (EST) Received: from oleane (dyn-1-1-051.Vin.dialup.oleane.fr [195.25.4.51]) by smtp1.cluster.oleane.net with SMTP id f0OE3H625239 for ; Wed, 24 Jan 2001 15:03:18 +0100 (CET) Message-ID: <005301c0860e$8bbda6a0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: [AAA-WG]: IPCN '01 conference Date: Wed, 24 Jan 2001 15:04:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C08616.ECF29FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C08616.ECF29FE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The request for proposals dead line for the IPCN '01 conference = (IP-based Cellular Networks) has been extended to February 15th. Please get more details at: http://www.upperside.fr/baipcn2001.htm ------=_NextPart_000_0050_01C08616.ECF29FE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The request for proposals dead line = for the IPCN=20 '01 conference (IP-based Cellular Networks) has been = extended=20 to February 15th.
Please get more details = at:
http://www.upperside.fr/b= aipcn2001.htm
 
------=_NextPart_000_0050_01C08616.ECF29FE0-- From owner-aaa-bof@merit.edu Wed Jan 24 09:07:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16341 for ; Wed, 24 Jan 2001 09:07:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 32C405DDD3; Wed, 24 Jan 2001 09:06:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20EF15DDD2; Wed, 24 Jan 2001 09:06:57 -0500 (EST) Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70]) by segue.merit.edu (Postfix) with ESMTP id 902945DDD3 for ; Wed, 24 Jan 2001 09:06:55 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14LQZS-0002kI-00; Wed, 24 Jan 2001 15:06:46 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Peter Lewis" Cc: , IETF Secretariat Subject: Re: [AAA-WG]: IPCN '01 conference References: <005301c0860e$8bbda6a0$8001a8c0@oleane.com> Message-Id: Date: Wed, 24 Jan 2001 15:06:46 +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk > The request for proposals dead line for the IPCN '01 conference (IP-based Cellular Networks) has been extended to February 15th. > Please get more details at: > http://www.upperside.fr/baipcn2001.htm will the list manager please block future postings from this low-life slimeball spammer? thank you. randy, ad hat on From owner-aaa-bof@merit.edu Wed Jan 24 09:22:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16683 for ; Wed, 24 Jan 2001 09:22:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 800505DDD2; Wed, 24 Jan 2001 09:22:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 682FA5DDDA; Wed, 24 Jan 2001 09:22:16 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [195.42.212.161]) by segue.merit.edu (Postfix) with ESMTP id A72855DDD2 for ; Wed, 24 Jan 2001 09:22:14 -0500 (EST) Received: from fredrikj (c38.local.ipunplugged.com [192.168.4.237]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA05753; Wed, 24 Jan 2001 15:22:58 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt Date: Wed, 24 Jan 2001 15:24:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, One down one to go :-) Still a typo in section 8.2. The command code value for DRI should be 257. /Fredrik >> Hi >> >> Found a type in section 8.2. The Command Codes that are specified within >> this specification should be 257, 259, 274-276 >> Compare section 8.2 with 2.1 > >check. > >Thanks, > >PatC > From owner-aaa-bof@merit.edu Wed Jan 24 10:48:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA18735 for ; Wed, 24 Jan 2001 10:48:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 489125DEB0; Wed, 24 Jan 2001 10:46:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2BC825DED6; Wed, 24 Jan 2001 10:46:10 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BDC745DEB0 for ; Wed, 24 Jan 2001 10:46:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28515 for ; Wed, 24 Jan 2001 07:46:08 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12705 for ; Wed, 24 Jan 2001 07:46:04 -0800 (PST) Received: from cinnamon (cinnamon [129.146.122.100]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21150 for ; Wed, 24 Jan 2001 07:46:06 -0800 (PST) Date: Wed, 24 Jan 2001 07:45:14 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: New proposed text for Destination-NAI To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, As discussed in the past couple of days, some mechanism is required for STI and other server initiated re-auth messages to find its way to the proper NAS. The following text is what I would propose in the next I-D: Comments (please!), PatC ---- 6.8 Finding a Target NAS within a Domain The DIAMETER protocol supports unsolicited server initiated messages. However, when such messages are transmitted, they have a specific target Network Access Server (NAS) in mind. Unsolicited server initiated messages are unique in that they contain the Destination- NAI AVP. Routing of such messages follow the same set of guidelines described in section 6.0, with one exception. When a proxy server has determined that a message, which includes the Destination-NAI AVP, has reached its target realm, the Destination-NAI AVP is used to identify the actual NAS the message should be forwarded to. 6.8.1 Destination-NAI AVP The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString, and contains the NAI [8] of the intended recipient of the message. This AVP MUST be present in all unsolicited server initiated messages. From owner-aaa-bof@merit.edu Thu Jan 25 06:04:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA12707 for ; Thu, 25 Jan 2001 06:04:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id C8A7E5DD8E; Thu, 25 Jan 2001 06:02:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A79715DE02; Thu, 25 Jan 2001 06:02:44 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 48DB25DD8E for ; Thu, 25 Jan 2001 06:02:42 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0PB2eC01852 for ; Thu, 25 Jan 2001 12:02:41 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Jan 25 12:02:46 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 25 Jan 2001 12:02:39 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE71@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "'DSpence@Interlinknetworks.com'" , "'aaa-wg@merit.edu'" Cc: "'barney@databus.com'" Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Date: Thu, 25 Jan 2001 12:02:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id GAA12707 Hi again, Sorry, I could not be part of yesterday´s discussion, but I'm very happy with the outcome. See enclosed comments. Martin > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Tuesday, January 23, 2001 6:55 PM > > > > > I also have a comment on the idea of including an > Extension-ID AVP in STRs > > and STIs. I can understand the desire to be able to > terminate subsessions > > of a complex session, but DIAMETER doesn't really support > subsessions. I > > can also understand the need to free some resources within > a session without > > terminating the entire session. But to do that, you need > real resource > > management, and DIAMETER doesn't do that either. I don't > think trying to do > > pseudo-resouce management through the use of the > Extension-ID AVP is a > > particularly good idea. The Extension-ID does not really indicate > > resources, nor does it precisely indicate applications > either. Instead it > > simply indicates which subsets of DIAMETER are being used > in the protocol > > exchange. So what would it mean if a server receives an > STR (or STI) > > specifying some Session-ID and the NASREQ Extension-ID, but not the > > Strong-Crypto Extension-ID which was also used in > establishing the session? > > Or if a server receives an STR specifying the Accounting > Extension-ID but > > not the NASREQ Extension-ID (although maybe we've decided to include > > accounting in the service extensions)? > > Good argument against extension ID in STRs. > > > > > Anyway, I think if we want to do resource management, then > we should figure > > out how to do resource management and not try to slap > together a quick fix > > that uses the wrong data element for the wrong purpose. > > ok, that works for me as well, since it is the easiest (both > in terms of > documentation as well as implementation). > > PatC > > I think you brought a very interesting point and I totally agree with you. IMHO, we should probably think of a well-defined way of doing resource mgmt before we go further on this discussion. So we should use the STR/STA and STI messages to simply release the user session, which automatically means all resources owned by the session, right? That's simple enough for now. I will try to see what we should/could do for resource mgmt in another thread of this ML. Martin From owner-aaa-bof@merit.edu Thu Jan 25 07:33:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA14195 for ; Thu, 25 Jan 2001 07:33:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A39495DE10; Thu, 25 Jan 2001 07:30:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CD1205DE1B; Thu, 25 Jan 2001 07:30:19 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 6A2A85DE10 for ; Thu, 25 Jan 2001 07:30:14 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0PCUDC08399 for ; Thu, 25 Jan 2001 13:30:13 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Jan 25 13:30:19 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 25 Jan 2001 13:30:12 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE72@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Tony Johansson'" , Pat Calhoun , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Date: Thu, 25 Jan 2001 13:29:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Tony and Pat, I would like to know why we can not use a more simple routing scheme based on Destination-NAI AVP (let's call it like that for now), to route the packet directly to the destination server, which could either be a NAS or an AAAH? The format of the Destination-NAI AVP could be something like "server1@realm.com", which could be used by the proxies to route messages to their final destination domain, and then to a particular server within the domain. So the order of priority for routing would be something like: (1) Destination-NAI, (2) Routing-Realm. I assumed that the originating servers should always use a Routing-Realm AVP (a default one in the case no User-Name AVP is available) or a Destination-NAI AVP (possibly extracted from the User-Name AVP like "@realm.com" with no server name, only domain) when sending messages. I assumed that the Routing-Realm AVP was only used when we did not really know where the message should go because the User-Name AVP was not yet available? I ! think it would simplify the routing scheme. Would that make any sense? The problem with the Routing-Realm AVP being used as the highest priority routing scheme is that I don't really know what will happen on the different proxies, since they might change it. Even tough we can assume that if more than one server is part of a AAAH domain and they would all share the same DB for user info, I don't know if it would be desirable to also put user session information in the DB in the case that messages from the access device (NAS) would need to send a STR to its very particular AAAH server. Then, the message could get routed to another server within the domain, that does not have access to the memory resident user session info. It remains the responsibility of the domain to use the "server1" part of the "server1@realm.com" address as it wishes, which should not be a problem if user sessions are shared among AAAH servers for load balancing and 100% availability. This solution would be more generic, which I think you like. Basically, I liked to idea behind the Resource-Owner AVP routing concept very much and think it is good, but I thought it also needed to be extended to handle both-ways messaging. BR, Martin > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Tuesday, January 23, 2001 11:59 PM > To: Pat Calhoun > Cc: 'aaa-wg@merit.edu'; Martin.Julien@ece.ericsson.se > Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments > Section 3.0 > > > I would prefer Destination-NAI AVP or something similar, thus > a more general name, > which works well for both a NAS (with re-auth and ST* > messages) or an FA (with ST* > messages). > > BR, > > /Tony > > Pat Calhoun wrote: > > > > Hi Pat, > > > > > > True, for the cases of home server initiated messages, > like STI and re-auth > > > request to the NAS, we do need some thing to route the > message to the right > > > NAS or FA and the AVP for that is the Resource-Owner-NAI > AVP. Correct? If > > > the idea here is only to change the name from > Resource-Owner-NAI AVP to > > > Destination-NAI AVP, it is fine with me. > > > > yes, the issue is that the REsource-Owner-NAI is tied to > ST* messages. We need > > something that can be used with re-auth as well. > Destination-NAI is one name > > we could use. > > > > > > > > Furthermore, just as clarification, if the case is to change the > > > Resource-Owner-NAI AVP to the Destination-NAI AVP it > should stated in the > > > text that the Destination-NAI AVP should ONLY be used for messages > > > originated from the AAA server. Correct? > > > > Correct. If that is the case, perhaps NAS-NAI is more appropriate. > > > > PatC > > -- > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > _/_/_/_/_ > > Tony Johansson > Mobile Networking Research > Ericsson Inc. mobile: +1 510 305 6108 > 2100 Shattuck Avenue > Berkeley, CA, 94704 > mailto:tony.johansson@ericsson.com > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > _/_/_/_/_ > > > From owner-aaa-bof@merit.edu Thu Jan 25 08:29:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA15159 for ; Thu, 25 Jan 2001 08:29:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id C80CA5DE1B; Thu, 25 Jan 2001 08:29:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B70F05DDE1; Thu, 25 Jan 2001 08:29:15 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D5E8A5DDB0 for ; Thu, 25 Jan 2001 08:29:14 -0500 (EST) Received: from Interlinknetworks.com (slip139-92-165-12.zwo.nl.ibm.net [139.92.165.12]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 1066B72; Thu, 25 Jan 2001 08:29:22 -0500 (EST) Message-ID: <3A700AD3.52D4668D@Interlinknetworks.com> Date: Thu, 25 Jan 2001 00:15:31 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: New proposed text for Destination-NAI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat Calhoun wrote: > > All, > > As discussed in the past couple of days, some mechanism is required for STI > and other server initiated re-auth messages to find its way to the proper NAS. > The following text is what I would propose in the next I-D: > > Comments (please!), Well, for starters, I would suggest replacing the terms "Network Access Server (NAS)" and "NAS" where they appear with the term "DIAMETER client" as defined in section 1.0. This is, after all, the base protocol -- not the NASREQ extension. Next, I think it might help to say something about how an AAA server would know what value to assign to the Destination-NAI AVP. Presumably it should be set to the value of the Host-Name AVP that appeared in the message from the DIAMETER client that established the session. Correct? > > PatC > ---- > 6.8 Finding a Target NAS within a Domain > > The DIAMETER protocol supports unsolicited server initiated messages. > However, when such messages are transmitted, they have a specific > target Network Access Server (NAS) in mind. Unsolicited server > initiated messages are unique in that they contain the Destination- > NAI AVP. Routing of such messages follow the same set of guidelines > described in section 6.0, with one exception. When a proxy server has > determined that a message, which includes the Destination-NAI AVP, > has reached its target realm, the Destination-NAI AVP is used to > identify the actual NAS the message should be forwarded to. > > 6.8.1 Destination-NAI AVP > > The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString, > and contains the NAI [8] of the intended recipient of the message. > This AVP MUST be present in all unsolicited server initiated > messages. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Thu Jan 25 09:38:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16213 for ; Thu, 25 Jan 2001 09:38:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 498B05DEE5; Thu, 25 Jan 2001 09:35:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2EDD65DED2; Thu, 25 Jan 2001 09:35:18 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 0FCEC5DEEE for ; Thu, 25 Jan 2001 09:35:14 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0PEZCC15215 for ; Thu, 25 Jan 2001 15:35:12 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 25 15:36:05 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 25 Jan 2001 15:35:12 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FE74@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , David Spence Cc: Barney Wolff , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 Date: Thu, 25 Jan 2001 15:35:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, I like David's solution, since it seems to handle the case where the Session-Timeout is reached in the AAAH server, as well as the one where a particular policy in the AAAH server triggers a user session termination in the DIAMETER client and server. So, if I understand correctly, it seems that the sending of a STI by the AAAH server to a DIAMETER client (access device) could mean for the client that it could send any other types of DIAMETER message it wants to re-authorize the session or example, not only a STR, right? For example, if a policy in the AAAH triggers a STI, then the DIAMETER client could possibly send a STR to terminate officially the user session or send a re-authorization message to re-authorize the session until the next Session-Timeout. That would mean that the AAAH should expect something back after sending an STI, and should have a local timeout to handle a response from the DIAMETER client to terminate the user session or re-authorize it, for example. I! believe it is important for an AAA server to enforce policies, which, IMHO, is one of its major role, right? However, in the case where the DIAMETER client would not answer a STI, it is not clear to me yet what the AAAH should do exactly, especially with regards to accouting. I think this idea is getting closer to the one I had when we discussed very briefly about the Session-Timeout AVP and the Authorization-Lifetime AVP. As discussed above, we could be using the Session-Timeout AVP for Re-Authentication/Re-Authorization instead of using a new Authorization-Lifetime AVP. However, maybe a small difference would be that the Authorization-Lifetime AVP would be used to trigger a Re-Authentication/Re-Authorization message from the DIAMETER client automatically as an optimization of the NASREQ extension, and the Session-Timeout AVP as a generic request to a DIAMETER client for information about what it wants to do now about the user session: terminate, re-authorize, or whatever would calm down the policies on the AAAH server. BR, Martin > -----Original Message----- > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] > Sent: Tuesday, January 23, 2001 8:06 PM > To: David Spence > Cc: Barney Wolff; Pat Calhoun; Martin Julien (ECE); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments > Sec tion 3.0 > > > Good, so NAS MUST sent STR, home server MAY sent STI. race > conditions are > handled by the NAS. > > I'll have text written up later today to represent the > session state machine. > > PatC > > I'm o.k. with making it a MUST for the NAS and a MAY for > the home server. > > If the protocol is specified as I've proposed, it should > work either way. > > > > Barney Wolff wrote: > > > > > > I do not think the home server has to run a fine-grained timer, > > > or any timer at all if it is not doing resource management. > > > It can do fine-grained timing, if it's anal, but we MUST NOT :) > > > make it a MUST. > > > > > > Barney > > > > > > On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote: > > > > Actually, both the NAS and the home server have to run > a timer. The home > > > > server has to because he's the one who cares and he > wants to enforce his > > > > policy. The NAS has to because it is possible that the > home server will be > > > > (temporarily) unreachable from the NAS at the time the > timeout is to occur. > > > > The NAS has an interest in running the timer because if the home > > > > organization will refuse to pay for a longer session > than the timeout > > > > specifies, then the NAS wants to make sure it doesn't > provide a longer > > > > session. > > > > > > > > This means that both parties will timeout approximately > simultaneously so a > > > > termination collision is likely. No problem. The home > server is expecting > > > > an STR in response to its STI, so if it receives the > STR generated by the > > > > NAS' timeout, its happy. The rule for the NAS is: > ignore an STI received in > > > > STR-sent state. So the NAS avoids sending a second > STR. The home server > > > > will send STA in response to STR and everyone is happy. > > > > > > > > Barney Wolff wrote: > > > > > > > > > > I'd say the NAS does it, as it should have the primary timing > > > > > responsibility. The server's timing is to avoid > getting stuck in > > > > > a state, and can be quite coarse, or nonexistent if the server > > > > > does not track session state. > > > > > > > > > > If the server had the primary > > > > > timing responsibility, we wouldn't need the > session-timout avp at > > > > > all, as it could just decide to terminate the session > when it wants > > > > > to. But I think that's a poor use of server cycles. > > > > > > > > > > Barney > > > > > > > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote: > > > > > > Cool, I think we are nearly there. One more > question. Who initiates the STR? > > > > > > Should it be the NAS, or the home server. We need > to provide some guidelines > > > > > > to reduce the changes of such messages crossing > through the network. > > > > > > > > > > > > PatC > > > > > > > > > > > > > > > > > > > > -- > > > > David Spence email: > DSpence@Interlinknetworks.com > > > > Interlink Networks, Inc. phone: (734) 821-1203 > > > > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > > > > Ann Arbor, MI 48108 > > > > U.S.A. > > > > -- > > David Spence email: > DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: (734) 821-1203 > > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > > Ann Arbor, MI 48108 > > U.S.A. > > From owner-aaa-bof@merit.edu Thu Jan 25 10:33:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17535 for ; Thu, 25 Jan 2001 10:33:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8302A5DEE7; Thu, 25 Jan 2001 10:31:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6FAE85DEE6; Thu, 25 Jan 2001 10:31:08 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1F3C05DED7 for ; Thu, 25 Jan 2001 10:31:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03886; Thu, 25 Jan 2001 07:31:01 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03694; Thu, 25 Jan 2001 07:31:01 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12616; Thu, 25 Jan 2001 07:30:55 -0800 (PST) Date: Thu, 25 Jan 2001 07:30:55 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0 To: "Martin Julien (ECE)" Cc: "'Tony Johansson'" , Pat Calhoun , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE72@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Martin, Thanks for the comment. I understand your concern, but from what I've heard on this list is that people do not want to tie users to a particular AAA home server (anyone, correct me if I am wrong). So, the Destination-NAI is (sort-of) the equivalent of the User-Name AVP, but in the reverse direction. When a message is destined for the home AAA server, the User-name is used to identify the home network. For messages directed towards the NAS, the Destionation-NAI is used. [now that I think of it, I am not sure this is clearly stated in the I-D]. The destination-NAI is slightly different since it also encodes the host name to which the message must be forwarded to. Again, if people really want to tie users to a particular AAA server, then we can relax the Destionation-NAI rules. Comments? PatC > Hi Tony and Pat, > > I would like to know why we can not use a more simple routing scheme based > on Destination-NAI AVP (let's call it like that for now), to route the > packet directly to the destination server, which could either be a NAS or an > AAAH? The format of the Destination-NAI AVP could be something like > "server1@realm.com", which could be used by the proxies to route messages to > their final destination domain, and then to a particular server within the > domain. So the order of priority for routing would be something like: (1) > Destination-NAI, (2) Routing-Realm. I assumed that the originating servers > should always use a Routing-Realm AVP (a default one in the case no > User-Name AVP is available) or a Destination-NAI AVP (possibly extracted > from the User-Name AVP like "@realm.com" with no server name, only domain) > when sending messages. I assumed that the Routing-Realm AVP was only used > when we did not really know where the message should go because the > User-Name AVP was not yet available? I ! think it would simplify the routing > scheme. Would that make any sense? The problem with the Routing-Realm AVP > being used as the highest priority routing scheme is that I don't really > know what will happen on the different proxies, since they might change it. > > Even tough we can assume that if more than one server is part of a AAAH > domain and they would all share the same DB for user info, I don't know if > it would be desirable to also put user session information in the DB in the > case that messages from the access device (NAS) would need to send a STR to > its very particular AAAH server. Then, the message could get routed to > another server within the domain, that does not have access to the memory > resident user session info. It remains the responsibility of the domain to > use the "server1" part of the "server1@realm.com" address as it wishes, > which should not be a problem if user sessions are shared among AAAH servers > for load balancing and 100% availability. This solution would be more > generic, which I think you like. > > Basically, I liked to idea behind the Resource-Owner AVP routing concept > very much and think it is good, but I thought it also needed to be extended > to handle both-ways messaging. > > BR, > Martin > > > -----Original Message----- > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > > Sent: Tuesday, January 23, 2001 11:59 PM > > To: Pat Calhoun > > Cc: 'aaa-wg@merit.edu'; Martin.Julien@ece.ericsson.se > > Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments > > Section 3.0 > > > > > > I would prefer Destination-NAI AVP or something similar, thus > > a more general name, > > which works well for both a NAS (with re-auth and ST* > > messages) or an FA (with ST* > > messages). > > > > BR, > > > > /Tony > > > > Pat Calhoun wrote: > > > > > > Hi Pat, > > > > > > > > True, for the cases of home server initiated messages, > > like STI and re-auth > > > > request to the NAS, we do need some thing to route the > > message to the right > > > > NAS or FA and the AVP for that is the Resource-Owner-NAI > > AVP. Correct? If > > > > the idea here is only to change the name from > > Resource-Owner-NAI AVP to > > > > Destination-NAI AVP, it is fine with me. > > > > > > yes, the issue is that the REsource-Owner-NAI is tied to > > ST* messages. We need > > > something that can be used with re-auth as well. > > Destination-NAI is one name > > > we could use. > > > > > > > > > > > Furthermore, just as clarification, if the case is to change the > > > > Resource-Owner-NAI AVP to the Destination-NAI AVP it > > should stated in the > > > > text that the Destination-NAI AVP should ONLY be used for messages > > > > originated from the AAA server. Correct? > > > > > > Correct. If that is the case, perhaps NAS-NAI is more appropriate. > > > > > > PatC > > > > -- > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > _/_/_/_/_ > > > > Tony Johansson > > Mobile Networking Research > > Ericsson Inc. mobile: +1 510 305 6108 > > 2100 Shattuck Avenue > > Berkeley, CA, 94704 > > mailto:tony.johansson@ericsson.com > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > _/_/_/_/_ > > > > > > From owner-aaa-bof@merit.edu Thu Jan 25 10:34:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17559 for ; Thu, 25 Jan 2001 10:34:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 776EB5DEBD; Thu, 25 Jan 2001 10:32:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 552A65DEE3; Thu, 25 Jan 2001 10:32:55 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 12E4C5DEBD for ; Thu, 25 Jan 2001 10:32:54 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04518; Thu, 25 Jan 2001 07:32:51 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04122; Thu, 25 Jan 2001 07:32:50 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12643; Thu, 25 Jan 2001 07:32:48 -0800 (PST) Date: Thu, 25 Jan 2001 07:32:48 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: New proposed text for Destination-NAI To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A700AD3.52D4668D@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Dave, as usual :), you are correct on both points. I will modify the text accordingly. Thanks, PatC ---- > Pat Calhoun wrote: > > > > All, > > > > As discussed in the past couple of days, some mechanism is required for STI > > and other server initiated re-auth messages to find its way to the proper NAS. > > The following text is what I would propose in the next I-D: > > > > Comments (please!), > > Well, for starters, I would suggest replacing the terms "Network Access > Server (NAS)" and "NAS" where they appear with the term "DIAMETER client" as > defined in section 1.0. This is, after all, the base protocol -- not the > NASREQ extension. > > Next, I think it might help to say something about how an AAA server would > know what value to assign to the Destination-NAI AVP. Presumably it should > be set to the value of the Host-Name AVP that appeared in the message from > the DIAMETER client that established the session. Correct? > > > > > PatC > > ---- > > 6.8 Finding a Target NAS within a Domain > > > > The DIAMETER protocol supports unsolicited server initiated messages. > > However, when such messages are transmitted, they have a specific > > target Network Access Server (NAS) in mind. Unsolicited server > > initiated messages are unique in that they contain the Destination- > > NAI AVP. Routing of such messages follow the same set of guidelines > > described in section 6.0, with one exception. When a proxy server has > > determined that a message, which includes the Destination-NAI AVP, > > has reached its target realm, the Destination-NAI AVP is used to > > identify the actual NAS the message should be forwarded to. > > > > 6.8.1 Destination-NAI AVP > > > > The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString, > > and contains the NAI [8] of the intended recipient of the message. > > This AVP MUST be present in all unsolicited server initiated > > messages. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. > From owner-aaa-bof@merit.edu Thu Jan 25 14:37:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23590 for ; Thu, 25 Jan 2001 14:37:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id D78DF5DEEB; Thu, 25 Jan 2001 14:37:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E4645DE40; Thu, 25 Jan 2001 14:37:06 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 034FC5DE40 for ; Thu, 25 Jan 2001 14:37:03 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0PJWdR02816 for ; Thu, 25 Jan 2001 11:32:39 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts Date: Thu, 25 Jan 2001 11:37:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk The RADIUS RFCs contain a table at the end, detailing which AVPs can and cannot be included in each message. The current DIAMETER drafts have not included such information, effectively leaving the syntax of DIAMETER messages undefined. We need to fix this. The question is how. Erik Guttman has proposed some fixes to the BNF format used in the existing specs, in order to clarify the issue. This is a request for discussion on whether these proposed changes should be applied to the documents or whether another approach should be taken. If we do not hear objections to the changes by Friday, February 2, 2001 then the changes will be incorporated into the DIAMETER specs. From owner-aaa-bof@merit.edu Thu Jan 25 14:48:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA23882 for ; Thu, 25 Jan 2001 14:48:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 78BF15DEDC; Thu, 25 Jan 2001 14:44:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE4A25DEEA; Thu, 25 Jan 2001 14:44:36 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BB26C5DEDC for ; Thu, 25 Jan 2001 14:44:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24496; Thu, 25 Jan 2001 11:44:01 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25839; Thu, 25 Jan 2001 11:43:56 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA16500; Thu, 25 Jan 2001 11:43:41 -0800 (PST) Date: Thu, 25 Jan 2001 11:43:42 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts To: Bernard Aboba Cc: "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 > The RADIUS RFCs contain a table at the end, detailing which > AVPs can and cannot be included in each message. The current > DIAMETER drafts have not included such information, > effectively leaving the syntax of DIAMETER messages > undefined. > > We need to fix this. The question is how. Erik Guttman > has proposed some fixes to the BNF format used in > the existing specs, in order to clarify the issue. > > This is a request for discussion on whether these > proposed changes should be applied to the documents > or whether another approach should be taken. > > If we do not hear objections to the changes by > Friday, February 2, 2001 then the changes will > be incorporated into the DIAMETER specs. > Just to refresh everyone's memory, Here is the proposed format definition: 2.2 Command Code Message Definitions All DIAMETER Command Code MUST include a corresponding ABNF specification, which is used to define the AVPs that MUST and MAY be present. The following format is used in the definition: command-def = command-name "::=" diameter-message diameter-name = ALPHA *(ALPHA / DIGIT / "-") command-name = diameter-name ; The command-name has to be Command name, ; defined in the base or extended DIAMETER ; specifications. diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] header = "" fixed = [qual] "<" avp-spec ">" required = [qual] "{" avp-spec "}" optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. qual = [min] "*" [max] ; See ABNF conventions, RFC 2234 section 3.6. ; The absence of any qualifiers implies that one ; and only one such AVP MUST be present. ; ; NOTE: "[" and "]" have a different meaning ; than in ABNF (see the optional rule, above). ; These braces cannot be used to express an ; optional fixed rules (such as an optional ; ICV at the end.) To do this, the convention ; is '0*1fixed'. min = 1*DIGIT ; The minimum number of times the element may ; be present. max = 1*DIGIT ; The maximum number of times the element may ; be present. avp-spec = diameter-name ; The avp-spec has to be an AVP Name, defined ; in the base or extended DIAMETER ; specifications. avp-name = avp-spec | "AVP" ; The string "AVP" stands for *any* arbitrary ; AVP Name, which does not conflict with the ; required or fixed position AVPs defined in ; the command code definition. The following is a definition of a fictitious command code: Example-Command ::= < DIAMETER-Header: 9999999 > { User-Name } * { Host-Name } * [ AVP ] 0*1< Integrity-Check-Vector > An example would be the MRI, which would look like: ::= < DIAMETER Header: 259 > { Result-Code } { Host-Name } { Error-Reporting-NAI } [ Session-Id ] [ Failed-Command-Code ] [ Failed-AVP ] * [ AVP ] * [ Proxy-State ] * [ Route-Record ] * [ Routing-Realm ] 0*1< Integrity-Check-Value > PatC From owner-aaa-bof@merit.edu Thu Jan 25 22:07:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA01439 for ; Thu, 25 Jan 2001 22:07:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5589B5E03F; Thu, 25 Jan 2001 22:07:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 353D85E038; Thu, 25 Jan 2001 22:07:01 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id C79BD5DE13 for ; Thu, 25 Jan 2001 22:06:59 -0500 (EST) Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA07315; Thu, 25 Jan 2001 19:07:12 -0800 (PST) Received: from osnet.ne.jp (emerald.osnet.ne.jp [210.227.149.146]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f0Q36tb09479; Thu, 25 Jan 2001 19:06:56 -0800 (PST) Received: from dsisd898 ([64.24.247.127]) by osnet.ne.jp (8.9.3/8.8.8) with ESMTP id LAA41061; Fri, 26 Jan 2001 11:57:50 +0900 (JST) (envelope-from pianoman@angelfire.com) Message-Id: <200101260257.LAA41061@osnet.ne.jp> From: "Melvin Dupont" Subject: [AAA-WG]: Only a Few More Openings #3428 To: today78u@osnet.ne.jp X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Thu, 25 Jan 2001 19:44:20 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id WAA01439 *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:ytzz@cmpmail.com?subject=tell_me_more //////////////////////////////////////////////////// Please remove at: mailto:theater@building.com?subject=remove //////////////////////////////////////////////////// From owner-aaa-bof@merit.edu Fri Jan 26 09:43:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA15089 for ; Fri, 26 Jan 2001 09:43:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id E5CFC5DD8C; Fri, 26 Jan 2001 09:43:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D2A2D5DD9D; Fri, 26 Jan 2001 09:43:24 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 893B75DD8C for ; Fri, 26 Jan 2001 09:43:23 -0500 (EST) Received: from gwzpc (ams-vpdn-client-238.cisco.com [144.254.46.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id GAA23338; Fri, 26 Jan 2001 06:41:28 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts Date: Fri, 26 Jan 2001 06:35:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard Aboba [mailto:aboba@internaut.com] writes: > The RADIUS RFCs contain a table at the end, detailing which > AVPs can and cannot be included in each message. The current > DIAMETER drafts have not included such information, > effectively leaving the syntax of DIAMETER messages > undefined. > > We need to fix this. The question is how. Erik Guttman > has proposed some fixes to the BNF format used in > the existing specs, in order to clarify the issue. > > This is a request for discussion on whether these > proposed changes should be applied to the documents > or whether another approach should be taken. Personally, I like the table approach. It has the virtues of extreme simplicity and clarity. Of corse, it says nothing about how the semantics of AVPs interact, but given that well-designed AVPs are both declaritive and semantically idempotent (except for groupings of AVPs designed to describe an instance of abstract entities), this should not be an issue. > > If we do not hear objections to the changes by > Friday, February 2, 2001 then the changes will > be incorporated into the DIAMETER specs. > > From owner-aaa-bof@merit.edu Fri Jan 26 09:59:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA15351 for ; Fri, 26 Jan 2001 09:59:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 184DE5DE31; Fri, 26 Jan 2001 09:58:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 082045DE35; Fri, 26 Jan 2001 09:58:54 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A9A865DE31 for ; Fri, 26 Jan 2001 09:58:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13121; Fri, 26 Jan 2001 06:58:41 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27336; Fri, 26 Jan 2001 06:58:40 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA28083; Fri, 26 Jan 2001 06:58:36 -0800 (PST) Date: Fri, 26 Jan 2001 06:58:36 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts To: gwz@cisco.com Cc: Bernard Aboba , "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 > Personally, I like the table approach. It has the virtues of extreme > simplicity and clarity. Of corse, it says nothing about how the semantics > of AVPs interact, but given that well-designed AVPs are both declaritive and > semantically idempotent (except for groupings of AVPs designed to describe > an instance of abstract entities), this should not be an issue. Interesting view. As a developer of RADIUS (or ex- :), I have always found that having to move to the end of the document to find out what belongs in a particular message to be ackward. As I am working on a particular command, I want everything in front on me. So in RADIUS, we have a table that spans multiple pages, such as: The following table provides a guide to which attributes may be found in Accounting-Request packets. No attributes should be found in Accounting-Response packets except Proxy-State and possibly Vendor- Specific. # Attribute 0-1 User-Name 0 User-Password 0 CHAP-Password 0-1 NAS-IP-Address [5] 0-1 NAS-Port 0-1 Service-Type 0-1 Framed-Protocol 0-1 Framed-IP-Address 0-1 Framed-IP-Netmask 0-1 Framed-Routing 0+ Filter-Id 0-1 Framed-MTU [ad nauseum] (btw, Given that some DIAMETER extensions have as many as 5 or 6 commands, the table would obviously be structured differently. In RADIUS this was simple due to the small number of commands that can include attributes, or 1). In DIAMETER, the approach we've taken is each individual command, while being defined, contains the ABNF as follows: ::= < DIAMETER Header: 259 > { Result-Code } { Host-Name } { Error-Reporting-NAI } [ Session-Id ] [ Failed-Command-Code ] [ Failed-AVP ] * [ AVP ] * [ Proxy-State ] * [ Route-Record ] * [ Routing-Realm ] 0*1< Integrity-Check-Value > (or course, there is a section that defines the ABNF format). I, personally, find this so much simpler since everything is in front of you, and there is no chance of missing something in the table. HOwever, I am willing to heard from others. PatC From owner-aaa-bof@merit.edu Fri Jan 26 10:58:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16828 for ; Fri, 26 Jan 2001 10:58:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E1285DE46; Fri, 26 Jan 2001 10:58:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 59B165DE65; Fri, 26 Jan 2001 10:58:32 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id E86435DE46 for ; Fri, 26 Jan 2001 10:58:30 -0500 (EST) Received: from gwzpc (ams-vpdn-client-238.cisco.com [144.254.46.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA23160; Fri, 26 Jan 2001 07:56:35 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Patrice Calhoun" Cc: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts Date: Fri, 26 Jan 2001 07:46:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] writes: > > Personally, I like the table approach. It has the virtues of extreme > > simplicity and clarity. Of corse, it says nothing about how > the semantics > > of AVPs interact, but given that well-designed AVPs are both > declaritive and > > semantically idempotent (except for groupings of AVPs designed > to describe > > an instance of abstract entities), this should not be an issue. > > Interesting view. As a developer of RADIUS (or ex- :), I have always found > that having to move to the end of the document to find out what > belongs in a > particular message to be ackward. As I am working on a particular > command, I > want everything in front on me. Recently, those smart software people have developed these things called "windows". Apparently, some systems even allow you to have view different parts of the _same_ file in _two_ "windows" at once! ;-) > > So in RADIUS, we have a table that spans multiple pages, such as: > > The following table provides a guide to which attributes may be found > in Accounting-Request packets. No attributes should be found in > Accounting-Response packets except Proxy-State and possibly Vendor- > Specific. > > # Attribute > 0-1 User-Name > 0 User-Password > 0 CHAP-Password > 0-1 NAS-IP-Address [5] > 0-1 NAS-Port > 0-1 Service-Type > 0-1 Framed-Protocol > 0-1 Framed-IP-Address > 0-1 Framed-IP-Netmask > 0-1 Framed-Routing > 0+ Filter-Id > 0-1 Framed-MTU > [ad nauseum] > > (btw, Given that some DIAMETER extensions have as many as 5 or 6 > commands, the > table would obviously be structured differently. In RADIUS this > was simple due > to the small number of commands that can include attributes, or 1). > > In DIAMETER, the approach we've taken is each individual command, > while being > defined, contains the ABNF as follows: In other words, "In Diameter, we have ABNF-like stuff spanning several pages..." > > ::= < DIAMETER Header: 259 > > { Result-Code } > { Host-Name } > { Error-Reporting-NAI } > [ Session-Id ] > [ Failed-Command-Code ] > [ Failed-AVP ] > * [ AVP ] > * [ Proxy-State ] > * [ Route-Record ] > * [ Routing-Realm ] > 0*1< Integrity-Check-Value > > > > (or course, there is a section that defines the ABNF format). > > I, personally, find this so much simpler since everything is in > front of you, > and there is no chance of missing something in the table. HOwever, I am > willing to heard from others. Whatever. > > PatC > > From owner-aaa-bof@merit.edu Fri Jan 26 14:35:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA21127 for ; Fri, 26 Jan 2001 14:35:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F2485DEC7; Fri, 26 Jan 2001 14:35:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 571E05DEF8; Fri, 26 Jan 2001 14:35:33 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 007C55DEC7 for ; Fri, 26 Jan 2001 14:35:31 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14170; Fri, 26 Jan 2001 11:35:29 -0800 (PST) Received: from vayne (muc-isdn-15 [129.157.164.115]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id UAA00277; Fri, 26 Jan 2001 20:35:27 +0100 (MET) Date: Fri, 26 Jan 2001 20:45:59 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts To: gwz@cisco.com Cc: Patrice Calhoun , Bernard Aboba , "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 > > Glen writes: > > > Personally, I like the table approach. It has the virtues of extreme > > > simplicity and clarity. > Pat responds: > > So in RADIUS, we have a table that spans multiple pages, such as: Glen ripostes: > In other words, "In Diameter, we have ABNF-like stuff spanning several > pages..." Glen has a point - a table may be all we need here. There are two additional things we need to bring out in our formal presentation of DIAMETER, though. We need to say that certain AVPs MUST come first (or last). We also need to specify that although optional AVPs can be included, mixed in with required AVPs in any order, these MUST NOT break the rules regarding how many AVPs of certain kinds may appear. Like if the rule says one and only one Z AVP has to be in a message, we can't include another couple Z AVPs as 'optional' AVPs in the message. This would have to be stated formally of course, and that's the hard part. Erik From owner-aaa-bof@merit.edu Fri Jan 26 15:52:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA22802 for ; Fri, 26 Jan 2001 15:52:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A9855DEFC; Fri, 26 Jan 2001 15:51:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 482E75DEF8; Fri, 26 Jan 2001 15:51:55 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 3E8495DEF7 for ; Fri, 26 Jan 2001 15:51:54 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id PAA07558 for aaa-wg@merit.edu; Fri, 26 Jan 2001 15:51:54 -0500 (EST) Date: Fri, 26 Jan 2001 15:51:54 -0500 From: William Bulley To: aaa-wg@merit.edu Subject: [AAA-WG]: Good News! (about the Merit archives) Message-ID: <20010126155153.L6675@web1.merit.edu> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-bof@merit.edu Precedence: bulk As Dave Mitton has previously stated, we have the Merit AAA-WG archives "homed" in a new location: http://www.merit.edu/mail.archives/aaa-wg/ (as a by-product of this, we have said "bye bye" to the aaa-bof stuff on www.merit.edu) The new news is that we have just added a spiffy new search capability (well, spiffy may be a bit over-blown...) for the aaa-wg mail archives. Same URL but the search feature is in the upper right corner now. Check it out! I tried to find "web" and, boy, was I surprised how overloaded that word is! :-) Regards, web... -- William Bulley Manager of Software Engineering Merit Network, Inc. Email: web@merit.edu Building One, Suite 2000 Phone: (734) 764-9430 4251 Plymouth Road Fax: (734) 647-3185 Ann Arbor, Michigan 48105-2785 "We're not C++ programmers. There is one program written in C++ in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt, father and principal archtitect of the OpenBSD operating system. From owner-aaa-bof@merit.edu Fri Jan 26 16:34:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24702 for ; Fri, 26 Jan 2001 16:34:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 19AEA5DEF7; Fri, 26 Jan 2001 16:30:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 004805DF06; Fri, 26 Jan 2001 16:30:58 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 07EDE5DEF7 for ; Fri, 26 Jan 2001 16:30:57 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0QLD9R22365; Fri, 26 Jan 2001 13:13:10 -0800 From: "Bernard Aboba" To: "Erik Guttman" , Cc: "Patrice Calhoun" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts Date: Fri, 26 Jan 2001 13:17:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >Glen has a point - a table may be all we need here. The table is nice and simple and might be useful no matter what else we do. But there may be situations which cannot be covered in the table. So how do we specify those? >We need to say that certain AVPs MUST come first (or last). I can think up a couple of things that haven't yet been discussed that would fit in this category. How do you specify, for example, that certain AVPs occur first in the message, and must not be encrypted (e.g. message type, destination NAI, etc.) From owner-aaa-bof@merit.edu Fri Jan 26 17:34:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25739 for ; Fri, 26 Jan 2001 17:34:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A65B5DF04; Fri, 26 Jan 2001 17:34:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 81ADC5DD90; Fri, 26 Jan 2001 17:34:19 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C31435DF04 for ; Fri, 26 Jan 2001 17:34:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02052; Fri, 26 Jan 2001 13:36:51 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06634; Fri, 26 Jan 2001 13:36:50 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA06185; Fri, 26 Jan 2001 13:36:46 -0800 (PST) Date: Fri, 26 Jan 2001 13:36:46 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts To: Bernard Aboba Cc: Erik Guttman , gwz@cisco.com, Patrice Calhoun , "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 > >Glen has a point - a table may be all we need here. > > The table is nice and simple and might be useful no matter > what else we do. But there may be situations which cannot be covered > in the table. So how do we specify those? > > >We need to say that certain AVPs MUST come first (or last). > > I can think up a couple of things that haven't yet been discussed > that would fit in this category. How do you specify, for example, > that certain AVPs occur first in the message, and must not be > encrypted (e.g. message type, destination NAI, etc.) Correct. There are a couple of ordering rules, and these are REALLY hard to put in a table. Of course, you can add text throughout the document, in the actual AVP descriptions, but that, again, just makes it harder to find. However, Glen really likes tables, and Erik seems to agree. Both? Where the table is just a quick reference? PatC From owner-aaa-bof@merit.edu Sat Jan 27 01:09:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA02618 for ; Sat, 27 Jan 2001 01:09:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC35D5DF2F; Sat, 27 Jan 2001 01:08:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 92D8B5DE83; Sat, 27 Jan 2001 01:08:59 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id E8AF55DDDE for ; Sat, 27 Jan 2001 01:08:57 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0R64LR19051; Fri, 26 Jan 2001 22:04:21 -0800 From: "Bernard Aboba" To: "Patrice Calhoun" Cc: "Erik Guttman" , , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts Date: Fri, 26 Jan 2001 22:09:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >Both? Where the table is just a quick reference? Do both, but make sure they agree ;) From owner-aaa-bof@merit.edu Sat Jan 27 06:44:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA07504 for ; Sat, 27 Jan 2001 06:44:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE9FF5DD95; Sat, 27 Jan 2001 06:44:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D22CD5DDB5; Sat, 27 Jan 2001 06:44:35 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 13F115DD95 for ; Sat, 27 Jan 2001 06:44:34 -0500 (EST) Received: from gwzpc (ams-vpdn-client-238.cisco.com [144.254.46.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA01938; Sat, 27 Jan 2001 03:42:43 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Erik Guttman" Cc: "Patrice Calhoun" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts Date: Sat, 27 Jan 2001 03:41:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard Aboba [mailto:aboba@internaut.com] writes: > >Glen has a point - a table may be all we need here. > > The table is nice and simple and might be useful no matter > what else we do. But there may be situations which cannot be covered > in the table. So how do we specify those? > > >We need to say that certain AVPs MUST come first (or last). > > I can think up a couple of things that haven't yet been discussed > that would fit in this category. How do you specify, for example, > that certain AVPs occur first in the message, and must not be > encrypted (e.g. message type, destination NAI, etc.) (Continuing in semi-smartass mode) How about English? > From owner-aaa-bof@merit.edu Sat Jan 27 13:18:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13559 for ; Sat, 27 Jan 2001 13:18:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36A215DF82; Sat, 27 Jan 2001 13:16:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 178745DF81; Sat, 27 Jan 2001 13:16:08 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 7B7A85DF7E for ; Sat, 27 Jan 2001 13:16:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15048; Sat, 27 Jan 2001 10:15:58 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13256; Sat, 27 Jan 2001 10:15:32 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA21527; Sat, 27 Jan 2001 10:15:27 -0800 (PST) Date: Sat, 27 Jan 2001 10:15:28 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts To: gwz@cisco.com Cc: Bernard Aboba , Erik Guttman , Patrice Calhoun , "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 > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > >Glen has a point - a table may be all we need here. > > > > The table is nice and simple and might be useful no matter > > what else we do. But there may be situations which cannot be covered > > in the table. So how do we specify those? > > > > >We need to say that certain AVPs MUST come first (or last). > > > > I can think up a couple of things that haven't yet been discussed > > that would fit in this category. How do you specify, for example, > > that certain AVPs occur first in the message, and must not be > > encrypted (e.g. message type, destination NAI, etc.) > > (Continuing in semi-smartass mode) How about English? Of course, that would be the language of choise. The issue, though (again) is whether distributed information like this would ease interoperability, as opposed to a central location (e.g. per message). Again, I am flexible. I'll do what the WG wants. PatC From owner-aaa-bof@merit.edu Sun Jan 28 22:40:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA13599 for ; Sun, 28 Jan 2001 22:40:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63E5E5DD8F; Sun, 28 Jan 2001 22:40:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E3835DDAA; Sun, 28 Jan 2001 22:40:14 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3EE9A5DD8F for ; Sun, 28 Jan 2001 22:40:13 -0500 (EST) Received: (qmail 2013 invoked by uid 500); 29 Jan 2001 04:13:53 -0000 Date: Sun, 28 Jan 2001 22:13:52 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: OctetString type Message-ID: <20010128221352.C1427@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I think removing the basic string type was a bad idea. With octet string, there is no easy way to tell if the data is printable. It was nice having a string type, since the data could be printed in log messages, debug strings, etc. I think we should still have two types, Octets, and String, and treat them appropriately. Granted, on the transport side, DIAMETER will treat the two equaly, but it makes debugging/logging much nicer to know when you can print out the data involved. Just my $.02 worth. -Dave From owner-aaa-bof@merit.edu Mon Jan 29 12:56:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01125 for ; Mon, 29 Jan 2001 12:56:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 240505DFB5; Mon, 29 Jan 2001 12:54:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EE5195DFA0; Mon, 29 Jan 2001 12:54:38 -0500 (EST) Received: from funk.funk.com (funk.funk.com [198.186.160.66]) by segue.merit.edu (Postfix) with ESMTP id 50E325DF9D for ; Mon, 29 Jan 2001 12:54:37 -0500 (EST) Received: from pii400 (pii400.funk.com [198.186.160.46]) by funk.funk.com (8.8.5/8.8.5) with SMTP id MAA16994; Mon, 29 Jan 2001 12:21:21 -0500 (EST) Message-Id: <4.1.20010129113831.01bef5b0@funk1.funk.com> X-Sender: paul@funk1.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 29 Jan 2001 12:36:53 -0500 To: David Frascone , aaa-wg@merit.edu From: Paul Funk Subject: Re: [AAA-WG]: OctetString type In-Reply-To: <20010128221352.C1427@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree that String should be a type. There will be numerous AVPs whose values must be human readable. In the text of the AVP's description, rather than specifying type as OctetString, then qualifying it to be "human readable UTF-8 character string", why not just just call a String a String? A Diameter implementation needs to know an AVP's type not only for processing purposes but also for administrative purposes, e.g., logging and configuration. While it is always possible to qualify the use of an AVP further in its description, it promotes precision and clarity to formally define types for common data formats. I think Time is also a candidate for re-inclusion as a data type. The Alpha-2 draft already defines the use of UTF-8 as a subset of OctetString, and time data as a subset of Unsigned32. They might as well be defined separately as types in their own right. At 10:13 PM 1/28/01 -0600, David Frascone wrote: >I think removing the basic string type was a bad idea. With octet string, >there is no easy way to tell if the data is printable. It was nice having >a string type, since the data could be printed in log messages, debug >strings, etc. > >I think we should still have two types, Octets, and String, and treat them >appropriately. > >Granted, on the transport side, DIAMETER will treat the two equaly, but it >makes debugging/logging much nicer to know when you can print out the >data involved. > >Just my $.02 worth. > > >-Dave From owner-aaa-bof@merit.edu Mon Jan 29 16:04:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07563 for ; Mon, 29 Jan 2001 16:04:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DA8C5DE70; Mon, 29 Jan 2001 16:01:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E91B75DE95; Mon, 29 Jan 2001 16:01:53 -0500 (EST) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by segue.merit.edu (Postfix) with ESMTP id C19755DE70 for ; Mon, 29 Jan 2001 16:01:52 -0500 (EST) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 14NLQm-0001h6-00; Mon, 29 Jan 2001 21:01:44 +0000 Received: from [206.133.83.14] (helo=localhost) by dfw-mmp2.email.verio.net with esmtp id 14NLQY-0002zy-00; Mon, 29 Jan 2001 21:01:31 +0000 X-Sender: misterprivacy@hushmail.com From: Dave To: "customer" Date: Mon, 29 Jan 2001 12:18:00 -0500 Subject: [AAA-WG]: I could go to JAIL for selling this CD! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__2979830_44280.05" Message-Id: Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__2979830_44280.05 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__2979830_44280.05 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4 OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250 cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51 dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5 b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9 MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48 L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48 L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5 IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1 aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52 ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7 IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0 IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7 IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250 PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1 cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5 b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3 aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91 IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52 ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93 IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5 Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0 cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2 NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+ PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0 ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2 Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250 IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250 IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0 b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9 KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0 d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48 aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5 b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93 d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5 IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+ WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+ ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8 YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+ U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91 IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3 LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3 cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0 aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__2979830_44280.05-- From owner-aaa-bof@merit.edu Tue Jan 30 10:32:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01395 for ; Tue, 30 Jan 2001 10:32:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 650EF5DEAE; Tue, 30 Jan 2001 10:31:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E9BF5DF0E; Tue, 30 Jan 2001 10:31:17 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 024975DEAE for ; Tue, 30 Jan 2001 10:31:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21159; Tue, 30 Jan 2001 07:31:13 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16136; Tue, 30 Jan 2001 07:31:08 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA02155; Tue, 30 Jan 2001 07:31:06 -0800 (PST) Date: Tue, 30 Jan 2001 07:31:06 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: DIAMETER or Diameter? To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, One of my co-authors correctly pointed out that the use of all CAPS is innapropriate, since DIAMETER is not an acronym, and recommended that it be changed to Diameter. I am asking for WG concensus on this one, although I do tend to agree. Objections? PatC From owner-aaa-bof@merit.edu Tue Jan 30 10:51:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01744 for ; Tue, 30 Jan 2001 10:51:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 797115DE10; Tue, 30 Jan 2001 10:51:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 651B55DE5B; Tue, 30 Jan 2001 10:51:25 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 82D3A5DE10 for ; Tue, 30 Jan 2001 10:51:24 -0500 (EST) Received: from Interlinknetworks.com (hst37155.phys.uu.nl [131.211.37.155]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 724A272; Tue, 30 Jan 2001 10:51:33 -0500 (EST) Message-ID: <3A76E2F4.97CFD75D@Interlinknetworks.com> Date: Tue, 30 Jan 2001 16:51:16 +0100 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: DIAMETER or Diameter? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk I prefer Diameter. I don't particularly like all caps and am not particularly impressed by strained acronyms. So please don't rename it "Diameter Is Aaa Messaging Explained Twice as Eloquently as Radius" just so you can write it all in caps as DIAMETER. Patrice Calhoun wrote: > > All, > > One of my co-authors correctly pointed out that the use of all CAPS is > innapropriate, since DIAMETER is not an acronym, and recommended that it be > changed to Diameter. I am asking for WG concensus on this one, although I do > tend to agree. > > Objections? > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Tue Jan 30 10:52:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01759 for ; Tue, 30 Jan 2001 10:52:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 864005DE75; Tue, 30 Jan 2001 10:52:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 745945DE73; Tue, 30 Jan 2001 10:52:34 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by segue.merit.edu (Postfix) with ESMTP id 253AB5DE5B for ; Tue, 30 Jan 2001 10:52:33 -0500 (EST) Received: from knox6195.CISCO.COM (rsargent@knox6195.cisco.com [161.44.216.195]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA29029; Tue, 30 Jan 2001 07:52:25 -0800 (PST) Date: Tue, 30 Jan 2001 10:52:22 -0500 From: Robert Sargent To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010130105222.C8219@Cisco.COM> Reply-To: Robert Sargent References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Tue, Jan 30, 2001 at 07:31:06AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun promised: > All, > > One of my co-authors correctly pointed out that the use of all CAPS is > innapropriate, since DIAMETER is not an acronym, and recommended that it be > changed to Diameter. I am asking for WG concensus on this one, although I do > tend to agree. Agree. > Objections? Nope. -- Rob Sargent From owner-aaa-bof@merit.edu Tue Jan 30 11:10:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02191 for ; Tue, 30 Jan 2001 11:10:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B02155DE73; Tue, 30 Jan 2001 11:09:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A0AB45DE1B; Tue, 30 Jan 2001 11:09:57 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 324C95DDE1 for ; Tue, 30 Jan 2001 11:09:56 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f0UG9kM54927; Tue, 30 Jan 2001 11:09:46 -0500 (EST) (envelope-from barney) Date: Tue, 30 Jan 2001 11:09:46 -0500 From: Barney Wolff To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010130110946.A54824@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Tue, Jan 30, 2001 at 07:31:06AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Dial In Access Management Essentially Transport- Enhanced RADIUS I'll point out that UNIX is not an acronym either, but is correctly written with all caps. If we're down at this level we must be done, right? :) Barney On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote: > All, > > One of my co-authors correctly pointed out that the use of all CAPS is > innapropriate, since DIAMETER is not an acronym, and recommended that it be > changed to Diameter. I am asking for WG concensus on this one, although I do > tend to agree. > > Objections? > > PatC > > From owner-aaa-bof@merit.edu Tue Jan 30 12:36:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA03932 for ; Tue, 30 Jan 2001 12:36:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35B105DE1B; Tue, 30 Jan 2001 12:35:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 16FD05DDE1; Tue, 30 Jan 2001 12:35:47 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id E187B5DDD7; Tue, 30 Jan 2001 12:35:45 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id MAA25580; Tue, 30 Jan 2001 12:35:45 -0500 (EST) Date: Tue, 30 Jan 2001 12:35:45 -0500 From: William Bulley To: Patrice Calhoun Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010130123545.I25133@web1.merit.edu> Mail-Followup-To: Patrice Calhoun , diameter@diameter.org, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-bof@merit.edu Precedence: bulk According to Patrice Calhoun : > > One of my co-authors correctly pointed out that the use of all CAPS is > innapropriate, since DIAMETER is not an acronym, and recommended that it be > changed to Diameter. I am asking for WG concensus on this one, although I do > tend to agree. Then shall we take this opportunity to make it into an acronym befitting its heritage? Afterall, RADIUS was an acronym. I have suggested such an acronym to you in the recent past... Regards, web... -- William Bulley Manager of Software Engineering Merit Network, Inc. Email: web@merit.edu Building One, Suite 2000 Phone: (734) 764-9430 4251 Plymouth Road Fax: (734) 647-3185 Ann Arbor, Michigan 48105-2785 "We're not C++ programmers. There is one program written in C++ in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt, father and principal archtitect of the OpenBSD operating system. From owner-aaa-bof@merit.edu Tue Jan 30 12:40:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA04045 for ; Tue, 30 Jan 2001 12:40:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3D4B5DE5D; Tue, 30 Jan 2001 12:39:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C23EE5DDE1; Tue, 30 Jan 2001 12:39:55 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 6FDCF5DDD7; Tue, 30 Jan 2001 12:39:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19728; Tue, 30 Jan 2001 09:39:52 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28023; Tue, 30 Jan 2001 09:39:50 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA04542; Tue, 30 Jan 2001 09:39:48 -0800 (PST) Date: Tue, 30 Jan 2001 09:39:49 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: DIAMETER or Diameter? To: William Bulley Cc: Patrice Calhoun , diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010130123545.I25133@web1.merit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > One of my co-authors correctly pointed out that the use of all CAPS is > > innapropriate, since DIAMETER is not an acronym, and recommended that it be > > changed to Diameter. I am asking for WG concensus on this one, although I do > > tend to agree. > > Then shall we take this opportunity to make it into an acronym > befitting its heritage? Afterall, RADIUS was an acronym. I > have suggested such an acronym to you in the recent past... Well, we could, but it really seems pointless at this time, given that it's been around for so long. My favorite is really "Diameter Is Aaa Messaging Explained Twice as Eloquently as Radius" :) Barney states: "If we're down at this level we must be done, right?" Not really, but I want the document right before it becomes a WG document. PatC From owner-aaa-bof@merit.edu Tue Jan 30 13:05:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA04646 for ; Tue, 30 Jan 2001 13:05:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1A725DF7C; Tue, 30 Jan 2001 13:01:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 954ED5DF7B; Tue, 30 Jan 2001 13:01:52 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 631B95DF73; Tue, 30 Jan 2001 13:01:50 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id NAA25720; Tue, 30 Jan 2001 13:01:50 -0500 (EST) Date: Tue, 30 Jan 2001 13:01:50 -0500 From: William Bulley To: Patrice Calhoun Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010130130150.N25133@web1.merit.edu> Mail-Followup-To: Patrice Calhoun , diameter@diameter.org, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-bof@merit.edu Precedence: bulk According to Patrice Calhoun : > > Well, we could, but it really seems pointless at this time, given that it's > been around for so long. What is the "it" that has "been around for so long"? > My favorite is really "Diameter Is Aaa Messaging Explained Twice as Eloquently > as Radius" :) Not bad -- and neither was the other (Barney's?) suggestion... :-) Regards, web... -- William Bulley Manager of Software Engineering Merit Network, Inc. Email: web@merit.edu Building One, Suite 2000 Phone: (734) 764-9430 4251 Plymouth Road Fax: (734) 647-3185 Ann Arbor, Michigan 48105-2785 "We're not C++ programmers. There is one program written in C++ in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt, father and principal archtitect of the OpenBSD operating system. From owner-aaa-bof@merit.edu Tue Jan 30 13:08:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA04682 for ; Tue, 30 Jan 2001 13:08:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C3B85DF50; Tue, 30 Jan 2001 13:05:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 297B75DED9; Tue, 30 Jan 2001 13:05:42 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 37C875DEAC for ; Tue, 30 Jan 2001 13:05:40 -0500 (EST) Received: (qmail 7673 invoked by uid 500); 30 Jan 2001 18:39:48 -0000 Date: Tue, 30 Jan 2001 12:39:48 -0600 From: David Frascone To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010130123948.A7556@newman.frascone.com> Mail-Followup-To: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Tue, Jan 30, 2001 at 07:31:06AM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Shouldn't we just come up with what it stands for instead? Distributed Internet Authentication Mechanism Effecting the Total Elimination of RADIUS On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote: > All, > > One of my co-authors correctly pointed out that the use of all CAPS is > innapropriate, since DIAMETER is not an acronym, and recommended that it be > changed to Diameter. I am asking for WG concensus on this one, although I do > tend to agree. > > Objections? > > PatC > > From owner-aaa-bof@merit.edu Tue Jan 30 13:49:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05442 for ; Tue, 30 Jan 2001 13:49:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABAE25DF12; Tue, 30 Jan 2001 13:47:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 98FAC5DF0D; Tue, 30 Jan 2001 13:47:55 -0500 (EST) Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 7A2105DEE1 for ; Tue, 30 Jan 2001 13:47:53 -0500 (EST) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.9.3/8.9.3) id NAA17381; Tue, 30 Jan 2001 13:47:41 -0500 (EST) Received: from unknown(0.0.0.0) by ahab via smap (V2.1) id xma017379; Tue, 30 Jan 01 13:47:15 -0500 Received: (from mail@localhost) by mailman.innovation.siemens.ca (8.9.3/8.9.3) id NAA06475; Tue, 30 Jan 2001 13:47:14 -0500 (EST) Received: from ticsmtp2.innovation.siemens.ca(172.21.24.160) by mailman.innovation.siemens.ca via smap (V2.1) id xma006367; Tue, 30 Jan 01 13:46:02 -0500 Received: by ticsmtp2.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 30 Jan 2001 13:43:52 -0500 Message-ID: <53D69AD06EFAD311842300A0C99B4F08D50C4B@ticsmtp2.innovation.siemens.ca> From: Arek Nowakowski To: "'David Frascone'" , Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [diameter] Re: [AAA-WG]: DIAMETER or Diameter? Date: Tue, 30 Jan 2001 13:43:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk What about: Distributed Internet Authentication Mechanism Effectivly and Totaly Eliminating Radius ??? Arek Nowakowski -----Original Message----- From: David Frascone [mailto:dave@frascone.com] Sent: Tuesday, January 30, 2001 1:40 PM To: Patrice Calhoun Cc: aaa-wg@merit.edu; diameter@diameter.org Subject: [diameter] Re: [AAA-WG]: DIAMETER or Diameter? Shouldn't we just come up with what it stands for instead? Distributed Internet Authentication Mechanism Effecting the Total Elimination of RADIUS On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote: > All, > > One of my co-authors correctly pointed out that the use of all CAPS is > innapropriate, since DIAMETER is not an acronym, and recommended that it be > changed to Diameter. I am asking for WG concensus on this one, although I do > tend to agree. > > Objections? > > PatC > > From owner-aaa-bof@merit.edu Tue Jan 30 13:56:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05632 for ; Tue, 30 Jan 2001 13:56:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB5195DE23; Tue, 30 Jan 2001 13:56:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99B8D5DDE1; Tue, 30 Jan 2001 13:56:08 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by segue.merit.edu (Postfix) with ESMTP id 408605DDD7 for ; Tue, 30 Jan 2001 13:56:07 -0500 (EST) Received: from knox6195.CISCO.COM (rsargent@knox6195.cisco.com [161.44.216.195]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA06845; Tue, 30 Jan 2001 10:56:00 -0800 (PST) Date: Tue, 30 Jan 2001 13:55:57 -0500 From: Robert Sargent To: Arek Nowakowski Cc: "'David Frascone'" , Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010130135557.N8219@Cisco.COM> Reply-To: Robert Sargent References: <53D69AD06EFAD311842300A0C99B4F08D50C4B@ticsmtp2.innovation.siemens.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <53D69AD06EFAD311842300A0C99B4F08D50C4B@ticsmtp2.innovation.siemens.ca>; from Arek.Nowakowski@tic.siemens.ca on Tue, Jan 30, 2001 at 01:43:51PM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk Dreamers In Another Megacosm Erroneously Thinking about Eliminating RADIUS. Okay, back to real work... Rob On Tue, Jan 30, 2001 at 01:43:51PM -0500, Arek Nowakowski promised: > What about: > Distributed Internet Authentication Mechanism Effectivly and Totaly > Eliminating Radius ??? > > Arek Nowakowski > > -----Original Message----- > From: David Frascone [mailto:dave@frascone.com] > Sent: Tuesday, January 30, 2001 1:40 PM > To: Patrice Calhoun > Cc: aaa-wg@merit.edu; diameter@diameter.org > Subject: [diameter] Re: [AAA-WG]: DIAMETER or Diameter? > > > Shouldn't we just come up with what it stands for instead? > > Distributed Internet Authentication Mechanism Effecting the Total > Elimination > of RADIUS > > On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote: > > All, > > > > One of my co-authors correctly pointed out that the use of all CAPS is > > innapropriate, since DIAMETER is not an acronym, and recommended that it > be > > changed to Diameter. I am asking for WG concensus on this one, although I > do > > tend to agree. > > > > Objections? > > > > PatC > > > > -- Rob Sargent Tel: (865) 671-8823 Software Development Manager -*- Remote Site Manager - Knoxville 10850 Murdock Dr Knoxville TN 37932 http://darien.cisco.com/ From owner-aaa-bof@merit.edu Wed Jan 31 15:01:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04275 for ; Wed, 31 Jan 2001 15:01:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B9CE5DF00; Wed, 31 Jan 2001 14:57:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5CEBD5DEE1; Wed, 31 Jan 2001 14:57:50 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by segue.merit.edu (Postfix) with ESMTP id EB74D5DE91 for ; Wed, 31 Jan 2001 14:57:47 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA15457; Wed, 31 Jan 2001 11:57:28 -0800 (PST) Message-Id: <4.1.20010131145349.00a1d180@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 31 Jan 2001 14:56:43 -0500 To: Barney Wolff , Patrice Calhoun From: John Schnizlein Subject: Re: [AAA-WG]: DIAMETER or Diameter? Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: <20010130110946.A54824@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote: >Dial >In >Access >Management >Essentially >Transport- >Enhanced >RADIUS Why strain to create an acronym where none existed? Punning is a fine tradition in naming. Diameter is twice 'RADIUS'. >I'll point out that UNIX is not an acronym either, >but is correctly written with all caps. No, Unix is not correctly written with all caps. "Unix" is a pun on Multics. Please do not attempt to force an acronym onto "Unix". John From owner-aaa-bof@merit.edu Wed Jan 31 16:19:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA05820 for ; Wed, 31 Jan 2001 16:19:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 341B55DFB4; Wed, 31 Jan 2001 16:16:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1DEF55DFBC; Wed, 31 Jan 2001 16:16:41 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 5F2A05DFB4 for ; Wed, 31 Jan 2001 16:16:38 -0500 (EST) Received: from knox6046.cisco.com (root@knox6046.cisco.com [161.44.216.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA03820; Wed, 31 Jan 2001 16:15:38 -0500 (EST) Received: (from srich@localhost) by knox6046.cisco.com (8.11.0/8.11.0) id f0VLFZB09945; Wed, 31 Jan 2001 16:15:35 -0500 From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14968.32887.533758.726464@knox6046.cisco.com> Date: Wed, 31 Jan 2001 16:15:35 -0500 To: John Schnizlein Cc: Barney Wolff , Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: DIAMETER or Diameter? In-Reply-To: <4.1.20010131145349.00a1d180@diablo.cisco.com> References: <4.1.20010131145349.00a1d180@diablo.cisco.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-aaa-bof@merit.edu Precedence: bulk John Schnizlein writes: > At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote: > >Dial > >In > >Access > >Management > >Essentially > >Transport- > >Enhanced > >RADIUS > > Why strain to create an acronym where none existed? > Punning is a fine tradition in naming. > Diameter is twice 'RADIUS'. > > >I'll point out that UNIX is not an acronym either, > >but is correctly written with all caps. > > No, Unix is not correctly written with all caps. > "Unix" is a pun on Multics. > Please do not attempt to force an acronym onto "Unix". Yeah, but MULTICS *is* an acronym. (I believe that that's why the pun ``UNIX'' is spelled in all-caps, even though it is *not* an acronym. Sorta hightens the mystique. :) :) sjr > > John > From owner-aaa-bof@merit.edu Wed Jan 31 18:19:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA08660 for ; Wed, 31 Jan 2001 18:19:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 577505DE91; Wed, 31 Jan 2001 18:16:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 37BDF5DEB9; Wed, 31 Jan 2001 18:16:00 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 0728B5DE91 for ; Wed, 31 Jan 2001 18:15:58 -0500 (EST) Received: from purol.East.Sun.COM ([129.148.9.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01300; Wed, 31 Jan 2001 15:15:57 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA26990; Wed, 31 Jan 2001 18:15:56 -0500 (EST) Date: Wed, 31 Jan 2001 18:15:54 -0500 (EST) From: Steven Glass - Solaris Software Reply-To: Steven Glass - Solaris Software Subject: Re: [AAA-WG]: DIAMETER or Diameter? To: diameter@diameter.org Cc: Patrice Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <14968.32887.533758.726464@knox6046.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > John Schnizlein writes: > > At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote: > > >Dial > > >In > > >Access > > >Management > > >Essentially > > >Transport- > > >Enhanced > > >RADIUS Diameter's not just for dial-in anymore. Either we figure out some acronym quickly and use "DIAMETER", or we don't worry about it and use "Diameter". My suggestions: Diverse [Internet] Access Management using Extensible Types and Enhancements to RADIUS Diverse Internet Access Management using Extensible Types and Enhanced [or element] Retrieval Diverse [Direct] Internet Access Management using Extensible Types and [/with] External [or Efficient or Enhanced] Relaying mix/match, tweek, etc. You get where I'm trying to go. Could use End2End in there too (if we want to open this up to controversy)... Cheers, Steve From owner-aaa-bof@merit.edu Wed Jan 31 23:04:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA13440 for ; Wed, 31 Jan 2001 23:04:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABDD85DEB2; Wed, 31 Jan 2001 23:01:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 97E665DEE5; Wed, 31 Jan 2001 23:01:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 38F885DEB2 for ; Wed, 31 Jan 2001 23:01:55 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id UAA13349; Wed, 31 Jan 2001 20:02:09 -0800 (PST) From: jewelers@building.com Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1141xm14987; Wed, 31 Jan 2001 20:01:59 -0800 (PST) Received: from gw.pfpfinancial.com.au (pfpfinancial.com.au [203.59.136.86]) by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f1141lu01830; Wed, 31 Jan 2001 20:01:48 -0800 (PST) Received: from 203.59.136.86 (03-118.044.popsite.net [64.24.247.118]) by gw.pfpfinancial.com.au (8.8.5/8.8.5) with SMTP id LAA29978; Thu, 1 Feb 2001 11:50:13 +0800 Message-Id: <200102010350.LAA29978@gw.pfpfinancial.com.au> Date: Wed, 31 Jan 01 21:08:00 EST To: g411hjd8h@idnkjkwo0.com Subject: [AAA-WG]: Worth a Shot Sender: owner-aaa-bof@merit.edu Precedence: bulk The Program ------------------------------------------------------------------------------------------------------- AS SEEN ON NATIONAL TV --- INCREDIBLE $0 to $50,000 in 90 days!!! ------------------------------------------------------------------------------------------------------- You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. HERE IT IS BELOW: *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days ! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response: "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. In less than one week, I was starting to receive orders for REPORT #1 By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!! ! Remember, it won't work if you don't try it. This program does work , but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945.I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS!I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if youdon't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! -- When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. -- Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested,and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do justthat, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5.......................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).....$50,000 THIS TOTALS ---------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER and NAME *** Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. -- Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM : B.Lapole P.O. Box 642 Spring, Texas 77383-0642 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: A. Williams 10606 Twin Circle Montgomery, Texas 77356 REPORT #3 "The Secrets to Multi-level Marketing on the Internet" ORDER REPORT #3 FROM: R. Ehrgott 10130 Mossycup Conroe, Texas 77304 REPORT #4 "How to Become a Millionaire Utilizing the Power of Multi-level Marketing and the Internet" ORDER REPORT #4 FROM: D. Vasicak 479 Bennett Street Luzerne, PA 18709 About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* -- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don 't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at boardgames@goplay.com /////////////////////////////////////////////////////////////////