From owner-aaa-wg@merit.edu Wed May 1 00:37:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21496 for ; Wed, 1 May 2002 00:37:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D2FA91244; Wed, 1 May 2002 00:37:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2F9E91245; Wed, 1 May 2002 00:37:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DACE291244 for ; Wed, 1 May 2002 00:37:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97F375DE52; Wed, 1 May 2002 00:37:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 16EC15DDC0 for ; Wed, 1 May 2002 00:37:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g413pNx05728; Tue, 30 Apr 2002 20:51:23 -0700 Date: Tue, 30 Apr 2002 20:51:23 -0700 (PDT) From: Bernard Aboba To: Johan Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions In-Reply-To: <3CCE89D6.7090804@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue 336. On Tue, 30 Apr 2002, Johan Johansson wrote: > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 2002-April-30 > Document: base (could also be that mip is the correct one) > Comment type: T > Priority: S > Section: 9.6 > Rationale/Explanation of issue: From owner-aaa-wg@merit.edu Wed May 1 00:41:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21665 for ; Wed, 1 May 2002 00:41:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68B8191245; Wed, 1 May 2002 00:40:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 326DD91246; Wed, 1 May 2002 00:40:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48C7191245 for ; Wed, 1 May 2002 00:40:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10A715DF2E; Wed, 1 May 2002 00:40:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 91F415DE52 for ; Wed, 1 May 2002 00:40:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g413t5X05914; Tue, 30 Apr 2002 20:55:05 -0700 Date: Tue, 30 Apr 2002 20:55:05 -0700 (PDT) From: Bernard Aboba To: julien.bournelle@int-evry.fr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: typos in mobile-ip draft 10 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id AAA21665 Assigned issue 337. On Tue, 30 Apr 2002, julien Bournelle wrote: > Hi, > I've just noticed 2 typos in draft 10 concerning Mobile IPv4 application: > > p.6 §1.2 > > "When a Mobile Node node requests..." > > => "When a Mobile Node requests" > > > p.19 §2.2 > > "An AMA message ...., MUST include the MIP-Home-Mobile-Node-Address AVP.." > > => "An AMA message ..., MUST include the MIP-Mobile-Node-Address AVP" > > Hope it helps, > > julien.bournelle@int-evry.fr > From owner-aaa-wg@merit.edu Wed May 1 00:43:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21734 for ; Wed, 1 May 2002 00:43:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23AA791246; Wed, 1 May 2002 00:42:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E79AC91247; Wed, 1 May 2002 00:42:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BD4E91246 for ; Wed, 1 May 2002 00:42:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D89105DF2E; Wed, 1 May 2002 00:42:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 55D515DE52 for ; Wed, 1 May 2002 00:42:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g413ujs06009; Tue, 30 Apr 2002 20:56:45 -0700 Date: Tue, 30 Apr 2002 20:56:45 -0700 (PDT) From: Bernard Aboba To: Tony Johansson Cc: "aaa-wg@merit.edu" Subject: Re: [AAA-WG]: Issue: Diameter Mobile IP application & backwards compatibility In-Reply-To: <3CC87F45.384D7681@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue 338. On Thu, 25 Apr 2002, Tony Johansson wrote: > > Description of issue: Diameter Mobile IP application & backwards > compatibility > Submitter name: Tony Johansson > Submitter email address: tony.johansson@ericsson.com > Date first submitted: 2002-04-25 > Reference: > Document: mip-10 > Comment type: T > Priority: S > Section: > Rationale/Explanation of issue: > > In the existing deployments of Mobile IP clients, especially those that > will soon be deployed for IS-835 (the cdma2000 standard). There have > been concerns raised about mandating the use of the AAA NAI extension in > the mip-10 as it requires restrictions on the client-to-network > interface. > > > Requested change: > As the mip-10 now is worded the AAA NAI is mandatory to over come the > previous found issues, e.g. in cases of multiple AAAH's in the same > domain, etc. However, to over come backwards compatibility issues for > those that would like to let Mobile IP clients (i.e. those clients that > are now deployed) run with the Diameter Mobile IPv4 application with > limited functionality, I would like to change the text in the mip-10 > draft from a MUST to a SHOULD for the use of the AAA NAI extension. In > other words, make the AAA NAI/HA NAI optional and the consequences of > not using the AAA NAI/HA NAI would be beyond the scope of the draft. > > > Any comments / objections to this. > > /Tony > From owner-aaa-wg@merit.edu Wed May 1 00:58:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21955 for ; Wed, 1 May 2002 00:58:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8999591248; Wed, 1 May 2002 00:57:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECB5291249; Wed, 1 May 2002 00:57:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA5B491248 for ; Wed, 1 May 2002 00:57:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB7865DF3B; Wed, 1 May 2002 00:57:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2C81F5DF34 for ; Wed, 1 May 2002 00:57:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g414C1l06890; Tue, 30 Apr 2002 21:12:02 -0700 Date: Tue, 30 Apr 2002 21:12:01 -0700 (PDT) From: Bernard Aboba To: Liu Qiong Bo Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Only DWR/DWA to be used to supervise transportconnection In-Reply-To: <4.3.2.7.2.20020425145947.022b3eb0@postman.cwc.nus.edu.sg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #339. On Thu, 25 Apr 2002, Liu Qiong Bo wrote: > Hi. > > in Diameter base protocol-10, section5.6, the 2nd paragraph: > "This state machine is closely coupled with the state machine > described in [AAATRANS], which is used to open, close, failover, > probe, and reopen transport connections. Note in particular that > [AAATRANS] requires the use of watchdog messages to probe > connections. For Diameter, DWR and DWA messages are to be used." > > in transport-07, appendix a, there is a failover state machine. > > I am confused by the state of DOWN in this failover state machine and the > state of closed in the peer state machine. > > In the state of DOWN, does it mean that this transport connection is > closed, and the related socket is closed. hence when tw time expires, the > diameter node try to open another socket and try to connect to the peer? > > If it is, then what is the difference between DOWN and closed? > > Hence what is the complete peer state machine like? > > Regards. > > Coral Liu > From owner-aaa-wg@merit.edu Wed May 1 01:03:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22077 for ; Wed, 1 May 2002 01:03:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3890791249; Wed, 1 May 2002 01:02:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A83B9124A; Wed, 1 May 2002 01:02:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 085EF91249 for ; Wed, 1 May 2002 01:02:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A70485DDDC; Wed, 1 May 2002 01:02:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 18CC75DDC0 for ; Wed, 1 May 2002 01:02:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g414H1x07235; Tue, 30 Apr 2002 21:17:01 -0700 Date: Tue, 30 Apr 2002 21:17:01 -0700 (PDT) From: Bernard Aboba To: Liu Qiong Bo Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: delete Snd-Conn-Ack In-Reply-To: <4.3.2.7.2.20020426105613.022d8058@postman.cwc.nus.edu.sg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Filed as an adjunct to Issue #339. On Fri, 26 Apr 2002, Liu Qiong Bo wrote: > Hi. > > in base-10, section 5.6.3, one action named Snd-Conn-Ack is defined, but it > doesn't appear in the peer state machine. Therefore suggest to delete this > action from the document. > > regards. > > Coral > From owner-aaa-wg@merit.edu Thu May 2 03:33:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28305 for ; Thu, 2 May 2002 03:33:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0516791286; Thu, 2 May 2002 03:31:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AED4891287; Thu, 2 May 2002 03:31:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D7C691286 for ; Thu, 2 May 2002 03:31:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17E595DDAC; Thu, 2 May 2002 03:31:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 1CEA05DDA5 for ; Thu, 2 May 2002 03:31:56 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g427WEF15687 for ; Thu, 2 May 2002 10:32:14 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 10:31:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 2 May 2002 10:31:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Date: Thu, 2 May 2002 10:31:54 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65074@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Thread-Index: AcHwQIMTUL73LgVUROOVPOM/uGaozABaotcQ From: To: , X-OriginalArrivalTime: 02 May 2002 07:31:55.0127 (UTC) FILETIME=[6F404870:01C1F1AB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA28305 Hi Johan, > Requested change: > > The Diameter protocol's Session-Id AVP, which is globally unique (see > section 8.8), is used during the authorization phase to identify a > particular session. Services that do not require any authorization > still use the Session-Id AVP to identify sessions. > > to > > The Diameter protocol's Session-Id AVP, which is globally unique (see > section 8.8), is used during the authorization phase to identify a > particular session. Services that do not require any authorization > still use the Session-Id AVP to identify sessions. Accounting messages > MUST use a different Session-Id from that sent in > authorization messages. Somehow, the "MUST use" part of the last sentence worries me. I think that it may be more application specific. I'd prefer to state something more like: Accounting messages MAY use a different Session-Id from that sent in authorization messages. Specific applications MAY require different a Session-ID for accounting messages. Then, the application (for example MIP) could use a MUST. Comments? John From owner-aaa-wg@merit.edu Thu May 2 04:36:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01545 for ; Thu, 2 May 2002 04:36:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93C229128E; Thu, 2 May 2002 04:34:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46F279128F; Thu, 2 May 2002 04:34:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E92109128E for ; Thu, 2 May 2002 04:34:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B24245DDCF; Thu, 2 May 2002 04:34:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 17D965DDA9 for ; Thu, 2 May 2002 04:34:14 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020502083413.SYXC3332.fep01-svc.swip.net@ipunplugged.com>; Thu, 2 May 2002 10:34:13 +0200 Message-ID: <3CD1167F.4070307@ipunplugged.com> Date: Thu, 02 May 2002 10:35:43 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65074@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: >Hi Johan, > > > >>Requested change: >> >> The Diameter protocol's Session-Id AVP, which is globally unique (see >> section 8.8), is used during the authorization phase to identify a >> particular session. Services that do not require any authorization >> still use the Session-Id AVP to identify sessions. >> >>to >> >>The Diameter protocol's Session-Id AVP, which is globally unique (see >>section 8.8), is used during the authorization phase to identify a >>particular session. Services that do not require any authorization >>still use the Session-Id AVP to identify sessions. Accounting messages >>MUST use a different Session-Id from that sent in >>authorization messages. >> >> > >Somehow, the "MUST use" part of the last sentence worries me. I think >that it may be more application specific. I'd prefer to state something >more like: > > Accounting messages MAY use a different Session-Id from that sent in > authorization messages. Specific applications MAY require different > a Session-ID for accounting messages. > >Then, the application (for example MIP) could use a MUST. > I can understand your concern. NASREQ is in many ways very different from the MIP application. I think that the crucial requirement is that each application either states that they must be the same or that they must be different. Nevertheless I think it could make things easier if things were solved consistently across applications. I am not religious about the choice of solution here. I think that the second best solution is to state that the same session id must be used. That said, using different session ids for accounting and authorization services is a more flexible solution and so far I am not aware of any problems with it. MIP people, speak your mind please. j From owner-aaa-wg@merit.edu Thu May 2 06:34:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09216 for ; Thu, 2 May 2002 06:34:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AFAAF9129C; Thu, 2 May 2002 06:33:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B19B912A1; Thu, 2 May 2002 06:33:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C09949129C for ; Thu, 2 May 2002 06:33:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E1CC5DDA1; Thu, 2 May 2002 06:33:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 93D655DD99 for ; Thu, 2 May 2002 06:33:45 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g42AY3n04703 for ; Thu, 2 May 2002 13:34:04 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 13:33:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 2 May 2002 13:33:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Result codes in vendor specific applications Date: Thu, 2 May 2002 13:33:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65091@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Result codes in vendor specific applications Thread-Index: AcHvUKTYyG1beW6KShm2wvjzP6ZaXgCdCU9w From: To: , , X-OriginalArrivalTime: 02 May 2002 10:33:42.0279 (UTC) FILETIME=[D46B9970:01C1F1C4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA09216 Hi all, This now has been fixed, in the upcoming version 11. John > -----Original Message----- > From: ext Miguel-Angel.Pallares-Lopez@ece.ericsson.se > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > Sent: 29 April, 2002 10:34 > To: Loughney John (NRC/Helsinki); mjones@bridgewatersystems.com; > aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > Hi, > > One minor editorial comment: > > Where it says: > "All Diameter answer messages defined in vendor-specific > applications MUST include either one Result-Code AVP or one > Vendor-Specific-Result-Code AVP." > > It should say: > "All Diameter answer messages defined in vendor-specific > applications MUST include either one Result-Code AVP or one > Vendor-Specific-Result AVP." > > Regards, > Miguel > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Wednesday, April 24, 2002 6:35 AM > > To: mjones@bridgewatersystems.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Result codes in vendor specific applications > > > > > > Hi all, > > > > I think that this can be accomadated - does anyone have misgivings > > about this? > > > > John > > > > > -----Original Message----- > > > From: ext Mark Jones [mailto:mjones@bridgewatersystems.com] > > > Sent: 22 April, 2002 23:45 > > > To: aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: Result codes in vendor specific > applications > > > > > > > > > As I stated earlier, my preference is for a single result > > > code per message. > > > If this is acceptable to the WG then building on > > > Miguel-Angel's earlier text > > > submission, the following changes are required to the Base > > > protocol draft: > > > > > > --- > > > > > > Modify section 7.1, replacing: "All Diameter answer messages > > > MUST include > > > one Result-Code AVP" with "All Diameter answer messages > > > defined in IETF > > > applications MUST include one Result-Code AVP." > > > > > > --- > > > > > > Add two new sub-sections to section 7: > > > > > > 7.x Vendor-Specific-Result AVP > > > > > > The Vendor-Specific-Result AVP (AVP Code tbd) is of type > > Grouped, and > > > indicates whether a particular vendor-specific request > was completed > > > successfully or whether an error occurred. Its Data field has > > > the following > > > ABNF grammar: > > > > > > Vendor-Specific-Result ::= < AVP Header: tbd > > > > { Vendor-Id } > > > { Vendor-Specific-Result-Code } > > > > > > The Vendor-Id AVP (see Section 5.3.3) in this grouped AVP > > > identifies the > > > vendor responsible for the assignment of the result code > > > which follows. All > > > Diameter answer messages defined in vendor-specific > > applications MUST > > > include either one Result-Code AVP or one > > > Vendor-Specific-Result-Code AVP. > > > > > > 7.y Vendor-Specific-Result-Code AVP > > > > > > The Vendor-Specific-Result-Code AVP (AVP Code TBD) is of type > > > Unsigned32 and > > > contains a vendor-assigned value representing the result of > > > processing the > > > request. > > > > > > It is recommended that vendor-specific result codes > follow the same > > > conventions given for the Result-Code AVP regarding the > > > different types of > > > result codes and the handling of errors (for non 2xxx values). > > > > > > --- > > > > > > In chapter 4.6: > > > > > > After: > > > ... > > > Vendor-Specific- 260 6.10 Grouped | M | P | | V | N | > > > Application-Id | | | | | | > > > > > > Add: > > > > > > Vendor-Specific- TBD 7.x Grouped | M | P | | V | N | > > > Result | | | | | | > > > Vendor-Specific- TBD 7.y Unsigned32 | M | P | | V | N | > > > Result-Code | | | | | | > > > > > > Regards, > > > Mark > > > > > > > > > From owner-aaa-wg@merit.edu Thu May 2 06:46:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10214 for ; Thu, 2 May 2002 06:46:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A99239129E; Thu, 2 May 2002 06:46:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56510912A2; Thu, 2 May 2002 06:46:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77E679129E for ; Thu, 2 May 2002 06:46:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3AF845DF23; Thu, 2 May 2002 06:46:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 76C555DD99 for ; Thu, 2 May 2002 06:46:27 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g42Akjn13471 for ; Thu, 2 May 2002 13:46:46 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 13:46:26 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 2 May 2002 13:46:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: delete Snd-Conn-Ack Date: Thu, 2 May 2002 13:46:25 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65095@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: delete Snd-Conn-Ack Thread-Index: AcHwzX5ZTg8YBaR7QderLdhgGahy5wA+Q1ng From: To: , Cc: X-OriginalArrivalTime: 02 May 2002 10:46:26.0444 (UTC) FILETIME=[9BE5ECC0:01C1F1C6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10214 Hi all, I agree - this is not used at all, I don't see the purpose of it, so I shall delete it. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 01 May, 2002 07:17 > To: Liu Qiong Bo > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: delete Snd-Conn-Ack > > > Filed as an adjunct to Issue #339. > > On Fri, 26 Apr 2002, Liu Qiong Bo wrote: > > > Hi. > > > > in base-10, section 5.6.3, one action named Snd-Conn-Ack is > defined, but it > > doesn't appear in the peer state machine. Therefore suggest > to delete this > > action from the document. > > > > regards. > > > > Coral > > > > From owner-aaa-wg@merit.edu Thu May 2 12:16:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10442 for ; Thu, 2 May 2002 12:16:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73E9D912AF; Thu, 2 May 2002 12:16:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D348912B0; Thu, 2 May 2002 12:16:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EED69912AF for ; Thu, 2 May 2002 12:16:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B91135DE15; Thu, 2 May 2002 12:16:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 42C975DDB9 for ; Thu, 2 May 2002 12:16:23 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g42GGMl16494; Thu, 2 May 2002 11:16:22 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g42GGMS14716; Thu, 2 May 2002 11:16:22 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA01877; Thu, 2 May 2002 11:16:22 -0500 (CDT) Received: from ericsson.com (busam52.berkeley.us.am.ericsson.se [138.85.159.202]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA13855; Thu, 2 May 2002 11:16:21 -0500 (CDT) Message-ID: <3CD1658B.95BDAC6C@ericsson.com> Date: Thu, 02 May 2002 09:12:59 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65074@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John and Johan, john.loughney@nokia.com wrote: > Hi Johan, > > > Requested change: > > > > The Diameter protocol's Session-Id AVP, which is globally unique (see > > section 8.8), is used during the authorization phase to identify a > > particular session. Services that do not require any authorization > > still use the Session-Id AVP to identify sessions. > > > > to > > > > The Diameter protocol's Session-Id AVP, which is globally unique (see > > section 8.8), is used during the authorization phase to identify a > > particular session. Services that do not require any authorization > > still use the Session-Id AVP to identify sessions. Accounting messages > > MUST use a different Session-Id from that sent in > > authorization messages. > > Somehow, the "MUST use" part of the last sentence worries me. I think > that it may be more application specific. I'd prefer to state something > more like: > > Accounting messages MAY use a different Session-Id from that sent in > authorization messages. Specific applications MAY require different > a Session-ID for accounting messages. > I agree on a MAY in the Base, which would make the mip-10 work perfectly fine as is, thus no MAY needs to be added in mip10. A MUST would be to strong and reduce the possibilities in mip-10 to actually make use of the initial session-Id received in the HAR as the acct-multi-seesion-id through out the users authorized registration time. Regards, /Tony From owner-aaa-wg@merit.edu Thu May 2 13:21:32 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16300 for ; Thu, 2 May 2002 13:21:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77DAF912B7; Thu, 2 May 2002 13:18:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 729A7912B9; Thu, 2 May 2002 13:18:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0C6C912B7 for ; Thu, 2 May 2002 13:18:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FD9F5DDF9; Thu, 2 May 2002 13:18:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 186C25DD9A for ; Thu, 2 May 2002 13:18:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g42GWJF30940; Thu, 2 May 2002 09:32:19 -0700 Date: Thu, 2 May 2002 09:32:19 -0700 (PDT) From: Bernard Aboba To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions In-Reply-To: <3CD1658B.95BDAC6C@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Question: shouldn't Session-ID AVP be both globally *and* temporally unique? Globally so that it is unique to a NAS, and temporally so that it doesn't repeat (and can be used for liveness to prevent things like CMS cut and past attacks). BA From owner-aaa-wg@merit.edu Thu May 2 18:36:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16811 for ; Thu, 2 May 2002 18:36:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AC15912D0; Thu, 2 May 2002 18:35:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA5BB912D3; Thu, 2 May 2002 18:35:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C254912D0 for ; Thu, 2 May 2002 18:34:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05EE85DD93; Thu, 2 May 2002 18:34:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 8374A5DD8C for ; Thu, 2 May 2002 18:34:16 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g42MYGl24934; Thu, 2 May 2002 17:34:16 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g42MYFS03174; Thu, 2 May 2002 17:34:15 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA15380; Thu, 2 May 2002 17:34:14 -0500 (CDT) Received: from ericsson.com (busam52.berkeley.us.am.ericsson.se [138.85.159.202]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA19089; Thu, 2 May 2002 17:34:13 -0500 (CDT) Message-ID: <3CD1BE1C.B99064E0@ericsson.com> Date: Thu, 02 May 2002 15:30:52 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I thought that the Session-Id AVP MUST *always* be globally unique, as stated in Base section 8.8 : "The Session-Id MUST be globally and eternally unique, as it is meant to uniquely identify a user session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below." But I'm not really sure that I've understood your point :) /Tony Bernard Aboba wrote: > Question: shouldn't Session-ID AVP be both globally *and* temporally > unique? Globally so that it is unique to a NAS, and temporally so that it > doesn't repeat (and can be used for liveness to prevent things like CMS > cut and past attacks). > > BA From owner-aaa-wg@merit.edu Thu May 2 18:51:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17135 for ; Thu, 2 May 2002 18:51:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63746912D3; Thu, 2 May 2002 18:51:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 391F7912D6; Thu, 2 May 2002 18:51:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BB4C912D3 for ; Thu, 2 May 2002 18:51:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 113C55DDAA; Thu, 2 May 2002 18:51:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8CD0C5DD8C for ; Thu, 2 May 2002 18:51:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g42M57916759; Thu, 2 May 2002 15:05:07 -0700 Date: Thu, 2 May 2002 15:05:07 -0700 (PDT) From: Bernard Aboba To: Tony Johansson Cc: john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions In-Reply-To: <3CD1BE1C.B99064E0@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I guess "eternally unique" means that it never repeats, which is the same as "temporally unique", so that this is covered. One question though is whether the session-ID can obviate the need for a Nonce AVP with respect to replay prevention. On Thu, 2 May 2002, Tony Johansson wrote: > I thought that the Session-Id AVP MUST *always* be globally unique, as stated > in Base section 8.8 : > > "The Session-Id MUST be globally and eternally unique, as it is meant > to uniquely identify a user session without reference to any other > information, and may be needed to correlate historical authentication > information with accounting information. The Session-Id includes a > mandatory portion and an implementation-defined portion; a > recommended format for the implementation-defined portion is outlined > below." > > But I'm not really sure that I've understood your point :) > > /Tony > > > Bernard Aboba wrote: > > > Question: shouldn't Session-ID AVP be both globally *and* temporally > > unique? Globally so that it is unique to a NAS, and temporally so that it > > doesn't repeat (and can be used for liveness to prevent things like CMS > > cut and past attacks). > > > > BA > From owner-aaa-wg@merit.edu Fri May 3 00:07:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24950 for ; Fri, 3 May 2002 00:07:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7CC4912E3; Fri, 3 May 2002 00:07:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A895B912E7; Fri, 3 May 2002 00:07:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADFB3912E3 for ; Fri, 3 May 2002 00:07:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A3A75DDC8; Fri, 3 May 2002 00:07:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id A7E0C5DD95 for ; Fri, 3 May 2002 00:07:33 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4346VO13183 for ; Fri, 3 May 2002 07:06:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 May 2002 07:07:32 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 3 May 2002 07:07:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions Date: Fri, 3 May 2002 07:07:31 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC650B1@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions Thread-Index: AcHyK9RnVb7JY1BLQPCSQzlD1s1dBgALAbeA From: To: , Cc: , X-OriginalArrivalTime: 03 May 2002 04:07:32.0609 (UTC) FILETIME=[0CA24710:01C1F258] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA24950 Hi Bernard, > I guess "eternally unique" means that it never repeats, which > is the same > as "temporally unique", so that this is covered. One question > though is > whether the session-ID can obviate the need for a Nonce AVP > with respect to replay prevention. I think that the security area prefers more randomness, that way it is not possible to guess the sequence number based upon seeing previous messages. John From owner-aaa-wg@merit.edu Fri May 3 02:22:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05649 for ; Fri, 3 May 2002 02:22:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 922DA912E7; Fri, 3 May 2002 02:22:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61D0F912EB; Fri, 3 May 2002 02:22:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70485912E7 for ; Fri, 3 May 2002 02:22:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 280D45DD9B; Fri, 3 May 2002 02:22:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A56185DD98 for ; Fri, 3 May 2002 02:22:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g435aDc09047; Thu, 2 May 2002 22:36:13 -0700 Date: Thu, 2 May 2002 22:36:13 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: tony.johansson@ericsson.com, johanj@ipunplugged.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC650B1@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > I guess "eternally unique" means that it never repeats, which > > is the same > > as "temporally unique", so that this is covered. One question > > though is > > whether the session-ID can obviate the need for a Nonce AVP > > with respect to replay prevention. > > I think that the security area prefers more randomness, that > way it is not possible to guess the sequence number based upon > seeing previous messages. The issue here, I think is replay. Nonces don't actually prevent replay unless the entities can keep a (potentially large) nonce cache. That's why IPsec packets contain a sequence number, not a nonce; the sequence number makes it possible to maintain a replay window. From owner-aaa-wg@merit.edu Fri May 3 04:36:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07179 for ; Fri, 3 May 2002 04:36:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3691991209; Fri, 3 May 2002 04:36:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA6EF91216; Fri, 3 May 2002 04:36:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7C3B91209 for ; Fri, 3 May 2002 04:36:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 864B65DDFD; Fri, 3 May 2002 04:36:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 96BE25DD8D for ; Fri, 3 May 2002 04:36:23 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g438ahn26736 for ; Fri, 3 May 2002 11:36:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 3 May 2002 11:36:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 3 May 2002 11:36:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth andaccountingsessions Date: Fri, 3 May 2002 11:36:21 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DDA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth andaccountingsessions Thread-Index: AcHyauz75VXZmtLnTsiOjhaOCiWIHwAEdL/Q From: To: Cc: , , X-OriginalArrivalTime: 03 May 2002 08:36:22.0567 (UTC) FILETIME=[9AD68B70:01C1F27D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA07179 Hi Bernard, > > > I guess "eternally unique" means that it never repeats, which > > > is the same > > > as "temporally unique", so that this is covered. One question > > > though is > > > whether the session-ID can obviate the need for a Nonce AVP > > > with respect to replay prevention. > > > > I think that the security area prefers more randomness, that > > way it is not possible to guess the sequence number based upon > > seeing previous messages. > > The issue here, I think is replay. Nonces don't actually > prevent replay > unless the entities can keep a (potentially large) nonce > cache. That's why > IPsec packets contain a sequence number, not a nonce; the > sequence number > makes it possible to maintain a replay window. OK - I agreed. A nonce is not needed, but a good sequence number is. So, does this go into the Diameter Header (I think the only way to remove part of the CMS dependency). Am I correctly understanding the problem? John From owner-aaa-wg@merit.edu Fri May 3 06:23:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08415 for ; Fri, 3 May 2002 06:23:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 099E4912EE; Fri, 3 May 2002 06:22:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C72F5912F0; Fri, 3 May 2002 06:22:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFA15912EE for ; Fri, 3 May 2002 06:22:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 966825DDED; Fri, 3 May 2002 06:22:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 43F145DD8D for ; Fri, 3 May 2002 06:22:54 -0400 (EDT) Received: from GWZ-W2K.cisco.com (ams-clip-vpn-dhcp4199.cisco.com [10.50.16.102]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id DAA03163; Fri, 3 May 2002 03:22:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20020503032124.00b5e470@franklin.cisco.com> X-Sender: gwz@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 May 2002 03:22:34 -0700 To: Tony Johansson From: Glen Zorn Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accountingsessions Cc: Bernard Aboba , john.loughney@nokia.com, johanj@ipunplugged.com, aaa-wg@merit.edu In-Reply-To: <3CD1BE1C.B99064E0@ericsson.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 03:30 PM 5/2/2002 -0700, Tony Johansson wrote: >I thought that the Session-Id AVP MUST *always* be globally unique, as stated >in Base section 8.8 : > > "The Session-Id MUST be globally and eternally unique, Yes, I think that "eternally" pretty much covers temporality ;-) >as it is meant > to uniquely identify a user session without reference to any other > information, and may be needed to correlate historical authentication > information with accounting information. The Session-Id includes a > mandatory portion and an implementation-defined portion; a > recommended format for the implementation-defined portion is outlined > below." > >But I'm not really sure that I've understood your point :) > >/Tony > > >Bernard Aboba wrote: > > > Question: shouldn't Session-ID AVP be both globally *and* temporally > > unique? Globally so that it is unique to a NAS, and temporally so that it > > doesn't repeat (and can be used for liveness to prevent things like CMS > > cut and past attacks). > > > > BA From owner-aaa-wg@merit.edu Fri May 3 10:44:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15899 for ; Fri, 3 May 2002 10:44:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B485912F7; Fri, 3 May 2002 10:44:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EDD6912F8; Fri, 3 May 2002 10:44:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10756912F7 for ; Fri, 3 May 2002 10:44:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2E7B5DE17; Fri, 3 May 2002 10:44:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hugo.int-evry.fr (hugo.int-evry.fr [157.159.100.81]) by segue.merit.edu (Postfix) with ESMTP id 10D0C5DDA3 for ; Fri, 3 May 2002 10:44:06 -0400 (EDT) Received: from jobim (jobim [157.159.100.41]) by hugo.int-evry.fr (8.8.8/jtpda-5.3) with ESMTP id QAA25734 for ; Fri, 3 May 2002 16:43:57 +0200 (MET DST) Date: Fri, 3 May 2002 16:44:00 +0200 (MET DST) From: julien Bournelle X-Sender: bournell@jobim Reply-To: julien.bournelle@int-evry.fr To: aaa-wg@merit.edu Subject: [AAA-WG]: [AAA-WG][issue]: Realm Routing Table and section 6.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Julien Bournelle Submitter email address: Julien.Bournelle@int-evry.fr Date first submitted: May 3, 2002 Document: base Comment type: E Priority: 2 Section: 2.7 and 6.1 Rationale/Explanation of issue: We have section 6.1: " When a message is received, the message is processed in the following order: 1. If the message is destined for the local host, the procedures listed in section 6.1.4 are followed. 2. If the message is intended for a Diameter peer with whom the local host is able to directly communicate, the procedures listed in section 6.1.5 are followed. This is known as Request Forwarding. 3. The procedures listed in section 6.1.6 are followed, which is known as Request Routing. 4. If none of the above is successful, an answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. " Concerning 2.: Maybe it could be nice to have a clear definiton of "a Diameter peer with whom the local host is able to directly communicate". Is it only a peer in the Diameter Peer table ? Concerning 3.: We must follow section 6.1.6 Section 6.1.6: " 6.1.6 Request Routing Diameter request message routing is done via realms. A Diameter message that is able to be proxied MUST include the target realm in the Destination-Realm AVP. The realm MAY be retrieved from the User- Name AVP, which is in the form of a Network Access Identifier (NAI). The realm portion of the NAI is inserted in the Destination-Realm AVP. Diameter agents MAY have a list of locally supported realms, and MAY have a list of externally supported realms. When a request is received that includes a realm that is not locally supported, the message is routed to the peer configured in the Realm Routing Table table (see section 2.8). " It appears that the only case for which we must use the Realm Routing Table not need LOCAL action. So is it useful to have this action in the Realm Routing Table ? May I miss something ? From owner-aaa-wg@merit.edu Fri May 3 10:56:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16164 for ; Fri, 3 May 2002 10:56:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0A799912F8; Fri, 3 May 2002 10:56:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA1C1912F9; Fri, 3 May 2002 10:56:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C86E2912F8 for ; Fri, 3 May 2002 10:56:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81BE75DE24; Fri, 3 May 2002 10:56:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by segue.merit.edu (Postfix) with ESMTP id AF87F5DDA3 for ; Fri, 3 May 2002 10:56:18 -0400 (EDT) Received: from ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by smtp.wineasy.se with ESMTP id g43EuCX29614; Fri, 3 May 2002 16:56:12 +0200 Message-ID: <3CD2A4D9.9010607@ipunplugged.com> Date: Fri, 03 May 2002 16:55:21 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65074@esebe004.NOE.Nokia.com> <3CD1658B.95BDAC6C@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >Hi John and Johan, > >john.loughney@nokia.com wrote: > >>Hi Johan, >> >>>Requested change: >>> >>> The Diameter protocol's Session-Id AVP, which is globally unique (see >>> section 8.8), is used during the authorization phase to identify a >>> particular session. Services that do not require any authorization >>> still use the Session-Id AVP to identify sessions. >>> >>>to >>> >>>The Diameter protocol's Session-Id AVP, which is globally unique (see >>>section 8.8), is used during the authorization phase to identify a >>>particular session. Services that do not require any authorization >>>still use the Session-Id AVP to identify sessions. Accounting messages >>>MUST use a different Session-Id from that sent in >>>authorization messages. >>> >>Somehow, the "MUST use" part of the last sentence worries me. I think >>that it may be more application specific. I'd prefer to state something >>more like: >> >> Accounting messages MAY use a different Session-Id from that sent in >> authorization messages. Specific applications MAY require different >> a Session-ID for accounting messages. >> > >I agree on a MAY in the Base, which would make the mip-10 work perfectly fine >as is, thus no MAY needs to be added in mip10. A MUST would be to strong and >reduce the possibilities in mip-10 to actually make use of the initial >session-Id received in the HAR as the acct-multi-seesion-id through out the >users authorized registration time. > I'm not sure I understand why it would stop the use of the id in the HAR as the acct-multi-session-id. I was only talking about the contents of the Session-Id AVP. In any case, after suitable consultations and deliberations I think you and John are right. A MAY would be sufficient but forces the server to handle both cases. That works for me. Well spotted. j From owner-aaa-wg@merit.edu Mon May 6 20:03:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11589 for ; Mon, 6 May 2002 20:03:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B72B191268; Mon, 6 May 2002 20:03:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C10691263; Mon, 6 May 2002 20:03:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC80B91263 for ; Mon, 6 May 2002 20:02:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 606B15DE78; Mon, 6 May 2002 20:02:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2433C5DE77 for ; Mon, 6 May 2002 20:02:48 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g47037n06054 for ; Tue, 7 May 2002 03:03:07 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 May 2002 03:02:47 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 03:02:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in failover state machine Date: Tue, 7 May 2002 03:02:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECCB@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in failover state machine Thread-Index: AcHszBykuJgeRTqIRmyT7uCKlqlkbgIUBW4A From: To: , X-OriginalArrivalTime: 07 May 2002 00:02:47.0221 (UTC) FILETIME=[851CE650:01C1F55A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11589 Hi, I believe closed refers to the AAA session. Down refers to the transport session below Diameter. I think that your requested solution is not needed as we have made an effort to seperate the Transport section from the Base draft. John > -----Original Message----- > From: ext Liu Qiong Bo [mailto:liuqb@cwc.nus.edu.sg] > Sent: 26 April, 2002 05:46 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in > failover state machine > > > Submitter name: Qiong Bo Liu > Submitter email address: liuqb@cwc.nus.edu.sg > Date first submitted: April 26, 2002 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03954.html > Document: base-10, transport-07 > Comment type: T > Priority: ? > Section: 5.6 in base, 3.4.1 and appendix A in transport > > Rationale/Explanation of issue: > in Diameter base protocol-10, section5.6, the 2nd paragraph: > "This state > machine is closely coupled with the state machine described > in [AAATRANS], > which is used to open, close, failover, probe, and reopen transport > connections. Note in particular that [AAATRANS] requires the use of > watchdog messages to probe connections. For Diameter, DWR and > DWA messages > are to be used." > > in transport-07, appendix A, there is a failover state > machine with a state > of DOWN. > > In the state of DOWN, does it mean that this transport connection is > closed, and the related socket is closed. hence when tw time > expires, the > diameter node try to open another socket and try to connect > to the peer? > > If it is, then what is the difference between DOWN and closed? > > Requested change: > suggest to give a complete peer state machine combining with > failover state > machine > > From owner-aaa-wg@merit.edu Mon May 6 20:03:58 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11611 for ; Mon, 6 May 2002 20:03:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5FDA391262; Mon, 6 May 2002 20:03:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2521E91267; Mon, 6 May 2002 20:03:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5FFC91262 for ; Mon, 6 May 2002 20:02:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C8465DE78; Mon, 6 May 2002 20:02:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7BBEB5DE43 for ; Mon, 6 May 2002 20:02:47 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g47045G18997 for ; Tue, 7 May 2002 03:04:05 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 7 May 2002 03:02:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 03:02:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 235 - seperation of CMS from base Date: Tue, 7 May 2002 03:02:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECCA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Thread-Index: AcHysq6PBmoPopw/TJeO4skrzW4bcgCZ9iqw From: To: X-OriginalArrivalTime: 07 May 2002 00:02:46.0907 (UTC) FILETIME=[84ECFCB0:01C1F55A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11611 Hi all, There have been some discussions on how to remove the CMS dependencies from the Base draft. Some suggestions included having a session-id, event-timestamp and/or nonce to protect against various things, including replay attacks. Rough definitions are: Session ID Session-ID is globally and temporally unique, as well as monotically increasing, it can serve as a liveness check. Event-Timestamp The Event-Timestamp is of type Time, and MAY be included to record the time that this event occurred, in seconds since January 1, 1970 00:00 UTC. Nonce The Nonce is of type OctetString. It is RECOMMENDED that it contains a psuedo-random value of at least 128 bits, meeting criteria detailed in "Randomness Recommendations for Security" RFC 1750. ==== I think that a Nonce is not needed, if the session-id & event-timestamp are used (and have been defined rigourously). Additional text needed would be: Diameter messages are subject to various deliberate and accidental threats, in particular messages may be replayed and if a replayed message is processed a number of times that might cause harm. In order to assist Diameter nodes in detecting replay the Session-ID and Event-Timestamp AVPs are defined in section X.X.X.X and these AVPs SHOULD be included in all messages where replay can cause harm. Note however, that without additional protection, these AVPs are subject to (accidental or deliberate) modification by any Diameter node. For this reason replay detection is only really effective where an end-to-end security mechanism (like [CMS]) is used to provide data integrity over those AVPs." I think I need to check on which messages these need to be included on, most likely at least some of the accounting messages. Can anyone comment on what additionally is needed to finish this issue? John From owner-aaa-wg@merit.edu Mon May 6 20:04:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11630 for ; Mon, 6 May 2002 20:04:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A28591264; Mon, 6 May 2002 20:03:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2822F91311; Mon, 6 May 2002 20:03:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15AB491264 for ; Mon, 6 May 2002 20:02:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AC9B5DE77; Mon, 6 May 2002 20:02:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E18955DE43 for ; Mon, 6 May 2002 20:02:48 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g47038n06061 for ; Tue, 7 May 2002 03:03:08 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 May 2002 03:02:44 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 03:02:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Question on Relaying Answers Section 6.2.2 Date: Tue, 7 May 2002 03:02:47 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECCD@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Question on Relaying Answers Section 6.2.2 Thread-Index: AcHsjMXTrR1St5jPQ+yCrHXOma0eVwIkDrig From: To: , X-OriginalArrivalTime: 07 May 2002 00:02:48.0119 (UTC) FILETIME=[85A5EC70:01C1F55A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11630 Hi Dilip, > I was reading the base protocol Section 6.2.2 > > Its states > "The agent MUST then send the answer to the host that > it received the original request from." > > Question: > What if the Host where this answer has to be sent is > DOWN(i.e connection has lost) You should look at the state machines in section 5.6, 8.1 and 8.2. It depends on what kind of session you have and what messages you are using. The host is the endpoint of the Diameter session, and if it is DOWN, there may be need for failover or session termination, for example. thanks, John From owner-aaa-wg@merit.edu Mon May 6 20:04:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11647 for ; Mon, 6 May 2002 20:04:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1209C91263; Mon, 6 May 2002 20:03:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D97191316; Mon, 6 May 2002 20:03:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CAFF91265 for ; Mon, 6 May 2002 20:02:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAF3E5DE77; Mon, 6 May 2002 20:02:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 0D2725DE43 for ; Mon, 6 May 2002 20:02:57 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4703Gn06116 for ; Tue, 7 May 2002 03:03:16 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 May 2002 03:02:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 7 May 2002 03:02:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [AAA-WG][issue]: Realm Routing Table and section 6.1 Date: Tue, 7 May 2002 03:02:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECDD@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [AAA-WG][issue]: Realm Routing Table and section 6.1 Thread-Index: AcHysQjrVIv7zUnqS/2WQIlUl6s2cwCgCBhQ From: To: , X-OriginalArrivalTime: 07 May 2002 00:02:56.0299 (UTC) FILETIME=[8A8617B0:01C1F55A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA11647 Hi Julien, Section 6.1 is a general recommendation section. I think that some implementation flexibility can be used. I think that the text in 6.1 is good, I would not want to make the text any more tight. I don't see any interoperability issues here - so I think that no changes are needed. John > We have section 6.1: > " > When a message is received, the message is processed in the > following > order: > 1. If the message is destined for the local host, the procedures > listed in section 6.1.4 are followed. > 2. If the message is intended for a Diameter peer with whom the > local host is able to directly communicate, the procedures > listed in section 6.1.5 are followed. This is known as Request > Forwarding. > 3. The procedures listed in section 6.1.6 are followed, which is > known as Request Routing. > 4. If none of the above is successful, an answer is returned with > the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. > " > > Concerning 2.: > > Maybe it could be nice to have a clear definiton of "a Diameter peer with whom > the local host is able to directly communicate". Is it only a peer in the > Diameter Peer table ? > > Concerning 3.: > > We must follow section 6.1.6 > > Section 6.1.6: > " > 6.1.6 Request Routing > > Diameter request message routing is done via realms. A Diameter > message that is able to be proxied MUST include the target realm in > the Destination-Realm AVP. The realm MAY be retrieved from > the User- > Name AVP, which is in the form of a Network Access > Identifier (NAI). > The realm portion of the NAI is inserted in the Destination-Realm > AVP. > > Diameter agents MAY have a list of locally supported > realms, and MAY > have a list of externally supported realms. When a request is > received that includes a realm that is not locally supported, the > message is routed to the peer configured in the Realm Routing Table > table (see section 2.8). > " > > It appears that the only case for which we must use the Realm > Routing Table > not need LOCAL action. So is it useful to have this action in > the Realm Routing > Table ? > > May I miss something ? > > > > > From owner-aaa-wg@merit.edu Mon May 6 21:37:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13155 for ; Mon, 6 May 2002 21:37:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 779779126A; Mon, 6 May 2002 21:37:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 475DF9126B; Mon, 6 May 2002 21:37:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4973C9126A for ; Mon, 6 May 2002 21:37:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9BC75DE87; Mon, 6 May 2002 21:37:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7374E5DE85 for ; Mon, 6 May 2002 21:37:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g470pBs25437; Mon, 6 May 2002 17:51:11 -0700 Date: Mon, 6 May 2002 17:51:11 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 235 - seperation of CMS from base In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECCA@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Can anyone comment on what additionally is needed to finish this > issue? The text seems to imply that there is a vulnerability to replay on a hop-by-hop basis if these AVPs are not included. Since both IPsec and TLS provide replay protection, that really isn't the issue. The issue is replay of CMS objects -- cutting and pasting a CMS object from one Diameter message to another. I think this implies that the individual CMS objects need to include replay protection. From owner-aaa-wg@merit.edu Tue May 7 02:09:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25827 for ; Tue, 7 May 2002 02:09:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23C7891271; Tue, 7 May 2002 02:09:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3C8791272; Tue, 7 May 2002 02:09:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEEA691271 for ; Tue, 7 May 2002 02:09:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B3915DDE9; Tue, 7 May 2002 02:09:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by segue.merit.edu (Postfix) with ESMTP id 926D45DD92 for ; Tue, 7 May 2002 02:09:12 -0400 (EDT) Received: from liuqb.cwc.nus.edu.sg (liuqb.cwc.nus.edu.sg [172.16.3.32]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id OAA00229; Tue, 7 May 2002 14:07:43 +0800 (SGT) Message-Id: <4.3.2.7.2.20020507135839.00b75728@postman.cwc.nus.edu.sg> X-Sender: liuqb@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 May 2002 14:19:12 +0800 To: john.loughney@nokia.com From: Liu Qiong Bo Subject: RE: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in failover state machine Cc: aaa-wg@merit.edu In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD8ECCB@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi. At 03:02 AM 5/7/2002 +0300, you wrote: >Hi, > >I believe closed refers to the AAA session. Down refers to the transport >session below Diameter. "This state machine is closely coupled with the state machine described in [AAATRANS]." Shall I say that if the transport session is in DOWN state, the AAA session must be in the Closed state? and even if the transport session is in the SUSPECT state, the AAA session will be still in the R-Open/I-Open State? If it was, then what is the relationship between these two kinds of states? Regards. >I think that your requested solution is not needed as we have made an >effort to seperate the Transport section from the Base draft. > >John > > > -----Original Message----- > > From: ext Liu Qiong Bo [mailto:liuqb@cwc.nus.edu.sg] > > Sent: 26 April, 2002 05:46 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in > > failover state machine > > > > > > Submitter name: Qiong Bo Liu > > Submitter email address: liuqb@cwc.nus.edu.sg > > Date first submitted: April 26, 2002 > > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03954.html > > Document: base-10, transport-07 > > Comment type: T > > Priority: ? > > Section: 5.6 in base, 3.4.1 and appendix A in transport > > > > Rationale/Explanation of issue: > > in Diameter base protocol-10, section5.6, the 2nd paragraph: > > "This state > > machine is closely coupled with the state machine described > > in [AAATRANS], > > which is used to open, close, failover, probe, and reopen transport > > connections. Note in particular that [AAATRANS] requires the use of > > watchdog messages to probe connections. For Diameter, DWR and > > DWA messages > > are to be used." > > > > in transport-07, appendix A, there is a failover state > > machine with a state > > of DOWN. > > > > In the state of DOWN, does it mean that this transport connection is > > closed, and the related socket is closed. hence when tw time > > expires, the > > diameter node try to open another socket and try to connect > > to the peer? > > > > If it is, then what is the difference between DOWN and closed? > > > > Requested change: > > suggest to give a complete peer state machine combining with > > failover state > > machine > > > > From owner-aaa-wg@merit.edu Tue May 7 17:31:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24726 for ; Tue, 7 May 2002 17:31:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA0E791278; Tue, 7 May 2002 17:31:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9349C9127C; Tue, 7 May 2002 17:31:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB34891278 for ; Tue, 7 May 2002 17:31:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 205285DE68; Tue, 7 May 2002 17:31:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 902655DD90 for ; Tue, 7 May 2002 17:31:16 -0400 (EDT) Received: (from gdweber@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA07000; Tue, 7 May 2002 17:31:15 -0400 (EDT) From: Greg Weber Message-Id: <200205072131.RAA07000@cisco.com> Subject: [AAA-WG]: [issue] Usage of 'Diameter process' confusing To: aaa-wg@merit.edu Date: Tue, 7 May 2002 17:31:15 -0400 (EDT) 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-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Usage of 'Diameter process' confusing Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: 5/7/2002 Reference: none Document: base Comment type: 'E'ditorial Priority: '2' May fix Section: 2.1 Transport Rationale/Explanation of issue: Regarding this this text: "A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and MUST be prepared to receive connections on port TBD. A given Diameter process MUST NOT use more than one transport connection to communicate with a given peer, unless multiple processes exist on the peer in which case a separate connection per process is allowed." The term "process" seems to be used in an operating system specific manner. This may be confusing, e.g. what is the 'Diameter process' in a JVM implementation where there are no processes, only threads. We should be explicit as we are expressing what MUST NOT be done. 'Diameter process' is not defined elsewhere in the draft. Requested change: I suggest changing "process" to "instance of the peer state machine" From owner-aaa-wg@merit.edu Tue May 7 20:38:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27873 for ; Tue, 7 May 2002 20:38:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32EAC9128C; Tue, 7 May 2002 20:38:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0291D9128E; Tue, 7 May 2002 20:38:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EF7B9128C for ; Tue, 7 May 2002 20:38:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 660BD5DE9D; Tue, 7 May 2002 20:38:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F372E5DDA0 for ; Tue, 7 May 2002 20:38:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g47Nq3V05030; Tue, 7 May 2002 16:52:03 -0700 Date: Tue, 7 May 2002 16:52:03 -0700 (PDT) From: Bernard Aboba To: Greg Weber Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of 'Diameter process' confusing In-Reply-To: <200205072131.RAA07000@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #340. On Tue, 7 May 2002, Greg Weber wrote: > Usage of 'Diameter process' confusing > Submitter name: Greg Weber > Submitter email address: gdweber@cisco.com > Date first submitted: 5/7/2002 > Reference: none > Document: base > Comment type: 'E'ditorial > Priority: '2' May fix > Section: 2.1 Transport > Rationale/Explanation of issue: From owner-aaa-wg@merit.edu Tue May 7 20:45:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27978 for ; Tue, 7 May 2002 20:45:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F218B9128F; Tue, 7 May 2002 20:45:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6428C91290; Tue, 7 May 2002 20:45:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6BADF9128F for ; Tue, 7 May 2002 20:45:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B04A5DE9D; Tue, 7 May 2002 20:45:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7BA675DDA0 for ; Tue, 7 May 2002 20:45:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g47Nwlk05379; Tue, 7 May 2002 16:58:47 -0700 Date: Tue, 7 May 2002 16:58:47 -0700 (PDT) From: Bernard Aboba To: julien.bournelle@int-evry.fr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [AAA-WG][issue]: Realm Routing Table and section 6.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned issue #341. On Fri, 3 May 2002, julien Bournelle wrote: > Submitter name: Julien Bournelle > Submitter email address: Julien.Bournelle@int-evry.fr > Date first submitted: May 3, 2002 > Document: base > Comment type: E > Priority: 2 > Section: 2.7 and 6.1 > Rationale/Explanation of issue: From owner-aaa-wg@merit.edu Wed May 8 04:13:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28639 for ; Wed, 8 May 2002 04:13:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CF5F9129F; Wed, 8 May 2002 04:13:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CAC7912A0; Wed, 8 May 2002 04:13:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 102BC9129F for ; Wed, 8 May 2002 04:13:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B00D5DDDA; Wed, 8 May 2002 04:13:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by segue.merit.edu (Postfix) with ESMTP id 1E7C25DD91 for ; Wed, 8 May 2002 04:13:08 -0400 (EDT) Received: from liuqb.cwc.nus.edu.sg (liuqb.cwc.nus.edu.sg [172.16.3.32]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id QAA29972 for ; Wed, 8 May 2002 16:11:51 +0800 (SGT) Message-Id: <4.3.2.7.2.20020508161931.00ba8160@postman.cwc.nus.edu.sg> X-Sender: liuqb@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 16:23:26 +0800 To: aaa-wg@merit.edu From: Liu Qiong Bo Subject: [AAA-WG]: authorization session state machine Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi. I think it is not described when the RAR will be sent by the server to the client in the authorization session state machine. (base draft 10) Maybe I missed something? regards. coral liu From owner-aaa-wg@merit.edu Wed May 8 12:10:43 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14858 for ; Wed, 8 May 2002 12:10:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 937B1912C1; Wed, 8 May 2002 12:07:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15308912BD; Wed, 8 May 2002 12:07:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE39B912C1 for ; Wed, 8 May 2002 12:05:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12EE55DDEB; Wed, 8 May 2002 12:05:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7CA365DD9B for ; Wed, 8 May 2002 12:05:55 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g48FJYg24615 for ; Wed, 8 May 2002 08:19:34 -0700 Date: Wed, 8 May 2002 08:19:34 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Resolution of Issue 235 - CMS replay attacks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk OK. I think the approach below solves the problem. As I understand it, you're suggesting including anti-replay AVPs in all messages, and protecting them with CMS when the processing rules indicate that. Bernard ------------------------------------------------------------------ Stephen Farrell spake thusly: "The E2E-Sequence AVP provides anti-replay protection for end to end messages and is of type grouped. It contains a random value (an OctetString with a nonce) and counter (an Integer). For each end-to-end peer with which a node communicates (or remembers communicating) a different nonce value MUST be used and the counter is intitiated at zero and increases by one each time this AVP is emitted to that peer. This AVP MUST be included in all messages which use end-to-end protection (e.g. CMS signing or encryption)." Assuming this only applies to CMS-protected stuff, I should have included a sentence like: "The recipient MUST reject the message if the E2E-Sequence and Event-Timestamp AVPs were not protected using end-to-end (e.g. CMS) protection that provides protection against substitution and replacement attacks." I'm not stating anything about IPsec or TLS (though there was a recent TLS thread with a hint that a relevant vulnerability could exist in some TLS-like protocols). What I do mean is that if a message is being send end to end, but without CMS protection, then there's still a value in including the anti-replay AVPs since you then force a MITM to be an active attacker at the Diameter message level (i.e. they have to decode the messages and tweak those AVP values), so as a result you're more likely to detect the replay (perhaps only later when an honest node re-uses a value via a different, honest, proxy). Stephen. From owner-aaa-wg@merit.edu Wed May 8 12:16:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15150 for ; Wed, 8 May 2002 12:16:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAEB391323; Wed, 8 May 2002 12:15:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE104912FA; Wed, 8 May 2002 12:15:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAF81912B7 for ; Wed, 8 May 2002 12:15:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F2AE5DDCA; Wed, 8 May 2002 12:15:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 5B0805DD9B for ; Wed, 8 May 2002 12:15:48 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g48GFmk30270 for ; Wed, 8 May 2002 17:15:48 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 8 May 2002 17:10:06 +0100 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA04808; Wed, 8 May 2002 17:15:45 +0100 Message-ID: <3CD94F37.82D652AA@baltimore.ie> Date: Wed, 08 May 2002 17:15:51 +0100 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: [AAA-WG]: Re: Resolution of Issue 235 - CMS replay attacks References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Exactly. I'll copy whatever text is final into the next CMS draft too. Stephen. Bernard Aboba wrote: > > OK. I think the approach below solves the problem. As I > understand it, you're suggesting including anti-replay AVPs in > all messages, and protecting them with CMS when the processing rules > indicate that. > > Bernard > > ------------------------------------------------------------------ > Stephen Farrell spake thusly: > > "The E2E-Sequence AVP provides anti-replay protection for end to end > messages and is of type grouped. It contains a random value (an OctetString > with a nonce) and counter (an Integer). For each end-to-end peer with which > a node communicates (or remembers communicating) a different nonce value > MUST be used and the counter is intitiated at zero and increases by one each > time this AVP is emitted to that peer. This AVP MUST be included in all > messages which use end-to-end protection (e.g. CMS signing or encryption)." > > Assuming this only applies to CMS-protected stuff, I should have > included a sentence like: "The recipient MUST reject the message if the > E2E-Sequence and Event-Timestamp AVPs were not protected using end-to-end > (e.g. CMS) protection that provides protection against substitution and > replacement attacks." > > I'm not stating anything about IPsec or TLS (though there was a recent > TLS thread with a hint that a relevant vulnerability could exist in > some TLS-like protocols). What I do mean is that if a message is being > send end to end, but without CMS protection, then there's still a > value in including the anti-replay AVPs since you then force a MITM > to be an active attacker at the Diameter message level (i.e. they have > to decode the messages and tweak those AVP values), so as a result > you're more likely to detect the replay (perhaps only later when an > honest node re-uses a value via a different, honest, proxy). > > 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-wg@merit.edu Wed May 8 17:34:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24398 for ; Wed, 8 May 2002 17:34:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A45A8912BC; Wed, 8 May 2002 17:34:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DF8C912BD; Wed, 8 May 2002 17:34:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D968912BC for ; Wed, 8 May 2002 17:34:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FE4F5DEA4; Wed, 8 May 2002 17:33:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id E5E845DDD6 for ; Wed, 8 May 2002 17:33:58 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48LXxi05826 for ; Wed, 8 May 2002 16:33:59 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g48LXxx27449 for ; Wed, 8 May 2002 16:33:59 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA04482 for ; Wed, 8 May 2002 16:33:58 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA27991 for ; Wed, 8 May 2002 16:33:58 -0500 (CDT) Message-ID: <3CD998F7.F01E4031@ericsson.com> Date: Wed, 08 May 2002 14:30:31 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: text proposal to Issue 338 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Here is the text proposal to solve issue 338: Diameter Mobile IP application & backwards compatibility. Any objections / comments. Regards, /Tony In section 1.0 Introduction: Change: "Furthermore, the nature of mobile IP also means that the mobile node will do handoffs between different foreign agents and to guarantee that a registered user always ends up in the same initial AAAH the Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to assist the AAAH in routing the messages to a mobile node's home agent the mobile node MUST always include the HA NAI [AAANAI]." To: "Furthermore, the nature of mobile IP also means that the mobile node will do handoffs between different foreign agents. To guarantee that a registered user always ends up in the same initial AAAH, the mobile node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist the AAAH in routing the messages to a mobile node's home agent the mobile node SHOULD always include the HA NAI [AAANAI]." In section 1.2 Inter-Realm Mobile IP: Change: "A mobile node, which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, in the registration request message [AAANAI] which is sent to the FA every time the Mobile Node needs to re-authenticate. So, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent- Host AVP with the identity and realm of the assigned HA found in the HA-NAI." To: "A mobile node with AAA NAI extension support [AAANAI], which has been previously authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, when re-authenticating. So, in the event that the AMR generated by the FA is for a session that was previously authorized, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home- Agent- Host AVP with the identity and realm of the assigned HA found in the HA-NAI. If on the other hand the mobile node does not support the AAA NAI extension, the FA may not have the identity of the AAAH and the identity and realm of the assigned HA. This means that without support of the AAA NAI extension, the FA may not be able to guarantee, that the AMR well be destined to the same AAAH, which previously authenticated and authorized the mobile node, since the FA may not know the identity of the AAAH." In section 1.4 Allocation of Home Agent in Foreign Network: Change: "In the event that the mobile node has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR including the MIP- Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP." To: "In the event that the mobile node (with AAA NAI extension support [AAANAI]) has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and instead of the MIP- Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign- Network bit in the MIP-Feature-Vector AVP." From owner-aaa-wg@merit.edu Fri May 10 02:31:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08745 for ; Fri, 10 May 2002 02:31:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEF41912CF; Fri, 10 May 2002 02:30:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A529912D6; Fri, 10 May 2002 02:30:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39C8F912CF for ; Fri, 10 May 2002 02:30:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEDA35DDD3; Fri, 10 May 2002 02:30:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 593D05DDA8 for ; Fri, 10 May 2002 02:30:30 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4A6Umk12335 for ; Fri, 10 May 2002 09:30:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 10 May 2002 09:30:20 +0300 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 10 May 2002 09:30:26 +0300 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 10 May 2002 14:29:47 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Why two parsers: XML parser and AVP parser? Date: Fri, 10 May 2002 14:27:45 +0800 Message-ID: Thread-Topic: [AAA-WG]: Why two parsers: XML parser and AVP parser? Thread-Index: AcH37BZ1RPCTUmPRT8C+5fH9b2GAGA== From: To: X-OriginalArrivalTime: 10 May 2002 06:29:47.0137 (UTC) FILETIME=[14802710:01C1F7EC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA08745 Hi, The paragraph in http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-02.txt Section 2.5 says: ------------------------------------- 2.5 Command Dictionary File The commands that can be parsed by the local Diameter client library or server are defined in a command dictionary file containing the command definitions including AVPs. The location and name of the command dictionary file is platform-specific. This file is read and parsed to drive creation of a command dictionary which is used by the library to parse commands. The syntax for the command dictionary file is in XML and a DTD described it is available in [4]. XML was selected as the definition language because support for XML parsing is available as an extension to the standard Java APIs [5] and as a wide variety of public-domain C libraries, simplifying implementation. Both APIs also support programmatic definition of commands, AVPs, and extensions so programs can add commands not in the dictionary for purposes of experimentation and implementing the library. ------------------------------------- Is it a good reason that we adopt only one parser, say it, XML parser, in our diameter specifications? In other words, can we change those to-and-fro diameter messges into the XML format for the simplicity of our diameter implementations? Best regards, roger From owner-aaa-wg@merit.edu Fri May 10 09:41:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22188 for ; Fri, 10 May 2002 09:41:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6833791203; Fri, 10 May 2002 09:41:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3213591206; Fri, 10 May 2002 09:41:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A14B91203 for ; Fri, 10 May 2002 09:41:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DCCA95DDA1; Fri, 10 May 2002 09:41:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 611415DD93 for ; Fri, 10 May 2002 09:41:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4ACtLD15120 for ; Fri, 10 May 2002 05:55:21 -0700 Date: Fri, 10 May 2002 05:55:21 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: 3GPP2 TSG-P Liaison to IETF on Diameter (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Haeng S. Koo Chair, 3GPP2 TSG-P > Samsung Telecommunications America > 1130 E. Arapaho Road > Richardson, TX 75801 > hskoo@sta.samsung.com > April 26, 2002 > > Mr. Bernard Aboba, WG Chair, AAA > Mr. David Mitton, WG Chair, AAA > > Dear Bernard and David, > > 3GPP2 expresses its gratitude for the progress the IETF has made on > the Diameter Base, MIP, and Transport drafts, and we look forward to > having these in RFC form. It turns out, however, that 3GPP2 also needs > the NASREQ document since we support a PPP-only IP access mechanism, > in addition to Mobile IP over PPP. The former implies a Diameter > support requirement for PAP and CHAP. > > We understand that two Diameter > implementations interoperated at the last Diameter Connectathon with > respect to PAP and CHAP. Given that NASREQ has successfully > interoperated, 3GPP2 would like to request that the Diameter Editor > delete EAP functionality from the current NASREQ draft, and that the > draft be progressed to proposed standard. > > Our current planned release > would require an RFC status by July 2002 to be included in our next > cdma2000 packet data standard. > > Regards, > Haeng S. Koo Chair, 3GPP2 TSG-P > > Cc: > Randy Bush Area Director, Operations and Management Area randy@psg.com > Bert Wijnen Area Director, Operations and Management Area bwijnen@lucent.com > Thomas Narten IETF Liaison to 3GPP2 narten@us.ibm.com > Tom Hiller 3GPP2 Liaison to IETF tom.hiller@lucent.com > Steve Dennett 3GPP2 SC Chair S.Dennett@motorola.com > Henry Cuschieri 3GPP2 Secretariat hcuschie@tia.eia.org From owner-aaa-wg@merit.edu Fri May 10 14:09:53 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09204 for ; Fri, 10 May 2002 14:09:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73B2B912EC; Fri, 10 May 2002 14:07:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EFA6912E7; Fri, 10 May 2002 14:07:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A677F912E3 for ; Fri, 10 May 2002 14:07:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5AAD35DD94; Fri, 10 May 2002 14:07:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EA8355DE34 for ; Fri, 10 May 2002 14:07:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4AHKZQ29837; Fri, 10 May 2002 10:20:35 -0700 Date: Fri, 10 May 2002 10:20:35 -0700 (PDT) From: Bernard Aboba To: John Vollbrecht Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: 3GPP2 TSG-P Liaison to IETF on Diameter (fwd) In-Reply-To: <3CDBF6CB.FE12FF3B@interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Not required, but it would be helpful. Interoperability demonstration is only required for Draft standards. On Fri, 10 May 2002, John Vollbrecht wrote: > > Would EAP interoperability need to be demonstrated before NASREQ could > become and RFC? From owner-aaa-wg@merit.edu Sun May 12 14:19:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23758 for ; Sun, 12 May 2002 14:19:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2469A9122E; Sun, 12 May 2002 14:19:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECB239123A; Sun, 12 May 2002 14:19:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EA1B9122E for ; Sun, 12 May 2002 14:19:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C2F95DECB; Sun, 12 May 2002 14:19:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D5FC85DE0A for ; Sun, 12 May 2002 14:19:23 -0400 (EDT) Received: from localhost (httpd@localhost) by internaut.com (8.10.2/8.10.2) with SMTP id g4CHWe831837 for aaa-wg@merit.edu; Sun, 12 May 2002 10:32:41 -0700 Message-Id: <200205121732.g4CHWe831837@internaut.com> X-Authentication-Warning: internaut.com: httpd owned process doing -bs To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ roadmap Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Cobalt Webmail Date: Sun, 12 May 2002 10:32:40 -0700 From: Bernard Aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk Due to a request from 3GPP2, we are going to be splitting the NASREQ document into EAP and non-EAP documents. The goal will be to address the outstanding issues on the non-EAP portion of the document and bring that portion of the document to AAA WG last call ASAP. Since there are non-EAP NASREQ implementations already, the non-EAP portion of the document appears to be better understood. By splitting off the EAP portion of the NASREQ document, it will be possible to complete the non-EAP portion of NASREQ considerably sooner. We can then focus on the split-off EAP portion of the document on a separate schedule. From owner-aaa-wg@merit.edu Mon May 13 04:56:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00954 for ; Mon, 13 May 2002 04:56:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1B789125E; Mon, 13 May 2002 04:56:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B557B9125F; Mon, 13 May 2002 04:56:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A72DA9125E for ; Mon, 13 May 2002 04:56:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDBF15DD92; Mon, 13 May 2002 04:56:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 3575B5DD90 for ; Mon, 13 May 2002 04:56:20 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep01-svc.swip.net with ESMTP id <20020513085621.YHJD2422.fep01-svc.swip.net@ipunplugged.com>; Mon, 13 May 2002 10:56:21 +0200 Message-ID: <3CDF9C38.2000102@ipunplugged.com> Date: Mon, 13 May 2002 10:58:00 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony. I have no objections to the sections I cut out. Regarding the remainder below, would it be possible to reformulate this to make it clearer what a MN without AAA-NAI support needs to do and what the effect of not supporting AAA-NAI is? I may be wrong, but it seems to me that with the proper support from the home network, in particular AAAH assigned by nai hashing, the only thing that is truly impossible to solve is to keep the HA if the AAAH goes down. In any case, you've made the entire section conditional on the support of AAA-NAI. Surely we need a way to assign a home agent in a foreign network even in a backwards-compatibly solution? If not we should add a sentence saying that without AAA-NAI you cannot allocate a home agent in the visited net. j Tony Johansson wrote: >In section 1.4 Allocation of Home Agent in Foreign Network: > >Change: > > "In the event that the mobile node has been previously authorized by > the AAAH and now needs to be re-authenticated, and requests to keep > the assigned home agent in the foreign network, the mobile node MUST > include the HA NAI and the AAAH NAI in the registration request to > the FA. Upon receipt, the FA will create the AMR including the MIP- > Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH > NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the > MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF > authorizes the use of the requested home agent, the AAAF MUST set the > > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP." > >To: > > "In the event that the mobile node (with AAA NAI extension support > [AAANAI]) has been previously authorized by the AAAH and now needs to > > be re-authenticated, and requests to keep the assigned home agent in > the foreign network, the mobile node MUST include the HA NAI and the > AAAH NAI in the registration request to the FA. Upon receipt, the FA > will create the AMR including the MIP-Home-Agent-Address AVP, the > Destination-Host AVP based on the AAAH NAI and instead of the MIP- > Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP > based on the home agent NAI. If the AAAF authorizes the use of the > requested home agent, the AAAF MUST set the Home-Agent-In-Foreign- > Network bit in the MIP-Feature-Vector AVP." > > From owner-aaa-wg@merit.edu Mon May 13 09:33:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09345 for ; Mon, 13 May 2002 09:33:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8C4791262; Mon, 13 May 2002 09:33:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A51391263; Mon, 13 May 2002 09:33:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EC6B91262 for ; Mon, 13 May 2002 09:32:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 777585DDFE; Mon, 13 May 2002 09:32:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 7897B5DDDD for ; Mon, 13 May 2002 09:32:54 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DDYHd04157 for ; Mon, 13 May 2002 16:34:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 May 2002 16:32:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 16:32:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Resolution of Issue 321: Normative references to CMS Date: Mon, 13 May 2002 16:32:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DE4@esebe004.NOE.Nokia.com> Thread-Topic: Resolution of Issue 321: Normative references to CMS Thread-Index: AcH6gq8zAbo+FmuYTKSOyN3/AzmLIQ== From: To: X-OriginalArrivalTime: 13 May 2002 13:32:53.0952 (UTC) FILETIME=[AF75F400:01C1FA82] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09345 Hi all, I have now made all of the modifications for issue 321. The major text added is as follows: 1.4 Terminology Diameter Security Exchange A Diameter Security Exchange is a process through which two Diameter nodes establish end-to-end security. [editor's note: this is the term to be used for the DSAR/DSAA message exchange) End-to-End Security TLS and IPsec provide hop-by-hop security, or security across a transport connection. When relays or proxy are involved, this hop-by-hop security may not protect the entire Diameter user session. End-to-end security is security across a Diameter session. Security Association A security association is an association between two endpoints in a Diameter session which allows the endpoints to communicate with integrity and confidentially, even in the presense of relays and/or proxies. ===================== 2.9 End-to-End Security Framework The basic components of end-to-end security include encryption and message origin authentication, or in otherwords, AVP integrity and confidentiality between two peers communicating through agents. End-to-end security can be provided by an end-to-end security extension, which is not defined in the base protocol specification. There is ongoing work toward an end-to-end security session [CMS] The circumstances requiring the use of end-to-end security are determined by service provider policy. This policy is not the subject of standardization. This policy may be indexed by next hop Diameter peer or by destination realm. For example, use of TLS or IPsec for Diameter peers communicating in on a peer-to-peer basis, without relays or proxies may be sufficient in many cases. The use of end-to-end security can be classified as the following: - Never use end-to-end security. - Use end-to-end security on messages containing sensitive AVPs. Which AVPs are sensitive is determined by service provider policy. AVPs containing keys and passwords should be considered sensitive. Accounting AVPs may be considered sensitive. Any AVP for which the P bit may be set or which may be encrypted may be considered sensitive. - Always use end-to-end security. It is strongly recommended that all Diameter implementations support end-to-end security. ===================== 4.6 Diameter Base Protocol AVPs The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. For the originator of a Diameter message, "MAY Encr" means that if a message containing that AVP is to be sent via a proxy/agent then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient OR the originator has locally trusted configuration that indicates that end-to-end security is not needed. Similarly, for the originator of a Diameter message, a "P" in the "MAY" column means that if a message containing that AVP is to be sent via a proxy/agent then the message MUST NOT be sent unless there is end-to-end security between the originator and the recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed. ======================== John From owner-aaa-wg@merit.edu Mon May 13 09:35:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09435 for ; Mon, 13 May 2002 09:35:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02BCA91261; Mon, 13 May 2002 09:35:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8AAF91263; Mon, 13 May 2002 09:35:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B887491261 for ; Mon, 13 May 2002 09:35:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CECF35DDDD; Mon, 13 May 2002 09:35:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 62F7B5DDD3 for ; Mon, 13 May 2002 09:35:00 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DDZNk00340 for ; Mon, 13 May 2002 16:35:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 May 2002 16:35:01 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 16:35:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 341 Realm Routing Table and Section 6.1 Date: Mon, 13 May 2002 16:35:00 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65118@esebe004.NOE.Nokia.com> Thread-Topic: Issue 341 Realm Routing Table and Section 6.1 Thread-Index: AcH6gvrWEJmk/ghwTwaRIC5XAHe8PA== From: To: X-OriginalArrivalTime: 13 May 2002 13:35:01.0166 (UTC) FILETIME=[FB4944E0:01C1FA82] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09435 Hi all, I see no improvement needed for issue 341, there has been no comment on it, so I am considering it a reject. John From owner-aaa-wg@merit.edu Mon May 13 09:37:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09518 for ; Mon, 13 May 2002 09:37:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC57391263; Mon, 13 May 2002 09:37:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE2CE91264; Mon, 13 May 2002 09:37:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99E9291263 for ; Mon, 13 May 2002 09:37:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A636F5DE01; Mon, 13 May 2002 09:37:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id ED11C5DDFE for ; Mon, 13 May 2002 09:37:17 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DDbfk01857 for ; Mon, 13 May 2002 16:37:41 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 May 2002 16:37:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 16:37:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Date: Mon, 13 May 2002 16:37:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65119@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions Thread-Index: AcHwQIMTUL73LgVUROOVPOM/uGaozABaotcQAjYKlIA= From: To: , , X-OriginalArrivalTime: 13 May 2002 13:37:18.0629 (UTC) FILETIME=[4D387550:01C1FA83] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09518 Hi all, I have made the changes, so issue 336 is closed. John > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 02 May, 2002 10:32 > To: johanj@ipunplugged.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and > accounting sessions > > > Hi Johan, > > > Requested change: > > > > The Diameter protocol's Session-Id AVP, which is > globally unique (see > > section 8.8), is used during the authorization phase to > identify a > > particular session. Services that do not require any > authorization > > still use the Session-Id AVP to identify sessions. > > > > to > > > > The Diameter protocol's Session-Id AVP, which is globally > unique (see > > section 8.8), is used during the authorization phase to identify a > > particular session. Services that do not require any authorization > > still use the Session-Id AVP to identify sessions. > Accounting messages > > MUST use a different Session-Id from that sent in > > authorization messages. > > Somehow, the "MUST use" part of the last sentence worries me. I think > that it may be more application specific. I'd prefer to > state something > more like: > > Accounting messages MAY use a different Session-Id from > that sent in > authorization messages. Specific applications MAY require different > a Session-ID for accounting messages. > > Then, the application (for example MIP) could use a MUST. > > Comments? > John > > From owner-aaa-wg@merit.edu Mon May 13 09:59:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10697 for ; Mon, 13 May 2002 09:59:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E1DF91266; Mon, 13 May 2002 09:59:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FF2F91267; Mon, 13 May 2002 09:59:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51C7F91266 for ; Mon, 13 May 2002 09:59:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60E5A5DE0A; Mon, 13 May 2002 09:59:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 401805DDD3 for ; Mon, 13 May 2002 09:59:15 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DDxck16157 for ; Mon, 13 May 2002 16:59:39 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 May 2002 16:59:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 16:59:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in failover state machine Date: Mon, 13 May 2002 16:59:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6511A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] "Closed" in peer state machine vs "DOWN" in failover state machine Thread-Index: AcH1ja1cqBzi1x+8R2CugiWkxhSqtAE+HMSg From: To: Cc: X-OriginalArrivalTime: 13 May 2002 13:59:16.0102 (UTC) FILETIME=[5E7EE260:01C1FA86] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10697 Hi, > "This state machine is closely coupled with the state machine described > in [AAATRANS]." Shall I say that if the transport session is in DOWN state, > the AAA session must be in the Closed state? and even if the transport > session is in the SUSPECT state, the AAA session will be still in the > R-Open/I-Open State? > > If it was, then what is the relationship between these two > kinds of states? This is getting to an implementation issue. It is dependent on how closely you are going to couple the transport protocol to the diameter protocol, also if there are multiple transport connections available. John From owner-aaa-wg@merit.edu Mon May 13 10:01:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10802 for ; Mon, 13 May 2002 10:01:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5DC891267; Mon, 13 May 2002 10:01:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 798C591268; Mon, 13 May 2002 10:01:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF92091267 for ; Mon, 13 May 2002 10:01:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDB435DE0F; Mon, 13 May 2002 10:01:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3F0DB5DDD3 for ; Mon, 13 May 2002 10:01:20 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DE1hk17494 for ; Mon, 13 May 2002 17:01:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 May 2002 17:01:21 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 17:01:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Usage of 'Diameter process' confusing Date: Mon, 13 May 2002 17:01:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6511B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Usage of 'Diameter process' confusing Thread-Index: AcH2KLhMan33mz+zT+OjP0nMg8sFGgEXeAvQ From: To: , Cc: X-OriginalArrivalTime: 13 May 2002 14:01:21.0221 (UTC) FILETIME=[A9128750:01C1FA86] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10802 Hi, Requested change made: I suggest changing "process" to "instance of the peer state machine" Issue closed. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 08 May, 2002 02:52 > To: Greg Weber > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Usage of 'Diameter process' confusing > > > Assigned issue #340. > > On Tue, 7 May 2002, Greg Weber wrote: > > > Usage of 'Diameter process' confusing > > Submitter name: Greg Weber > > Submitter email address: gdweber@cisco.com > > Date first submitted: 5/7/2002 > > Reference: none > > Document: base > > Comment type: 'E'ditorial > > Priority: '2' May fix > > Section: 2.1 Transport > > Rationale/Explanation of issue: > > From owner-aaa-wg@merit.edu Mon May 13 10:28:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12492 for ; Mon, 13 May 2002 10:28:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E7EB91269; Mon, 13 May 2002 10:28:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D83E89126A; Mon, 13 May 2002 10:28:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA1D191269 for ; Mon, 13 May 2002 10:28:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D238A5DE4B; Mon, 13 May 2002 10:28:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 3B9FD5DDD3 for ; Mon, 13 May 2002 10:28:48 -0400 (EDT) Received: (qmail 3105 invoked by uid 500); 13 May 2002 14:28:49 -0000 Date: Mon, 13 May 2002 09:28:49 -0500 From: David Frascone To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: NASREQ roadmap Message-ID: <20020513142849.GG13465@newman.frascone.com> Mail-Followup-To: Bernard Aboba , aaa-wg@merit.edu References: <200205121732.g4CHWe831837@internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205121732.g4CHWe831837@internaut.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk That is a good idea. We already have interoperations of non-EAP requests, but none with EAP yet. If anyone wants to test interoperations across the net, please post here or or to diameter@diameter.org. -Dave On Sunday, 12 May 2002, Bernard Aboba wrote: > Due to a request from 3GPP2, we are going to be splitting the NASREQ document into EAP and non-EAP documents. The goal will be to address the outstanding issues on the non-EAP portion of the document and bring that portion of the document to AAA WG last call ASAP. Since there are non-EAP NASREQ implementations already, the non-EAP portion of the document appears to be better understood. > > By splitting off the EAP portion of the NASREQ document, it will be possible to complete the non-EAP portion of NASREQ considerably sooner. We can then focus on the split-off EAP portion of the document on a separate schedule. > -- David Frascone HELP! I need a tagline. HELP! Not just any tagline. From owner-aaa-wg@merit.edu Mon May 13 14:44:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25694 for ; Mon, 13 May 2002 14:44:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C924B91271; Mon, 13 May 2002 14:44:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8ECD491272; Mon, 13 May 2002 14:44:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88BCF91271 for ; Mon, 13 May 2002 14:44:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 922415DDFA; Mon, 13 May 2002 14:44:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 9F3B35DDCA for ; Mon, 13 May 2002 14:44:11 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DIjYd05754 for ; Mon, 13 May 2002 21:45:35 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 13 May 2002 21:44:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 13 May 2002 21:44:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port - closed Date: Mon, 13 May 2002 21:44:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6511F@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port Thread-Index: AcHkjD5VjeiO03toSd65MfF2X6BJVAWIdPiw From: To: X-OriginalArrivalTime: 13 May 2002 18:44:12.0251 (UTC) FILETIME=[2C9832B0:01C1FAAE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25694 Hi all, I have added the needed text, AVP, etc. so this issue sould be marked closed. John From owner-aaa-wg@merit.edu Wed May 15 11:26:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09803 for ; Wed, 15 May 2002 11:26:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA2A791291; Wed, 15 May 2002 11:26:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBB7691292; Wed, 15 May 2002 11:26:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D875F91291 for ; Wed, 15 May 2002 11:26:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CC485E076; Wed, 15 May 2002 11:26:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B94BF5E071 for ; Wed, 15 May 2002 11:26:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4FEdII04067 for ; Wed, 15 May 2002 07:39:18 -0700 Date: Wed, 15 May 2002 07:39:18 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-ietf-aaa-diameter-cms-sec-04 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Wed, 15 May 2002 08:49:10 -0400 From: "Housley, Russ" To: pcalhoun@diameter.org, stephen.farrell@baltimore.ie, web@merit.edu Cc: aboba@internaut.com Subject: draft-ietf-aaa-diameter-cms-sec-04 Dear Authors: I have just finished going through draft-ietf-aaa-diameter-cms-sec-04, and I have a few questions and comments. 1. On page 4, the terms MUST, SHOULD, and MAY are used before the requirements language explanation. I suggest that section 1.1 be moved up two paragraphs, and that those two paragraphs become section 1.2. Of course, you then need to renumber the subsequent subsections. 2. On page 6, in the paragraph right after figure 2, you say: This document defines the Diameter commands that are used to establish a DSA through Diameter agents, and specifies how encapsulating CMS objects [CMS] in Diameter AVPs can provide authentication, integrity, confidentiality and data origin authentication. CMS objects MAY also be used to transport X.509 certificates and revocation lists. What is the difference between "authentication" and "data origin authentication?" Should I interpret "authentication" as peer entity authentication? 3. On page 7, you say: ... In the latter case, the proxy agent acts as an access device of sorts and the rules in section 1.2 should be used instead. Instead of what? Can we drop the word? 4. On page 12, in the 3rd paragraph of section 3.1, you say: Revalidations SHOULD also occur before the DSA expires according to PKI policies. During the process of certificate path validation some implementations will calculate a duration for which the certificate path may be considered "safe". For example, ... Please change "certificate path" to "certification path." This is the term used in RFC 2459 and RFC 3280. Please ensure that the correct term is used throughout the document. 5. On page 13, in the 3rd bullet in the middle of the page, you say: - the list of direct trust CA's that the originating Diameter node has configured into it for certificate validation. A "direct trust" CA is one that the node is willing to use as the "top" of a certificate chain, sometimes confusingly known as a "root CA." Please use the term "trust anchor" instead of "direct trust CA." Trust anchor is defined in RFC 3280. 6. On page 15, in the 5th paragraph from the top of the page, please add "checking" after "If certificate revocation." 7. On page 17, at the end of section 3.3, please add: Implementations MAY support other algorithms. 8. On page 22, in the 1st paragraph of section 6.0, you say: This section contains AVPs that are used to establish a Diameter Security Association, and to transport CMS objects. Except as specifically constrained, the profile of CMS algorithm and structure usage is as specified in the S/MIME v3 message specification [MSG]. I have two comments. First, CMS is not an "algorithm." I suggest "... of the CMS is specified ..." Second, I am confused about the reference to [MSG]. You use very little that is defined there. You use different algorithms. You do not use the MIME encoding. Why reference it at all? The only place that it seems relevant is in the discussion of certs-only messages. 9. On page 23, after the table, there is another use of "CMS algorithm." Please fix it too. 10. On page 23, after the table, there is further discussion of [MSG]. Basically, the two paragraphs after the table are saying that [MSG] is irrelevant. 11. On page 24, in the 1st full paragraph on the page, please change "sequentially" to either "subsequently" or "serially." 12. On page 24, 2nd to last paragraph in section 6.1, please add (at the end): The ciphertext is signed. 13. On page 24, last paragraph on the page, you say: The contentType of the EncryptedContentInfo value MUST be id- data [MSG]. Please do not do this! The IESG complained about id-data, and the following text was added to the update to RFC 2630 (rfc2630bis) to address the complaint: S/MIME uses id-data to identify MIME encoded content. The use of this content identifier is specified in RFC 2311 for S/MIME v2 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. Since you are not MIME encoding your content, please do not use id-data. I will be glad to assign you a new OID for Diameter AVPs. 14. On page 26, section 6.4.2, you define an AVP that is the SHA-1 hash of the public key. I similar construct is defined in draft-ietf-pkix-okid-01.txt. Can we harmonize these specifications? 15. On page 27, in the 1st paragraph of section 6.8, the discussion of the certs-only message should reference [MSG]. Best I can tell, this is the only aspect of [MSG] that is being use in the specification, and it is being used without the MIME wrapper (I think). You should be explicit about whether the MIME wrapper is being used. 16. On page 32, in the last paragraph of section 10.0, please change "SA" to "DSA." 17. On page 32, section 10.0, should discuss replay detection. 18. Please reference rfc2630bis and cmsalg documents instead of [CMS]. These two documents from the S/MIME working group have finished IETF Last Call, and I think that the last IESG DISCUSS vote was cleared yesterday. 19. Please change [CERTPROF] to reference RFC 3279 and RFC 3280. Note that some places [CERTPROF] is used in reference to algorithms, and these should reference RFC 3279. One example is at the top of page 27. Other places, [CERTPROF] is used in reference to certificates, and these should reference RFC 3280. Thanks for you attention. Russ From owner-aaa-wg@merit.edu Wed May 15 17:35:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22990 for ; Wed, 15 May 2002 17:35:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F42191231; Wed, 15 May 2002 17:35:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28FA491299; Wed, 15 May 2002 17:35:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10A5591231 for ; Wed, 15 May 2002 17:35:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 912605E0CF; Wed, 15 May 2002 17:35:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 278BB5E0C2 for ; Wed, 15 May 2002 17:35:11 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g4FLZ9i00301; Wed, 15 May 2002 16:35:09 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4FLZ8b12213; Wed, 15 May 2002 16:35:08 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA09409; Wed, 15 May 2002 16:35:08 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA17402; Wed, 15 May 2002 16:35:07 -0500 (CDT) Message-ID: <3CE2D3B8.AEE64546@ericsson.com> Date: Wed, 15 May 2002 14:31:36 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, I'm sorry for my late reply. So, how about the following clarifications: "1.0 Introduction: .... Furthermore, the nature of mobile IP also means that the mobile node will do handoffs between different foreign agents. To guarantee that a registered user always ends up in the same initial AAAH, the mobile node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist the AAAH in routing the messages to a mobile node's home agent the mobile node SHOULD always include the HA NAI [AAANAI]. If the mobile node does not support the Mobile IP AAA NAI extenstion [AAANAI], this MAY limit the functionality that can be offered to such a mobile node" 1.4 Allocation of Home Agent in Foreign Network: .... In the event that the mobile node with AAA NAI extension support [AAANAI] has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. In the event that the mobile node that does not support the AAA NAI extension has been previously authorized by the AAAH and now needs to be re-authenticated, and requests to keep the assigned home agent in the foreign network, the mobile node sends a registration request without the AAA NAI and the HA NAI. Upon receipt, the FA will create the AMR including the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP." Would this make it clear enough. /Tony Johan Johansson wrote: > Hi Tony. > > I have no objections to the sections I cut out. Regarding the remainder > below, would it be possible to reformulate this to make it clearer what > a MN without AAA-NAI support needs to do and what the effect of not > supporting AAA-NAI is? I may be wrong, but it seems to me that with the > proper support from the home network, in particular AAAH assigned by nai > hashing, the only thing that is truly impossible to solve is to keep the > HA if the AAAH goes down. > > In any case, you've made the entire section conditional on the support > of AAA-NAI. Surely we need a way to assign a home agent in a foreign > network even in a backwards-compatibly solution? If not we should add a > sentence saying that without AAA-NAI you cannot allocate a home agent in > the visited net. > > j > > Tony Johansson wrote: > > >In section 1.4 Allocation of Home Agent in Foreign Network: > > > >Change: > > > > "In the event that the mobile node has been previously authorized by > > the AAAH and now needs to be re-authenticated, and requests to keep > > the assigned home agent in the foreign network, the mobile node MUST > > include the HA NAI and the AAAH NAI in the registration request to > > the FA. Upon receipt, the FA will create the AMR including the MIP- > > Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH > > NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the > > MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF > > authorizes the use of the requested home agent, the AAAF MUST set the > > > > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP." > > > >To: > > > > "In the event that the mobile node (with AAA NAI extension support > > [AAANAI]) has been previously authorized by the AAAH and now needs to > > > > be re-authenticated, and requests to keep the assigned home agent in > > the foreign network, the mobile node MUST include the HA NAI and the > > AAAH NAI in the registration request to the FA. Upon receipt, the FA > > will create the AMR including the MIP-Home-Agent-Address AVP, the > > Destination-Host AVP based on the AAAH NAI and instead of the MIP- > > Candidate-Home-Agent-Host AVP include the MIP-Home-Agent-Host AVP > > based on the home agent NAI. If the AAAF authorizes the use of the > > requested home agent, the AAAF MUST set the Home-Agent-In-Foreign- > > Network bit in the MIP-Feature-Vector AVP." > > > > From owner-aaa-wg@merit.edu Wed May 15 18:01:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23618 for ; Wed, 15 May 2002 18:01:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 69D899129A; Wed, 15 May 2002 18:00:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B5CE9129B; Wed, 15 May 2002 18:00:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 235219129A for ; Wed, 15 May 2002 18:00:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFCE75E0D8; Wed, 15 May 2002 18:00:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 2AB255E0C2 for ; Wed, 15 May 2002 18:00:48 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020515220049.JCEB4756.fep02-svc.swip.net@ipunplugged.com>; Thu, 16 May 2002 00:00:49 +0200 Message-ID: <3CE2F716.4070902@ipunplugged.com> Date: Thu, 16 May 2002 00:02:30 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony Johansson wrote: >Hi Johan, > >I'm sorry for my late reply. > >So, how about the following clarifications: > >"1.0 Introduction: > >.... > >Furthermore, the nature of mobile IP also means that the mobile node will do >handoffs between different foreign agents. To guarantee that a registered >user always ends up in the same initial AAAH, the mobile node SHOULD always >include the AAAH NAI [AAANAI]. Finally, to assist the AAAH in routing the >messages to a mobile node's home agent the mobile node SHOULD always include >the HA NAI [AAANAI]. If the mobile node does not support the Mobile IP AAA >NAI extenstion [AAANAI], this MAY limit the functionality that can be offered >to such a mobile node" > Klockrent as we would say in swedish. This part is perfect in my opinion. >1.4 Allocation of Home Agent in Foreign Network: > > >.... > >In the event that the mobile node with AAA NAI extension support [AAANAI] has >been previously authorized by the AAAH and now needs to be re-authenticated, >and requests to keep the assigned home agent in the foreign network, the >mobile node MUST include the HA NAI and the AAAH NAI in the registration >request to the FA. Upon receipt, the FA will create the AMR including the >MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI >and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the >AAAF authorizes the use of the requested home agent, the AAAF MUST set the >Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > >In the event that the mobile node that does not support the AAA NAI extension >has been previously authorized by the AAAH and now needs to be >re-authenticated, and requests to keep the assigned home agent in the foreign >network, the mobile node sends a registration request without the AAA NAI and >the HA NAI. Upon receipt, the FA will create the AMR including the >MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested >home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the >MIP-Feature-Vector AVP." > > This is also much clearer. On the surface it looks a bit redundant but the separation of the two cases makes it easier to understand. Besides, my attempt at merging the two paragraphs wasn't very successful, so let's go with this one. j From owner-aaa-wg@merit.edu Thu May 16 04:55:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17876 for ; Thu, 16 May 2002 04:55:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 92A44912AC; Thu, 16 May 2002 04:55:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E1AE912AD; Thu, 16 May 2002 04:55:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41F1B912AC for ; Thu, 16 May 2002 04:55:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B98685DDE3; Thu, 16 May 2002 04:55:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id CBB4B5DDB0 for ; Thu, 16 May 2002 04:55:06 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g4G8t8k05156 for ; Thu, 16 May 2002 09:55:08 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 16 May 2002 09:49:21 +0100 Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id JAA30933; Thu, 16 May 2002 09:54:56 +0100 Message-ID: <3CE373D9.22DA0F84@baltimore.ie> Date: Thu, 16 May 2002 09:54:49 +0100 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: Russ Housley Cc: Bernard Aboba , aaa-wg@merit.edu, xme Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-cms-sec-04 (fwd) References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Russ, > Dear Authors: > > I have just finished going through draft-ietf-aaa-diameter-cms-sec-04, and > I have a few questions and comments. Thanks for these, you've certainly found some of our legacy text:-) Bernard - As far as I can tell only Russ' #13 needs to be raised as an open "issue". (#5,#7 might lead to discussion, but I hope not). For the rest, if you raise a single new issue for the lot and immediately mark it closed, I think that'd be right (maybe wait a day to see if Russ detects any problems first). Cheers, Stephen. > 1. On page 4, the terms MUST, SHOULD, and MAY are used before the > requirements language explanation. I suggest that section 1.1 be moved up > two paragraphs, and that those two paragraphs become section 1.2. Of > course, you then need to renumber the subsequent subsections. OK. > 2. On page 6, in the paragraph right after figure 2, you say: > > This document defines the Diameter commands that are used to > establish a DSA through Diameter agents, and specifies how > encapsulating CMS objects [CMS] in Diameter AVPs can provide > authentication, integrity, confidentiality and data origin > authentication. CMS objects MAY also be used to transport X.509 > certificates and revocation lists. > > What is the difference between "authentication" and "data origin > authentication?" Should I interpret "authentication" as peer entity > authentication? Yes, so long as you're not too strict in your interpretation! (This arose because I did an s/N-R/D-A-O/g to avoid the yukkie term:-) Best is to tidy this up to: [...] encapsulating CMS objects [CMS] in Diameter AVPs can provide integrity, confidentiality and data origin authentication. CMS objects MAY also be used to transport X.509 [...] > > 3. On page 7, you say: > > ... In the latter case, the proxy agent acts as > an access device of sorts and the rules in section 1.2 should be used > instead. > > Instead of what? Can we drop the word? OK. > > 4. On page 12, in the 3rd paragraph of section 3.1, you say: > > Revalidations SHOULD also occur before the DSA expires according to > PKI policies. During the process of certificate path validation some > implementations will calculate a duration for which the certificate > path may be considered "safe". For example, ... > > Please change "certificate path" to "certification path." This is the term > used in RFC 2459 and RFC 3280. Please ensure that the correct term is used > throughout the document. OK. > > 5. On page 13, in the 3rd bullet in the middle of the page, you say: > > - the list of direct trust CA's that the originating Diameter > node has configured into it for certificate validation. A > "direct trust" CA is one that the node is willing to use as the > "top" of a certificate chain, sometimes confusingly known as a > "root CA." > > Please use the term "trust anchor" instead of "direct trust CA." Trust > anchor is defined in RFC 3280. I personally don't think that these have to be identical settings, but it could be simpler if we pretend they are! (They look the same externally.) The use case where they're not is where a corporate Diameter node has the corporate CA as its trust anchor, and where the corporate CA has certified a bunch of other CAs which are known to the outside world (e.g. cybertrust). That node would then be better off advertising the fact that if you can chain up to one of the other CAs, then you're in business. Advertising only the corporate CA would probably result in many outside Diameter nodes not being able to form a chain up to the advertised CA. How about if I use the "trust anchor" term, but also include text like the above? (Which BTW ought also go into TLS, SMIME capabilities and anywhere else network elements advertise their set of favorite CAs?) > 6. On page 15, in the 5th paragraph from the top of the page, please add > "checking" after "If certificate revocation." OK. > > 7. On page 17, at the end of section 3.3, please add: > > Implementations MAY support other algorithms. Why? There is no statement that they "MAY NOT" support other algorithms and since I don't want to run into ECDSA, Camelia, GOST or any of the other raft of algorithms that exist, why encourage complication? (The background is that a number of Diameter folks have already baulked at the apparent complexity of CMS and I don't want them to have to think about other algorithms for now.) Basically I think we're ok to just pick good algorithms here since its not a framework - if we get demand for other algorithms, then we can write a new rfc. > 8. On page 22, in the 1st paragraph of section 6.0, you say: > > This section contains AVPs that are used to establish a Diameter > Security Association, and to transport CMS objects. Except as > specifically constrained, the profile of CMS algorithm and structure > usage is as specified in the S/MIME v3 message specification [MSG]. > > I have two comments. First, CMS is not an "algorithm." I suggest "... of > the CMS is specified ..." Fine. > Second, I am confused about the reference to > [MSG]. You use very little that is defined there. You use different > algorithms. You do not use the MIME encoding. Why reference it at > all? The only place that it seems relevant is in the discussion of > certs-only messages. Yes. This is historical, we started out using the MIME encoding and then dropped it. Will tidy appropriately, depending on id-data issue (#13). > > 9. On page 23, after the table, there is another use of "CMS algorithm." > Please fix it too. OK. > > 10. On page 23, after the table, there is further discussion of > [MSG]. Basically, the two paragraphs after the table are saying that [MSG] > is irrelevant. OK. > > 11. On page 24, in the 1st full paragraph on the page, please change > "sequentially" to either "subsequently" or "serially." OK. > > 12. On page 24, 2nd to last paragraph in section 6.1, please add (at the > end): > > The ciphertext is signed. OK. > > 13. On page 24, last paragraph on the page, you say: > > The contentType of the EncryptedContentInfo value MUST be id- > data [MSG]. > > Please do not do this! The IESG complained about id-data, and the > following text was added to the update to RFC 2630 (rfc2630bis) to address > the complaint: > > S/MIME uses id-data to identify MIME encoded content. The use of > this content identifier is specified in RFC 2311 for S/MIME v2 > [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. > > Since you are not MIME encoding your content, please do not use id-data. I > will be glad to assign you a new OID for Diameter AVPs. Ark! I need to check/think about this - basically, will existing toolkits barf on a new OID? If they do, then we're not (IMO) doing a very good job. Is there any generic "non-MIME encoded binary content" OID that's already supported? Bernard, you ought to open an "issue" about this, at least 'till I check. > > 14. On page 26, section 6.4.2, you define an AVP that is the SHA-1 hash of > the public key. I similar construct is defined in > draft-ietf-pkix-okid-01.txt. Can we harmonize these specifications? In principle yes, but practically, probably not. We want this to progress quicker than (I think) okid will. The uses also differ - okid is mainly for human consumption, isn't it? This AVP isn't for warm bodies. > > 15. On page 27, in the 1st paragraph of section 6.8, the discussion of the > certs-only message should reference [MSG]. Best I can tell, this is the > only aspect of [MSG] that is being use in the specification, and it is > being used without the MIME wrapper (I think). You should be explicit > about whether the MIME wrapper is being used. More history. Will change so as to make you happy. > 16. On page 32, in the last paragraph of section 10.0, please change "SA" > to "DSA." OK > 17. On page 32, section 10.0, should discuss replay detection. Yes. > 18. Please reference rfc2630bis and cmsalg documents instead of > [CMS]. These two documents from the S/MIME working group have finished > IETF Last Call, and I think that the last IESG DISCUSS vote was cleared > yesterday. OK, assuming 2630-compliant code remains complaint (which I think it does for the bits we're using), but with the caveat that we'll drop back to 2630 if this draft gets to the authors 48 hour mark first. > 19. Please change [CERTPROF] to reference RFC 3279 and RFC 3280. Note > that some places [CERTPROF] is used in reference to algorithms, and these > should reference RFC 3279. One example is at the top of page > 27. Other places, [CERTPROF] is used in reference to certificates, and > these should reference RFC 3280. OK. (I might even re-insert an informative reference to the now-rfc3281, just to celebrate its eventual emergence from the pkix/iesg/rfc-editor process:-) > Thanks for you attention. And thanks for yours! -- ____________________________________________________________ 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-wg@merit.edu Thu May 16 09:42:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24702 for ; Thu, 16 May 2002 09:42:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBB87912AF; Thu, 16 May 2002 09:42:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B00A912B0; Thu, 16 May 2002 09:42:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74C39912AF for ; Thu, 16 May 2002 09:42:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3EE35DDD4; Thu, 16 May 2002 09:42:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by segue.merit.edu (Postfix) with SMTP id 6CCE95DD9F for ; Thu, 16 May 2002 09:42:34 -0400 (EDT) Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for segue.merit.edu [198.108.1.41]) with SMTP; 16 May 2002 13:40:54 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA23645; Thu, 16 May 2002 09:42:26 -0400 (EDT) Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g4GDeYJ06607; Thu, 16 May 2002 09:40:34 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 09:42:23 -0400 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.145]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLCYPM; Thu, 16 May 2002 09:42:16 -0400 From: "Housley, Russ" To: stephen.farrell@baltimore.ie Cc: Bernard Aboba , aaa-wg@merit.edu Message-Id: <5.1.0.14.2.20020516093058.02d93978@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 May 2002 09:42:02 -0400 Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-cms-sec-04 (fwd) In-Reply-To: <3CE373D9.22DA0F84@baltimore.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Steve: Most of these are fine. Below, I have not included comments that are closed. I have included ones that have open issues or you asked me a question. > > 5. On page 13, in the 3rd bullet in the middle of the page, you say: > > > > - the list of direct trust CA's that the originating Diameter > > node has configured into it for certificate validation. A > > "direct trust" CA is one that the node is willing to use as the > > "top" of a certificate chain, sometimes confusingly known as a > > "root CA." > > > > Please use the term "trust anchor" instead of "direct trust CA." Trust > > anchor is defined in RFC 3280. > >I personally don't think that these have to be identical settings, but it >could be simpler if we pretend they are! (They look the same externally.) > >The use case where they're not is where a corporate Diameter node has the >corporate CA as its trust anchor, and where the corporate CA has certified >a bunch of other CAs which are known to the outside world (e.g. cybertrust). >That node would then be better off advertising the fact that if you can chain >up to one of the other CAs, then you're in business. Advertising only the >corporate CA would probably result in many outside Diameter nodes not being >able to form a chain up to the advertised CA. > >How about if I use the "trust anchor" term, but also include text like >the above? (Which BTW ought also go into TLS, SMIME capabilities and anywhere >else network elements advertise their set of favorite CAs?) OK. > > 7. On page 17, at the end of section 3.3, please add: > > > > Implementations MAY support other algorithms. > >Why? There is no statement that they "MAY NOT" support other algorithms and >since I don't want to run into ECDSA, Camelia, GOST or any of the other raft >of algorithms that exist, why encourage complication? (The background is that >a number of Diameter folks have already baulked at the apparent complexity of >CMS and I don't want them to have to think about other algorithms for now.) > >Basically I think we're ok to just pick good algorithms here since its not >a framework - if we get demand for other algorithms, then we can write a new >rfc. OK. > > 13. On page 24, last paragraph on the page, you say: > > > > The contentType of the EncryptedContentInfo value MUST be id- > > data [MSG]. > > > > Please do not do this! The IESG complained about id-data, and the > > following text was added to the update to RFC 2630 (rfc2630bis) to address > > the complaint: > > > > S/MIME uses id-data to identify MIME encoded content. The use of > > this content identifier is specified in RFC 2311 for S/MIME v2 > > [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. > > > > Since you are not MIME encoding your content, please do not use id-data. I > > will be glad to assign you a new OID for Diameter AVPs. > >Ark! I need to check/think about this - basically, will existing toolkits >barf on a new OID? If they do, then we're not (IMO) doing a very good job. >Is there any generic "non-MIME encoded binary content" OID that's already >supported? As I understand it, most toolkits just return the OID, leaving demultipexing to the calling application. >Bernard, you ought to open an "issue" about this, at least 'till I check. Why don't you post a question to ietf-smime@imc.org to confirm my understanding. > > 14. On page 26, section 6.4.2, you define an AVP that is the SHA-1 hash of > > the public key. I similar construct is defined in > > draft-ietf-pkix-okid-01.txt. Can we harmonize these specifications? > >In principle yes, but practically, probably not. We want this to progress >quicker than (I think) okid will. The uses also differ - okid is mainly for >human consumption, isn't it? This AVP isn't for warm bodies. OK. > > 18. Please reference rfc2630bis and cmsalg documents instead of > > [CMS]. These two documents from the S/MIME working group have finished > > IETF Last Call, and I think that the last IESG DISCUSS vote was cleared > > yesterday. > >OK, assuming 2630-compliant code remains complaint (which I think it does >for the bits we're using), but with the caveat that we'll drop back to >2630 if this draft gets to the authors 48 hour mark first. OK. > > 19. Please change [CERTPROF] to reference RFC 3279 and RFC 3280. Note > > that some places [CERTPROF] is used in reference to algorithms, and these > > should reference RFC 3279. One example is at the top of page > > 27. Other places, [CERTPROF] is used in reference to certificates, and > > these should reference RFC 3280. > >OK. (I might even re-insert an informative reference to the now-rfc3281, just >to celebrate its eventual emergence from the pkix/iesg/rfc-editor process:-) Yes, the process is not an infinite loop. It just feels that way sometimes... Russ From owner-aaa-wg@merit.edu Thu May 16 12:14:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00500 for ; Thu, 16 May 2002 12:14:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65ACE912B5; Thu, 16 May 2002 12:14:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39499912B6; Thu, 16 May 2002 12:14:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 191CE912B5 for ; Thu, 16 May 2002 12:14:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A75B5DDA3; Thu, 16 May 2002 12:14:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id EC8CA5DD9F for ; Thu, 16 May 2002 12:14:18 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4GGEGa13293; Thu, 16 May 2002 12:14:16 -0400 (EDT) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA04791; Thu, 16 May 2002 11:14:15 -0500 (CDT) Received: by nwsgpc.ih.lucent.com (8.11.6+Sun/EMS-1.5 client sol2) id g4GGEFu00350; Thu, 16 May 2002 11:14:15 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15587.56023.651237.144119@nwsgpc.ih.lucent.com> Date: Thu, 16 May 2002 11:14:15 -0500 (CDT) From: Pete McCann To: Johan Johansson Cc: Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 In-Reply-To: <3CE2F716.4070902@ipunplugged.com> References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am glad to see that issues of backwards-compatibility are being addressed. One comment below... Johan Johansson writes: > Tony Johansson wrote: > >1.4 Allocation of Home Agent in Foreign Network: > > > > > >.... > > > >In the event that the mobile node with AAA NAI extension support [AAANAI] has > >been previously authorized by the AAAH and now needs to be re-authenticated, > >and requests to keep the assigned home agent in the foreign network, the > >mobile node MUST include the HA NAI and the AAAH NAI in the registration > >request to the FA. Upon receipt, the FA will create the AMR including the > >MIP-Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH NAI > >and include the MIP-Home-Agent-Host AVP based on the home agent NAI. If the > >AAAF authorizes the use of the requested home agent, the AAAF MUST set the > >Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > >In the event that the mobile node that does not support the AAA NAI extension > >has been previously authorized by the AAAH and now needs to be > >re-authenticated, and requests to keep the assigned home agent in the foreign > >network, the mobile node sends a registration request without the AAA NAI and > >the HA NAI. Upon receipt, the FA will create the AMR including the > >MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested > >home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the > >MIP-Feature-Vector AVP." > > > This is also much clearer. On the surface it looks a bit redundant but > the separation of the two cases makes it easier to understand. Besides, > my attempt at merging the two paragraphs wasn't very successful, so > let's go with this one. If only the HA's IP address appears, not the HA NAI, will it always be possible for the FA to properly set the value of Home-Agent-In-Foreign-Network? I assume we need to cover the case where the MN has moved to a new FA, maybe in the same or different network, but wants to keep the HA it was assigned at the first FA. With the HA NAI, the FA can compare the realm value to its own and determine the proper setting of Home-Agent-In-Foreign-Network. How does the current FA know this was an HA in the foreign network, and not an HA in the home network, just from the IP address? Maybe a better approach would be to set the bit if the FA has some knowledge (e.g., based on a table of IP address prefixes) that the HA is in its OWN network. Otherwise, the bit should be cleared. Note that the HA may not need a new HAR to keep it active; it might just be willing to provide service for the duration of the Mobile IP session, even if it doesn't hear from AAA for a long time. The Mobile IP registration messages would go directly to it and would be authenticated based on MN-HA authentication extension. I realize this is less functionality than if we had the HA NAI, but it should still be a valid deployment scenario. -Pete From owner-aaa-wg@merit.edu Thu May 16 15:29:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07744 for ; Thu, 16 May 2002 15:29:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7278912BA; Thu, 16 May 2002 15:29:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86BBC912BB; Thu, 16 May 2002 15:29:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AD1C912BA for ; Thu, 16 May 2002 15:29:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB1B85DDE0; Thu, 16 May 2002 15:29:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 801815DD97 for ; Thu, 16 May 2002 15:29:12 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g4GJTEl12117; Thu, 16 May 2002 14:29:14 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4GJTD425863; Thu, 16 May 2002 14:29:13 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA22969; Thu, 16 May 2002 14:29:13 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA06245; Thu, 16 May 2002 14:29:12 -0500 (CDT) Message-ID: <3CE407B4.B638B5C3@ericsson.com> Date: Thu, 16 May 2002 12:25:40 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pete, Please find my comments embedded... /Tony Pete McCann wrote: > > If only the HA's IP address appears, not the HA NAI, will it always be > possible for the FA to properly set the value of > Home-Agent-In-Foreign-Network? It is the AAAF that authorizes and sets the Home-Agent-In-Foreign-Network flag bit and without the HA NAI the AAAF must be able to make that judgment based on only the HA's IP address (e.g. through reverse DNS lookup, but this is impl. specific and it has also been concluded that reverse DNS lookup may not at all work (please see previous mail threads)). So, I guess my answer would be - maybe. See further comments below. > I assume we need to cover the case > where the MN has moved to a new FA, maybe in the same or different > network, but wants to keep the HA it was assigned at the first FA. > > With the HA NAI, the FA can compare the realm value to its own and > determine the proper setting of Home-Agent-In-Foreign-Network. Correct, however it is the AAAF that does this not the FA. > How > does the current FA know this was an HA in the foreign network, and > not an HA in the home network, just from the IP address? The FA would only know if this is a subsequent registration from the MN. If not, the FA wouldn't know and must ask it's AAAF for help. So, again with only the HA's IP address the AAAF may have problems to figure out how to authorize this. This is an old debate in which we have come to the consensus on the list and at the IETF53 that the Mobile IP AAA NAI extension should be supported by the mobile node :) I guess if you can make sure to always end up in the same AAAF (and that it is statefull) when you move in the same foriegn network and that you also can make sure to always and up in the same AAAH (also being statefull), then the need for the HA NAI and the AAAH NAI would be of less importans and it would be possible to fully make use of the Diameter Mobile IPv4 application without the AAA NAI extension. /Tony From owner-aaa-wg@merit.edu Thu May 16 15:48:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08819 for ; Thu, 16 May 2002 15:48:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED00D912BB; Thu, 16 May 2002 15:48:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6864912BD; Thu, 16 May 2002 15:48:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF459912BB for ; Thu, 16 May 2002 15:48:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 33B5F5DE14; Thu, 16 May 2002 15:48:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id D56625DE10 for ; Thu, 16 May 2002 15:48:07 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4GJm5H04598; Thu, 16 May 2002 15:48:05 -0400 (EDT) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA22284; Thu, 16 May 2002 14:48:05 -0500 (CDT) Received: by nwsgpc.ih.lucent.com (8.11.6+Sun/EMS-1.5 client sol2) id g4GJm4G27271; Thu, 16 May 2002 14:48:04 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.3316.714420.988318@nwsgpc.ih.lucent.com> Date: Thu, 16 May 2002 14:48:04 -0500 (CDT) From: Pete McCann To: Tony Johansson Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 In-Reply-To: <3CE407B4.B638B5C3@ericsson.com> References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> <3CE407B4.B638B5C3@ericsson.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Tony, I realize I am coming a bit late to an old discussion, but comments below... Tony Johansson writes: > > With the HA NAI, the FA can compare the realm value to its own and > > determine the proper setting of Home-Agent-In-Foreign-Network. > > Correct, however it is the AAAF that does this not the FA. Sorry about my confusion - yes, AAAF. But my point then applies when the user changes AAAF. > > How > > does the current FA know this was an HA in the foreign network, and > > not an HA in the home network, just from the IP address? > > The FA would only know if this is a subsequent registration from the MN. If not, the > FA wouldn't know and must ask it's AAAF for help. So, again with only the HA's IP > address the AAAF may have problems to figure out how to authorize this. This is an > old debate in which we have come to the consensus on the list and at the IETF53 that > the Mobile IP AAA NAI extension should be supported by the mobile node :) > > I guess if you can make sure to always end up in the same AAAF (and that it is > statefull) when you move in the same foriegn network and that you also can make sure > to always and up in the same AAAH (also being statefull), then the need for the HA > NAI and the AAAH NAI would be of less importans and it would be possible to fully > make use of the Diameter Mobile IPv4 application without the AAA NAI extension. I am not saying we shouldn't do AAA NAI, it is obviously the best approach that gives the most flexibility in setting policies. I am just trying to find the right wording for the case where we don't have it due to a legacy MN that only implements MN-AAA and its own NAI. I don't think we should prohibit those less-than-perfect mechanisms, such as reverse IP address lookup, or that we should prohibit someone from using an HA in a previously visited network just because *some* network policies might not allow it. I would rather see wording that says, for instance, "Home-Agent-In-Foreign-Network flag SHOULD be set if the AAAF has knowledge that the HA is in its own domain." Knowing the HA's NAI is one way, but there could be others. The 3 different networks (those containing AAAH, AAAF and HA, respectively) may be perfectly happy to authorize service, even though the visited network has no idea who owns the HA and there is no direct contact with the old AAAF in the HA's network. Even if we can't guarantee finding the same stateful AAAH for the access-request, so not even the home network knows who owns the HA, the policy might be to grant access. -Pete From owner-aaa-wg@merit.edu Thu May 16 17:10:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10976 for ; Thu, 16 May 2002 17:10:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C5F6912BF; Thu, 16 May 2002 17:10:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65D40912BE; Thu, 16 May 2002 17:10:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09463912BF for ; Thu, 16 May 2002 17:10:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A2855DD90; Thu, 16 May 2002 17:10:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 22B665DD8E for ; Thu, 16 May 2002 17:10:19 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g4GLALi07589; Thu, 16 May 2002 16:10:21 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4GLALK00416; Thu, 16 May 2002 16:10:21 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA26809; Thu, 16 May 2002 16:10:20 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA07799; Thu, 16 May 2002 16:10:19 -0500 (CDT) Message-ID: <3CE41F66.4A4E4D9A@ericsson.com> Date: Thu, 16 May 2002 14:06:47 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> <3CE407B4.B638B5C3@ericsson.com> <15588.3316.714420.988318@nwsgpc.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pete, In principle and IMHO, there isn't anything in draft -10 (with new proposed text to issue 338) that wouldn't let you authorize the usage in the way you reasoning below. If you disagree, please let me know where the wording is to strong or unclear. /Tony Pete McCann wrote: > Hi, Tony, > > I realize I am coming a bit late to an old discussion, but comments below... > > Tony Johansson writes: > > > With the HA NAI, the FA can compare the realm value to its own and > > > determine the proper setting of Home-Agent-In-Foreign-Network. > > > > Correct, however it is the AAAF that does this not the FA. > > Sorry about my confusion - yes, AAAF. But my point then applies when > the user changes AAAF. > > > > How > > > does the current FA know this was an HA in the foreign network, and > > > not an HA in the home network, just from the IP address? > > > > The FA would only know if this is a subsequent registration from the MN. If not, the > > FA wouldn't know and must ask it's AAAF for help. So, again with only the HA's IP > > address the AAAF may have problems to figure out how to authorize this. This is an > > old debate in which we have come to the consensus on the list and at the IETF53 that > > the Mobile IP AAA NAI extension should be supported by the mobile node :) > > > > I guess if you can make sure to always end up in the same AAAF (and that it is > > statefull) when you move in the same foriegn network and that you also can make sure > > to always and up in the same AAAH (also being statefull), then the need for the HA > > NAI and the AAAH NAI would be of less importans and it would be possible to fully > > make use of the Diameter Mobile IPv4 application without the AAA NAI extension. > > I am not saying we shouldn't do AAA NAI, it is obviously the best > approach that gives the most flexibility in setting policies. I am > just trying to find the right wording for the case where we don't have > it due to a legacy MN that only implements MN-AAA and its own NAI. I > don't think we should prohibit those less-than-perfect mechanisms, > such as reverse IP address lookup, or that we should prohibit someone > from using an HA in a previously visited network just because *some* > network policies might not allow it. I would rather see wording that > says, for instance, > > "Home-Agent-In-Foreign-Network flag SHOULD be set if the AAAF has > knowledge that the HA is in its own domain." > > Knowing the HA's NAI is one way, but there could be others. The 3 > different networks (those containing AAAH, AAAF and HA, respectively) > may be perfectly happy to authorize service, even though the visited > network has no idea who owns the HA and there is no direct contact > with the old AAAF in the HA's network. Even if we can't guarantee > finding the same stateful AAAH for the access-request, so not even the > home network knows who owns the HA, the policy might be to grant > access. > > -Pete From owner-aaa-wg@merit.edu Fri May 17 10:53:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16428 for ; Fri, 17 May 2002 10:53:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C11891244; Fri, 17 May 2002 10:53:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51D129124C; Fri, 17 May 2002 10:53:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1491E91244 for ; Fri, 17 May 2002 10:53:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 287495DE12; Fri, 17 May 2002 10:53:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id CE8305DDD7 for ; Fri, 17 May 2002 10:53:43 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4HErf922961; Fri, 17 May 2002 10:53:41 -0400 (EDT) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA14898; Fri, 17 May 2002 09:53:40 -0500 (CDT) Received: by nwsgpc.ih.lucent.com (8.11.6+Sun/EMS-1.5 client sol2) id g4HEret24715; Fri, 17 May 2002 09:53:40 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15589.6515.891148.337359@nwsgpc.ih.lucent.com> Date: Fri, 17 May 2002 09:53:39 -0500 (CDT) From: Pete McCann To: Tony Johansson Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 In-Reply-To: <3CE41F66.4A4E4D9A@ericsson.com> References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> <3CE407B4.B638B5C3@ericsson.com> <15588.3316.714420.988318@nwsgpc.ih.lucent.com> <3CE41F66.4A4E4D9A@ericsson.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Tony, Tony Johansson writes: > In principle and IMHO, there isn't anything in draft -10 (with new proposed text to issue > 338) that wouldn't let you authorize the usage in the way you reasoning below. If you > disagree, please let me know where the wording is to strong or unclear. I hope you are correct, but I still think there may be issues with section 1.4. From the proposed text you have been discussing: > In the event that the mobile node that does not support the AAA NAI extension > has been previously authorized by the AAAH and now needs to be > re-authenticated, and requests to keep the assigned home agent in the foreign > network, the mobile node sends a registration request without the AAA NAI and > the HA NAI. Upon receipt, the FA will create the AMR including the > MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested > home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the > MIP-Feature-Vector AVP." I would rather propose that the last sentence be changed to, "If the AAAF authorizes the use of the requested home agent, and if it has knowledge that the requested home agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP." Also, in re-reading the rest of Section 1.4, it seems that re-authorization always requires an HAR to the home agent, wherever it happens to be. Is this a good idea, as we may not be able to reach the HA through the Diameter infrastructure if we don't have HA NAI? It would seem better in some cases, such as when the MN is using a previously allocated HA, to authorize the access via AAA but do Mobile IP registration as in RFC 2002, i.e., send the RRQ directly to the HA from the FA. While this doesn't allow the AAA infrastructure to make detailed decisions based on the domain of the HA, it may be allowed in some cases by the 3 networks. I guess what I am saying is, in the absence of both HA NAI and a guaranteed stateful AAAH, we have no way to distinguish the "previously allocated in foreign network" HA from one that is simply statically allocated, and which may not be connected to the AAA infrastructure in any way. Does the current text allow such HAs (such as a personal HA in my basement, not connected to a carrier AAA infrastructure) to get used? I would hope so, but if not, maybe the change is too big to get done at this point. Maybe I'm raising an old, closed issue here again... please let me know. -Pete From owner-aaa-wg@merit.edu Tue May 21 14:17:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23072 for ; Tue, 21 May 2002 14:17:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A00AA91239; Tue, 21 May 2002 14:15:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 760749123B; Tue, 21 May 2002 14:15:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CA9891239 for ; Tue, 21 May 2002 14:15:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18D275DE23; Tue, 21 May 2002 14:15:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id C32AC5DE04 for ; Tue, 21 May 2002 14:15:22 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g4LIFQl29345; Tue, 21 May 2002 13:15:26 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4LIFQa27539; Tue, 21 May 2002 13:15:26 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA19033; Tue, 21 May 2002 13:15:25 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA28622; Tue, 21 May 2002 13:15:24 -0500 (CDT) Message-ID: <3CEA8DE6.F917796B@ericsson.com> Date: Tue, 21 May 2002 11:11:50 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> <3CE407B4.B638B5C3@ericsson.com> <15588.3316.714420.988318@nwsgpc.ih.lucent.com> <3CE41F66.4A4E4D9A@ericsson.com> <15589.6515.891148.337359@nwsgpc.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Pete, Pete McCann wrote: > Hi, Tony, > > Tony Johansson writes: > > In principle and IMHO, there isn't anything in draft -10 (with new proposed text to issue > > 338) that wouldn't let you authorize the usage in the way you reasoning below. If you > > disagree, please let me know where the wording is to strong or unclear. > > I hope you are correct, but I still think there may be issues with > section 1.4. From the proposed text you have been discussing: > > > In the event that the mobile node that does not support the AAA NAI extension > > has been previously authorized by the AAAH and now needs to be > > re-authenticated, and requests to keep the assigned home agent in the foreign > > network, the mobile node sends a registration request without the AAA NAI and > > the HA NAI. Upon receipt, the FA will create the AMR including the > > MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of the requested > > home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the > > MIP-Feature-Vector AVP." > > I would rather propose that the last sentence be changed to, > > "If the AAAF authorizes the use of the requested home agent, and if it > has knowledge that the requested home agent is in its own > domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the > MIP-Feature-Vector AVP." I agree, thanks. > > > Also, in re-reading the rest of Section 1.4, it seems that > re-authorization always requires an HAR to the home agent, wherever it > happens to be. Is this a good idea, as we may not be able to reach > the HA through the Diameter infrastructure if we don't have HA NAI? > It would seem better in some cases, such as when the MN is using a > previously allocated HA, to authorize the access via AAA but do Mobile > IP registration as in RFC 2002, i.e., send the RRQ directly to the HA > from the FA. While this doesn't allow the AAA infrastructure to make > detailed decisions based on the domain of the HA, it may be allowed in > some cases by the 3 networks. I guess what I am saying is, in the > absence of both HA NAI and a guaranteed stateful AAAH, we have no way > to distinguish the "previously allocated in foreign network" HA from > one that is simply statically allocated, and which may not be > connected to the AAA infrastructure in any way. Does the current text > allow such HAs (such as a personal HA in my basement, not connected to > a carrier AAA infrastructure) to get used? I would hope so, but if > not, maybe the change is too big to get done at this point. Maybe I'm > raising an old, closed issue here again... please let me know. I would say this is both pretty hefty protocol changes and old closed issues, and in either case I strongly recommend that we reject this, if we plan to be done in the near future. It is true, without the AAA key distribution extension and the AAA NAI extension the functionality that can be offered to such legacy mobiles is limited, but nevertheless these mobiles can be offered at least the level of service as of today (and even more depending on how you can set up and configure your Diameter servers). Regards, /Tony > > > -Pete From owner-aaa-wg@merit.edu Tue May 21 14:39:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23827 for ; Tue, 21 May 2002 14:39:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55DD99123B; Tue, 21 May 2002 14:39:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BAB39123C; Tue, 21 May 2002 14:39:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DEFB89123B for ; Tue, 21 May 2002 14:39:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB2055DE63; Tue, 21 May 2002 14:39:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 763E85DE04 for ; Tue, 21 May 2002 14:39:46 -0400 (EDT) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4LIdm927275; Tue, 21 May 2002 14:39:48 -0400 (EDT) Received: from nwsgpc.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA13334; Tue, 21 May 2002 13:39:48 -0500 (CDT) Received: by nwsgpc.ih.lucent.com (8.11.6+Sun/EMS-1.5 client sol2) id g4LIdll22883; Tue, 21 May 2002 13:39:47 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15594.38003.426833.811405@nwsgpc.ih.lucent.com> Date: Tue, 21 May 2002 13:39:47 -0500 (CDT) From: Pete McCann To: Tony Johansson Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 In-Reply-To: <3CEA8DE6.F917796B@ericsson.com> References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> <3CE407B4.B638B5C3@ericsson.com> <15588.3316.714420.988318@nwsgpc.ih.lucent.com> <3CE41F66.4A4E4D9A@ericsson.com> <15589.6515.891148.337359@nwsgpc.ih.lucent.com> <3CEA8DE6.F917796B@ericsson.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Tony, Tony Johansson writes: > > I would rather propose that the last sentence be changed to, > > > > "If the AAAF authorizes the use of the requested home agent, and if it > > has knowledge that the requested home agent is in its own > > domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the > > MIP-Feature-Vector AVP." > > I agree, thanks. Ok. > > Also, in re-reading the rest of Section 1.4, it seems that > > re-authorization always requires an HAR to the home agent, wherever it > > happens to be. Is this a good idea, as we may not be able to reach > > the HA through the Diameter infrastructure if we don't have HA NAI? > > It would seem better in some cases, such as when the MN is using a > > previously allocated HA, to authorize the access via AAA but do Mobile > > IP registration as in RFC 2002, i.e., send the RRQ directly to the HA > > from the FA. While this doesn't allow the AAA infrastructure to make > > detailed decisions based on the domain of the HA, it may be allowed in > > some cases by the 3 networks. I guess what I am saying is, in the > > absence of both HA NAI and a guaranteed stateful AAAH, we have no way > > to distinguish the "previously allocated in foreign network" HA from > > one that is simply statically allocated, and which may not be > > connected to the AAA infrastructure in any way. Does the current text > > allow such HAs (such as a personal HA in my basement, not connected to > > a carrier AAA infrastructure) to get used? I would hope so, but if > > not, maybe the change is too big to get done at this point. Maybe I'm > > raising an old, closed issue here again... please let me know. > > I would say this is both pretty hefty protocol changes and old closed issues, and in either case > I strongly recommend that we reject this, if we plan to be done in the near future. It is true, > without the AAA key distribution extension and the AAA NAI extension the functionality that can > be offered to such legacy mobiles is limited, but nevertheless these mobiles can be offered at > least the level of service as of today (and even more depending on how you can set up and > configure your Diameter servers). Ok, I can accept that. I guess you are saying it may still be possible to do what I want with proper configuration of Diameter servers, even if HAR isn't implemented as outlined in the document (and it wouldn't strictly comply with the message flows there). I think this is reasonable for now, given that we need to close the document ASAP. -Pete From owner-aaa-wg@merit.edu Tue May 21 15:47:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26575 for ; Tue, 21 May 2002 15:47:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCDA49123D; Tue, 21 May 2002 15:47:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CC729123E; Tue, 21 May 2002 15:47:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C8CA9123D for ; Tue, 21 May 2002 15:46:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 083F95DE6B; Tue, 21 May 2002 15:46:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id CBBFE5DE23 for ; Tue, 21 May 2002 15:46:51 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g4LJkLDm015783 for ; Tue, 21 May 2002 15:46:22 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA10983 for ; Tue, 21 May 2002 15:46:27 -0400 (EDT) Date: Tue, 21 May 2002 15:46:19 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] location of Proxy-Info and Route-Record AVPs Message-ID: <20020521194619.GC1041@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 72 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: May 21, 2002 Reference: Document: base Comment type: T Priority: 1 Section: 8.3.1 etc. Rationale/Explanation of issue: In the following message format of Re-Auth-Request command described in section 8.3.1, Proxy-Info and Route-Record AVPs, which are defined to be optional, comes after "[ AVP ]" (this comment also applies to other commands that define AVP(s) after "[ AVP ]"): Message Format ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] But I think this definition contains the following ambiguity. If the intention is that those AVPs are optional but to be put at the tail of the command, they should be defined as AVPs with fixed position like: ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ AVP ] * < Proxy-Info > * < Route-Record > Otherwise, if those AVPs are just optional AVPs without a special position requirement, it would be better to define the format as: ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] Requested change: Needs more clarification or change the format to remove ambiguity. From owner-aaa-wg@merit.edu Tue May 21 22:26:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11973 for ; Tue, 21 May 2002 22:26:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 387789121C; Tue, 21 May 2002 22:26:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 126B29123E; Tue, 21 May 2002 22:26:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90D749121C for ; Tue, 21 May 2002 22:26:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78B5C5DE83; Tue, 21 May 2002 22:26:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 3FED35DE79 for ; Tue, 21 May 2002 22:26:46 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g4M2Qoi14601; Tue, 21 May 2002 21:26:50 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4M2Qnd24437; Tue, 21 May 2002 21:26:49 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA04441; Tue, 21 May 2002 21:26:49 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA05708; Tue, 21 May 2002 21:26:48 -0500 (CDT) Message-ID: <3CEB0111.DC57E3FA@ericsson.com> Date: Tue, 21 May 2002 19:23:13 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann Cc: Johan Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: text proposal to Issue 338 References: <3CD998F7.F01E4031@ericsson.com> <3CDF9C38.2000102@ipunplugged.com> <3CE2D3B8.AEE64546@ericsson.com> <3CE2F716.4070902@ipunplugged.com> <15587.56023.651237.144119@nwsgpc.ih.lucent.com> <3CE407B4.B638B5C3@ericsson.com> <15588.3316.714420.988318@nwsgpc.ih.lucent.com> <3CE41F66.4A4E4D9A@ericsson.com> <15589.6515.891148.337359@nwsgpc.ih.lucent.com> <3CEA8DE6.F917796B@ericsson.com> <15594.38003.426833.811405@nwsgpc.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pete McCann wrote: > > Ok, I can accept that. Very good. > I guess you are saying it may still be > possible to do what I want with proper configuration of Diameter > servers, even if HAR isn't implemented as outlined in the document > (and it wouldn't strictly comply with the message flows there). Well, not issuing HAR would be part of the hefty protocol change:) So, that you still have to do, if you want to stay interoperable. Regards, /Tony > I > think this is reasonable for now, given that we need to close the > document ASAP. > > -Pete From owner-aaa-wg@merit.edu Mon May 27 19:11:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25940 for ; Mon, 27 May 2002 19:11:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DBA791223; Mon, 27 May 2002 19:11:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21B6391224; Mon, 27 May 2002 19:11:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37F6D91223 for ; Mon, 27 May 2002 19:11:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBE4D5DE4E; Mon, 27 May 2002 19:11:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 455675DDD9 for ; Mon, 27 May 2002 19:11:36 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4RMNV822806 for ; Mon, 27 May 2002 15:23:31 -0700 Date: Mon, 27 May 2002 15:23:31 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 349: Accounting Response Bloat Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 349: Accounting Response Bloat Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 22, 2002 Reference: Document: Base Comment type: T Priority: S Section: 9.7.2 Rationale/Explanation of issue: Early on, Accounting Response bloating was identified as an issue in Diameter. For example, this is cited in Section 3.5 of draft-ietf-aaa-issues-05.txt, which refers to "SNMP-style" response bloat within Diameter. The problem is having the AVPs included in the Accounting-Request echo'd in the Accounting-Answer, greatly increasing the size of the ACA message. Section 9.7.2 of Base states: "The Accounting-Answer command contains the same Session-Id and MAY contains the same Accounting Description and Usage AVPs that were sent in the Accounting-Request command." This is inappropriate. The only reason that the usage AVPs should be included in the Accounting-Answer is if the NAS specifically requests this, such as by including the CMS-Data AVP. From owner-aaa-wg@merit.edu Tue May 28 14:35:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27546 for ; Tue, 28 May 2002 14:35:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 713CE91209; Tue, 28 May 2002 14:35:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D0C091236; Tue, 28 May 2002 14:35:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 576BB91209 for ; Tue, 28 May 2002 14:35:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B17E55DE64; Tue, 28 May 2002 14:35:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CAAD65DE59 for ; Tue, 28 May 2002 14:35:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4SHl3722243 for ; Tue, 28 May 2002 10:47:03 -0700 Date: Tue, 28 May 2002 10:47:03 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG roadmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has now completed on the following documents: http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-10.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-10.txt The issues raised in WG last call are tracked here: http://www.drizzle.com/~aboba/AAA/issues.html The current plan is to resolve all WG last call comments, and reissue new versions of the above documents, prior to the IETF 54 draft submission cutoff deadline. We will also be splitting out the EAP functionality of the NASREQ-09 draft into a separate document. We will then address the non-EAP issues in the NASREQ splitoff, and bring that document to AAA WG last call. This will also occur prior to the IETF 54 draft submission deadline. Given that the current focus is on resolving WG last call issues and readying documents for consideration by the IESG, there does not appear to be a need for the AAA WG to meet at IETF 54 in Yokahama. From owner-aaa-wg@merit.edu Tue May 28 21:01:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05333 for ; Tue, 28 May 2002 21:01:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A871F91253; Tue, 28 May 2002 21:00:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E35A91255; Tue, 28 May 2002 21:00:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 240B391253 for ; Tue, 28 May 2002 21:00:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 630215DE6E; Tue, 28 May 2002 21:00:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E86CA5DE2B for ; Tue, 28 May 2002 21:00:49 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4T0CdP10810 for ; Tue, 28 May 2002 17:12:39 -0700 Date: Tue, 28 May 2002 17:12:38 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 350: Mandatory Security Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 350: Mandatory Security Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 22, 2002 Reference: Document: Base Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: Security is mandatory to implement in Diameter Base, but not mandatory to use. This makes little sense, since security is mandatory to use in RADIUS. Section 2.2 of Base states: "Operating the Diameter protocol without any security mechanism is not recommended." Change to: "The Diameter protocol MUST NOT be used without any security mechanism (TLS or IPsec)." From owner-aaa-wg@merit.edu Wed May 29 01:28:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10286 for ; Wed, 29 May 2002 01:28:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8BED391252; Wed, 29 May 2002 01:28:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DB4791254; Wed, 29 May 2002 01:28:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53A5991252 for ; Wed, 29 May 2002 01:28:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95DE25DE21; Wed, 29 May 2002 01:28:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id B05055DDC6 for ; Wed, 29 May 2002 01:28:07 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4T5Tja07380 for ; Wed, 29 May 2002 08:29:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 May 2002 08:28:12 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 08:28:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 350: Mandatory Security Date: Wed, 29 May 2002 08:28:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD87@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 350: Mandatory Security Thread-Index: AcIGrGLFRYih6XACRI6rBA0wJGCbhAAIm9Mw From: To: , X-OriginalArrivalTime: 29 May 2002 05:28:12.0521 (UTC) FILETIME=[A02FBD90:01C206D1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA10286 Hi Bernard, I have made the change, you can close the issue. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 29 May, 2002 03:13 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 350: Mandatory Security > > > Issue 350: Mandatory Security > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: May 22, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > > Security is mandatory to implement in Diameter Base, but not > mandatory to use. This makes little sense, since security > is mandatory to use in RADIUS. > > Section 2.2 of Base states: > > "Operating the Diameter protocol without any security mechanism is not > recommended." > > Change to: > > "The Diameter protocol MUST NOT be used without any security > mechanism (TLS or IPsec)." > > > From owner-aaa-wg@merit.edu Wed May 29 01:28:44 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10316 for ; Wed, 29 May 2002 01:28:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB6B691254; Wed, 29 May 2002 01:28:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6876891255; Wed, 29 May 2002 01:28:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE63891254 for ; Wed, 29 May 2002 01:28:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3100E5DE21; Wed, 29 May 2002 01:28:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 788F25DDC6 for ; Wed, 29 May 2002 01:28:14 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4T5R8912735 for ; Wed, 29 May 2002 08:27:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 May 2002 08:28:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 08:28:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat Date: Wed, 29 May 2002 08:28:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD8A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 349: Accounting Response Bloat Thread-Index: AcIF0+oBlkAEqI64ToqLjE2Cg8s4WAA/BULQ From: To: , X-OriginalArrivalTime: 29 May 2002 05:28:19.0302 (UTC) FILETIME=[A43A7060:01C206D1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA10316 Hi Bernard, Do you propose to strike the 2nd part of the text entirely (that is OK for me) or modifying it to be something like: The Accounting-Answer command contains the same Session-Id and includes the the usage AVPs only if the NSA specifically requests that they be included, such as by including the CMS- DATA AVP. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 28 May, 2002 01:24 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 349: Accounting Response Bloat > > > Issue 349: Accounting Response Bloat > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: May 22, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 9.7.2 > Rationale/Explanation of issue: > > Early on, Accounting Response bloating was identified as an > issue in Diameter. For example, this is cited in > Section 3.5 of draft-ietf-aaa-issues-05.txt, which > refers to "SNMP-style" response bloat within Diameter. > The problem is having the AVPs included in the Accounting-Request > echo'd in the Accounting-Answer, greatly increasing the size > of the ACA message. > > Section 9.7.2 of Base states: > > "The Accounting-Answer command contains the same Session-Id and > MAY contains the same Accounting Description and Usage AVPs > that were sent in the Accounting-Request command." > > This is inappropriate. The only reason that the usage AVPs should > be included in the Accounting-Answer is if the NAS specifically > requests this, such as by including the CMS-Data AVP. > > > > From owner-aaa-wg@merit.edu Wed May 29 02:47:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04478 for ; Wed, 29 May 2002 02:47:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BF0891255; Wed, 29 May 2002 02:47:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFC3A91256; Wed, 29 May 2002 02:47:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE22591255 for ; Wed, 29 May 2002 02:47:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 320C55DD93; Wed, 29 May 2002 02:47:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B52E95DD8D for ; Wed, 29 May 2002 02:47:49 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4T5xZm29691; Tue, 28 May 2002 22:59:35 -0700 Date: Tue, 28 May 2002 22:59:35 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF0112FD8A@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Do you propose to strike the 2nd part of the text entirely (that is OK for me) or > modifying it to be something like: > > The Accounting-Answer command contains the same Session-Id and > includes the the usage AVPs only if the NSA specifically > requests that they be included, such as by including the CMS- > DATA AVP. This text would work for me. From owner-aaa-wg@merit.edu Wed May 29 03:14:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05237 for ; Wed, 29 May 2002 03:14:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11ED291256; Wed, 29 May 2002 03:14:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C56BC91258; Wed, 29 May 2002 03:14:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84B8391256 for ; Wed, 29 May 2002 03:14:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88BD45DE58; Wed, 29 May 2002 03:13:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 674915DD8D for ; Wed, 29 May 2002 03:13:50 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4T7FPa21605 for ; Wed, 29 May 2002 10:15:25 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 May 2002 10:13:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 29 May 2002 10:13:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat Date: Wed, 29 May 2002 10:13:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6529C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 349: Accounting Response Bloat Thread-Index: AcIG3Mr3JGS+JmeKTNWhGr107XFCxwAA49qg From: To: Cc: X-OriginalArrivalTime: 29 May 2002 07:13:52.0401 (UTC) FILETIME=[630CA810:01C206E0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA05237 Hi Bernard, Change is made, issue can be considered closed. John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 29 May, 2002 09:00 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat > > > > Do you propose to strike the 2nd part of the text entirely > (that is OK for me) or > > modifying it to be something like: > > > > The Accounting-Answer command contains the same Session-Id and > > includes the the usage AVPs only if the NSA specifically > > requests that they be included, such as by including the CMS- > > DATA AVP. > > This text would work for me. > > From owner-aaa-wg@merit.edu Wed May 29 05:08:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08019 for ; Wed, 29 May 2002 05:08:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06C4891259; Wed, 29 May 2002 05:09:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C88A39125A; Wed, 29 May 2002 05:09:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4A8D91259 for ; Wed, 29 May 2002 05:09:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04B675DD96; Wed, 29 May 2002 05:08:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 454195DDF2 for ; Wed, 29 May 2002 05:08:57 -0400 (EDT) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g4T9AM3O002029; Wed, 29 May 2002 11:10:22 +0200 Message-ID: <3CF49A86.2080308@ipunplugged.com> Date: Wed, 29 May 2002 11:08:22 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Bernard Aboba Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just out of curiousity, why would anyone want the AVPs echoed back in the first place? Theoretically the server could create the response by the mere flick of a bit and replacing the source and destination AVPs, but this seems like an insignificant optimization to me and there is no gain to the access device? It can not be used for verification of the transmitted AVPs and CMS would be a much better candidate for that in any case. Why is this needed/allowed at all? j Bernard Aboba wrote: >>Do you propose to strike the 2nd part of the text entirely (that is OK for me) or >>modifying it to be something like: >> >> The Accounting-Answer command contains the same Session-Id and >> includes the the usage AVPs only if the NSA specifically >> requests that they be included, such as by including the CMS- >> DATA AVP. >> > >This text would work for me. > From owner-aaa-wg@merit.edu Wed May 29 11:12:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20614 for ; Wed, 29 May 2002 11:12:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B20829125E; Wed, 29 May 2002 11:12:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8198D9125F; Wed, 29 May 2002 11:12:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 921FC9125E for ; Wed, 29 May 2002 11:12:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B75955DE58; Wed, 29 May 2002 11:12:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 397745DD8C for ; Wed, 29 May 2002 11:12:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g4TENqf25672; Wed, 29 May 2002 07:23:52 -0700 Date: Wed, 29 May 2002 07:23:52 -0700 (PDT) From: Bernard Aboba To: Johan Johansson Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat In-Reply-To: <3CF49A86.2080308@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I had assumed that it was needed/wanted in order for the NAS to check that the received AVPs were the ones that were sent. However, the text does not require or even suggest that such a check be done. Another reason would be if the NAS wanted a signed receipt. However, as you point out, CMS is a better candidate for that. So it looks to me like you are making an argument that there is no situation in which Response Bloating is helpful, and that it should be prohibited. Does anyone want to speak up *for* Response Bloating? On Wed, 29 May 2002, Johan Johansson wrote: > Just out of curiousity, why would anyone want the AVPs echoed back in > the first place? Theoretically the server could create the response by > the mere flick of a bit and replacing the source and destination AVPs, > but this seems like an insignificant optimization to me and there is no > gain to the access device? It can not be used for verification of the > transmitted AVPs and CMS would be a much better candidate for that in > any case. > > Why is this needed/allowed at all? > > j > > Bernard Aboba wrote: > > >>Do you propose to strike the 2nd part of the text entirely (that is OK for me) or > >>modifying it to be something like: > >> > >> The Accounting-Answer command contains the same Session-Id and > >> includes the the usage AVPs only if the NSA specifically > >> requests that they be included, such as by including the CMS- > >> DATA AVP. > >> > > > >This text would work for me. > > > > > From owner-aaa-wg@merit.edu Wed May 29 11:19:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20969 for ; Wed, 29 May 2002 11:19:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA0EB91205; Wed, 29 May 2002 11:20:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9DC991237; Wed, 29 May 2002 11:20:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F47F91205 for ; Wed, 29 May 2002 11:20:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AE235DE7E; Wed, 29 May 2002 11:19:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id 477665DE72; Wed, 29 May 2002 11:19:54 -0400 (EDT) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id LAA29630; Wed, 29 May 2002 11:20:00 -0400 (EDT) Date: Wed, 29 May 2002 11:20:00 -0400 From: William Bulley To: john.loughney@nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat Message-ID: <20020529112000.C29335@web1.merit.edu> Mail-Followup-To: john.loughney@nokia.com, aboba@internaut.com, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-wg@merit.edu Precedence: bulk According to john.loughney@nokia.com: > > Do you propose to strike the 2nd part of the text entirely (that is OK for me) or > modifying it to be something like: > > The Accounting-Answer command contains the same Session-Id and > includes the the usage AVPs only if the NSA specifically > requests that they be included, such as by including the CMS- > DATA AVP. s/NSA/NAS/ otherwise we are in deep doo-doo... ;^) Regards, web... -- William Bulley Email: web@merit.edu Merit Network Inc. Ann Arbor, Michigan From owner-aaa-wg@merit.edu Wed May 29 15:33:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00419 for ; Wed, 29 May 2002 15:33:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCC7E91263; Wed, 29 May 2002 15:33:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE86691264; Wed, 29 May 2002 15:33:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0B2591263 for ; Wed, 29 May 2002 15:33:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFF1B5DD99; Wed, 29 May 2002 15:33:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 89F6A5DE8E; Wed, 29 May 2002 15:33:46 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 53CE46A904; Wed, 29 May 2002 22:33:44 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4E0656A905; Wed, 29 May 2002 22:33:42 +0300 (EEST) Message-ID: <3CF52D5B.2020501@kolumbus.fi> Date: Wed, 29 May 2002 22:34:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com, aboba@internaut.com Cc: William Bulley , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat References: <20020529112000.C29335@web1.merit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree that we should avoid bloat. The question is, if we will avoid it only most of the time, or all of the time. John's suggested text deals with the case that the NAS [or the NSA -- are you sure John you don't work for them? ;-) ] indicates its need through either using or not using the CMS AVPs. This is the current approach, but it seems a bit at odds with the regular CMS 'P' and 'MAY ENCR' approach with fixed policies. There are AVPs that have a 'P' and 'MAY ENCR' in every ACR/ACA command, so it would seem that the CMS AVPs are needed in any case. Local configurations may indicate that CMS should be turned off for some communications, though. So indicating the need for the CMS AVPs in the response is one problem. Here we have the following alternatives: 1) current text, clarify that this rule takes precedence over the regular P/ENCR rules or 2) simply use the P/ENCR rules. Then there is another problem. What should go into the response, and how should the signature be made? Here we have the following alternatives: 1) If CMS is needed at all, copy all AVPs to the response. 2) Decide that we don't need this function i.e. no usage AVP copying at all and no signatures either. 3) Invent some special rules in CMS so that CMS-Signed-Data AVP can sign even AVPs that are omitted from the response. 4) A "hash" AVP is added by the NAS when it uses CMS, containing a hash of the AVPs protected by CMS. The server is then required to copy this AVP back, and per P/ENCR rules sign it. Personally, 2+4 would be the cleanest technical solution. I can live with 1+1 (John's text) to avoid too many changes. Jari From owner-aaa-wg@merit.edu Wed May 29 17:54:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04935 for ; Wed, 29 May 2002 17:54:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E13E691218; Wed, 29 May 2002 17:54:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB04091264; Wed, 29 May 2002 17:54:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4E2091218 for ; Wed, 29 May 2002 17:54:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B22EC5DD97; Wed, 29 May 2002 17:54:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id 055905DDA6; Wed, 29 May 2002 17:54:06 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep03-svc.swip.net with ESMTP id <20020529215411.JWHG12461.fep03-svc.swip.net@ipunplugged.com>; Wed, 29 May 2002 23:54:11 +0200 Message-ID: <3CF54E76.5010009@ipunplugged.com> Date: Wed, 29 May 2002 23:56:06 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: john.loughney@nokia.com, aboba@internaut.com, William Bulley , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat References: <20020529112000.C29335@web1.merit.edu> <3CF52D5B.2020501@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm have a shady understanding of how CMS works at best, so please bear with me if I'm completely off target. If you are using CMS, wouldn't the simple fact that the ACR checked out at the accounting server by itself mean that it was transfered correctly and the ACA with a DIAMETER_SUCCESS Result-Code be the receipt that it did? If this is not the case then I'd prefer your solutions in the order 4, 2, 1. I can't really comment on number 3. j Jari Arkko wrote: > > I agree that we should avoid bloat. > > The question is, if we will avoid it only most of the time, or all of > the time. > John's suggested text deals with the case that the NAS [or the NSA -- > are you > sure John you don't work for them? ;-) ] indicates its need through > either using > or not using the CMS AVPs. This is the current approach, but it seems > a bit > at odds with the regular CMS 'P' and 'MAY ENCR' approach with fixed > policies. > There are AVPs that have a 'P' and 'MAY ENCR' in every ACR/ACA > command, so > it would seem that the CMS AVPs are needed in any case. Local > configurations > may indicate that CMS should be turned off for some communications, > though. > > So indicating the need for the CMS AVPs in the response is one problem. > Here we have the following alternatives: 1) current text, clarify that > this rule takes precedence over the regular P/ENCR rules or 2) simply use > the P/ENCR rules. > > Then there is another problem. What should go into the response, and > how should the signature be made? Here we have the following > alternatives: > 1) If CMS is needed at all, copy all AVPs to the response. 2) Decide that > we don't need this function i.e. no usage AVP copying at all and no > signatures either. 3) Invent some special rules in CMS so that > CMS-Signed-Data > AVP can sign even AVPs that are omitted from the response. 4) A "hash" > AVP > is added by the NAS when it uses CMS, containing a hash of the AVPs > protected by CMS. The server is then required to copy this AVP back, > and per P/ENCR rules sign it. > > Personally, 2+4 would be the cleanest technical solution. I can live > with 1+1 (John's text) to avoid too many changes. > > Jari > From owner-aaa-wg@merit.edu Wed May 29 18:07:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05284 for ; Wed, 29 May 2002 18:07:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9100291264; Wed, 29 May 2002 18:07:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EB0091265; Wed, 29 May 2002 18:07:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AA5A91264 for ; Wed, 29 May 2002 18:07:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37E3D5DD97; Wed, 29 May 2002 18:07:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id EAA155DD8C; Wed, 29 May 2002 18:07:25 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 5E8C66A905; Thu, 30 May 2002 01:07:31 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4E1E46A904; Thu, 30 May 2002 01:07:29 +0300 (EEST) Message-ID: <3CF55165.4020107@kolumbus.fi> Date: Thu, 30 May 2002 01:08:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Johan Johansson Cc: john.loughney@nokia.com, aboba@internaut.com, William Bulley , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat References: <20020529112000.C29335@web1.merit.edu> <3CF52D5B.2020501@kolumbus.fi> <3CF54E76.5010009@ipunplugged.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson wrote: > I'm have a shady understanding of how CMS works at best, so please bear > with me if I'm completely off target. If you are using CMS, wouldn't the > simple fact that the ACR checked out at the accounting server by itself > mean that it was transfered correctly and the ACA with a > DIAMETER_SUCCESS Result-Code be the receipt that it did? Yes, though for the purposes of non-repudiation a "plaintext" ACA SUCCESS will not be helpful. That is, I send you something encrypted with your PK and signed by my PK. You will be able to conclusively show that I wrote the message. But I will not be able to show that you received it. Adding CMS on the ACA SUCCESS helps a bit, because now I can show you received something for session ID X. However, I still can't prove you received exactly those values that I sent you, because I could be lying later and claiming that I used the session ID with some other AVP values. Finally, adding either the usage AVPs, or a hash of them in the ACA SUCCESS, protected by CMS, will help me to show that you actually did receive the AVPs in question. Whether we need this function is another debate. Jari From owner-aaa-wg@merit.edu Wed May 29 18:57:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06554 for ; Wed, 29 May 2002 18:57:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E09891266; Wed, 29 May 2002 18:57:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFC5A91267; Wed, 29 May 2002 18:57:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDF9591266 for ; Wed, 29 May 2002 18:57:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1028F5DD97; Wed, 29 May 2002 18:57:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 7CEA15DD8C for ; Wed, 29 May 2002 18:57:07 -0400 (EDT) Received: from ipunplugged.com ([213.100.60.194]) by fep02-svc.swip.net with ESMTP id <20020529225712.MICT345.fep02-svc.swip.net@ipunplugged.com>; Thu, 30 May 2002 00:57:12 +0200 Message-ID: <3CF55D3B.8030208@ipunplugged.com> Date: Thu, 30 May 2002 00:59:07 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat References: <20020529112000.C29335@web1.merit.edu> <3CF52D5B.2020501@kolumbus.fi> <3CF54E76.5010009@ipunplugged.com> <3CF55165.4020107@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Johan Johansson wrote: > >> I'm have a shady understanding of how CMS works at best, so please >> bear with me if I'm completely off target. If you are using CMS, >> wouldn't the simple fact that the ACR checked out at the accounting >> server by itself mean that it was transfered correctly and the ACA >> with a DIAMETER_SUCCESS Result-Code be the receipt that it did? > > > Yes, though for the purposes of non-repudiation a "plaintext" ACA SUCCESS > will not be helpful. That is, I send you something encrypted with your > PK and signed by my PK. You will be able to conclusively show that I > wrote the message. But I will not be able to show that you received > it. True. And we all seem to agree that without CMS the same goes for echoing back the usage AVPs. > Adding CMS on the ACA SUCCESS helps a bit, because now I can show > you received something for session ID X. However, I still can't > prove you received exactly those values that I sent you, because > I could be lying later and claiming that I used the session ID > with some other AVP values. Yes, I think I understand now. You need to send something back that takes the sent values into account for non-repudiation purposes. Thank you for your explanation. So while the receiving end can prove that it received something from me and that it received the values I sent, I still can't prove that it received the values that I sent. > Finally, adding either the usage AVPs, or a hash of them in the > ACA SUCCESS, protected by CMS, will help me to show that you > actually did receive the AVPs in question. > > Whether we need this function is another debate. Non-repudiation seems near-essential on any AAA protocol's feature list. Using a hash seems lean, sufficient and in line with solutions to similar problems. j From owner-aaa-wg@merit.edu Thu May 30 02:46:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24347 for ; Thu, 30 May 2002 02:46:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 246B691220; Thu, 30 May 2002 02:46:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 818ED91270; Thu, 30 May 2002 02:46:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0166191220 for ; Thu, 30 May 2002 02:46:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D29DD5DDC3; Thu, 30 May 2002 02:46:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id EC7B45DDB7; Thu, 30 May 2002 02:46:05 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4U6kaq28734; Thu, 30 May 2002 09:46:36 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 09:46:10 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 09:46:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat Date: Thu, 30 May 2002 09:45:58 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652A7@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 349: Accounting Response Bloat Thread-Index: AcIHXTsqd2pA1MmvTPSl0ENePYKLwQAPALtQ From: To: , Cc: , , X-OriginalArrivalTime: 30 May 2002 06:46:10.0674 (UTC) FILETIME=[AEFEFD20:01C207A5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA24347 Hi all, In summary, my original 'NSA' will be included. I think that should solve it. John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 30 May, 2002 01:09 > To: Johan Johansson > Cc: Loughney John (NRC/Helsinki); aboba@internaut.com; William Bulley; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat > > > Johan Johansson wrote: > > > I'm have a shady understanding of how CMS works at best, so > please bear > > with me if I'm completely off target. If you are using CMS, > wouldn't the > > simple fact that the ACR checked out at the accounting > server by itself > > mean that it was transfered correctly and the ACA with a > > DIAMETER_SUCCESS Result-Code be the receipt that it did? > > > Yes, though for the purposes of non-repudiation a "plaintext" > ACA SUCCESS > will not be helpful. That is, I send you something encrypted with your > PK and signed by my PK. You will be able to conclusively show that I > wrote the message. But I will not be able to show that you received > it. > > Adding CMS on the ACA SUCCESS helps a bit, because now I can show > you received something for session ID X. However, I still can't > prove you received exactly those values that I sent you, because > I could be lying later and claiming that I used the session ID > with some other AVP values. > > Finally, adding either the usage AVPs, or a hash of them in the > ACA SUCCESS, protected by CMS, will help me to show that you > actually did receive the AVPs in question. > > Whether we need this function is another debate. > > Jari > > From owner-aaa-wg@merit.edu Thu May 30 03:43:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25331 for ; Thu, 30 May 2002 03:43:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 100D791222; Thu, 30 May 2002 03:43:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDF8691235; Thu, 30 May 2002 03:43:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1CAA91222 for ; Thu, 30 May 2002 03:43:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD7855DDC3; Thu, 30 May 2002 03:43:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id D4CE85DDB9; Thu, 30 May 2002 03:43:37 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4U7i8q19152; Thu, 30 May 2002 10:44:08 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 10:43:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 10:43:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat Date: Thu, 30 May 2002 10:43:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E2D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 349: Accounting Response Bloat Thread-Index: AcIHR9CVeKDlOwn8QnO6x0QUSEar1gAXjCWQ From: To: , Cc: , X-OriginalArrivalTime: 30 May 2002 07:43:42.0794 (UTC) FILETIME=[B89EB2A0:01C207AD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25331 Hi all, > The question is, if we will avoid it only most of the time, or all of the time. > John's suggested text deals with the case that the NAS [or the NSA -- are you > sure John you don't work for them? ;-) ] indicates its need through either using > or not using the CMS AVPs. This is the current approach, but it seems a bit > at odds with the regular CMS 'P' and 'MAY ENCR' approach with fixed policies. > There are AVPs that have a 'P' and 'MAY ENCR' in every ACR/ACA command, so > it would seem that the CMS AVPs are needed in any case. Local configurations > may indicate that CMS should be turned off for some communications, though. > > So indicating the need for the CMS AVPs in the response is one problem. > Here we have the following alternatives: 1) current text, clarify that > this rule takes precedence over the regular P/ENCR rules or > 2) simply use the P/ENCR rules. > > Then there is another problem. What should go into the response, and > how should the signature be made? Here we have the following > alternatives: > 1) If CMS is needed at all, copy all AVPs to the response. 2) Decide that > we don't need this function i.e. no usage AVP copying at all and no > signatures either. 3) Invent some special rules in CMS so that CMS-Signed-Data > AVP can sign even AVPs that are omitted from the response. 4) A "hash" AVP > is added by the NAS when it uses CMS, containing a hash of the AVPs > protected by CMS. The server is then required to copy this AVP back, > and per P/ENCR rules sign it. > > Personally, 2+4 would be the cleanest technical solution. I can live > with 1+1 (John's text) to avoid too many changes. I prefer the 1+1 approach. What would you see as the clarifying text needed. Is this sufficient? The Accounting-Answer command contains the same Session-Id and includes the the usage AVPs only if the NSA specifically requests that they be included, such as by including the CMS- DATA AVP. This this rule takes precedence over the regular P/ENCR rules. John From owner-aaa-wg@merit.edu Thu May 30 03:54:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25478 for ; Thu, 30 May 2002 03:54:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4880391235; Thu, 30 May 2002 03:54:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 164DD91271; Thu, 30 May 2002 03:54:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E32291235 for ; Thu, 30 May 2002 03:54:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CF845DE7D; Thu, 30 May 2002 03:54:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B9E745DE01; Thu, 30 May 2002 03:54:12 -0400 (EDT) Received: by p2.piuha.net (Postfix, from userid 962) id 1958D6A905; Thu, 30 May 2002 10:54:14 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8B9486A904; Thu, 30 May 2002 10:54:12 +0300 (EEST) Message-ID: <3CF5DAEA.4090806@kolumbus.fi> Date: Thu, 30 May 2002 10:55:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aboba@internaut.com, web@merit.edu, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38E2D@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > I prefer the 1+1 approach. What would you see as the clarifying text needed. > > Is this sufficient? > > The Accounting-Answer command contains the same Session-Id and > includes the the usage AVPs only if the NSA specifically > requests that they be included, such as by including the CMS- > DATA AVP. This this rule takes precedence over the regular > P/ENCR rules. => The Accounting-Answer command contains the same Session-Id and includes the usage AVPs only if CMS is in use when sending this command. Note that the inclusion of the usage AVPs when CMS is not being used leads to unnecessarily large answer messages, and can not be used as a server's proof of the receipt of these AVPs in an end-to-end fashion. (Then, later, when we want to fix the bloat problem also with CMS, we can add a new AVP that the NAS can include in the request for the hash, and the server can send it back signed. So I don't think we will lose this functionality for ever if we go for 1+1.) Jari From owner-aaa-wg@merit.edu Thu May 30 03:59:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25615 for ; Thu, 30 May 2002 03:59:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 870FF91271; Thu, 30 May 2002 04:00:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB6AC91272; Thu, 30 May 2002 04:00:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8212891271 for ; Thu, 30 May 2002 03:59:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 823A85DE01; Thu, 30 May 2002 03:59:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 6C5135DDB9; Thu, 30 May 2002 03:59:52 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4U7xhq03156; Thu, 30 May 2002 11:00:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 May 2002 10:59:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 30 May 2002 10:59:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 349: Accounting Response Bloat Date: Thu, 30 May 2002 10:59:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC652B4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 349: Accounting Response Bloat Thread-Index: AcIHr0kOonwVAxuXRG+xj2/dKqLcawAAJZ1Q From: To: Cc: , , X-OriginalArrivalTime: 30 May 2002 07:59:18.0089 (UTC) FILETIME=[E6196390:01C207AF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25615 Hi Jari, Sounds good, I will add the text. john > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 30 May, 2002 10:55 > To: Loughney John (NRC/Helsinki) > Cc: aboba@internaut.com; web@merit.edu; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 349: Accounting Response Bloat > > > john.loughney@nokia.com wrote: > > > > I prefer the 1+1 approach. What would you see as the > clarifying text needed. > > > > Is this sufficient? > > > > The Accounting-Answer command contains the same Session-Id and > > includes the the usage AVPs only if the NSA specifically > > requests that they be included, such as by including the CMS- > > DATA AVP. This this rule takes precedence over the regular > > P/ENCR rules. > > > => > > The Accounting-Answer command contains the same Session-Id and > includes the usage AVPs only if CMS is in use when sending this > command. Note that the inclusion of the usage AVPs when CMS is > not being used leads to unnecessarily large answer messages, > > and can not be used as a server's proof of the receipt of these > > AVPs in an end-to-end fashion. > > (Then, later, when we want to fix the bloat problem also with > CMS, we can add a new AVP that the NAS can include in the request > for the hash, and the server can send it back signed. So I don't > think we will lose this functionality for ever if we go for 1+1.) > > Jari > >