From owner-aaa-wg@merit.edu Mon Oct 1 05:14:25 2001 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 FAA08626 for ; Mon, 1 Oct 2001 05:14:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBBD491241; Mon, 1 Oct 2001 05:15:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6167191244; Mon, 1 Oct 2001 05:15: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 CB74791241 for ; Mon, 1 Oct 2001 05:15:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDFE75DDB9; Mon, 1 Oct 2001 05:15:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C3CD65DDB4 for ; Mon, 1 Oct 2001 05:14:59 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA20121 for ; Mon, 1 Oct 2001 11:14:27 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue: Missing Disconnect Cause Date: Mon, 1 Oct 2001 11:15:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Fredrik Johansson Submitter email address: fredrik@ipunplugged.com Date first submitted: 2001-10-01 Reference: Document: base-08-alpha Comment type: T Priority: 1 Section: Rationale/Explanation of issue: What disconnect cause should be sent when disconnecting due to a lost election. Requested change: Add new disconnect cause code, e.g. ELECTION_LOST 3 Sent on the transport connection that has lost the election. From owner-aaa-wg@merit.edu Mon Oct 1 05:23:27 2001 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 FAA09145 for ; Mon, 1 Oct 2001 05:23:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0E4191244; Mon, 1 Oct 2001 05:24:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 788B991245; Mon, 1 Oct 2001 05:24:02 -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 1520691244 for ; Mon, 1 Oct 2001 05:24:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8D795DDB9; Mon, 1 Oct 2001 05:24:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B676B5DDB4 for ; Mon, 1 Oct 2001 05:23:59 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA20403 for ; Mon, 1 Oct 2001 11:23:27 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue: Changes to Peer state machine in base-08-alpha Date: Mon, 1 Oct 2001 11:24:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Fredrik Johansson Submitter email address: fredrik@ipunplugged.com Date first submitted: 2001-10-01 Reference: Document: base-08-alpha Comment type: T Priority: 1 Section: Rationale/Explanation of issue: Typos/errors in peer state machine Requested change: change: Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept, Wait-Returns Process-CER, Elect I-Peer-Disc I-Disc Closed ------> I-Rcv-DPR I-Snd-DPA,I-Disc Closed <----- I-Rcv-Non-CEA Error ^^^^^^ Closed Timeout Error Closed I-Open Send-Message I-Snd-Message I-Open I-Rcv-Message Process I-Open WatchDog-Timer I-Snd-DWR I-Open I-Rcv-DWR Process-DWR, I-Open I-Snd-DWA I-Rcv-DWA Process-DWA I-Open R-Conn-CER R-Reject I-Open ------> Stop I-Snd-DPR Closing <------ I-Rcv-DPR I-Snd-DPA, Closed I-Disc I-Peer-Disc I-Disc Closed <------- I-Rcv-CER Error Closed I-Rcv-CEA Error Closed and add: Closing I-Rcv-DPA I-Disc Closed R-Rcv-DPA R-Disc Closed Timeout Error Closed -----> I-Peer-Disc I-Disc Closed <------- -----> R-Peer-Disc R-Disc Closed <------- From owner-aaa-wg@merit.edu Mon Oct 1 07:31:30 2001 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 HAA11435 for ; Mon, 1 Oct 2001 07:31:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7574491247; Mon, 1 Oct 2001 07:31:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 496049124B; Mon, 1 Oct 2001 07:31:50 -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 1283F91247 for ; Mon, 1 Oct 2001 07:31:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A59885DDA0; Mon, 1 Oct 2001 07:31:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 660245DD8C for ; Mon, 1 Oct 2001 07:31:48 -0400 (EDT) Received: (qmail 18531 invoked by uid 500); 1 Oct 2001 11:16:34 -0000 Date: Mon, 1 Oct 2001 04:16:33 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 186: Decouple authorization and key generation Message-ID: <20011001041633.A18522@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, The proposed solution removes the ability for mobility entities to be notified of the key lifetime. How about we introduce a new avp: x.x.x MIP-Key-Lifetime AVP The MIP-Key-Lifetime AVP (AVP Code TBD) is of type Unsigned32 and represents the period of time (in seconds) for which the session key is valid. The session key MUST NOT be used if the lifetime has expired; if the key lifetime expires while the session to which it applies is still active, either the session key MUST be changed or the or the session MUST be terminated. PatC From owner-aaa-wg@merit.edu Mon Oct 1 07:45:53 2001 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 HAA11876 for ; Mon, 1 Oct 2001 07:45:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9885D9124C; Mon, 1 Oct 2001 07:45:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 664BD9124D; Mon, 1 Oct 2001 07:45: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 3798D9124C for ; Mon, 1 Oct 2001 07:45:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 085925DDA0; Mon, 1 Oct 2001 07:45:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B490D5DD8C for ; Mon, 1 Oct 2001 07:45:36 -0400 (EDT) Received: (qmail 18599 invoked by uid 500); 1 Oct 2001 11:30:23 -0000 Date: Mon, 1 Oct 2001 04:30:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011001043023.D18522@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk The proposed resolution is to look at the URI to determine whether TLS should be used to connect to the peer. One way to look at this is that section 2.2 states that all servers must support TLS, so it would probably be safe to connect to the TLS port if IPSec is not locally used. However, if a server was to connect to a client, TLS is not guaranteed. So, we have the following options: 1. rely on the URI 2. state that the TLS port is used if IPSec is not used my preference is #2. PatC From owner-aaa-wg@merit.edu Mon Oct 1 08:08:17 2001 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 IAA12754 for ; Mon, 1 Oct 2001 08:08:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B798B91250; Mon, 1 Oct 2001 08:09:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8366391254; Mon, 1 Oct 2001 08:09: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 3C51591250 for ; Mon, 1 Oct 2001 08:09:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F40365DD96; Mon, 1 Oct 2001 08:09:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B441C5DD8C for ; Mon, 1 Oct 2001 08:09:03 -0400 (EDT) Received: (qmail 18988 invoked by uid 500); 1 Oct 2001 11:53:50 -0000 Date: Mon, 1 Oct 2001 04:53:49 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 164: problems with watchdog Message-ID: <20011001045349.F18522@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Since issue 173 moves all of the transport text to the aaa-transports specification, I will reject 164. Could the author of this issue please make sure that the issue has been resolved in the proposed language for aaa-transports which Bernard sent out last week? PatC From owner-aaa-wg@merit.edu Mon Oct 1 09:12:10 2001 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 JAA15962 for ; Mon, 1 Oct 2001 09:12:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACDC69120D; Mon, 1 Oct 2001 09:12:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ED4591253; Mon, 1 Oct 2001 09:12: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 6E7189120D for ; Mon, 1 Oct 2001 09:12:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 420695DDA0; Mon, 1 Oct 2001 09:12:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 5AB885DD8C for ; Mon, 1 Oct 2001 09:12:56 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA27809; Mon, 1 Oct 2001 15:12:21 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 191: How to know when to use TLS Date: Mon, 1 Oct 2001 15:12:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011001043023.D18522@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >The proposed resolution is to look at the URI to determine whether TLS >should be used to connect to the peer. > >One way to look at this is that section 2.2 states that all servers must >support TLS, so it would probably be safe to connect to the TLS port if >IPSec is not locally used. However, if a server was to connect to a client, >TLS is not guaranteed. > >So, we have the following options: >1. rely on the URI >2. state that the TLS port is used if IPSec is not used TLS port?!? I guess you mean to use TLS on diameter default port TBD (or other configured port). How can the diameter application determine if IPsec is used? /Fredrik > >my preference is #2. > >PatC From owner-aaa-wg@merit.edu Mon Oct 1 10:25:23 2001 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 KAA18502 for ; Mon, 1 Oct 2001 10:25:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5ABD491249; Mon, 1 Oct 2001 10:26:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 288309124F; Mon, 1 Oct 2001 10:26:10 -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 163CC91249 for ; Mon, 1 Oct 2001 10:26:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA7C85DDB4; Mon, 1 Oct 2001 10:26:08 -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 905A75DDB3 for ; Mon, 1 Oct 2001 10:26:08 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-129.cisco.com [144.254.46.130]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA18446; Mon, 1 Oct 2001 07:24:57 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Henry. Haverinen@Nokia. Com" Cc: "AAA WG" , Subject: [AAA-WG]: Issue 188 Date: Mon, 1 Oct 2001 07:24:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011001042524.B18522@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The issue says: "The NAS-Key-Binding AVP specifies the purpose of the session key. The AVP MUST be included if the NAS-Session-Key AVP is included. The key binding specifies which ciphersuite will be used between the NAS and the user. The problem is that the ciphersuite may not have been selected yet. In PPP, ECP is used to negotiate the ciphersuite and it occurs between the user and the NAS after authentication. In IEEE 802.11, the ciphesuite negotiation may as well occur after authentication." I think that this is a red herring: it doesn't matter if the ciphersuite is negotiated _after_ authentication, because the Diameter server is _telling_ the NAS or AP which ciphersuite to choose. "In addition, the NAS-Key-Binding AVP makes AAA servers dependent on and aware of different ciphersuites, so they need to be updated if a new ciphersuite is specified." This is a more reasonable concern, but OTOH 1) the frequency of the adoption of new ciphersuites is probably going to be fairly low and 2) the task of updating the Diameter servers w/a new ciphersuite type seems to pale beside that of updating the access devices to support the new ciphersuite. "Even if the ciphersuite hasn't been selected, the AAA server can still transport keying material to the NAS in the NAS-Session-Key AVP. For example, it can include large session keys which the NAS can truncate as necessary for use with a given ciphersuite." Isn't there more to it than just transporting & truncating keying material, though? For instance, DES, RC4 and other algorithms have so-called "weak" keys... From owner-aaa-wg@merit.edu Mon Oct 1 10:30:40 2001 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 KAA18688 for ; Mon, 1 Oct 2001 10:30:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACE2D91251; Mon, 1 Oct 2001 10:30:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EB7C91258; Mon, 1 Oct 2001 10:30: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 49F2A91251 for ; Mon, 1 Oct 2001 10:30:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F46B5DDB4; Mon, 1 Oct 2001 10:30:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C05D85DDB3 for ; Mon, 1 Oct 2001 10:30:50 -0400 (EDT) Received: (qmail 19383 invoked by uid 500); 1 Oct 2001 14:15:36 -0000 Date: Mon, 1 Oct 2001 07:15:36 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011001071536.A19374@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20011001043023.D18522@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Mon, Oct 01, 2001 at 03:12:55PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Oct 01, 2001 at 03:12:55PM +0200, Fredrik Johansson wrote: > > > >The proposed resolution is to look at the URI to determine whether TLS > >should be used to connect to the peer. > > > >One way to look at this is that section 2.2 states that all servers must > >support TLS, so it would probably be safe to connect to the TLS port if > >IPSec is not locally used. However, if a server was to connect to a client, > >TLS is not guaranteed. > > > >So, we have the following options: > >1. rely on the URI > >2. state that the TLS port is used if IPSec is not used > > TLS port?!? I guess you mean to use TLS on diameter default port TBD > (or other configured port). draft-ietf-aaa-diameter-08.txt, section 2.1: " The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until IANA assigns a port to the protocol). When used with TLS [38], The Diameter protocol is run on port TBD of both TCP and SCTP." There are two ports allocated for the protocol, one where TLS is used and the other one. > How can the diameter application determine if IPsec is used? That's unfortunately an implementation detail. If the OS you are on doesn't allow you to view the local security policies, then you can always attempt TLS. PatC From owner-aaa-wg@merit.edu Mon Oct 1 10:37:56 2001 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 KAA18996 for ; Mon, 1 Oct 2001 10:37:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2EF369124F; Mon, 1 Oct 2001 10:38:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EED1691258; Mon, 1 Oct 2001 10:38:32 -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 DC8D19124F for ; Mon, 1 Oct 2001 10:38:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB62F5DDB4; Mon, 1 Oct 2001 10:38:31 -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 3284A5DDB3 for ; Mon, 1 Oct 2001 10:38:31 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-129.cisco.com [144.254.46.130]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA26719; Mon, 1 Oct 2001 07:32:23 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Henry. Haverinen@Nokia. Com" Cc: "AAA WG" Subject: [AAA-WG]: Issue 189 Date: Mon, 1 Oct 2001 07:32:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Henry, I contributed some text a couple of weeks ago (see below) that I think deals w/these concerns. NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key-Binding } { NAS-Key-Data } [ NAS-Key-Lifetime ] [ NAS-IV ] * [ AVP ] <...> The NAS-IV AVP (AVP Code 410) is of type OctetString. Its contents MAY be used as an initialization vector (IV) by cryptographic algorithms (e.g., block ciphers). From owner-aaa-wg@merit.edu Mon Oct 1 10:42:10 2001 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 KAA19163 for ; Mon, 1 Oct 2001 10:42:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2496591258; Mon, 1 Oct 2001 10:42:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E26D39125E; Mon, 1 Oct 2001 10:42: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 B5C5B91258 for ; Mon, 1 Oct 2001 10:42:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 946415DDC0; Mon, 1 Oct 2001 10:42:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1455B5DDB4 for ; Mon, 1 Oct 2001 10:42:45 -0400 (EDT) Received: (qmail 20146 invoked by uid 500); 1 Oct 2001 14:27:29 -0000 Date: Mon, 1 Oct 2001 07:27:28 -0700 From: Pat Calhoun To: Glen Zorn Cc: "Henry. Haverinen@Nokia. Com" , AAA WG Subject: Re: [AAA-WG]: Issue 189 Message-ID: <20011001072728.I19374@charizard.diameter.org> Mail-Followup-To: Glen Zorn , "Henry. Haverinen@Nokia. Com" , AAA WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gwz@cisco.com on Mon, Oct 01, 2001 at 07:32:23AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk yes, these changes didn't make it into the alpha last week, but will be in the next revision. If Glen's changes addresses this problem, then I'd like to close 189. PatC On Mon, Oct 01, 2001 at 07:32:23AM -0700, Glen Zorn wrote: > Henry, > > I contributed some text a couple of weeks ago (see below) that I think deals > w/these concerns. > > NAS-Session-Key ::= < AVP Header: 408 > > { NAS-Key-Direction } > { NAS-Key-Type } > { NAS-Key-Binding } > { NAS-Key-Data } > [ NAS-Key-Lifetime ] > [ NAS-IV ] > * [ AVP ] > <...> > The NAS-IV AVP (AVP Code 410) is of type OctetString. Its contents > MAY be used as an initialization vector (IV) by cryptographic algorithms > (e.g., block ciphers). > From owner-aaa-wg@merit.edu Mon Oct 1 11:11:38 2001 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 LAA19972 for ; Mon, 1 Oct 2001 11:11:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3BC4491252; Mon, 1 Oct 2001 11:12:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0986891255; Mon, 1 Oct 2001 11:12: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 D303F91252 for ; Mon, 1 Oct 2001 11:12:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE6965DDBF; Mon, 1 Oct 2001 11:12:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5B5945DDB3 for ; Mon, 1 Oct 2001 11:12:24 -0400 (EDT) Received: (qmail 20913 invoked by uid 500); 1 Oct 2001 14:57:09 -0000 Date: Mon, 1 Oct 2001 07:57:09 -0700 From: Pat Calhoun To: Simon Josefsson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: [AAA-WG]: Re: Issue 191: How to know when to use TLS Message-ID: <20011001075709.K19374@charizard.diameter.org> Mail-Followup-To: Simon Josefsson , Pat Calhoun , aaa-wg@merit.edu References: <20011001071536.A19374@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sjosefsson@rsasecurity.com on Mon, Oct 01, 2001 at 04:52:20PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > There are two ports allocated for the protocol, one where TLS is used and the > > other one. > > Has this been decided? I believe IETF/IANA does not want to issue > parallel "secure" port numbers, see e.g. RFC 2817 (I can't find a > better reference, sorry): > > At the Washington DC IETF meeting in December 1997, the Applications > Area Directors and the IESG reaffirmed that the practice of issuing > parallel "secure" port numbers should be deprecated. > hmmm... this creates some serious challenges at the app layer. > The other alternative, using the URI to find out security status, has > the same problem -- it requires one URI format for the raw protocol > and one URI format for the TLS-wrapped protocol. > > I believe the right thing to do is to support negotiation of these > parameters within the protocol -- something like SASL's "EXTERNAL" may > be used if implementation uses IPSEC or TLS to protect the > communication. so perhaps two ways: 1. static configuration - we don't care about this case 2. add info in URI This would allow for a single port to be used. PatC From owner-aaa-wg@merit.edu Mon Oct 1 11:36:25 2001 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 LAA20790 for ; Mon, 1 Oct 2001 11:36:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1403691255; Mon, 1 Oct 2001 11:37:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9F519125A; Mon, 1 Oct 2001 11:37: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 AF5EA91255 for ; Mon, 1 Oct 2001 11:37:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 842C25DDBF; Mon, 1 Oct 2001 11:37:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3D1115DDB3 for ; Mon, 1 Oct 2001 11:37:10 -0400 (EDT) Received: (qmail 21083 invoked by uid 500); 1 Oct 2001 15:21:55 -0000 Date: Mon, 1 Oct 2001 08:21:55 -0700 From: Pat Calhoun To: Simon Josefsson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: [AAA-WG]: Re: Issue 191: How to know when to use TLS Message-ID: <20011001082155.P19374@charizard.diameter.org> Mail-Followup-To: Simon Josefsson , Pat Calhoun , aaa-wg@merit.edu References: <20011001071536.A19374@charizard.diameter.org> <20011001075709.K19374@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sjosefsson@rsasecurity.com on Mon, Oct 01, 2001 at 05:32:30PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Oct 01, 2001 at 05:32:30PM +0200, Simon Josefsson wrote: > Pat Calhoun writes: > > >> > There are two ports allocated for the protocol, one where TLS is used and the > >> > other one. > >> > >> Has this been decided? I believe IETF/IANA does not want to issue > >> parallel "secure" port numbers, see e.g. RFC 2817 (I can't find a > >> better reference, sorry): > >> > >> At the Washington DC IETF meeting in December 1997, the Applications > >> Area Directors and the IESG reaffirmed that the practice of issuing > >> parallel "secure" port numbers should be deprecated. > >> > > hmmm... this creates some serious challenges at the app layer. > > I think that was the point -- application protocols should be designed > with security in mind. > > Of course, the decision is intended to help rather than to annoy you, > if the application protocol is not designed for this, that design will > cause problems for you later when something other than TLS or IPSEC > comes around. Most "old" protocols, SMTP, HTTP etc has showed this to > be enough of a problem to motivate the above practice, I believe. not annoyed The challenge here is how does one know whether to invoke the TLS library to connect to a peer or not. The above assumes that TLS is native in the app, so it can detect whether a peer wishes to do TLS negotiation. > Does this mean that it is too late to add the proper security > negotiation mechanisms in the Diameter protocol? (Similar to the > security negotiation phases that has been added to SMTP, HTTP and > other protocols not designed for security from the beginning.) > > I'm sorry, I do not know enough about Diameter to tell. Well, protocol fixes are allowed, new features aren't. I guess the challenge here is to determine which category this falls under. PatC From owner-aaa-wg@merit.edu Mon Oct 1 12:01:55 2001 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 MAA21638 for ; Mon, 1 Oct 2001 12:01:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83DBE9125A; Mon, 1 Oct 2001 12:02:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4570C91261; Mon, 1 Oct 2001 12:02: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 22EE89125A for ; Mon, 1 Oct 2001 12:02:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE0BE5DDB3; Mon, 1 Oct 2001 12:02:25 -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 56F445DD98 for ; Mon, 1 Oct 2001 12:02:25 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-129.cisco.com [144.254.46.130]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA20550; Mon, 1 Oct 2001 08:54:50 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Simon Josefsson" Cc: Subject: RE: [AAA-WG]: Re: Issue 191: How to know when to use TLS Date: Mon, 1 Oct 2001 08:54:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011001082155.P19374@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Or we could just use CMS for both hop-by-hop and e2e security... From owner-aaa-wg@merit.edu Mon Oct 1 12:03:19 2001 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 MAA21681 for ; Mon, 1 Oct 2001 12:03:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 470C091261; Mon, 1 Oct 2001 12:04:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCBF091262; Mon, 1 Oct 2001 12:04:09 -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 7138591261 for ; Mon, 1 Oct 2001 12:04:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52D4F5DD98; Mon, 1 Oct 2001 12:04:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 2A9955DDB3 for ; Mon, 1 Oct 2001 12:04:08 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA04248 for ; Mon, 1 Oct 2001 09:03:08 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA25478 for ; Mon, 1 Oct 2001 09:03:07 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 1 Oct 2001 11:03:07 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 186: Decouple authorization and key generatio n Date: Mon, 1 Oct 2001 11:03:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, If the intent is to add the MIP-Key-Lifetime AVP in the MIP-XX-to-XX-Key AVP definitions (Sections 6.1-6.6), then our solutions coincide and you can close this issue. -Panos -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Monday, October 01, 2001 6:17 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 186: Decouple authorization and key generation All, The proposed solution removes the ability for mobility entities to be notified of the key lifetime. How about we introduce a new avp: x.x.x MIP-Key-Lifetime AVP The MIP-Key-Lifetime AVP (AVP Code TBD) is of type Unsigned32 and represents the period of time (in seconds) for which the session key is valid. The session key MUST NOT be used if the lifetime has expired; if the key lifetime expires while the session to which it applies is still active, either the session key MUST be changed or the or the session MUST be terminated. PatC From owner-aaa-wg@merit.edu Mon Oct 1 13:16:29 2001 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 NAA23971 for ; Mon, 1 Oct 2001 13:16:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A17891260; Mon, 1 Oct 2001 13:16:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDFD391264; Mon, 1 Oct 2001 13:16: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 CD8CC91260 for ; Mon, 1 Oct 2001 13:16:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5E045DDB0; Mon, 1 Oct 2001 13:16:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 745A45DD98 for ; Mon, 1 Oct 2001 13:16:57 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id 444C51F7B9 for ; Mon, 1 Oct 2001 10:15:47 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA25770; Mon, 1 Oct 2001 10:17:20 -0700 (PDT) Date: Mon, 1 Oct 2001 10:17:20 -0700 (PDT) From: Joe Lau Message-Id: <200110011717.KAA25770@strtio1.cup.hp.com> To: aaa-wg@merit.edu Subject: [AAA-WG]: MIP-Filter-Rule Cc: jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Can someone show me an example on how the MIP-Filter-Rule AVP is used? Thank you. Joe From owner-aaa-wg@merit.edu Mon Oct 1 15:27:18 2001 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 PAA28250 for ; Mon, 1 Oct 2001 15:27:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEF9991265; Mon, 1 Oct 2001 15:28:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92C2591266; Mon, 1 Oct 2001 15:28:06 -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 7D06191265 for ; Mon, 1 Oct 2001 15:28:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 497B35DDB0; Mon, 1 Oct 2001 15:28:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id 04C7B5DD98 for ; Mon, 1 Oct 2001 15:28:04 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel13.hp.com (Postfix) with ESMTP id 473CA1F6AF; Mon, 1 Oct 2001 12:27:03 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA26208; Mon, 1 Oct 2001 12:28:36 -0700 (PDT) Date: Mon, 1 Oct 2001 12:28:36 -0700 (PDT) From: Joe Lau Message-Id: <200110011928.MAA26208@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: [AAA-WG]: Authorization-Lifetime contradiction Cc: aaa-wg@merit.edu, jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I found contradictory statement about about the value of Authorization-Lifetime in the two following drafts: : A value of zero (0) means that immediate re-auth is necessary by the accesss device. ... The absence of this AVP, or a value of all ones means no re-auth is expected. : The Authorization-Lifetime AVP contains the number of seconds before registration keys destined for the Home Agent and/or Foreign Agent expire. A value of zero indicates infinity (no timeout). Which statement is correct? Regards, Joe From owner-aaa-wg@merit.edu Mon Oct 1 15:34:19 2001 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 PAA28476 for ; Mon, 1 Oct 2001 15:34:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6504A91274; Mon, 1 Oct 2001 15:34:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C549912A4; Mon, 1 Oct 2001 15:34:49 -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 9240F91274 for ; Mon, 1 Oct 2001 15:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C7EA5DDB0; Mon, 1 Oct 2001 15:34:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by segue.merit.edu (Postfix) with ESMTP id 286015DD98 for ; Mon, 1 Oct 2001 15:34:44 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id 6F6B0484; Mon, 1 Oct 2001 12:33:39 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA26287; Mon, 1 Oct 2001 12:35:12 -0700 (PDT) Date: Mon, 1 Oct 2001 12:35:12 -0700 (PDT) From: Joe Lau Message-Id: <200110011935.MAA26287@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: [AAA-WG]: MIP-Replay-Mode value assignement Cc: aaa-wg@merit.edu, jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I found inconsistency between the two drafts on Replay-Mode value assignments: : Replay Method Name ------------- ----- 1 None 2 Timestamps 3 Nonces : The 6.10 MIP-Replay-Mode AVP The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent should use when authenticating the Mobile Node. The following values are supported (see [4] for more information): 0 None 1 Timestamps 2 Nonces Which one is correct? Regards, Joe From owner-aaa-wg@merit.edu Mon Oct 1 15:34:44 2001 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 PAA28507 for ; Mon, 1 Oct 2001 15:34:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 60C17912A4; Mon, 1 Oct 2001 15:35:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 202A5912A9; Mon, 1 Oct 2001 15:35: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 44F1C912A4 for ; Mon, 1 Oct 2001 15:35:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F9CA5DDB0; Mon, 1 Oct 2001 15:35:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id B22805DD98 for ; Mon, 1 Oct 2001 15:35:11 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA21170 for ; Mon, 1 Oct 2001 12:25:44 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA16141 for ; Mon, 1 Oct 2001 12:34:11 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 1 Oct 2001 14:34:11 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: Add Termination-Cause values for MIPv4 Date: Mon, 1 Oct 2001 14:34:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Panos Thomas Submitter email address: Panos.Thomas@motorola.com Date first submitted: 2001-10-01 Reference: N/A Document: base-08-alpha Comment type: T Priority: 1 Section: 8.15 Rationale/Explanation of issue: In a MIPv4 scenario, when old-FA detects that the user has moved to a new-FA, or when its Auth-Lifetime+Grace-Period timer expires, it sends an STR to AAAH to terminate the (old-FA)-(AAAH) session. What Termination-Cause value should the old-FA use in these cases? DIAMETER_LOGOUT or DIAMETER_LINK_BROKEN may cause the AAAH to also terminate the (AAAH)-(HA) session. Requested change: Add the following Termination-Cause AVP values in Section 8.15: DIAMETER_AUTH_EXPIRED This value is used when the Auth-Lifetime + Auth-Grace-Period expires on access device. DIAMETER_USER_MOVED This value is used in a MIP scenario when the FA determines that the user has moved to a new FA. -Panos From owner-aaa-wg@merit.edu Tue Oct 2 03:17:28 2001 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 DAA29180 for ; Tue, 2 Oct 2001 03:17:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49D149126D; Tue, 2 Oct 2001 03:17:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5802A91276; Tue, 2 Oct 2001 03:17: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 A5BB19126D for ; Tue, 2 Oct 2001 03:17:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 700CA5DDC9; Tue, 2 Oct 2001 03:17:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 183325DD93 for ; Tue, 2 Oct 2001 03:17:40 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA29110; Tue, 2 Oct 2001 09:16:32 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 191: How to know when to use TLS Date: Tue, 2 Oct 2001 09:17:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011001071536.A19374@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >On Mon, Oct 01, 2001 at 03:12:55PM +0200, Fredrik Johansson wrote: >> > >> >The proposed resolution is to look at the URI to determine whether TLS >> >should be used to connect to the peer. >> > >> >One way to look at this is that section 2.2 states that all servers must >> >support TLS, so it would probably be safe to connect to the TLS port if >> >IPSec is not locally used. However, if a server was to connect >to a client, >> >TLS is not guaranteed. >> > >> >So, we have the following options: >> >1. rely on the URI >> >2. state that the TLS port is used if IPSec is not used >> >> TLS port?!? I guess you mean to use TLS on diameter default port TBD >> (or other configured port). > >draft-ietf-aaa-diameter-08.txt, section 2.1: > >" The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until IANA assigns a port to the protocol). > When used with TLS [38], The Diameter protocol is run on port TBD of > both TCP and SCTP." > >There are two ports allocated for the protocol, one where TLS is >used and the >other one. That's ok as long as you run over the default port, so I guess it has to be configurable on each node. Then I suggest adding a new result code saying DIAMETER_TLS_REQUIRED A connection request was received without using TLS, but the receiving peer is configured to run TLS. /Fredrik > >> How can the diameter application determine if IPsec is used? > >That's unfortunately an implementation detail. If the OS you are >on doesn't allow >you to view the local security policies, then you can always attempt TLS. > >PatC From owner-aaa-wg@merit.edu Tue Oct 2 07:45:19 2001 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 HAA05129 for ; Tue, 2 Oct 2001 07:45:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D79AA9127B; Tue, 2 Oct 2001 07:45:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A358D9127C; Tue, 2 Oct 2001 07:45: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 7CC669127B for ; Tue, 2 Oct 2001 07:45:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D4025DD92; Tue, 2 Oct 2001 07:45:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 46E965DD90 for ; Tue, 2 Oct 2001 07:45:40 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id NAA07131; Tue, 2 Oct 2001 13:44:45 +0200 From: "Fredrik Johansson" To: "Thomas Panagiotis-PTHOMAS1" , "'Pat Calhoun'" , Subject: RE: [AAA-WG]: Issue 186: Decouple authorization and key generation Date: Tue, 2 Oct 2001 13:45:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Works for me as long as it's stated that all keys distributed must have the same lifetime otherwise we may end up in a situation where the fa-ha key expires before the mn's keys and that will result in the fa-ha key not being updated. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Thomas Panagiotis-PTHOMAS1 >Sent: den 1 oktober 2001 18:03 >To: 'Pat Calhoun'; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Issue 186: Decouple authorization and key >generation > > >Pat, > >If the intent is to add the MIP-Key-Lifetime AVP in the >MIP-XX-to-XX-Key AVP definitions (Sections 6.1-6.6), then >our solutions coincide and you can close this issue. > >-Panos > >-----Original Message----- >From: Pat Calhoun [mailto:pcalhoun@diameter.org] >Sent: Monday, October 01, 2001 6:17 AM >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 186: Decouple authorization and key generation > > >All, > >The proposed solution removes the ability for mobility entities to be >notified of the key lifetime. How about we introduce a new avp: > >x.x.x MIP-Key-Lifetime AVP > >The MIP-Key-Lifetime AVP (AVP Code TBD) is of type Unsigned32 and >represents the period of time (in seconds) for which the session key >is valid. The session key MUST NOT be used if the lifetime has >expired; if the key lifetime expires while the session to which it >applies is still active, either the session key MUST be changed or >the or the session MUST be terminated. > >PatC From owner-aaa-wg@merit.edu Tue Oct 2 09:13:15 2001 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 JAA09417 for ; Tue, 2 Oct 2001 09:13:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3206E9127C; Tue, 2 Oct 2001 09:13:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05E0F9127D; Tue, 2 Oct 2001 09:13: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 BD1FB9127C for ; Tue, 2 Oct 2001 09:13:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B8F75DDC6; Tue, 2 Oct 2001 09:13:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 13D9D5DD90 for ; Tue, 2 Oct 2001 09:13:54 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id JAA07017 for ; Tue, 2 Oct 2001 09:06:38 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id JAA06370 for ; Tue, 2 Oct 2001 09:14:23 -0400 (EDT) From: "Mark Jones" To: "IETF AAA WG" Subject: [AAA-WG]: [issue] Clarifications on key generation (mobileip-08) Date: Tue, 2 Oct 2001 09:14:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit (Note: This issue relates to questions already answered on mailing list (see reference) and is raised in [issue] format to track the requested updates to the drafts.) Submitter name: Mark Jones Submitter email address: mjones@matrixmuse.com Date first submitted: 2001-10-02 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02204.html Document: mobileip-08, aaa-key-08 Comment type: 'E' Priority: '1' Section: 5.x, 6.0 of mobileip-08, 2 of aaa-key-08 Rationale/Explanation of issue: 1) The text in 5.x and 6.0 refers to the generation of Registration Keys. The KDC AVP descriptions (sections 6.1 onwards) refer only to session keys. These are one and the same so the naming should be consistent. 2) Section 5.3 entitled 'Distributing the Foreign-Home Registration Key' does not give any details on how the key is derived. 3) The aaa-key-08 draft does not explicitly state that key material must be distinct for each of the requested keys leaving the implementor the option of using the same key material for deriving Mobile-Home, Mobile-Foreign and Home-Foreign session key. Requested change: 1) In section 5.x and 6.0, replace the term Registration Key(s) with 'Session Key(s)' for consistency. 2) Add the following text to the end of the first paragraph in section 5.3: "The procedure for generation of key material and derivation of this session key is identical to that for the Mobile-Home and Mobile-Foreign session keys as specified in [15]." 3) In aaa-keys, modify the text in step 5 of section 2 (Scope of Protocol) to read: 5. At the time the information within the MN-AAA Authentication extension is verified by the AAA server, the AAA server also generates distinct Key Material for each of the keys requested by the mobile node, and causes insertion of the Key Material fields along with the Registration Reply. Regards, Mark From owner-aaa-wg@merit.edu Tue Oct 2 09:55:30 2001 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 JAA11712 for ; Tue, 2 Oct 2001 09:55:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E3EA91270; Tue, 2 Oct 2001 09:56:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C00E9127D; Tue, 2 Oct 2001 09:56: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 E9D7291270 for ; Tue, 2 Oct 2001 09:56:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBE3C5DDC6; Tue, 2 Oct 2001 09:56:10 -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 1FF605DDB4 for ; Tue, 2 Oct 2001 09:56:10 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA24183 for ; Tue, 2 Oct 2001 09:54:56 -0400 (EDT) Date: Tue, 2 Oct 2001 09:55:33 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA SPI generation for Unsolicited MN-FA Key Material Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I'm not certain if I have a fundamental understanding issue, or if there is some flaw in the key distribution algorithm. When the HA creates an Unsolicited MN-FA Key Material in the MIP-Reg-Reply, I can only determine how it knows 4 of the 5 fields. The fields are taken from draft-ietf-mobileip-aaa-key-08.txt Lifetime: MIP-Key-Lifetime AVP in MIP-MN-to-FA-Key AAA SPI: ? (see below) FA SPI: Mobile Node SPI in MN-FA Key Request Extension in MIP-Reg-Request Algorithm Identifier: MIP-Algorithm-Type in MIP-MN-FA-Key Key Material: MIP-Key-Material in MIP-MN-FA-Key I think that either the AAA SPI is not available, or I don't understand what it is. My understanding is that it specifies the security association between the MN and AAAH. It is chosen by the AAAH. When the AAAH creates the MIP-Session-Key in the MIP-FA-MN-Key in the AMR it uses the AAA-key that is specified by this AAA SPI. If this is true, the HA doesn't know what the AAA-SPI is. Elucidation would be appreciated. Thanks, -mark From owner-aaa-wg@merit.edu Tue Oct 2 11:07:41 2001 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 LAA15634 for ; Tue, 2 Oct 2001 11:07:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A913C91273; Tue, 2 Oct 2001 11:08:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 532FC91287; Tue, 2 Oct 2001 11:08: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 1B7B191273 for ; Tue, 2 Oct 2001 11:08:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE5B05DD90; Tue, 2 Oct 2001 11:08:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 2C7AC5DD8E for ; Tue, 2 Oct 2001 11:08:27 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA14319; Tue, 2 Oct 2001 17:07:33 +0200 From: "Fredrik Johansson" To: "Mark Eklund" , Subject: RE: [AAA-WG]: AAA SPI generation for Unsolicited MN-FA Key Material Date: Tue, 2 Oct 2001 17:08:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, I believe you're right, there is a SPI missing in the MIP-MN-to-FA-Key and in the MIP-MN-to-HA-Key, and that is the SPI that the Mn will use to retreive the mn-aaa key with which it will create the new mip key. I suggest we either reuse the existing SPI avp (MIP-Peer-SPI, btw why peer, strange name considering it's used for mip only and there is no peers in mip, can we change the name to MIP-SPI?) or add a new AVP. The former may cause problems when explaining for what purposes the SPI is used, so I'd prefer the latter. Aaa-SPI AVP The Aaa-SPI AVP (AVP Code TBD) is of type Unsigned32, and contains the Security Parameter Index to use to reference the key which the mobile node will use together with the key material when creating the MIP key. hope this clarifies things for you, I haven't had the time to go trough the key dist. in -08-alpha, but I'll try to do that asap to see if there are more information missing /Fredrik > >All, > >I'm not certain if I have a fundamental understanding issue, or >if there is some flaw in the key distribution algorithm. When >the HA creates an Unsolicited MN-FA Key Material in the >MIP-Reg-Reply, I can only determine how it knows 4 of the 5 >fields. The fields are taken from draft-ietf-mobileip-aaa-key-08.txt > >Lifetime: MIP-Key-Lifetime AVP in MIP-MN-to-FA-Key >AAA SPI: ? (see below) >FA SPI: Mobile Node SPI in MN-FA Key Request Extension in > MIP-Reg-Request >Algorithm Identifier: MIP-Algorithm-Type in MIP-MN-FA-Key >Key Material: MIP-Key-Material in MIP-MN-FA-Key > >I think that either the AAA SPI is not available, or I don't >understand what it is. My understanding is that it specifies the >security association between the MN and AAAH. It is chosen by the >AAAH. When the AAAH creates the MIP-Session-Key in the MIP-FA-MN-Key >in the AMR it uses the AAA-key that is specified by this AAA SPI. > >If this is true, the HA doesn't know what the AAA-SPI is. > >Elucidation would be appreciated. > >Thanks, > >-mark > > From owner-aaa-wg@merit.edu Tue Oct 2 11:15:17 2001 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 LAA15915 for ; Tue, 2 Oct 2001 11:15:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B29E991287; Tue, 2 Oct 2001 11:15:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C27391289; Tue, 2 Oct 2001 11:15:54 -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 4FAAF91287 for ; Tue, 2 Oct 2001 11:15:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B8FD5DD8E; Tue, 2 Oct 2001 11:15:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C5F205DD90 for ; Tue, 2 Oct 2001 11:15:52 -0400 (EDT) Received: (qmail 27435 invoked by uid 500); 2 Oct 2001 15:00:31 -0000 Date: Tue, 2 Oct 2001 08:00:30 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011002080030.L26914@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20011001071536.A19374@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Tue, Oct 02, 2001 at 09:17:07AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk great suggestion, but in light of the use one port for both statement from someone on the list, this may possibly not work. I need to check with IESG on the current trends. PatC On Tue, Oct 02, 2001 at 09:17:07AM +0200, Fredrik Johansson wrote: > > > >On Mon, Oct 01, 2001 at 03:12:55PM +0200, Fredrik Johansson wrote: > >> > > >> >The proposed resolution is to look at the URI to determine whether TLS > >> >should be used to connect to the peer. > >> > > >> >One way to look at this is that section 2.2 states that all servers must > >> >support TLS, so it would probably be safe to connect to the TLS port if > >> >IPSec is not locally used. However, if a server was to connect > >to a client, > >> >TLS is not guaranteed. > >> > > >> >So, we have the following options: > >> >1. rely on the URI > >> >2. state that the TLS port is used if IPSec is not used > >> > >> TLS port?!? I guess you mean to use TLS on diameter default port TBD > >> (or other configured port). > > > >draft-ietf-aaa-diameter-08.txt, section 2.1: > > > >" The base Diameter protocol is run on port TBD of both TCP [27] and > > SCTP [26] transport protocols (for interoperability test purposes > > port 1812 will be used until IANA assigns a port to the protocol). > > When used with TLS [38], The Diameter protocol is run on port TBD of > > both TCP and SCTP." > > > >There are two ports allocated for the protocol, one where TLS is > >used and the > >other one. > > That's ok as long as you run over the default port, so I guess it has to be > configurable on each node. Then I suggest adding a new result code saying > > DIAMETER_TLS_REQUIRED > A connection request was received without using TLS, but the receiving peer > is configured to run TLS. > > /Fredrik > > > >> How can the diameter application determine if IPsec is used? > > > >That's unfortunately an implementation detail. If the OS you are > >on doesn't allow > >you to view the local security policies, then you can always attempt TLS. > > > >PatC > From owner-aaa-wg@merit.edu Tue Oct 2 11:25:03 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16427 for ; Tue, 2 Oct 2001 11:25:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83B6191298; Tue, 2 Oct 2001 11:24:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 349069129B; Tue, 2 Oct 2001 11:24: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 5396691298 for ; Tue, 2 Oct 2001 11:24:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CE8F5DD90; Tue, 2 Oct 2001 11:24:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8844A5DD8E for ; Tue, 2 Oct 2001 11:24:09 -0400 (EDT) Received: (qmail 27544 invoked by uid 500); 2 Oct 2001 15:08:48 -0000 Date: Tue, 2 Oct 2001 08:08:48 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: MIP-Replay-Mode value assignement Message-ID: <20011002080847.N26914@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu References: <200110011935.MAA26287@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110011935.MAA26287@strtio1.cup.hp.com>; from jlau@cup.hp.com on Mon, Oct 01, 2001 at 12:35:12PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk the former, and I've just fixed the Diameter spec accordingly. PatC On Mon, Oct 01, 2001 at 12:35:12PM -0700, Joe Lau wrote: > Hi Pat, > > I found inconsistency between the two drafts on Replay-Mode value > assignments: > > : > > Replay Method Name > ------------- ----- > 1 None > 2 Timestamps > 3 Nonces > > : > > The 6.10 MIP-Replay-Mode AVP > > The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and > contains the replay mode the Home Agent should use when > authenticating the Mobile Node. > > The following values are supported (see [4] for more information): > > 0 None > 1 Timestamps > 2 Nonces > > Which one is correct? > > Regards, > > Joe From owner-aaa-wg@merit.edu Tue Oct 2 11:33:20 2001 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 LAA16792 for ; Tue, 2 Oct 2001 11:33:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3D8C91225; Tue, 2 Oct 2001 11:34:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BA839126D; Tue, 2 Oct 2001 11:34: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 6AD0B91225 for ; Tue, 2 Oct 2001 11:34:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A0DA5DD92; Tue, 2 Oct 2001 11:34:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 39D245DD8E for ; Tue, 2 Oct 2001 11:34:08 -0400 (EDT) Received: (qmail 27629 invoked by uid 500); 2 Oct 2001 15:18:46 -0000 Date: Tue, 2 Oct 2001 08:18:46 -0700 From: Pat Calhoun To: Glen Zorn Cc: Pat Calhoun , Simon Josefsson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Issue 191: How to know when to use TLS Message-ID: <20011002081846.R26914@charizard.diameter.org> Mail-Followup-To: Glen Zorn , Pat Calhoun , Simon Josefsson , aaa-wg@merit.edu References: <20011001082155.P19374@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gwz@cisco.com on Mon, Oct 01, 2001 at 08:54:49AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Oct 01, 2001 at 08:54:49AM -0700, Glen Zorn wrote: > Or we could just use CMS for both hop-by-hop and e2e security... Interesting idea. That did come up some time ago when the kerb folks were proposing their solution. Essentially, they were stating that there was no reason no require two different security schemes, and one would be sufficient. PatC From owner-aaa-wg@merit.edu Tue Oct 2 11:38:23 2001 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 LAA17035 for ; Tue, 2 Oct 2001 11:38:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F93191270; Tue, 2 Oct 2001 11:39:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D4E391273; Tue, 2 Oct 2001 11:39: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 E50CE91270 for ; Tue, 2 Oct 2001 11:39:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3A325DD95; Tue, 2 Oct 2001 11:39:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C17345DD90 for ; Tue, 2 Oct 2001 11:39:14 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA15564; Tue, 2 Oct 2001 17:38:34 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 191: How to know when to use TLS Date: Tue, 2 Oct 2001 17:39:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011002080030.L26914@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I saw the mail about one port to late :-) guess we'll have to wait to see what IESG has to say about it. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 2 oktober 2001 17:01 >To: Fredrik Johansson >Cc: Pat Calhoun; aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS > > >great suggestion, but in light of the use one port for both statement from >someone on the list, this may possibly not work. I need to check >with IESG on >the current trends. > >PatC >On Tue, Oct 02, 2001 at 09:17:07AM +0200, Fredrik Johansson wrote: >> > >> >On Mon, Oct 01, 2001 at 03:12:55PM +0200, Fredrik Johansson wrote: >> >> > >> >> >The proposed resolution is to look at the URI to determine >whether TLS >> >> >should be used to connect to the peer. >> >> > >> >> >One way to look at this is that section 2.2 states that all >servers must >> >> >support TLS, so it would probably be safe to connect to the >TLS port if >> >> >IPSec is not locally used. However, if a server was to connect >> >to a client, >> >> >TLS is not guaranteed. >> >> > >> >> >So, we have the following options: >> >> >1. rely on the URI >> >> >2. state that the TLS port is used if IPSec is not used >> >> >> >> TLS port?!? I guess you mean to use TLS on diameter default port TBD >> >> (or other configured port). >> > >> >draft-ietf-aaa-diameter-08.txt, section 2.1: >> > >> >" The base Diameter protocol is run on port TBD of both TCP [27] and >> > SCTP [26] transport protocols (for interoperability test purposes >> > port 1812 will be used until IANA assigns a port to the protocol). >> > When used with TLS [38], The Diameter protocol is run on port TBD of >> > both TCP and SCTP." >> > >> >There are two ports allocated for the protocol, one where TLS is >> >used and the >> >other one. >> >> That's ok as long as you run over the default port, so I guess >it has to be >> configurable on each node. Then I suggest adding a new result code saying >> >> DIAMETER_TLS_REQUIRED >> A connection request was received without using TLS, but the >receiving peer >> is configured to run TLS. >> >> /Fredrik >> > >> >> How can the diameter application determine if IPsec is used? >> > >> >That's unfortunately an implementation detail. If the OS you are >> >on doesn't allow >> >you to view the local security policies, then you can always >attempt TLS. >> > >> >PatC >> From owner-aaa-wg@merit.edu Tue Oct 2 11:50:26 2001 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 LAA17952 for ; Tue, 2 Oct 2001 11:50:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B57491225; Tue, 2 Oct 2001 11:51:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B42391273; Tue, 2 Oct 2001 11:51:18 -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 ECC1891225 for ; Tue, 2 Oct 2001 11:51:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACBAD5DD90; Tue, 2 Oct 2001 11:51:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id CB3DF5DD8E for ; Tue, 2 Oct 2001 11:51:15 -0400 (EDT) Received: from jariws1 ([62.248.238.237]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011002155011.YDUH11276.fep01-app.kolumbus.fi@jariws1>; Tue, 2 Oct 2001 18:50:11 +0300 Message-ID: <005901c14b59$f3bff260$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Glen Zorn" Cc: "Pat Calhoun" , "Simon Josefsson" , References: <20011001082155.P19374@charizard.diameter.org> <20011002081846.R26914@charizard.diameter.org> Subject: Re: [AAA-WG]: Re: Issue 191: How to know when to use TLS Date: Tue, 2 Oct 2001 18:50:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure I like the CMS-only approach. Seems like the only security scheme we'd be left with would be mandatorily based on public keys (e.g. ipsec from a NAS could be configured with manual keys and without IKE). Current devices are also likely to support Ipsec/Tls. Jari > On Mon, Oct 01, 2001 at 08:54:49AM -0700, Glen Zorn wrote: > > Or we could just use CMS for both hop-by-hop and e2e security... > > Interesting idea. That did come up some time ago when the kerb folks were > proposing their solution. Essentially, they were stating that there was no > reason no require two different security schemes, and one would be sufficient. From owner-aaa-wg@merit.edu Tue Oct 2 12:39:38 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19625 for ; Tue, 2 Oct 2001 12:39:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A659C91270; Tue, 2 Oct 2001 12:38:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5ECC891293; Tue, 2 Oct 2001 12:38:06 -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 701BE91270 for ; Tue, 2 Oct 2001 12:38:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C8A15DD9B; Tue, 2 Oct 2001 12:38:01 -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 E35C65DD95 for ; Tue, 2 Oct 2001 12:38:00 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-157.cisco.com [144.254.46.158]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA03845; Tue, 2 Oct 2001 09:36:08 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Jari Arkko" , "Pat Calhoun" Cc: "Pat Calhoun" , "Simon Josefsson" , Subject: RE: [AAA-WG]: Re: Issue 191: How to know when to use TLS Date: Tue, 2 Oct 2001 09:36:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <005901c14b59$f3bff260$8a1b6e0a@arenanet.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko [mailto:jari.arkko@kolumbus.fi] writes: > I'm not sure I like the CMS-only approach. Seems like the only security > scheme we'd be left with would be mandatorily based on public keys > (e.g. ipsec from a NAS could be configured with manual keys and > without IKE). Current devices are also likely to support Ipsec/Tls. Is there some inherent technical reason that CMS cannot work w/symmetric keys? > > Jari > > > On Mon, Oct 01, 2001 at 08:54:49AM -0700, Glen Zorn wrote: > > > Or we could just use CMS for both hop-by-hop and e2e security... > > > > Interesting idea. That did come up some time ago when the kerb > folks were > > proposing their solution. Essentially, they were stating that > there was no > > reason no require two different security schemes, and one would > be sufficient. > > > > From owner-aaa-wg@merit.edu Tue Oct 2 12:40:00 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19643 for ; Tue, 2 Oct 2001 12:39:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2845991293; Tue, 2 Oct 2001 12:39:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5CEE91299; Tue, 2 Oct 2001 12:39:32 -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 26D9D91293 for ; Tue, 2 Oct 2001 12:39:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBD095DD8E; Tue, 2 Oct 2001 12:39:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by segue.merit.edu (Postfix) with ESMTP id 70B085DD95 for ; Tue, 2 Oct 2001 12:39:27 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f92GcaP00233 for ; Tue, 2 Oct 2001 09:38:37 -0700 (PDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id MAA25333; Tue, 2 Oct 2001 12:38:50 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@knox6039 using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15289.60826.577774.279478@gargle.gargle.HOWL> Date: Tue, 2 Oct 2001 12:38:50 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: Section 8.1 X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I was looking at draft-ietf-aaa-diameter-mobileip-08-alpha01.txt, section 8.1 with respect to key distribution and needed enlightenment on two issues. 1. Why is a MIP-MN-to-HA-Key allowed in an AMA? This is already encapsulated in the MIP-Reg-Reply. Is there some reason the FA needs to know its value? 2. Why is a MIP-FA-to-HA-Key allowed in a HAR? The HA is already getting what it needs in the MIP-HA-to-FA-Key. In fact, the MIP-FA-to-HA-SPI is generated by the HA, so the MIP-Session-Key in the MIP-FA-to-HA-Key isn't even available when the HAR is created. Note: I'll create issues if this brings one up. Thanks, -mark From owner-aaa-wg@merit.edu Tue Oct 2 13:36:11 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB22506 for ; Tue, 2 Oct 2001 13:36:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3F829124A; Tue, 2 Oct 2001 13:36:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDB4F9127B; Tue, 2 Oct 2001 13:36:37 -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 AD6E09124A for ; Tue, 2 Oct 2001 13:36:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C3565DD95; Tue, 2 Oct 2001 13:36:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id 432DF5DD8E for ; Tue, 2 Oct 2001 13:36:36 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel11.hp.com (Postfix) with ESMTP id C35AA1F87C; Tue, 2 Oct 2001 10:35:28 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA28205; Tue, 2 Oct 2001 10:37:01 -0700 (PDT) Date: Tue, 2 Oct 2001 10:37:01 -0700 (PDT) From: Joe Lau Message-Id: <200110021737.KAA28205@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: [AAA-WG]: Authorization-Lifetime contradiction Cc: aaa-wg@merit.edu, jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I found contradictory statement about about the value of Authorization-Lifetime in the two following drafts: : A value of zero (0) means that immediate re-auth is necessary by the accesss device. ... The absence of this AVP, or a value of all ones means no re-auth is expected. : The Authorization-Lifetime AVP contains the number of seconds before registration keys destined for the Home Agent and/or Foreign Agent expire. A value of zero indicates infinity (no timeout). Which statement is correct? Regards, Joe From owner-aaa-wg@merit.edu Tue Oct 2 15:47:25 2001 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 PAA27029 for ; Tue, 2 Oct 2001 15:47:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0237D91290; Tue, 2 Oct 2001 15:48:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C47B391292; Tue, 2 Oct 2001 15:48: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 E297691290 for ; Tue, 2 Oct 2001 15:48:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A49C35DDC6; Tue, 2 Oct 2001 15:48:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by segue.merit.edu (Postfix) with ESMTP id 59F785DD9B for ; Tue, 2 Oct 2001 15:48:09 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f92JlIP15198 for ; Tue, 2 Oct 2001 12:47:18 -0700 (PDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA25666; Tue, 2 Oct 2001 15:47:32 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@knox6039 using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15290.6612.8463.125082@gargle.gargle.HOWL> Date: Tue, 2 Oct 2001 15:47:32 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: FA-HA Key Generation in the foreign domain X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I need to clarify what happens when the AAAF generates the FA-HA key when the HA is in the foreign domain. What this concerns is how the MIP-FA-to-HA-Key gets added to the AMA. When the AAAF gets an HAR with the FA-HA-Key-Request set in the MIP-Feature-Vector AVP, it generates the FA-HA Key. It then includes it in the MIP-HA-to-FA-Key that it sends to the HA. When it gets back the HAA, it remembers the MIP-FA-to-HA-SPI, its own generated key, and the Accounting-Multi-Session-Id AVP from the HA. It then forwards the HAA on to the AAAH. When the AAAH sends the AMA to the AAAF, the AAAF will have to add the MIP-FA-to-HA-Key AVP. It will do this by matching the Accounting-Multi-Session-Id in the AMA to the one saved when the HAA was received. The Accounting-Multi-Session-Id is the only thing that is common between the HAA and the AMA. Is this the only way the current specification will allow this? Is there any merit to changing the specification so that if a FA-HA-Key is generated in the foreign domain, the AAAF MUST add the FA-to-HA-Key to the HAR and the AAAH MUST move it from the HAR to the AMA? This would prevent the AAAF from having to keep a lookup table and do garbage collection on that table if the AMA is never received. If so, I'll raise the issue. -mark From owner-aaa-wg@merit.edu Wed Oct 3 03:18:59 2001 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 DAA01699 for ; Wed, 3 Oct 2001 03:18:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0434B912C3; Wed, 3 Oct 2001 03:19:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B98E8912C4; Wed, 3 Oct 2001 03:19:50 -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 76EE2912C3 for ; Wed, 3 Oct 2001 03:19:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34DFE5DDD2; Wed, 3 Oct 2001 03:19: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 EFADE5DDA1 for ; Wed, 3 Oct 2001 03:19:47 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f937J8f03475 for ; Wed, 3 Oct 2001 10:19:08 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Oct 2001 10:18:33 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 3 Oct 2001 10:18:34 +0300 Message-ID: From: henry.haverinen@nokia.com To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Wed, 3 Oct 2001 10:18:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello Glen, Issue 190 (session master keys): > > Perhaps the NASREQ document could simply say that the > > CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as > > a session master key from which the NAS derives the actual > > cipher keys (integrity keys). > From: ext Glen Zorn [mailto:gwz@cisco.com] > I think that that goes w/o out saying. I don't think this is obvious especially regarding the transport of a session master key from which IV's are derived. I'd still like to have a clarification that says this explicitly. Issue 188 (ciphersuite negotiation): > From: ext Glen Zorn [mailto:gwz@cisco.com] > I think that this is a red herring: it doesn't matter if the > ciphersuite is > negotiated _after_ authentication, because the Diameter > server is _telling_ > the NAS or AP which ciphersuite to choose. OK, I can see this can be done with ECP and possibly with other ciphersuite negotiations. But it still doesn't make sense to include the key binding AVP if the keying material will be used as session master keys. Can we just we make the key binding AVP optional? Then it could be included when ciphersuite negotiation inside EAP has been performed, or when the keying material is intented for a certain ciphersuite only, and omitted in other cases. > "Even if the ciphersuite hasn't been selected, the AAA server > can still transport keying material to the NAS in the > NAS-Session-Key AVP. For example, it can include large > session keys which the NAS can truncate as necessary for use > with a given ciphersuite." > > Isn't there more to it than just transporting & truncating > keying material, > though? For instance, DES, RC4 and other algorithms have > so-called "weak" > keys... I agree, weak keys can be a problem. It would be nice if the NAS and the client could handle them. If the AAA server transports enough keying material, maybe the NAS and the client can check for weak keys and skip them when encountered. Some people think that the chance of picking a weak DES key is negligible. If weak keys are so improbable, then maybe the NAS could even make the authentication fail if the transported key is weak. Issue 189 (initialization vectors): > From: ext Glen Zorn [mailto:gwz@cisco.com] > I contributed some text a couple of weeks ago (see below) > that I think deals > w/these concerns. > > NAS-Session-Key ::= < AVP Header: 408 > > { NAS-Key-Direction } > { NAS-Key-Type } > { NAS-Key-Binding } > { NAS-Key-Data } > [ NAS-Key-Lifetime ] > [ NAS-IV ] > * [ AVP ] > <...> > The NAS-IV AVP (AVP Code 410) is of type OctetString. Its contents > MAY be used as an initialization vector (IV) by cryptographic > algorithms > (e.g., block ciphers). I missed your contribution. It seems not to be included in the 08-alpha01 version of the NASREQ document either. The NAS-IV AVP looks good to me, as long as it works for the session master key case as well. Regards, Henry From owner-aaa-wg@merit.edu Wed Oct 3 05:53:48 2001 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 FAA05114 for ; Wed, 3 Oct 2001 05:53:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8046F912CC; Wed, 3 Oct 2001 05:54:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 438DB912CE; Wed, 3 Oct 2001 05:54: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 02ECA912CC for ; Wed, 3 Oct 2001 05:54:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A47525DDAD; Wed, 3 Oct 2001 05:54:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id B1CEC5DDA1 for ; Wed, 3 Oct 2001 05:54:39 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f939rTL24192 for ; Wed, 3 Oct 2001 11:53:29 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Oct 03 11:53:29 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 11:46:11 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: How to use Diameter Accounting Date: Wed, 3 Oct 2001 11:53:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Harri Hakala Submitter email address: Harri.Hakala@lmf.ericsson.se Date first submitted: 10.10.2001 Reference: Document: Base (draft-ietf-aaa-diameter-08-alpha01) Comment type: T/E Priority: 1 Section: 2.3 and 8 Rationale/Explanation of issue: According to the section 8.0 Diameter can provide two different type of services to applications. The first involves authentication and authorization, and can optionally make use of accounting. The second only makes use of accounting. There are certain applications, which needs only send the accounting information and do not need the support of authentication and authorization. The Accounting commands from the Diameter base protocol suits very well for this purpose. In section 2.3 Diameter Protocol Extensibility it is described the ways how the Diameter protocols can be extended. Section 2.3.2 defines that when no existing AVP can be used appropriately to communicate some service-specific information, a new AVP should be created. By using the accounting commands and service-specific AVPs would be the perfect solutions for the applications which only want to send the accounting information. But it is not possible to use the Accounting commands with service specific AVPs without creating a new application, because the accounting is not an application by itself (no Application identifier defined). This means that there is always need to create a new application before it is possible to use the Diameter accounting commands. Anyhow it is said in section 2.3.3 that the creation of a new application should be view as a last resort. In the same chapter it is also defined that the new Diameter application MUST define at least one Command Code. Does this mean that if a new application is created it still can use Commands from the base protocol without creating a new Commands ? Does this restrict the possibility to use Diameter protocol only for accounting purposes ? Requested change: Proposal Even if the Accounting is part of the Base protocol it should be possible to use only the accounting part of Diameter without creating each time a new application. Application Id for accounting used for capabilities exchange. Best regards.........Harri Hakala From owner-aaa-wg@merit.edu Wed Oct 3 06:06:45 2001 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 GAA05512 for ; Wed, 3 Oct 2001 06:06:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8228912CE; Wed, 3 Oct 2001 06:07:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 958EB912CF; Wed, 3 Oct 2001 06:07:30 -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 6F611912CE for ; Wed, 3 Oct 2001 06:07:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27DA85DDAD; Wed, 3 Oct 2001 06:07:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 33B375DDA1 for ; Wed, 3 Oct 2001 06:07:28 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f93A6LC22281 for ; Wed, 3 Oct 2001 12:06:21 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f93A6Kl23972; Wed, 3 Oct 2001 13:06:21 +0300 (EET DST) Message-ID: <3BBAE31D.88CF01C5@lmf.ericsson.se> Date: Wed, 03 Oct 2001 13:06:21 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Harri Hakala (LMF)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes. At present we allow the use of Diameter also only for accounting. But then the mandatory Application Id, and the rules governing the creation of new applications make some restrictions anyway. The end result is that folks who want to use accounting features in Diameter are forced to create new dummy applications, and if the application creation rules are followed, also invent dummy messages -- all for stating some new AVPs that should be sent. What can we do? Weaken the restrictions on adding new applications? Jari From owner-aaa-wg@merit.edu Wed Oct 3 06:26:10 2001 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 GAA05889 for ; Wed, 3 Oct 2001 06:26:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 559F2912CF; Wed, 3 Oct 2001 06:26:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25104912D0; Wed, 3 Oct 2001 06:26: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 D286E912CF for ; Wed, 3 Oct 2001 06:26:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85F145DDAD; Wed, 3 Oct 2001 06:26:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id A40BB5DDA1 for ; Wed, 3 Oct 2001 06:26:49 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA15229; Wed, 3 Oct 2001 12:25:08 +0200 From: "Fredrik Johansson" To: "Mark Eklund" , Subject: RE: [AAA-WG]: Section 8.1 Date: Wed, 3 Oct 2001 12:25:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15289.60826.577774.279478@gargle.gargle.HOWL> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >All, > >I was looking at draft-ietf-aaa-diameter-mobileip-08-alpha01.txt, >section 8.1 with respect to key distribution and needed enlightenment >on two issues. > >1. Why is a MIP-MN-to-HA-Key allowed in an AMA? > This is already encapsulated in the MIP-Reg-Reply. Is there some > reason the FA needs to know its value? > >2. Why is a MIP-FA-to-HA-Key allowed in a HAR? > The HA is already getting what it needs in the MIP-HA-to-FA-Key. > In fact, the MIP-FA-to-HA-SPI is generated by the HA, so the > MIP-Session-Key in the MIP-FA-to-HA-Key isn't even available when > the HAR is created. I believe that it's so the AAAh doesn't have to keep state, if the MIP-FA-to-HA-Key is in the HAR it must be returned in the HAA so it can be inserted into the AMA. But as you point out, the SPI is not available in the AAAh before it receives the HAA from the HA. Thus we either have to mandate the AAAh to keep the state, or make the SPI optional or set to a certain value (say 0) that will changed when the new value is available. /Fredrik > >Note: I'll create issues if this brings one up. > >Thanks, > >-mark From owner-aaa-wg@merit.edu Wed Oct 3 07:20:44 2001 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 HAA07670 for ; Wed, 3 Oct 2001 07:20:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49204912D2; Wed, 3 Oct 2001 07:21:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1889A912D3; Wed, 3 Oct 2001 07:21:37 -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 EA8C4912D2 for ; Wed, 3 Oct 2001 07:21:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BCD65DDAB; Wed, 3 Oct 2001 07:21:35 -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 E03245DDA1 for ; Wed, 3 Oct 2001 07:21:34 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f93BL2f19003 for ; Wed, 3 Oct 2001 14:21:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Oct 2001 14:20:28 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 3 Oct 2001 14:20:28 +0300 Message-ID: From: henry.haverinen@nokia.com To: gwz@cisco.com, aaa-wg@merit.edu Subject: [AAA-WG]: Do we need a NAS-Ciphersuite-Capabilities AVP? Date: Wed, 3 Oct 2001 14:20:15 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, This e-mail is related to issue #188 and the discussion at the following URLs: http://www.merit.edu/mail.archives/aaa-wg/msg02211.html http://www.merit.edu/mail.archives/aaa-wg/msg02237.html There is demand for enabling ciphersuite negotiation within EAP. The result of the negotiation (the selected ciphersuite) can already be transported to the NAS in the NAS-Key-Binding AVP. But there is no AVP to transport the NAS capabilities to the AAA server. If the EAP type is supposed to negotiate the ciphersuite, then I guess we need to specify a new AVP for NAS capabilities. For example, a NAS-Ciphersuite-Capabilities AVP could be included in the first Diameter-EAP-Request sent by the Diameter client. The AVP would list the ciphersuites supported by the NAS. Ideally, the same ciphersuite numbering space should be used in the AVP and in the NAS-Key-Binding AVP. Should I file an issue? Regards, Henry From owner-aaa-wg@merit.edu Wed Oct 3 09:12:47 2001 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 JAA12848 for ; Wed, 3 Oct 2001 09:12:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 62158912DA; Wed, 3 Oct 2001 09:13:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 358C2912D9; Wed, 3 Oct 2001 09:13:33 -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 860E4912DA for ; Wed, 3 Oct 2001 09:13:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 377A85DDB2; Wed, 3 Oct 2001 09:13:31 -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 DA7F65DDAF for ; Wed, 3 Oct 2001 09:13:30 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f93DBuC16546; Wed, 3 Oct 2001 09:11:59 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA25137; Wed, 3 Oct 2001 09:11:57 -0400 (EDT) Date: Wed, 03 Oct 2001 08:55:55 -0400 Message-ID: <87d7442884.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: henry.haverinen@nokia.com Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issues 188, 189 and 190 In-Reply-To: References: User-Agent: Wanderlust/2.7.4 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk I would prefer defining a new NAS-Key-Type value "MASTER_KEY" for representing a session master key and not including the NAS-Key-Binding AVP when the value of the NAS-Key-Type AVP is MASTER_KEY. It eliminates ambiguity and seems no harm. Yoshihiro Ohba At Wed, 3 Oct 2001 10:18:25 +0300 , Henry wrote: > > > Hello Glen, > > Issue 190 (session master keys): > > > > Perhaps the NASREQ document could simply say that the > > > CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as > > > a session master key from which the NAS derives the actual > > > cipher keys (integrity keys). > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > I think that that goes w/o out saying. > > I don't think this is obvious especially regarding the transport of > a session master key from which IV's are derived. I'd still like to > have a clarification that says this explicitly. > > Issue 188 (ciphersuite negotiation): > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > > I think that this is a red herring: it doesn't matter if the > > ciphersuite is > > negotiated _after_ authentication, because the Diameter > > server is _telling_ > > the NAS or AP which ciphersuite to choose. > > OK, I can see this can be done with ECP and possibly with > other ciphersuite negotiations. But it still doesn't make sense > to include the key binding AVP if the keying material will be used > as session master keys. > > Can we just we make the key binding AVP optional? Then it could > be included when ciphersuite negotiation inside EAP has been > performed, or when the keying material is intented for a certain > ciphersuite only, and omitted in other cases. > > > "Even if the ciphersuite hasn't been selected, the AAA server > > can still transport keying material to the NAS in the > > NAS-Session-Key AVP. For example, it can include large > > session keys which the NAS can truncate as necessary for use > > with a given ciphersuite." > > > > Isn't there more to it than just transporting & truncating > > keying material, > > though? For instance, DES, RC4 and other algorithms have > > so-called "weak" > > keys... > > I agree, weak keys can be a problem. It would be nice if the > NAS and the client could handle them. If the AAA server > transports enough keying material, maybe the NAS and the client > can check for weak keys and skip them when encountered. Some people > think that the chance of picking a weak DES key is negligible. > If weak keys are so improbable, then maybe the NAS could even make > the authentication fail if the transported key is weak. > > Issue 189 (initialization vectors): > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > I contributed some text a couple of weeks ago (see below) > > that I think deals > > w/these concerns. > > > > NAS-Session-Key ::= < AVP Header: 408 > > > { NAS-Key-Direction } > > { NAS-Key-Type } > > { NAS-Key-Binding } > > { NAS-Key-Data } > > [ NAS-Key-Lifetime ] > > [ NAS-IV ] > > * [ AVP ] > > <...> > > The NAS-IV AVP (AVP Code 410) is of type OctetString. Its contents > > MAY be used as an initialization vector (IV) by cryptographic > > algorithms > > (e.g., block ciphers). > > I missed your contribution. It seems not to be included in > the 08-alpha01 version of the NASREQ document either. > > The NAS-IV AVP looks good to me, as long as it works for the > session master key case as well. > > Regards, > Henry > From owner-aaa-wg@merit.edu Wed Oct 3 10:16:12 2001 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 KAA15916 for ; Wed, 3 Oct 2001 10:16:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB588912DC; Wed, 3 Oct 2001 10:16:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8D44912DD; Wed, 3 Oct 2001 10:16:54 -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 7865B912DC for ; Wed, 3 Oct 2001 10:16:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FA715DDD8; Wed, 3 Oct 2001 10:16:53 -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 2DCC95DDAD for ; Wed, 3 Oct 2001 10:16:52 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA26304; Wed, 3 Oct 2001 10:15:32 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA26683; Wed, 3 Oct 2001 10:16:10 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15291.7594.469885.446752@gargle.gargle.HOWL> Date: Wed, 3 Oct 2001 10:16:10 -0400 To: "Fredrik Johansson" Cc: "Mark Eklund" , Subject: RE: [AAA-WG]: Section 8.1 In-Reply-To: References: <15289.60826.577774.279478@gargle.gargle.HOWL> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik Johansson writes: > > > > >All, > > > >I was looking at draft-ietf-aaa-diameter-mobileip-08-alpha01.txt, > >section 8.1 with respect to key distribution and needed enlightenment > >on two issues. > > > >1. Why is a MIP-MN-to-HA-Key allowed in an AMA? > > This is already encapsulated in the MIP-Reg-Reply. Is there some > > reason the FA needs to know its value? > > > >2. Why is a MIP-FA-to-HA-Key allowed in a HAR? > > The HA is already getting what it needs in the MIP-HA-to-FA-Key. > > In fact, the MIP-FA-to-HA-SPI is generated by the HA, so the > > MIP-Session-Key in the MIP-FA-to-HA-Key isn't even available when > > the HAR is created. > > I believe that it's so the AAAh doesn't have to keep state, if the > MIP-FA-to-HA-Key is in the HAR it must be returned in the HAA so it can > be inserted into the AMA. > > But as you point out, the SPI is not available in the AAAh before it > receives the HAA from the HA. Thus we either have to mandate the AAAh > to keep the state, or make the SPI optional or set to a certain value > (say 0) that will changed when the new value is available. > The AAAH already has to maintain enough state to know which AMA to send back when it gets the HAA. According to section 8.1 the HAA can't contain a MIP-FA-to-HA-Key. I'll make an issue to not allow a MIP-MN-to-HA-Key in an AMA, a MIP-FA-to-HA Key in a HAR, and (a new one) not allow a MIP-FA-to-MN Key in a HAR. -mark > /Fredrik > > > > >Note: I'll create issues if this brings one up. > > > >Thanks, > > > >-mark From owner-aaa-wg@merit.edu Wed Oct 3 10:17:40 2001 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 KAA15956 for ; Wed, 3 Oct 2001 10:17:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD653912DD; Wed, 3 Oct 2001 10:18:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EE11912DE; Wed, 3 Oct 2001 10:18:39 -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 933F1912DD for ; Wed, 3 Oct 2001 10:18:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5710E5DDAF; Wed, 3 Oct 2001 10:18: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 9A0075DDAD for ; Wed, 3 Oct 2001 10:18:37 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f93EI4f00572 for ; Wed, 3 Oct 2001 17:18:04 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 3 Oct 2001 17:17:30 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 3 Oct 2001 17:17:30 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA27@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Abort-Session-Request and User-Name AVP Date: Wed, 3 Oct 2001 17:17:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, Currently, the Abort-Session-Request/Answer does not contain the User-Name AVP as a mandatory AVP. However, the Session-Termination-Request/Answer contains the User-Name AVP as a mandatory AVP. Is there any specific reason why these two command codes are defined differently with regards to the User-Name AVP? As these command codes are quite similar, it would be logical if the Abort-Session-Request/Answer also contains the User-Name AVP as a mandatory AVP and it would be useful to have the user name in the messages e.g. for trouble shooting. Best Regards, Jaakko From owner-aaa-wg@merit.edu Wed Oct 3 10:27:15 2001 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 KAA16227 for ; Wed, 3 Oct 2001 10:27:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E088912DE; Wed, 3 Oct 2001 10:28:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33935912DF; Wed, 3 Oct 2001 10:28: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 032FD912DE for ; Wed, 3 Oct 2001 10:27:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B27815DDB2; Wed, 3 Oct 2001 10:27:58 -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 676685DDAF for ; Wed, 3 Oct 2001 10:27:58 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-66.cisco.com [144.254.46.67]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA22780; Wed, 3 Oct 2001 07:26:15 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Yoshihiro Ohba" , Cc: Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Wed, 3 Oct 2001 07:26:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <87d7442884.wl@catfish.research.telcordia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > I would prefer defining a new NAS-Key-Type value "MASTER_KEY" for > representing a session master key and not including the > NAS-Key-Binding AVP when the value of the NAS-Key-Type AVP is > MASTER_KEY. It eliminates ambiguity and seems no harm. Maybe it's just old age, but I fail to discern the ambiguity in the terms "ENCRYPTION_KEY" and "INTEGRITY_KEY". "MASTER_KEY", OTOH seems quite ambiguous, meaning different things to different people at different times. > > Yoshihiro Ohba > > > > At Wed, 3 Oct 2001 10:18:25 +0300 , > Henry wrote: > > > > > > Hello Glen, > > > > Issue 190 (session master keys): > > > > > > Perhaps the NASREQ document could simply say that the > > > > CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as > > > > a session master key from which the NAS derives the actual > > > > cipher keys (integrity keys). > > > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > > I think that that goes w/o out saying. > > > > I don't think this is obvious especially regarding the transport of > > a session master key from which IV's are derived. I'd still like to > > have a clarification that says this explicitly. > > > > Issue 188 (ciphersuite negotiation): > > > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > > > > I think that this is a red herring: it doesn't matter if the > > > ciphersuite is > > > negotiated _after_ authentication, because the Diameter > > > server is _telling_ > > > the NAS or AP which ciphersuite to choose. > > > > OK, I can see this can be done with ECP and possibly with > > other ciphersuite negotiations. But it still doesn't make sense > > to include the key binding AVP if the keying material will be used > > as session master keys. > > > > Can we just we make the key binding AVP optional? Then it could > > be included when ciphersuite negotiation inside EAP has been > > performed, or when the keying material is intented for a certain > > ciphersuite only, and omitted in other cases. > > > > > "Even if the ciphersuite hasn't been selected, the AAA server > > > can still transport keying material to the NAS in the > > > NAS-Session-Key AVP. For example, it can include large > > > session keys which the NAS can truncate as necessary for use > > > with a given ciphersuite." > > > > > > Isn't there more to it than just transporting & truncating > > > keying material, > > > though? For instance, DES, RC4 and other algorithms have > > > so-called "weak" > > > keys... > > > > I agree, weak keys can be a problem. It would be nice if the > > NAS and the client could handle them. If the AAA server > > transports enough keying material, maybe the NAS and the client > > can check for weak keys and skip them when encountered. Some people > > think that the chance of picking a weak DES key is negligible. > > If weak keys are so improbable, then maybe the NAS could even make > > the authentication fail if the transported key is weak. > > > > Issue 189 (initialization vectors): > > > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > > I contributed some text a couple of weeks ago (see below) > > > that I think deals > > > w/these concerns. > > > > > > NAS-Session-Key ::= < AVP Header: 408 > > > > { NAS-Key-Direction } > > > { NAS-Key-Type } > > > { NAS-Key-Binding } > > > { NAS-Key-Data } > > > [ NAS-Key-Lifetime ] > > > [ NAS-IV ] > > > * [ AVP ] > > > <...> > > > The NAS-IV AVP (AVP Code 410) is of type OctetString. Its contents > > > MAY be used as an initialization vector (IV) by cryptographic > > > algorithms > > > (e.g., block ciphers). > > > > I missed your contribution. It seems not to be included in > > the 08-alpha01 version of the NASREQ document either. > > > > The NAS-IV AVP looks good to me, as long as it works for the > > session master key case as well. > > > > Regards, > > Henry > > > From owner-aaa-wg@merit.edu Wed Oct 3 11:20:34 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18183 for ; Wed, 3 Oct 2001 11:20:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AFEC4912E3; Wed, 3 Oct 2001 11:21:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6ADBD912E6; Wed, 3 Oct 2001 11:21: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 341A8912E3 for ; Wed, 3 Oct 2001 11:21:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DCB595DDB2; Wed, 3 Oct 2001 11:21:02 -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 E3F525DD94 for ; Wed, 3 Oct 2001 11:21:01 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA27510; Wed, 3 Oct 2001 11:19:42 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id LAA26742; Wed, 3 Oct 2001 11:20:19 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15291.11443.607373.19844@gargle.gargle.HOWL> Date: Wed, 3 Oct 2001 11:20:19 -0400 To: Johan Johansson Cc: meklund@cisco.com, aaa-wg@merit.edu Subject: Re: [Fwd: FW: [AAA-WG]: Section 8.1] In-Reply-To: <3BBB2B49.47571262@ipunplugged.com> References: <3BBB2B49.47571262@ipunplugged.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson writes: > Fredrik Johansson wrote: > > > > >I was looking at draft-ietf-aaa-diameter-mobileip-08-alpha01.txt, > > > >section 8.1 with respect to key distribution and needed enlightenment > > > >on two issues. > > > > > > > >1. Why is a MIP-MN-to-HA-Key allowed in an AMA? > > > > This is already encapsulated in the MIP-Reg-Reply. Is there some > > > > reason the FA needs to know its value? > > No, but if the mobile node is in co-located mode the HA will receive the > AMA. In this case the AMA interestingly enough plays the role of an HAR. > I forgot about the co-located possibility. Thanks. -mark > j From owner-aaa-wg@merit.edu Wed Oct 3 11:51:16 2001 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 LAA19119 for ; Wed, 3 Oct 2001 11:51:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A66B9137E; Wed, 3 Oct 2001 11:49:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A226C913AB; Wed, 3 Oct 2001 11:42:54 -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 955329139C for ; Wed, 3 Oct 2001 11:40:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5432F5DDB5; Wed, 3 Oct 2001 11:40:07 -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 070125DDB4 for ; Wed, 3 Oct 2001 11:40:07 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-66.cisco.com [144.254.46.67]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA06587; Wed, 3 Oct 2001 08:38:27 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 186: Decouple authorization and key generation Date: Wed, 3 Oct 2001 08:38:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011001041633.A18522@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:/pcalhoun@diameter.org] writes: > All, > > The proposed solution removes the ability for mobility entities to be > notified of the key lifetime. How about we introduce a new avp: > > x.x.x MIP-Key-Lifetime AVP > > The MIP-Key-Lifetime AVP (AVP Code TBD) is of type Unsigned32 and > represents the period of time (in seconds) for which the session key > is valid. The session key MUST NOT be used if the lifetime has > expired; if the key lifetime expires while the session to which it > applies is still active, either the session key MUST be changed or > the or the session MUST be terminated. I'm thinking that there seems to be a great deal of similarity between MIP & NASREQ here. Would it be worthwhile to define a basic Key-Material AVP in the base that both apps can use? > > PatC > From owner-aaa-wg@merit.edu Wed Oct 3 11:54:57 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19275 for ; Wed, 3 Oct 2001 11:54:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66869913D4; Wed, 3 Oct 2001 11:49:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07D2C913A4; Wed, 3 Oct 2001 11:49: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 C2D64913BE for ; Wed, 3 Oct 2001 11:44:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 861095DDD5; Wed, 3 Oct 2001 11:44: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 B4A0E5DDB4 for ; Wed, 3 Oct 2001 11:44:55 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA41044; Wed, 3 Oct 2001 08:35:08 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 3 Oct 2001 08:35:08 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting In-Reply-To: <3BBAE31D.88CF01C5@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yes. At present we allow the use of Diameter also only > for accounting. But then the mandatory Application > Id, and the rules governing the creation of new > applications make some restrictions anyway. > The end result is that folks who want to use > accounting features in Diameter are forced to > create new dummy applications, and if the application > creation rules are followed, also invent dummy > messages -- all for stating some new AVPs that > should be sent. I would suggest that Diameter accounting should be usable as a general service without requiring creation of dummy appliations. All that should be required is new AVPs. > > What can we do? Weaken the restrictions on adding > new applications? > How about assigning accounting its own application ID? From owner-aaa-wg@merit.edu Wed Oct 3 12:08:19 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19897 for ; Wed, 3 Oct 2001 12:08:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 81EAD91449; Wed, 3 Oct 2001 12:07:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25D499143F; Wed, 3 Oct 2001 12: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 2469A91440 for ; Wed, 3 Oct 2001 12:06:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D24A65DDAF; Wed, 3 Oct 2001 12:06:20 -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 7C3E45DD94 for ; Wed, 3 Oct 2001 12:06:20 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-66.cisco.com [144.254.46.67]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA17729; Wed, 3 Oct 2001 09:05:09 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Cc: Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Wed, 3 Oct 2001 09:05:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com [mailto:henry.haverinen@nokia.com] writes: > Hello Glen, > > Issue 190 (session master keys): > > > > Perhaps the NASREQ document could simply say that the > > > CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as > > > a session master key from which the NAS derives the actual > > > cipher keys (integrity keys). > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > I think that that goes w/o out saying. > > I don't think this is obvious especially regarding the transport of > a session master key from which IV's are derived. I'd still like to > have a clarification that says this explicitly. I'm unfamiliar w/the practice of deriving IVs from secret material. Since IVs are often transmitted in the clear, could this not release information about the master key itself? From owner-aaa-wg@merit.edu Wed Oct 3 12:29:51 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20572 for ; Wed, 3 Oct 2001 12:29:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CF2D912E5; Wed, 3 Oct 2001 12:27:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2821D912EA; Wed, 3 Oct 2001 12:27: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 E60F9912E5 for ; Wed, 3 Oct 2001 12:27:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BED45DDB5; Wed, 3 Oct 2001 12:27:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 43DF75DDAF for ; Wed, 3 Oct 2001 12:27:42 -0400 (EDT) Received: (qmail 32214 invoked by uid 500); 3 Oct 2001 16:12:13 -0000 Date: Wed, 3 Oct 2001 09:12:13 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Section 8.1 Message-ID: <20011003091213.E32101@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Mark Eklund , aaa-wg@merit.edu References: <15289.60826.577774.279478@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Wed, Oct 03, 2001 at 12:25:38PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 03, 2001 at 12:25:38PM +0200, Fredrik Johansson wrote: > > > > >All, > > > >I was looking at draft-ietf-aaa-diameter-mobileip-08-alpha01.txt, > >section 8.1 with respect to key distribution and needed enlightenment > >on two issues. > > > >1. Why is a MIP-MN-to-HA-Key allowed in an AMA? > > This is already encapsulated in the MIP-Reg-Reply. Is there some > > reason the FA needs to know its value? > > > >2. Why is a MIP-FA-to-HA-Key allowed in a HAR? > > The HA is already getting what it needs in the MIP-HA-to-FA-Key. > > In fact, the MIP-FA-to-HA-SPI is generated by the HA, so the > > MIP-Session-Key in the MIP-FA-to-HA-Key isn't even available when > > the HAR is created. > > I believe that it's so the AAAh doesn't have to keep state, if the > MIP-FA-to-HA-Key is in the HAR it must be returned in the HAA so it can > be inserted into the AMA. > > But as you point out, the SPI is not available in the AAAh before it > receives the HAA from the HA. Thus we either have to mandate the AAAh > to keep the state, or make the SPI optional or set to a certain value > (say 0) that will changed when the new value is available. The general idea was that the HA modify the SPI value in the MIP-FA-to-HA-Key, and return the updated AVP in the HAA. That is my understand of the agreement we had previously had in regards to the issue on whom creates the SPI. PatC From owner-aaa-wg@merit.edu Wed Oct 3 12:38:10 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21002 for ; Wed, 3 Oct 2001 12:38:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2302A912FE; Wed, 3 Oct 2001 12:36:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4B9A9135B; Wed, 3 Oct 2001 12:36: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 B27DE912FE for ; Wed, 3 Oct 2001 12:33:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FB385DDD8; Wed, 3 Oct 2001 12:33:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DC15E5DD94 for ; Wed, 3 Oct 2001 12:33:21 -0400 (EDT) Received: (qmail 32228 invoked by uid 500); 3 Oct 2001 16:17:53 -0000 Date: Wed, 3 Oct 2001 09:17:53 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Authorization-Lifetime contradiction Message-ID: <20011003091753.F32101@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu References: <200110021737.KAA28205@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110021737.KAA28205@strtio1.cup.hp.com>; from jlau@cup.hp.com on Tue, Oct 02, 2001 at 10:37:01AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is being currently being addressed by adding a new AVP that specifies the key lifetime. By no longer binding the key's lifetime to the authorization lifetime, this issue goes away. Thanks, PatC On Tue, Oct 02, 2001 at 10:37:01AM -0700, Joe Lau wrote: > Hi Pat, > > I found contradictory statement about about the value of > Authorization-Lifetime in the two following drafts: > > : > > A value of zero (0) means that immediate re-auth is necessary by the > accesss device. ... The absence of this AVP, or a value of all ones > means no re-auth is expected. > > > : > > The Authorization-Lifetime AVP contains the number of seconds before > registration keys destined for the Home Agent and/or Foreign Agent > expire. A value of zero indicates infinity (no timeout). > > Which statement is correct? > > Regards, > > Joe From owner-aaa-wg@merit.edu Wed Oct 3 12:45:27 2001 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 MAA21385 for ; Wed, 3 Oct 2001 12:45:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBC78912EA; Wed, 3 Oct 2001 12:45:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD43B912ED; Wed, 3 Oct 2001 12:45:41 -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 A1669912EA for ; Wed, 3 Oct 2001 12:45:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D9D35DDD6; Wed, 3 Oct 2001 12:45:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 03ABE5DDD5 for ; Wed, 3 Oct 2001 12:45:40 -0400 (EDT) Received: (qmail 32553 invoked by uid 500); 3 Oct 2001 16:30:11 -0000 Date: Wed, 3 Oct 2001 09:30:11 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011003093010.I32101@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" References: <3BBAE31D.88CF01C5@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Wed, Oct 03, 2001 at 08:35:08AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 03, 2001 at 08:35:08AM -0700, Bernard Aboba wrote: > > Yes. At present we allow the use of Diameter also only > > for accounting. But then the mandatory Application > > Id, and the rules governing the creation of new > > applications make some restrictions anyway. > > The end result is that folks who want to use > > accounting features in Diameter are forced to > > create new dummy applications, and if the application > > creation rules are followed, also invent dummy > > messages -- all for stating some new AVPs that > > should be sent. > > I would suggest that Diameter accounting should be usable as a general > service without requiring creation of dummy appliations. All that should > be required is new AVPs. right because the folks wanting to use Accounting for another purpose really need to define the contents of the accounting messages. Actually, section 9.3 of the base spec details this. how else can folks get interoperability? > > What can we do? Weaken the restrictions on adding > > new applications? > > > How about assigning accounting its own application ID? This is the way it used to work.... then Glen argued to bundle it into the base spec, and remove the separate appl-id, and we created the acct-appl-id. Is reversing on a WG decision we made over 8 months ago really the right thing to do here? PatC From owner-aaa-wg@merit.edu Wed Oct 3 12:46:23 2001 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 MAA21468 for ; Wed, 3 Oct 2001 12:46:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DFB6912E9; Wed, 3 Oct 2001 12:47:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C565D912EC; Wed, 3 Oct 2001 12:47: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 9D217912E9 for ; Wed, 3 Oct 2001 12:47:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D1295DDD5; Wed, 3 Oct 2001 12:47:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B935F5DDAD for ; Wed, 3 Oct 2001 12:47:18 -0400 (EDT) Received: (qmail 32575 invoked by uid 500); 3 Oct 2001 16:31:50 -0000 Date: Wed, 3 Oct 2001 09:31:50 -0700 From: Pat Calhoun To: "Harri Hakala (LMF)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011003093150.J32101@charizard.diameter.org> Mail-Followup-To: "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102>; from Harri.Hakala@lmf.ericsson.se on Wed, Oct 03, 2001 at 11:53:16AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Perhaps the more appropriate fix is to state that new applications do not have to include a command code if they are used for accounting only. The goal was to eliminate the possibility of folks submitting hundreds of applications containing simple AVPs to extend an existing command. PatC On Wed, Oct 03, 2001 at 11:53:16AM +0200, Harri Hakala (LMF) wrote: > Submitter name: Harri Hakala > Submitter email address: Harri.Hakala@lmf.ericsson.se > Date first submitted: 10.10.2001 > Reference: > Document: Base (draft-ietf-aaa-diameter-08-alpha01) > Comment type: T/E > Priority: 1 > Section: 2.3 and 8 > Rationale/Explanation of issue: > > According to the section 8.0 Diameter can provide two different type of services to applications. > The first involves authentication and authorization, and can optionally make use of accounting. > The second only makes use of accounting. > > There are certain applications, which needs only send the accounting information and > do not need the support of authentication and authorization. > > The Accounting commands from the Diameter base protocol suits very well for this purpose. > > In section 2.3 Diameter Protocol Extensibility it is described the ways how > the Diameter protocols can be extended. > Section 2.3.2 defines that when no existing AVP can be used appropriately to communicate some > service-specific information, a new AVP should be created. > By using the accounting commands and service-specific AVPs would be the perfect solutions > for the applications which only want to send the accounting information. > > But it is not possible to use the Accounting commands with service specific AVPs without > creating a new application, because the accounting is not an application by itself > (no Application identifier defined). > > This means that there is always need to create a new application before it is possible to use > the Diameter accounting commands. > Anyhow it is said in section 2.3.3 that the creation of a new application should be view as a > last resort. > In the same chapter it is also defined that the new Diameter application MUST define at least one > Command Code. > Does this mean that if a new application is created it still can use Commands from the base protocol without > creating a new Commands ? > > Does this restrict the possibility to use Diameter protocol only for accounting purposes ? > > Requested change: > Proposal > > Even if the Accounting is part of the Base protocol it should be possible to use only the accounting part of > Diameter without creating each time a new application. > > Application Id for accounting used for capabilities exchange. > > Best regards.........Harri Hakala > > > From owner-aaa-wg@merit.edu Wed Oct 3 12:49:08 2001 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 MAA21606 for ; Wed, 3 Oct 2001 12:49:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5AC5912EC; Wed, 3 Oct 2001 12:49:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 711F9912ED; Wed, 3 Oct 2001 12:49: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 5D20E912EC for ; Wed, 3 Oct 2001 12:49:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E2BC5DDAD; Wed, 3 Oct 2001 12:49:51 -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 5B5185DDA2 for ; Wed, 3 Oct 2001 12:49:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA41174; Wed, 3 Oct 2001 09:40:01 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 3 Oct 2001 09:40:01 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting In-Reply-To: <20011003093010.I32101@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > right because the folks wanting to use Accounting for another purpose really > need to define the contents of the accounting messages. Actually, section 9.3 > of the base spec details this. > > how else can folks get interoperability? So how do we accomplish this? From owner-aaa-wg@merit.edu Wed Oct 3 12:51:49 2001 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 MAA21765 for ; Wed, 3 Oct 2001 12:51:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54CAA912ED; Wed, 3 Oct 2001 12:52:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24469912EE; Wed, 3 Oct 2001 12:52:33 -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 1A721912ED for ; Wed, 3 Oct 2001 12:52:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D17A45DDAD; Wed, 3 Oct 2001 12:52:21 -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 51A085DDA2 for ; Wed, 3 Oct 2001 12:52:21 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-66.cisco.com [144.254.46.67]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA05237; Wed, 3 Oct 2001 09:50:55 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Harri Hakala (LMF)" , Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Wed, 3 Oct 2001 09:50:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] writes: ... > According to the section 8.0 Diameter can provide two different > type of services to applications. > The first involves authentication and authorization, and can > optionally make use of accounting. > The second only makes use of accounting. > > There are certain applications, which needs only send the > accounting information and > do not need the support of authentication and authorization. > > The Accounting commands from the Diameter base protocol suits > very well for this purpose. > > In section 2.3 Diameter Protocol Extensibility it is described > the ways how > the Diameter protocols can be extended. > Section 2.3.2 defines that when no existing AVP can be used > appropriately to communicate some > service-specific information, a new AVP should be created. > By using the accounting commands and service-specific AVPs would > be the perfect solutions > for the applications which only want to send the accounting information. > > But it is not possible to use the Accounting commands with > service specific AVPs without > creating a new application, because the accounting is not an > application by itself > (no Application identifier defined). I'm confused: first you say that "There are certain applications, which needs only send the accounting information and do not need the support of authentication and authorization." but then youcomplain about having to create a new Diameter application identifying the application. I don't understand. > > This means that there is always need to create a new application > before it is possible to use > the Diameter accounting commands. > Anyhow it is said in section 2.3.3 that the creation of a new > application should be view as a > last resort. > In the same chapter it is also defined that the new Diameter > application MUST define at least one > Command Code. > Does this mean that if a new application is created it still can > use Commands from the base protocol without > creating a new Commands ? > > Does this restrict the possibility to use Diameter protocol only > for accounting purposes ? > > Requested change: > Proposal > > Even if the Accounting is part of the Base protocol it should be > possible to use only the accounting part of > Diameter without creating each time a new application. > > Application Id for accounting used for capabilities exchange. > > Best regards.........Harri Hakala > > > > From owner-aaa-wg@merit.edu Wed Oct 3 12:52:39 2001 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 MAA21805 for ; Wed, 3 Oct 2001 12:52:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D4CB5912EE; Wed, 3 Oct 2001 12:53:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A027D912EF; Wed, 3 Oct 2001 12:53: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 618D1912EE for ; Wed, 3 Oct 2001 12:53:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B0BE5DDAD; Wed, 3 Oct 2001 12:53:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 87CF95DDA2 for ; Wed, 3 Oct 2001 12:53:11 -0400 (EDT) Received: (qmail 32646 invoked by uid 500); 3 Oct 2001 16:37:28 -0000 Date: Wed, 3 Oct 2001 09:37:28 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011003093728.K32101@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" References: <20011003093010.I32101@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Wed, Oct 03, 2001 at 09:40:01AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 03, 2001 at 09:40:01AM -0700, Bernard Aboba wrote: > > right because the folks wanting to use Accounting for another purpose really > > need to define the contents of the accounting messages. Actually, section 9.3 > > of the base spec details this. > > > > how else can folks get interoperability? > > So how do we accomplish this? By following my recommendation (in the other e-mail to this thread). Allow for folks to create accounting related applications that do not define new command codes, but only AVPs. That would require a change to section 2.3 PatC From owner-aaa-wg@merit.edu Wed Oct 3 12:53:31 2001 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 MAA21895 for ; Wed, 3 Oct 2001 12:53:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2FEB0912F0; Wed, 3 Oct 2001 12:54:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3170912F2; Wed, 3 Oct 2001 12:54: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 EDC7C912F0 for ; Wed, 3 Oct 2001 12:54:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5C195DDD8; Wed, 3 Oct 2001 12:54:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 18E6E5DDA2 for ; Wed, 3 Oct 2001 12:54:14 -0400 (EDT) Received: (qmail 32670 invoked by uid 500); 3 Oct 2001 16:38:45 -0000 Date: Wed, 3 Oct 2001 09:38:45 -0700 From: Pat Calhoun To: Glen Zorn Cc: "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011003093845.L32101@charizard.diameter.org> Mail-Followup-To: Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gwz@cisco.com on Wed, Oct 03, 2001 at 09:50:54AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > But it is not possible to use the Accounting commands with > > service specific AVPs without > > creating a new application, because the accounting is not an > > application by itself > > (no Application identifier defined). > > I'm confused: first you say that "There are certain applications, which > needs only send the > accounting information and do not need the support of authentication and > authorization." but then youcomplain about having to create a new Diameter > application identifying the application. I don't understand. Actually, that's an interesting point. It is possible to just create a Diameter spec that defines new AVPs to be included in the Accounting messages, and then you are done. sometimes the solution is so simple it's hard to see. Thanks Glen! PatC From owner-aaa-wg@merit.edu Wed Oct 3 12:53:33 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21905 for ; Wed, 3 Oct 2001 12:53:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E01F912EF; Wed, 3 Oct 2001 12:54:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB87E912F0; Wed, 3 Oct 2001 12:54: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 D98A7912EF for ; Wed, 3 Oct 2001 12:54:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96BC65DDD6; Wed, 3 Oct 2001 12:54: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 C5F245DDD5 for ; Wed, 3 Oct 2001 12:54:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA41195; Wed, 3 Oct 2001 09:44:17 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 3 Oct 2001 09:44:17 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting In-Reply-To: <20011003093150.J32101@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Perhaps the more appropriate fix is to state that new applications do not have > to include a command code if they are used for accounting only. > That makes sense to me. After all, the Accounting Server typically only writes the AVPs to disk anyway. So it need not necessarily understand the semantics of the AVPs. > The goal was to eliminate the possibility of folks submitting hundreds of > applications containing simple AVPs to extend an existing command. > > PatC > All that should be needed is to define the AVPs. No new command code should be required. > > By using the accounting commands and service-specific AVPs would be the perfect solutions > > for the applications which only want to send the accounting information. > > Yes, this is very important. > > But it is not possible to use the Accounting commands with service specific AVPs without > > creating a new application, because the accounting is not an application by itself > > (no Application identifier defined). From owner-aaa-wg@merit.edu Wed Oct 3 12:54:49 2001 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 MAA21984 for ; Wed, 3 Oct 2001 12:54:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D232D912F1; Wed, 3 Oct 2001 12:55:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B8F9912F2; Wed, 3 Oct 2001 12:55:39 -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 89A08912F1 for ; Wed, 3 Oct 2001 12:55:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47D025DDAD; Wed, 3 Oct 2001 12:55:38 -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 BB0815DDA2 for ; Wed, 3 Oct 2001 12:55:37 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-66.cisco.com [144.254.46.67]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA10323; Wed, 3 Oct 2001 09:53:53 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Jari Arkko" Cc: "Harri Hakala (LMF)" , Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Wed, 3 Oct 2001 09:53:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > Yes. At present we allow the use of Diameter also only > > for accounting. But then the mandatory Application > > Id, and the rules governing the creation of new > > applications make some restrictions anyway. > > The end result is that folks who want to use > > accounting features in Diameter are forced to > > create new dummy applications, and if the application > > creation rules are followed, also invent dummy > > messages -- all for stating some new AVPs that > > should be sent. I agree that this is silly. As I recall, though, the restrictions are intentional and arise from a fear of extensible protocols. Of course, hamstringing Diameter extensibility virtually guarantees that we (or some other set of folks) will go through this same exercise again in a few years... > > I would suggest that Diameter accounting should be usable as a general > service without requiring creation of dummy appliations. All that should > be required is new AVPs. > > > > > What can we do? Weaken the restrictions on adding > > new applications? Good idea. In fact, I would be in favor of removing all arbitrary restrictions (other than IANA registration and documentation) on the creation of new applications. > > > How about assigning accounting its own application ID? > > From owner-aaa-wg@merit.edu Wed Oct 3 12:56:21 2001 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 MAA22104 for ; Wed, 3 Oct 2001 12:56:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 81C24912F3; Wed, 3 Oct 2001 12:57:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B63B912F2; Wed, 3 Oct 2001 12:57: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 18BD8912F4 for ; Wed, 3 Oct 2001 12:57:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C73C05DDD5; Wed, 3 Oct 2001 12:57:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 69C185DDA2 for ; Wed, 3 Oct 2001 12:57:10 -0400 (EDT) Received: (qmail 32696 invoked by uid 500); 3 Oct 2001 16:41:42 -0000 Date: Wed, 3 Oct 2001 09:41:42 -0700 From: Pat Calhoun To: Glen Zorn Cc: Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011003094141.M32101@charizard.diameter.org> Mail-Followup-To: Glen Zorn , Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gwz@cisco.com on Wed, Oct 03, 2001 at 09:53:52AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 03, 2001 at 09:53:52AM -0700, Glen Zorn wrote: > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > > Yes. At present we allow the use of Diameter also only > > > for accounting. But then the mandatory Application > > > Id, and the rules governing the creation of new > > > applications make some restrictions anyway. > > > The end result is that folks who want to use > > > accounting features in Diameter are forced to > > > create new dummy applications, and if the application > > > creation rules are followed, also invent dummy > > > messages -- all for stating some new AVPs that > > > should be sent. > > I agree that this is silly. As I recall, though, the restrictions are > intentional and arise from a fear of extensible protocols. Of course, > hamstringing Diameter extensibility virtually guarantees that we (or some > other set of folks) will go through this same exercise again in a few > years... > > > > > I would suggest that Diameter accounting should be usable as a general > > service without requiring creation of dummy appliations. All that should > > be required is new AVPs. > > > > > > > > What can we do? Weaken the restrictions on adding > > > new applications? > > Good idea. In fact, I would be in favor of removing all arbitrary > restrictions (other than IANA registration and documentation) on the > creation of new applications. > What would IESG folks say about this one? PatC From owner-aaa-wg@merit.edu Wed Oct 3 12:56:59 2001 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 MAA22178 for ; Wed, 3 Oct 2001 12:56:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4F18912F2; Wed, 3 Oct 2001 12:57:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B475F912F4; Wed, 3 Oct 2001 12:57: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 8E28C912F2 for ; Wed, 3 Oct 2001 12:57:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48C965DDA2; Wed, 3 Oct 2001 12:57:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B0EAC5DDAD for ; Wed, 3 Oct 2001 12:57:46 -0400 (EDT) Received: (qmail 32713 invoked by uid 500); 3 Oct 2001 16:42:18 -0000 Date: Wed, 3 Oct 2001 09:42:18 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP Message-ID: <20011003094218.N32101@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA27@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA27@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Wed, Oct 03, 2001 at 05:17:25PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Not sure why this is the case. PatC On Wed, Oct 03, 2001 at 05:17:25PM +0300, jaakko.rajaniemi@nokia.com wrote: > Hello, > > Currently, the Abort-Session-Request/Answer does not contain the User-Name > AVP as a mandatory AVP. However, the Session-Termination-Request/Answer > contains the User-Name AVP as a mandatory AVP. Is there any specific reason > why these two command codes are defined differently with regards to the > User-Name AVP? As these command codes are quite similar, it would be logical > if the Abort-Session-Request/Answer also contains the User-Name AVP as a > mandatory AVP and it would be useful to have the user name in the messages > e.g. for trouble shooting. > > Best Regards, Jaakko From owner-aaa-wg@merit.edu Wed Oct 3 12:58:16 2001 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 MAA22265 for ; Wed, 3 Oct 2001 12:58:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 835F3912F4; Wed, 3 Oct 2001 12:59:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5901E912F5; Wed, 3 Oct 2001 12:59: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 42F39912F4 for ; Wed, 3 Oct 2001 12:59:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F29805DDAD; Wed, 3 Oct 2001 12:59:05 -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 384A05DDA2 for ; Wed, 3 Oct 2001 12:59:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA41235; Wed, 3 Oct 2001 09:49:12 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 3 Oct 2001 09:49:12 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting In-Reply-To: <20011003093845.L32101@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Actually, that's an interesting point. It is possible to just create a > Diameter spec that defines new AVPs to be included in the Accounting > messages, and then you are done. > > sometimes the solution is so simple it's hard to see. Thanks Glen! > Yes, it would seem that this is the most straightforward way to handle it. That is after all how it works in RADIUS. Can we get some text inserted that will make this crystal clear? This keeps coming up again and again -- and used as a justification for creating new protocols. From owner-aaa-wg@merit.edu Wed Oct 3 13:02:30 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB22433 for ; Wed, 3 Oct 2001 13:02:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C4F0912F5; Wed, 3 Oct 2001 13:03:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9C86912F6; Wed, 3 Oct 2001 13:03: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 B5D9A912F5 for ; Wed, 3 Oct 2001 13:03:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 705745DDA8; Wed, 3 Oct 2001 13:03: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 A42285DDA2 for ; Wed, 3 Oct 2001 13:03:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA41251; Wed, 3 Oct 2001 09:53:12 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 3 Oct 2001 09:53:12 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Jari Arkko , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: How to use Diameter Accounting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree that this is silly. As I recall, though, the restrictions are > intentional and arise from a fear of extensible protocols. Of course, > hamstringing Diameter extensibility virtually guarantees that we (or some > other set of folks) will go through this same exercise again in a few > years... > Months, not years. If Diameter can't be used as a general accounting facility, then there are at least two other WGs ready to define their own accounting protocols. This makes no sense. I'm not sure why anyone should be afraid of extending the Accounting functionality. There are no interoperability issues -- an Accounting Server that just writes AVPs to disk can do this with arbitrary AVPs. From owner-aaa-wg@merit.edu Wed Oct 3 13:14:18 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22770 for ; Wed, 3 Oct 2001 13:14:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39C82912F6; Wed, 3 Oct 2001 13:11:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0737A912F8; Wed, 3 Oct 2001 13:11: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 C7E9F912F6 for ; Wed, 3 Oct 2001 13:11:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 823B75DDAD; Wed, 3 Oct 2001 13:11:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 088065DDA2 for ; Wed, 3 Oct 2001 13:11:49 -0400 (EDT) Received: from client62-2-82-195.hispeed.ch (HELO ETCL001.yahoo.com) (62.2.82.195) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Oct 2001 17:10:41 -0000 X-Apparently-From: Message-Id: <5.1.0.14.0.20011003190617.02cb3450@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Oct 2001 19:09:54 +0200 To: Bernard Aboba From: Jacques Caron Subject: RE: [AAA-WG]: How to use Diameter Accounting Cc: Glen Zorn , Jari Arkko , "Harri Hakala (LMF)" , aaa-wg@merit.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, What about a server that would _require_ some specific AVPs for the application (in the general sense, not the Diameter sense) it handles? Say, in a roaming environment, a server that would want to have billing information... I guess you could always send back an error saying that AVPs are missing, but it's probably better to know beforehand (at capabilities exchange time)? Jacques. At 18:53 03/10/2001, Bernard Aboba wrote: > > I agree that this is silly. As I recall, though, the restrictions are > > intentional and arise from a fear of extensible protocols. Of course, > > hamstringing Diameter extensibility virtually guarantees that we (or some > > other set of folks) will go through this same exercise again in a few > > years... > > > >Months, not years. If Diameter can't be used as a general accounting >facility, then there are at least two other WGs ready to define their own >accounting protocols. This makes no sense. > >I'm not sure why anyone should be afraid of extending the Accounting >functionality. There are no interoperability issues -- an Accounting >Server that just writes AVPs to disk can do this with arbitrary AVPs. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Oct 3 13:31:30 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23079 for ; Wed, 3 Oct 2001 13:31:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A87B912F7; Wed, 3 Oct 2001 13:31:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1F089135D; Wed, 3 Oct 2001 13:31: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 1FA8A912F7 for ; Wed, 3 Oct 2001 13:31:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4ECA5DDAD; Wed, 3 Oct 2001 13:31:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by segue.merit.edu (Postfix) with ESMTP id AFC675DDA2 for ; Wed, 3 Oct 2001 13:31:10 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel11.hp.com (Postfix) with ESMTP id EC06B1F6F0; Wed, 3 Oct 2001 10:29:58 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA00221; Wed, 3 Oct 2001 10:31:31 -0700 (PDT) Date: Wed, 3 Oct 2001 10:31:31 -0700 (PDT) From: Joe Lau Message-Id: <200110031731.KAA00221@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 Cc: aaa-wg@merit.edu, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The general idea was that the HA modify the SPI value in the > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, alpha. Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this discussion? Joe From owner-aaa-wg@merit.edu Wed Oct 3 13:31:38 2001 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 NAA23091 for ; Wed, 3 Oct 2001 13:31:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A44C912FB; Wed, 3 Oct 2001 13:31:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23AFC91362; Wed, 3 Oct 2001 13:31: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 D92FC912FB for ; Wed, 3 Oct 2001 13:31:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9127E5DDAD; Wed, 3 Oct 2001 13:31:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by segue.merit.edu (Postfix) with SMTP id 0EC845DDA2 for ; Wed, 3 Oct 2001 13:31:41 -0400 (EDT) Received: (cpmta 15277 invoked from network); 3 Oct 2001 10:30:07 -0700 Received: from h000094929690.ne.mediaone.net (HELO h000094929690.mitton.com) (24.147.222.182) by smtp.mitton.com (209.228.32.64) with SMTP; 3 Oct 2001 10:30:07 -0700 X-Sent: 3 Oct 2001 17:30:08 GMT Message-Id: <5.1.0.14.2.20011003132338.051e3490@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 03 Oct 2001 13:30:00 -0400 To: Jacques Caron , Bernard Aboba From: David Mitton Subject: RE: [AAA-WG]: How to use Diameter Accounting Cc: Glen Zorn , Jari Arkko , "Harri Hakala (LMF)" , aaa-wg@merit.edu In-Reply-To: <5.1.0.14.0.20011003190617.02cb3450@pop.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 10/3/2001 07:09 PM +0200, Jacques Caron wrote: >Hi, > >What about a server that would _require_ some specific AVPs for the >application (in the general sense, not the Diameter sense) it handles? > >Say, in a roaming environment, a server that would want to have billing >information... I guess you could always send back an error saying that >AVPs are missing, but it's probably better to know beforehand (at >capabilities exchange time)? > >Jacques. ummm... my mind explodes contemplating a scalable protocol that would have someone withhold information, unless someone downstream says "pretty please", so you can have more round trips... Either the access server has the information to support the service and always forwards it, or the downstream server did not authorize the correct service. sorry for being terse, but you could argue this in many angles, but it comes down to provisioning AND IMPLEMENTING the correct service to start with, NOT negotiating up on the fly. The real work is detailing these "required" AVPs. And getting them provided as a matter of course. Dave. From owner-aaa-wg@merit.edu Wed Oct 3 13:40:29 2001 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 NAA23585 for ; Wed, 3 Oct 2001 13:40:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9B909121F; Wed, 3 Oct 2001 13:41:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D78D912F9; Wed, 3 Oct 2001 13:41:22 -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 50E9A9121F for ; Wed, 3 Oct 2001 13:41:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EAD85DDA2; Wed, 3 Oct 2001 13:41:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 736385DDD6 for ; Wed, 3 Oct 2001 13:41:20 -0400 (EDT) Received: (qmail 654 invoked by uid 500); 3 Oct 2001 17:25:51 -0000 Date: Wed, 3 Oct 2001 10:25:51 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011003102551.B633@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu References: <20011003093845.L32101@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Wed, Oct 03, 2001 at 09:49:12AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk will do this as part of the recent issue that was filed for acct purposes. PatC On Wed, Oct 03, 2001 at 09:49:12AM -0700, Bernard Aboba wrote: > > Actually, that's an interesting point. It is possible to just create a > > Diameter spec that defines new AVPs to be included in the Accounting > > messages, and then you are done. > > > > sometimes the solution is so simple it's hard to see. Thanks Glen! > > > > Yes, it would seem that this is the most straightforward way to handle > it. That is after all how it works in RADIUS. > > Can we get some text inserted that will make this crystal clear? This > keeps coming up again and again -- and used as a justification for > creating new protocols. > From owner-aaa-wg@merit.edu Wed Oct 3 14:23:27 2001 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 OAA25057 for ; Wed, 3 Oct 2001 14:23:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0A34A912FC; Wed, 3 Oct 2001 14:24:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDCCD91303; Wed, 3 Oct 2001 14:24: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 B7C76912FC for ; Wed, 3 Oct 2001 14:24:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 722CA5DDAD; Wed, 3 Oct 2001 14:24:20 -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 E1C425DDA2 for ; Wed, 3 Oct 2001 14:24:19 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-66.cisco.com [144.254.46.67]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA22397; Wed, 3 Oct 2001 11:23:08 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Subject: [AAA-WG]: RE: Do we need a NAS-Ciphersuite-Capabilities AVP? Date: Wed, 3 Oct 2001 11:23:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit henry.haverinen@nokia.com [mailto:henry.haverinen@nokia.com] writes: > Hi all, > > This e-mail is related to issue #188 and the discussion > at the following URLs: > http://www.merit.edu/mail.archives/aaa-wg/msg02211.html > http://www.merit.edu/mail.archives/aaa-wg/msg02237.html > > There is demand for enabling ciphersuite negotiation within > EAP. The result of the negotiation (the selected ciphersuite) > can already be transported to the NAS in the NAS-Key-Binding > AVP. But there is no AVP to transport the NAS capabilities to > the AAA server. > > If the EAP type is supposed to negotiate the ciphersuite, > then I guess we need to specify a new AVP for NAS capabilities. > For example, a NAS-Ciphersuite-Capabilities AVP could be included > in the first Diameter-EAP-Request sent by the Diameter client. > The AVP would list the ciphersuites supported by the NAS. Ideally, > the same ciphersuite numbering space should be used in the AVP and > in the NAS-Key-Binding AVP. This seems like a reasonable idea at first glance, but I have some concerns. 1) Since the cryptosystem is being negotiated in EAP and the EAP server and Diameter server may likely be distinct entities, this would seem to add interface requirements to EAP servers. 2) EAP should probably not be allowed to negotiate just any cryptosystem it likes: there seems to be an authorization issue as well. For example, suppose that EAP negotiates 40-bit RC4 but the user is only allowed to connect using 128-bit AES. How would this restriction be enforced? Both these concerns seem to suggest that EAP cannot be treated simply as a "pass-through" any more... > > Should I file an issue? > > Regards, > Henry > From owner-aaa-wg@merit.edu Wed Oct 3 14:30:51 2001 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 OAA25235 for ; Wed, 3 Oct 2001 14:30:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5595A91303; Wed, 3 Oct 2001 14:31:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20D0291304; Wed, 3 Oct 2001 14:31: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 04D8D91303 for ; Wed, 3 Oct 2001 14:31:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE2B85DDA8; Wed, 3 Oct 2001 14:31:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 097FD5DDA2 for ; Wed, 3 Oct 2001 14:31:43 -0400 (EDT) Received: from jariws1 ([62.248.238.237]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011003183035.FAFS11276.fep01-app.kolumbus.fi@jariws1>; Wed, 3 Oct 2001 21:30:35 +0300 Message-ID: <004d01c14c39$88d51f80$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Glen Zorn" Cc: "Harri Hakala (LMF)" , References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> <20011003093845.L32101@charizard.diameter.org> Subject: Re: [AAA-WG]: How to use Diameter Accounting Date: Wed, 3 Oct 2001 21:30:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Actually, that's an interesting point. It is possible to just create a > > Diameter spec that defines new AVPs to be included in the Accounting > > messages, and then you are done. > > sometimes the solution is so simple it's hard to see. Thanks Glen! Not so fast! This isn't *just* a problem with the arbitrary rules on creating new apps. Acct-Application-Id is a mandatory AVP on accounting messages, and you need to put in a value. So, what value to put in? Ok, let's assume we loosen the rules on making new accounting apps, perhaps by introducing a new section between 2.3.2 and 2.3.3. Anybody can add these and allocate an application id, and define new AVPs. (New cmds are still harder to get.) So: the first conclusion is that we do need an acct app value*. But that's fine. Finally, the current text in 2.5 dictates that "Relay" app can only be used by relay nodes. Well... what about "plain accounting" diameter servers that don't care if they record Foo or Bar service? Shouldn't they be allowed to advertise "Relay" in Acct-Application-Id as well? So in conclusion, how about the following: 1. Introduce a new section between 2.3.2 and 2.3.3 that tells you how you can make new applications for accounting 2. Allow the allocation of apps ids for these. 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for Diameter servers. Jari *) Alternative solution: use "Relay", or "Accounting". Not sure I like these. It would be useful to indicate what service generated the acct records. From owner-aaa-wg@merit.edu Wed Oct 3 14:38:46 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25555 for ; Wed, 3 Oct 2001 14:38:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 901EB91305; Wed, 3 Oct 2001 14:36:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D68E91306; Wed, 3 Oct 2001 14:36: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 EF88591305 for ; Wed, 3 Oct 2001 14:36:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE03A5DDA8; Wed, 3 Oct 2001 14:36:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id 2773D5DDA2 for ; Wed, 3 Oct 2001 14:36:07 -0400 (EDT) Received: from erilab.com (eblcl57.erilab.com [192.168.174.197]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f93IPuI14892; Wed, 3 Oct 2001 11:25:56 -0700 (PDT) Message-ID: <3BBB57E8.BA5BD9A0@erilab.com> Date: Wed, 03 Oct 2001 11:24:40 -0700 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com Subject: Re: [AAA-WG]: Section 8.1 References: <200110031731.KAA00221@strtio1.cup.hp.com> Content-Type: multipart/alternative; boundary="------------E9A36EF30F9B970D0F625B9D" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------E9A36EF30F9B970D0F625B9D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, why don't we put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the MIP-Peer-SPI ? In other words, see below MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-FA-to-MN-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] MIP-FA-to-HA-Key ::= < AVP Header: 328 > { MIP-FA-to-HA-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] By the way, I don't think we can impletement stateless diameter server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be returned in the HAA so it can be inserted into the AMA." and so on. Because in redirect case, there is no guarantee that whay avps you send, you will see all of them from the redirect answer. So all the diameter have to keep the state. please correct me if I am wrong. -Michael Joe Lau wrote: > > The general idea was that the HA modify the SPI value in the > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, alpha. > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > discussion? > > Joe --------------E9A36EF30F9B970D0F625B9D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit We have defined MIP-FA-to-HA-SPI  MIP-FA-to-MN-SPI  two AVPs, why don't we put these AVPs in the MIP-FA-to-HA-Key  MIP-FA-to-MN-Key to replace the MIP-Peer-SPI ?    In other words, see below
      MIP-FA-to-MN-Key ::= < AVP Header: 326 >
                           { MIP-FA-to-MN-SPI }
                           { MIP-Algorithm-Type }
                           { MIP-Session-Key }
                         * [ AVP ]

      MIP-FA-to-HA-Key ::= < AVP Header: 328 >
                           { MIP-FA-to-HA-SPI }
                           { MIP-Algorithm-Type }
                           { MIP-Session-Key }
                         * [ AVP ]
By the way, I don't think we can impletement stateless diameter server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be returned in the HAA so it can be inserted into the AMA." and so on.
Because in redirect case, there is no guarantee that whay avps you send, you will see all of them from the redirect answer. So all the diameter have to keep the state. please correct me if I am wrong.

-Michael
 

 

Joe Lau wrote:

> The general idea was that the HA modify the SPI value in the
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA.

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, alpha.
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing in this
discussion?

Joe

--------------E9A36EF30F9B970D0F625B9D-- From owner-aaa-wg@merit.edu Wed Oct 3 14:52:45 2001 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 OAA25969 for ; Wed, 3 Oct 2001 14:52:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C18B91306; Wed, 3 Oct 2001 14:53:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF94891307; Wed, 3 Oct 2001 14:53: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 D9AF691306 for ; Wed, 3 Oct 2001 14:53:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 884195DDA8; Wed, 3 Oct 2001 14:53:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by segue.merit.edu (Postfix) with ESMTP id 485B95DDA2 for ; Wed, 3 Oct 2001 14:53:27 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id 3D2E553A; Wed, 3 Oct 2001 11:52:20 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA00424; Wed, 3 Oct 2001 11:53:52 -0700 (PDT) Date: Wed, 3 Oct 2001 11:53:52 -0700 (PDT) From: Joe Lau Message-Id: <200110031853.LAA00424@strtio1.cup.hp.com> To: cchen@erilab.com Subject: Re: [AAA-WG]: Section 8.1 Cc: aaa-wg@merit.edu, fredrik.johansson@ipunplugged.com, jlau@cup.hp.com, meklund@knox6039.cisco.com, pcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, why don't we > put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > MIP-Peer-SPI ? In other words, see below > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > { MIP-FA-to-HA-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > By the way, I don't think we can impletement stateless diameter server by > requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > returned in the HAA so it can be inserted into the AMA." and so on. > Because in redirect case, there is no guarantee that whay avps you send, you > will see all of them from the redirect answer. So all the diameter have to > keep the state. please correct me if I am wrong. I agree with Michael that _all_ diameter have to keep state. Another good example would be the following statement on section 1.2. During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see figure 2). Of course, the AAAH MUST use the _same_ session identifier for _all_ HARs initiated on behalf of a given mobile node's session. This will require the AAAH server to be stateful. Anyone disagree on this? Joe > Joe Lau wrote: > > > > The general idea was that the HA modify the SPI value in the > > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > > But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, alpha. > > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > > discussion? > > > > Joe > > --------------E9A36EF30F9B970D0F625B9D > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > We have defined MIP-FA-to-HA-SPI  MIP-FA-to-MN-SPI  two AVPs, > why don't we put these AVPs in the MIP-FA-to-HA-Key  MIP-FA-to-MN-Key > to replace the MIP-Peer-SPI ?    In other words, see below >
      MIP-FA-to-MN-Key ::= < AVP Header: > 326 > >
                           > { MIP-FA-to-MN-SPI } >
                           > { MIP-Algorithm-Type } >
                           > { MIP-Session-Key } >
                         > * [ AVP ] >

      MIP-FA-to-HA-Key ::= < AVP Header: > 328 > >
                           > { MIP-FA-to-HA-SPI } >
                           > { MIP-Algorithm-Type } >
                           > { MIP-Session-Key } >
                         > * [ AVP ] >
By the way, I don't think we can impletement stateless diameter > server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > it must be returned in the HAA so it can be inserted into the AMA." and > so on. >
Because in redirect case, there is no guarantee that whay avps > you send, you will see all of them from the redirect answer. So all the > diameter have to keep the state. please correct me if I am wrong. >

-Michael >
  >

  >

Joe Lau wrote: >

> The general idea was that the HA modify the SPI > value in the >
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > alpha. >
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > in this >
discussion? >

Joe

> > > --------------E9A36EF30F9B970D0F625B9D-- > > From owner-aaa-wg@merit.edu Wed Oct 3 15:30:28 2001 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 PAA27072 for ; Wed, 3 Oct 2001 15:30:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 453D791308; Wed, 3 Oct 2001 15:30:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18A2991309; Wed, 3 Oct 2001 15:30: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 F0CBF91308 for ; Wed, 3 Oct 2001 15:30:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AD625DDA8; Wed, 3 Oct 2001 15:30:43 -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 34D245DDA2 for ; Wed, 3 Oct 2001 15:30:43 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f93JTRC28741; Wed, 3 Oct 2001 15:29:28 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA26054; Wed, 3 Oct 2001 15:29:27 -0400 (EDT) Date: Wed, 03 Oct 2001 15:13:23 -0400 Message-ID: <87k7yca65o.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: Cc: , Subject: Re: [AAA-WG]: Issues 188, 189 and 190 In-Reply-To: References: <87d7442884.wl@catfish.research.telcordia.com> User-Agent: Wanderlust/2.7.4 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk At Wed, 3 Oct 2001 07:26:15 -0700, Glen Zorn wrote: > > Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > > > I would prefer defining a new NAS-Key-Type value "MASTER_KEY" for > > representing a session master key and not including the > > NAS-Key-Binding AVP when the value of the NAS-Key-Type AVP is > > MASTER_KEY. It eliminates ambiguity and seems no harm. > > Maybe it's just old age, but I fail to discern the ambiguity in the terms > "ENCRYPTION_KEY" and "INTEGRITY_KEY". "MASTER_KEY", OTOH seems quite > ambiguous, meaning different things to different people at different times. > > > > > Yoshihiro Ohba > > > > > > > > At Wed, 3 Oct 2001 10:18:25 +0300 , > > Henry wrote: > > > > > > > > > Hello Glen, > > > > > > Issue 190 (session master keys): > > > > > > > > Perhaps the NASREQ document could simply say that the > > > > > CIPHER_KEY (or INTEGRITY_KEY) can alternatively be used as > > > > > a session master key from which the NAS derives the actual > > > > > cipher keys (integrity keys). > > > > > > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > > > I think that that goes w/o out saying. Sorry for the nested quotation, but if master key itself is ambiguous, I think the NASREQ document could not simply say that the CIPHER_KEY or INTEGRITY_KEY can alternatively be used as a session master key. So are you actually suggesting not using master key? Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 3 20:28:04 2001 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 UAA04781 for ; Wed, 3 Oct 2001 20:28:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 710E79122D; Wed, 3 Oct 2001 20:28:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32C6E9130E; Wed, 3 Oct 2001 20:28:50 -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 101C79122D for ; Wed, 3 Oct 2001 20:28:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B05BE5DDD8; Wed, 3 Oct 2001 20:28:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 8AEDD5DDD5 for ; Wed, 3 Oct 2001 20:28:48 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA25124 for ; Wed, 3 Oct 2001 17:27:40 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA13281 for ; Wed, 3 Oct 2001 17:27:40 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 3 Oct 2001 19:27:39 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: aaa-wg@merit.edu Subject: [AAA-WG]: General question on MIP and AAA interaction Date: Wed, 3 Oct 2001 19:27:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, As noted in many places, mobility agents (FA,HA) do not have to interact with the AAA infrastructure every time a mobile is sending a Registration Request. To my understanding, this implies that whenever a AAA infrastructure is available and used, the HA does NOT have the authority to extend the registration lifetime. In other words, (i) either the MN ignores the lifetime field in Registration Replies coming directly from the HA, or (ii) Registration Replies sent directly to the MN MUST have the lifetime field set to: (Authorization-Lifetime in last received HAR) minus (Time elapsed since last HAR was received) minus (some delays) Is that how it's supposed to work or am I way off on this? :) Thanks, -Panos From owner-aaa-wg@merit.edu Thu Oct 4 03:23:56 2001 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 DAA00732 for ; Thu, 4 Oct 2001 03:23:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADCB99123A; Thu, 4 Oct 2001 03:24:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77A9791275; Thu, 4 Oct 2001 03:24:41 -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 265299123A for ; Thu, 4 Oct 2001 03:24:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE5E35DDD4; Thu, 4 Oct 2001 03:24:39 -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 575D95DDB1 for ; Thu, 4 Oct 2001 03:24:34 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f947Nwf18056 for ; Thu, 4 Oct 2001 10:23:58 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Oct 2001 10:23:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Oct 2001 10:23:25 +0300 Message-ID: From: henry.haverinen@nokia.com To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Thu, 4 Oct 2001 10:23:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > From: ext Glen Zorn [mailto:gwz@cisco.com] > > I'm unfamiliar w/the practice of deriving IVs from secret > material. Since > IVs are often transmitted in the clear, could this not > release information > about the master key itself? The IV doesn't have to be secret but it should be integrity protected, at least with CBC. Otherwise an adversary can modify the IV to make predictable bit changes to the first plaintext block recovered. Using a secret IV is one method for preventing this. Sending the IV in the clear and protecting it (and the message itself) with a MAC is another method. Regards, Henry From owner-aaa-wg@merit.edu Thu Oct 4 03:45:28 2001 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 DAA01048 for ; Thu, 4 Oct 2001 03:45:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3ECB791275; Thu, 4 Oct 2001 03:46:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDDF9912AC; Thu, 4 Oct 2001 03:46:09 -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 51D0591275 for ; Thu, 4 Oct 2001 03:46:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD4345DDD4; Thu, 4 Oct 2001 03:46:07 -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 0789F5DD9C for ; Thu, 4 Oct 2001 03:46:07 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f947jUf07565 for ; Thu, 4 Oct 2001 10:45:30 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Oct 2001 10:44:54 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Oct 2001 10:44:56 +0300 Message-ID: <9E3407CE45911B4097632389B77B202306CF69@esebe014.NOE.Nokia.com> From: Ext-Venkata.Ghadiyaram@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Outstanding unanswered requests. Date: Thu, 4 Oct 2001 10:44:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Is there any limit on the number of outstanding unanswered requests within a single session at a diameter server. Thanks and regards, Kishore From owner-aaa-wg@merit.edu Thu Oct 4 03:47:12 2001 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 DAA01096 for ; Thu, 4 Oct 2001 03:47:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDA9E912AC; Thu, 4 Oct 2001 03:48:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A53DA9130E; Thu, 4 Oct 2001 03:48:03 -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 5C373912AC for ; Thu, 4 Oct 2001 03:48:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12BE05DDD4; Thu, 4 Oct 2001 03:48:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 356075DD9C for ; Thu, 4 Oct 2001 03:48:01 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA12106; Thu, 4 Oct 2001 09:47:09 +0200 From: "Fredrik Johansson" To: "Thomas Panagiotis-PTHOMAS1" , Subject: RE: [AAA-WG]: General question on MIP and AAA interaction Date: Thu, 4 Oct 2001 09:47:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >Hi, > >As noted in many places, mobility agents (FA,HA) do not have to >interact with the AAA infrastructure every time a mobile is >sending a Registration Request. To my understanding, this implies >that whenever a AAA infrastructure is available and used, the HA >does NOT have the authority to extend the registration lifetime. >In other words, >(i) either the MN ignores the lifetime field in Registration > Replies coming directly from the HA, or No, it will not ignore the lifetime field in the Reg Reply >(ii) Registration Replies sent directly to the MN MUST have the > lifetime field set to: > (Authorization-Lifetime in last received HAR) minus > (Time elapsed since last HAR was received) minus > (some delays) The Lifetime field in the registration reply should be set so that the Authorization-Lifetime is a multiple of the lifetime in the reg-reply. This way the mobile node will be able to do periodic tunnel updates without involving AAA. AAA is only involved when the Authorization-Lifetime expires. Hope this clarifies /Fredrik > >Is that how it's supposed to work or am I way off on this? :) > >Thanks, > >-Panos From owner-aaa-wg@merit.edu Thu Oct 4 03:49:34 2001 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 DAA01158 for ; Thu, 4 Oct 2001 03:49:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2892A9130E; Thu, 4 Oct 2001 03:50:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDFD591312; Thu, 4 Oct 2001 03:50:22 -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 DA3849130E for ; Thu, 4 Oct 2001 03:50:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 900025DDD4; Thu, 4 Oct 2001 03:50:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from dhcp118.ripemtg.ripe.net (dhcp118.ripemtg.ripe.net [193.0.8.118]) by segue.merit.edu (Postfix) with ESMTP id 385CA5DD9C for ; Thu, 4 Oct 2001 03:50:21 -0400 (EDT) Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.33 #1) id 15p3Fa-000F6K-00; Thu, 04 Oct 2001 09:48:58 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pat Calhoun Cc: Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting References: <3BBAE31D.88CF01C5@lmf.ericsson.se> <20011003093010.I32101@charizard.diameter.org> Message-Id: Date: Thu, 04 Oct 2001 09:48:58 +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > This is the way it used to work.... then Glen argued to bundle it into the > base spec, and remove the separate appl-id, and we created the acct-appl-id. > > Is reversing on a WG decision we made over 8 months ago really the right > thing to do here? what is the technically right thing to do? randy From owner-aaa-wg@merit.edu Thu Oct 4 04:52:57 2001 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 EAA02133 for ; Thu, 4 Oct 2001 04:52:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4195791313; Thu, 4 Oct 2001 04:53:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10ECD91314; Thu, 4 Oct 2001 04:53: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 AE2DD91313 for ; Thu, 4 Oct 2001 04:53:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C8EA5DDDD; Thu, 4 Oct 2001 04:53:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 69B9F5DDD4 for ; Thu, 4 Oct 2001 04:53:45 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f948qUC21243 for ; Thu, 4 Oct 2001 10:52:30 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Oct 04 10:52:30 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 10:52:29 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA03441CCC@efijont102> From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" Cc: "Jari Arkko (LMF)" Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 10:52:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I agree with Jari's proposal. That solves the original problem, that is, the need to create a new dummy application before it is possible to use the Diameter accounting. Regards........Harri -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 3. lokakuuta 2001 21:31 To: Pat Calhoun; Glen Zorn Cc: Harri Hakala (LMF); Subject: Re: [AAA-WG]: How to use Diameter Accounting > > Actually, that's an interesting point. It is possible to just create a > > Diameter spec that defines new AVPs to be included in the Accounting > > messages, and then you are done. > > sometimes the solution is so simple it's hard to see. Thanks Glen! Not so fast! This isn't *just* a problem with the arbitrary rules on creating new apps. Acct-Application-Id is a mandatory AVP on accounting messages, and you need to put in a value. So, what value to put in? Ok, let's assume we loosen the rules on making new accounting apps, perhaps by introducing a new section between 2.3.2 and 2.3.3. Anybody can add these and allocate an application id, and define new AVPs. (New cmds are still harder to get.) So: the first conclusion is that we do need an acct app value*. But that's fine. Finally, the current text in 2.5 dictates that "Relay" app can only be used by relay nodes. Well... what about "plain accounting" diameter servers that don't care if they record Foo or Bar service? Shouldn't they be allowed to advertise "Relay" in Acct-Application-Id as well? So in conclusion, how about the following: 1. Introduce a new section between 2.3.2 and 2.3.3 that tells you how you can make new applications for accounting 2. Allow the allocation of apps ids for these. 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for Diameter servers. Jari *) Alternative solution: use "Relay", or "Accounting". Not sure I like these. It would be useful to indicate what service generated the acct records. From owner-aaa-wg@merit.edu Thu Oct 4 06:01:57 2001 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 GAA03912 for ; Thu, 4 Oct 2001 06:01:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3525091314; Thu, 4 Oct 2001 06:02:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE62191315; Thu, 4 Oct 2001 06:02:49 -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 C652091314 for ; Thu, 4 Oct 2001 06:02:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C1545DDB6; Thu, 4 Oct 2001 06:02:48 -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 E36C25DD8F for ; Thu, 4 Oct 2001 06:02:47 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-121.cisco.com [144.254.46.122]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA27366; Thu, 4 Oct 2001 03:01:01 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Jari Arkko" , "Pat Calhoun" Cc: "Harri Hakala (LMF)" , Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 03:01:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <004d01c14c39$88d51f80$8a1b6e0a@arenanet.fi> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko [mailto:jari.arkko@kolumbus.fi] writes: > > > Actually, that's an interesting point. It is possible to just create a > > > Diameter spec that defines new AVPs to be included in the Accounting > > > messages, and then you are done. > > > > sometimes the solution is so simple it's hard to see. Thanks Glen! > > Not so fast! This isn't *just* a problem with the arbitrary rules on > creating new apps. Acct-Application-Id is a mandatory AVP on > accounting messages, and you need to put in a value. So, what > value to put in? Ok, let's assume we loosen the rules on making > new accounting apps, perhaps by introducing a new section > between 2.3.2 and 2.3.3. Anybody can add these and allocate > an application id, and define new AVPs. (New cmds are still > harder to get.) So: the first conclusion is that we do need an acct > app value*. What do you mean by "acct app value"? Do you mean a "generic" value for accounting? If so, I disagree... > But that's fine. > > Finally, the current text in 2.5 dictates that "Relay" app can > only be used > by relay nodes. Well... what about "plain accounting" diameter servers > that don't care if they record Foo or Bar service? Shouldn't they > be allowed > to advertise "Relay" in Acct-Application-Id as well? > > So in conclusion, how about the following: > > 1. Introduce a new section between 2.3.2 and 2.3.3 that tells > you how you can make new applications for accounting > 2. Allow the allocation of apps ids for these. > 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for > Diameter servers. > > Jari > *) Alternative solution: use "Relay", or "Accounting". Not sure > I like these. It would be useful to indicate what service generated > the acct records. > > > > > From owner-aaa-wg@merit.edu Thu Oct 4 06:15:43 2001 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 GAA04081 for ; Thu, 4 Oct 2001 06:15:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD2CA91315; Thu, 4 Oct 2001 06:16:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A97F891316; Thu, 4 Oct 2001 06:16: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 3793E91315 for ; Thu, 4 Oct 2001 06:16:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C09FE5DDB6; Thu, 4 Oct 2001 06:16:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id CB3AA5DD8F for ; Thu, 4 Oct 2001 06:16:09 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f94AEwL24771; Thu, 4 Oct 2001 12:14:58 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f94AEvl28252; Thu, 4 Oct 2001 13:14:57 +0300 (EET DST) Message-ID: <3BBC36A1.75424CEF@lmf.ericsson.se> Date: Thu, 04 Oct 2001 13:14:57 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: Jari Arkko , Pat Calhoun , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >What do you mean by "acct app value"? Do you mean a "generic" value for >accounting? If so, I disagree... Given that Acct-Application-Id AVP is mandatory in accounting messages, we need *some* value for that. This we can propably agree on, or? Then it is another question what the value should be. My preference is at the moment that user groups should be able to create new apps, and allocate new values that they use here. This seems to match your desire, or? Jari From owner-aaa-wg@merit.edu Thu Oct 4 06:27:11 2001 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 GAA04184 for ; Thu, 4 Oct 2001 06:27:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E20A91316; Thu, 4 Oct 2001 06:27:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E31E391317; Thu, 4 Oct 2001 06:27: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 97F6D91316 for ; Thu, 4 Oct 2001 06:27:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 433E35DDB6; Thu, 4 Oct 2001 06:27:55 -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 BB0275DD8F for ; Thu, 4 Oct 2001 06:27:54 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-121.cisco.com [144.254.46.122]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA08621; Thu, 4 Oct 2001 03:26:09 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Jari Arkko" Cc: "Pat Calhoun" , "Harri Hakala (LMF)" , Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 03:26:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3BBC36A1.75424CEF@lmf.ericsson.se> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] writes: > >What do you mean by "acct app value"? Do you mean a "generic" value for > >accounting? If so, I disagree... > > Given that Acct-Application-Id AVP is mandatory in accounting > messages, we need *some* value for that. This we can propably > agree on, or? > > Then it is another question what the value should be. My > preference is at the moment that user groups should be able > to create new apps, and allocate new values that they use > here. This seems to match your desire, or? Yes, exactly. I wanted to clarify, since our preferences don't seem to match Harri's (see his last message)... > > Jari > From owner-aaa-wg@merit.edu Thu Oct 4 06:32:38 2001 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 GAA04301 for ; Thu, 4 Oct 2001 06:32:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E283891317; Thu, 4 Oct 2001 06:33:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9A7591318; Thu, 4 Oct 2001 06:33:30 -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 87AB291317 for ; Thu, 4 Oct 2001 06:33:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3424A5DDB6; Thu, 4 Oct 2001 06:33:29 -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 AE0585DD8F for ; Thu, 4 Oct 2001 06:33:28 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-121.cisco.com [144.254.46.122]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA11059; Thu, 4 Oct 2001 03:32:15 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Cc: Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Thu, 4 Oct 2001 03:32:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Henry Haverinen [mailto:henry.haverinen@nokia.com] writes: > > From: ext Glen Zorn [mailto:gwz@cisco.com] > > > > I'm unfamiliar w/the practice of deriving IVs from secret > > material. Since > > IVs are often transmitted in the clear, could this not > > release information > > about the master key itself? > > The IV doesn't have to be secret but it should be integrity > protected, at least with CBC. Otherwise an adversary can modify > the IV to make predictable bit changes to the first plaintext > block recovered. Using a secret IV is one method for preventing > this. but secrecy != integrity protection... > Sending the IV in the clear and protecting it (and the > message itself) with a MAC is another method. > > Regards, > Henry > From owner-aaa-wg@merit.edu Thu Oct 4 06:37:05 2001 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 GAA04355 for ; Thu, 4 Oct 2001 06:37:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F3F191318; Thu, 4 Oct 2001 06:37:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 287AA91319; Thu, 4 Oct 2001 06:37: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 087BC91318 for ; Thu, 4 Oct 2001 06:37:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B05C95DDB6; Thu, 4 Oct 2001 06:37:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id BA79B5DD8F for ; Thu, 4 Oct 2001 06:37:49 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f94AadC12313; Thu, 4 Oct 2001 12:36:39 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f94Aadl29007; Thu, 4 Oct 2001 13:36:39 +0300 (EET DST) Message-ID: <3BBC3BB7.E58001D1@lmf.ericsson.se> Date: Thu, 04 Oct 2001 13:36:39 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: Pat Calhoun , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Yes, exactly. I wanted to clarify, since our preferences don't seem to >match Harri's (see his last message)... Harri said he wanted to eliminate the "need to create a new dummy application". This could mean the dummy new messages, the renaming of the acct messages app specific ones, the allocation of an app id, or some combination of these. I tried to reach Harri but couldn't find him at the moment. But I thought that he didn't mind allocating new application identities, particularly when he said OK to my proposal that suggested this as one part of the solution. So, we just might all agree, but I'll let Harri confirm... Jari From owner-aaa-wg@merit.edu Thu Oct 4 06:48:24 2001 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 GAA04537 for ; Thu, 4 Oct 2001 06:48:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 710B291319; Thu, 4 Oct 2001 06:49:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 342F39131A; Thu, 4 Oct 2001 06:49: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 D9A4F91319 for ; Thu, 4 Oct 2001 06:49:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B4E45DDBA; Thu, 4 Oct 2001 06:49:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 81BB45DD8F for ; Thu, 4 Oct 2001 06:49:17 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f94Am7C18122 for ; Thu, 4 Oct 2001 12:48:07 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Oct 04 12:48:07 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 12:48:06 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA03441CCD@efijont102> From: "Harri Hakala (LMF)" To: "Jari Arkko (LMF)" , gwz@cisco.com Cc: Pat Calhoun , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 12:47:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Yes, As I said I agree with Jari's proposal. It is perfect solution for me. Harri -----Original Message----- From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] Sent: 4. lokakuuta 2001 13:37 To: gwz@cisco.com Cc: Pat Calhoun; Harri Hakala (LMF); aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting >Yes, exactly. I wanted to clarify, since our preferences don't seem to >match Harri's (see his last message)... Harri said he wanted to eliminate the "need to create a new dummy application". This could mean the dummy new messages, the renaming of the acct messages app specific ones, the allocation of an app id, or some combination of these. I tried to reach Harri but couldn't find him at the moment. But I thought that he didn't mind allocating new application identities, particularly when he said OK to my proposal that suggested this as one part of the solution. So, we just might all agree, but I'll let Harri confirm... Jari From owner-aaa-wg@merit.edu Thu Oct 4 07:01:18 2001 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 HAA05022 for ; Thu, 4 Oct 2001 07:01:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A0D69131A; Thu, 4 Oct 2001 07:02:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D08249131B; Thu, 4 Oct 2001 07:02:02 -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 924329131A for ; Thu, 4 Oct 2001 07:02:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C50F5DDBA; Thu, 4 Oct 2001 07:02:01 -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 D4F625DD8F for ; Thu, 4 Oct 2001 07:02:00 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-121.cisco.com [144.254.46.122]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id EAA27785; Thu, 4 Oct 2001 04:00:15 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Yoshihiro Ohba" Cc: , Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Thu, 4 Oct 2001 04:00:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <87k7yca65o.wl@catfish.research.telcordia.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > Sorry for the nested quotation, but if master key itself is ambiguous, > I think the NASREQ document could not simply say that the CIPHER_KEY > or INTEGRITY_KEY can alternatively be used as a session master key. > So are you actually suggesting not using master key? What I'm saying is that just saying "MASTER_KEY" w/o further qualification is by definition more ambiguous that saying either "ENCRYPTION_KEY" or "INTEGRITY_KEY". Furthermore, I can't find in the definition of the NAS-Key-Type AVP any requirement (either explicit or implied) that the key material therein be used w/o modification or any prohibition of the derivation of other keys from that material. So all I can see the "MASTER_KEY" type adding is the ability to ship arbitrary stuff labeled w/the cryptographic equivalent of "whatever". This doesn't seem like a big plus to me; however, if you insist upon it then I think that the language around "ENCRYPTION_KEY" and "INTEGRITY_KEY" needs to be tightened up to state the kind of usage restrictions the Henty seems to have inexplicably (to me, at least) read into the existing definitions. If we do that, though, then we should probably add definitions for "MASTER_ENCRYPTION_KEY" and "MASTER_INTEGRITY_KEY" as well... > > Yoshihiro Ohba > > > From owner-aaa-wg@merit.edu Thu Oct 4 07:05:03 2001 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 HAA05509 for ; Thu, 4 Oct 2001 07:05:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F8CA9131B; Thu, 4 Oct 2001 07:05:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D71269131C; Thu, 4 Oct 2001 07:05: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 B10299131B for ; Thu, 4 Oct 2001 07:05:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6117F5DDBA; Thu, 4 Oct 2001 07:05:56 -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 15B725DD8F for ; Thu, 4 Oct 2001 07:05:56 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-121.cisco.com [144.254.46.122]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id EAA29589; Thu, 4 Oct 2001 04:04:11 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Harri Hakala (LMF)" , "Jari Arkko (LMF)" Cc: "Pat Calhoun" , Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 04:04:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <0154633DAF7BD4119C360002A513AA03441CCD@efijont102> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] writes: > Hi, > > Yes, As I said I agree with Jari's proposal. > It is perfect solution for me. Cool, so we're in violent agreement ;-) > > Harri > > -----Original Message----- > From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > Sent: 4. lokakuuta 2001 13:37 > To: gwz@cisco.com > Cc: Pat Calhoun; Harri Hakala (LMF); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: How to use Diameter Accounting > > > >Yes, exactly. I wanted to clarify, since our preferences don't seem to > >match Harri's (see his last message)... > > Harri said he wanted to eliminate the "need to create a new dummy > application". This could mean the dummy new messages, the renaming > of the acct messages app specific ones, the allocation of an app > id, or some combination of these. I tried to reach Harri but couldn't > find him at the moment. But I thought that he didn't mind allocating > new application identities, particularly when he said OK to my > proposal that suggested this as one part of the solution. So, we just > might all agree, but I'll let Harri confirm... > > Jari > From owner-aaa-wg@merit.edu Thu Oct 4 08:31:41 2001 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 IAA08743 for ; Thu, 4 Oct 2001 08:31:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 312529131D; Thu, 4 Oct 2001 08:32:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA2AC9131E; Thu, 4 Oct 2001 08:32:41 -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 A1DBB9131D for ; Thu, 4 Oct 2001 08:32:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 529485DDC5; Thu, 4 Oct 2001 08:32:40 -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 5F8AF5DDBA for ; Thu, 4 Oct 2001 08:32:39 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f94CW2f07038 for ; Thu, 4 Oct 2001 15:32:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Oct 2001 15:31:29 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Oct 2001 15:31:29 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2E@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: gwz@cisco.com, Harri.Hakala@lmf.ericsson.se, Jari.Arkko@lmf.ericsson.se Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 15:31:17 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Now that we are clarifying these issues regarding new applications and their accounting extensions I have one proposal to add. Because it is possible that a service only makes use of the Accounting portion of the Diameter application then the application must clearly described in the application specification which part contains the accounting portion. The current text describes in the section 9.3 (Application document requirements) clearly how new accounting AVPs must be described in new applications but it does say anything how new accounting command codes (if exist) should be described. One way to enforce that this is clearly described in the new applications is to modify the section 9.3 in the following way: "Each Diameter application (e.g. NASREQ, MobileIP), MUST define their Service-Specific accounting part in a section entitled "Accounting". Under the section "Accounting" they MUST define their Service-Specific AVPs that MUST be present in the Accounting-Request message in a section entitled "Accounting AVPs" and their Service-Specific command codes if exists in a section entitled "Accounting Command-Codes". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in this section." Best Regards, Jaakko From owner-aaa-wg@merit.edu Thu Oct 4 09:01:50 2001 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 JAA10371 for ; Thu, 4 Oct 2001 09:01:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27CC19131E; Thu, 4 Oct 2001 09:02:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6E1B9131F; Thu, 4 Oct 2001 09:02:39 -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 AAC7D9131E for ; Thu, 4 Oct 2001 09:02:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 538BC5DDC5; Thu, 4 Oct 2001 09:02:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 6F8595DDBA for ; Thu, 4 Oct 2001 09:02:37 -0400 (EDT) Received: from jariws1 ([62.248.238.237]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011004130127.KAEE11276.fep01-app.kolumbus.fi@jariws1>; Thu, 4 Oct 2001 16:01:27 +0300 Message-ID: <005501c14cd4$b9225fe0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , , , Cc: , References: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2E@esebe013.NOE.Nokia.com> Subject: Re: [AAA-WG]: How to use Diameter Accounting Date: Thu, 4 Oct 2001 16:01:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > accounting portion. The current text describes in the section 9.3 > (Application document requirements) clearly how new accounting AVPs must be > described in new applications but it does say anything how new accounting > command codes (if exist) should be described. One way to enforce that this > is clearly described in the new applications is to modify the section 9.3 in > the following way: Agreed. Jari From owner-aaa-wg@merit.edu Thu Oct 4 10:06:09 2001 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 KAA13376 for ; Thu, 4 Oct 2001 10:06:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65F1291323; Thu, 4 Oct 2001 10:06:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE4BF91322; Thu, 4 Oct 2001 10:06:54 -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 4A44B91321 for ; Thu, 4 Oct 2001 10:06:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED33A5DDBA; Thu, 4 Oct 2001 10:06:52 -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 3AE045DD99 for ; Thu, 4 Oct 2001 10:06:52 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f94E6Ff20793 for ; Thu, 4 Oct 2001 17:06:15 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Oct 2001 17:05:42 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 4 Oct 2001 17:05:41 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2F@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP Date: Thu, 4 Oct 2001 17:05:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, One tool for trouble shooting is taking protocol traces between servers in the network. Tracer equipments provides filtering capabilities for getting only the interesting messages (this in an important feature since in live environments there are lot of messages going). Quite often certain problem can be reproduced using a known user, therefore it is important that messages related to this user can be filtered from the wire without using any information stored to servers in network. So, in this case it is important that every request contains user name so that those messages can be intercepted. Note that response can be usually intercepted without subscriber id since normally there is "transaction id" which connects request and response together. One can say that each Diameter application should be specified considering these types of issues in mind and not the base protocol. However, my thinking here was that since the User-Name AVP already is in the Session-Termination-Request/Answer it would be quite natural (for me) that the Abort-Session-Request also contains it and in addition for the above mentioned reason. However, this issue is not so straighforward because the Re-Auth-Request command does not contain the User-Name AVP either. After this long talk my question here is that, is there a specific reason why the User-Name AVP is included into some of the base protocol commands as a mandatory AVP and some of them don't have it? Best Regards, Jaakko > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 03 October, 2001 19:42 > To: Rajaniemi Jaakko (NET/Espoo) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > Not sure why this is the case. > > PatC > On Wed, Oct 03, 2001 at 05:17:25PM +0300, > jaakko.rajaniemi@nokia.com wrote: > > Hello, > > > > Currently, the Abort-Session-Request/Answer does not > contain the User-Name > > AVP as a mandatory AVP. However, the > Session-Termination-Request/Answer > > contains the User-Name AVP as a mandatory AVP. Is there any > specific reason > > why these two command codes are defined differently with > regards to the > > User-Name AVP? As these command codes are quite similar, it > would be logical > > if the Abort-Session-Request/Answer also contains the > User-Name AVP as a > > mandatory AVP and it would be useful to have the user name > in the messages > > e.g. for trouble shooting. > > > > Best Regards, Jaakko > From owner-aaa-wg@merit.edu Thu Oct 4 11:19:13 2001 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 LAA16025 for ; Thu, 4 Oct 2001 11:19:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F240B91326; Thu, 4 Oct 2001 11:19:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD71691327; Thu, 4 Oct 2001 11:19: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 37FEC91326 for ; Thu, 4 Oct 2001 11:19:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9AC85DDD4; Thu, 4 Oct 2001 11:19:51 -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 0B3105DD99 for ; Thu, 4 Oct 2001 11:19:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA42917; Thu, 4 Oct 2001 08:09:29 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 4 Oct 2001 08:09:29 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Yoshihiro Ohba , henry.haverinen@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issues 188, 189 and 190 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > > > Sorry for the nested quotation, but if master key itself is ambiguous, > > I think the NASREQ document could not simply say that the CIPHER_KEY > > or INTEGRITY_KEY can alternatively be used as a session master key. > > So are you actually suggesting not using master key? > > What I'm saying is that just saying "MASTER_KEY" w/o further qualification > is by definition more ambiguous that saying either "ENCRYPTION_KEY" or > "INTEGRITY_KEY". Furthermore, I can't find in the definition of the > NAS-Key-Type AVP any requirement (either explicit or implied) that the key > material therein be used w/o modification or any prohibition of the > derivation of other keys from that material. So all I can see the > "MASTER_KEY" type adding is the ability to ship arbitrary stuff labeled > w/the cryptographic equivalent of "whatever". This doesn't seem like a big > plus to me; however, if you insist upon it then I think that the language > around "ENCRYPTION_KEY" and "INTEGRITY_KEY" needs to be tightened up to > state the kind of usage restrictions the Henty seems to have inexplicably > (to me, at least) read into the existing definitions. If we do that, > though, then we should probably add definitions for "MASTER_ENCRYPTION_KEY" > and "MASTER_INTEGRITY_KEY" as well... > What I think is needed here is some definition of what the "MASTER KEY" is and how authentication/integrity, confidentiality, IV, etc. are derived from it. We can then reference this spec, or at least agree that it will be delivered later. I agree with Henry though that the present specification is not workable. It is not appropriate to require modification of the AAA server and EAP methods every time we get a new ciphersuite for a Diameter application. So the keys passed by AAA & EAP need to be generic, and the logic for converting master keys to specific keys needs to be present in the NAS, not in the AAA server. This can include logic for checking weak keys, truncation for the specific ciphersuite, etc. Presumably the NAS is implementing the given ciphersuite, so it needs to have ciphersuite-specific code anyway. The AAA server and EAP methods do not. From owner-aaa-wg@merit.edu Thu Oct 4 11:48:42 2001 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 LAA16966 for ; Thu, 4 Oct 2001 11:48:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5C019132A; Thu, 4 Oct 2001 11:49:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46A009132B; Thu, 4 Oct 2001 11:49:30 -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 E80379132A for ; Thu, 4 Oct 2001 11:49:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94A235DDDD; Thu, 4 Oct 2001 11:49:28 -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 59D155DDB6 for ; Thu, 4 Oct 2001 11:49:28 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f94Fm9C22832; Thu, 4 Oct 2001 11:48:10 -0400 (EDT) Received: from catfish.research.telcordia.com (ohba@tari-dhcp1.research.telcordia.com [207.3.232.115]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA28079; Thu, 4 Oct 2001 11:48:11 -0400 (EDT) Date: Thu, 04 Oct 2001 11:32:05 -0400 Message-ID: <87y9mr4e16.wl@catfish.research.telcordia.com> From: Yoshihiro Ohba To: Cc: , Subject: Re: [AAA-WG]: Issues 188, 189 and 190 In-Reply-To: References: <87k7yca65o.wl@catfish.research.telcordia.com> User-Agent: Wanderlust/2.7.4 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello Glen, At Thu, 4 Oct 2001 04:00:16 -0700, Glen Zorn wrote: > > Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > > > Sorry for the nested quotation, but if master key itself is ambiguous, > > I think the NASREQ document could not simply say that the CIPHER_KEY > > or INTEGRITY_KEY can alternatively be used as a session master key. > > So are you actually suggesting not using master key? > > What I'm saying is that just saying "MASTER_KEY" w/o further qualification > is by definition more ambiguous that saying either "ENCRYPTION_KEY" or > "INTEGRITY_KEY". Furthermore, I can't find in the definition of the > NAS-Key-Type AVP any requirement (either explicit or implied) that the key > material therein be used w/o modification or any prohibition of the > derivation of other keys from that material. So all I can see the > "MASTER_KEY" type adding is the ability to ship arbitrary stuff labeled > w/the cryptographic equivalent of "whatever". This doesn't seem like a big > plus to me; however, if you insist upon it then I think that the language > around "ENCRYPTION_KEY" and "INTEGRITY_KEY" needs to be tightened up to > state the kind of usage restrictions the Henty seems to have inexplicably > (to me, at least) read into the existing definitions. If we do that, > though, then we should probably add definitions for "MASTER_ENCRYPTION_KEY" > and "MASTER_INTEGRITY_KEY" as well... > > > > > Yoshihiro Ohba > > Thanks for your clarification. I understand from your standpoint (i.e., clear separation of encryption key and integrity key) that adding definitions for "MASTER_ENCRYPTION_KEY" and "MASTER_INTEGRITY_KEY" is natural. Anyway, I think the notion of master key is needed for local re-keying between NAS and user host. Here I have a question. If the same key, which is either directly provided by AAA server or indirectly derived from a master key, is used for both message encryption and message integrity check, which class should those keys be categorised into, encryption or integrity? For example, keys used for 802.11i operating in AES-OCB mode are used for both encryption and integrity check. I think explicit statement would be helpful for how to deal with those two-purpose keys. Fixed categorization of those keys into encryption key (or integrity key) is one possibily. Defining new types such as (MASTER_)ENCRYPTION_AND_INTEGRITY_KEY is another possibility. Yoshihiro Ohba From owner-aaa-wg@merit.edu Thu Oct 4 12:20:58 2001 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 MAA18025 for ; Thu, 4 Oct 2001 12:20:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9085F9123B; Thu, 4 Oct 2001 12:21:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 566399132C; Thu, 4 Oct 2001 12:21: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 E2C169123B for ; Thu, 4 Oct 2001 12:21:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7EC635DDD8; Thu, 4 Oct 2001 12:21:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 7C14B5DDB6 for ; Thu, 4 Oct 2001 12:21:53 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA26461; Thu, 4 Oct 2001 18:18:01 +0200 From: "Fredrik Johansson" To: "Joe Lau" , Cc: , , Subject: RE: [AAA-WG]: Section 8.1 Date: Thu, 4 Oct 2001 18:18:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200110031853.LAA00424@strtio1.cup.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree that the AAAh must be statefull anyway so there is no gain in sending the FA keys to the HA so, the key distribution avps will now look like this? (adding the key lifetime avp as well) MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-FA-to-MN-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-FA-to-HA-Key ::= < AVP Header: 328 > { MIP-FA-to-HA-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-HA-to-FA-Key ::= < AVP Header: 329 > { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-HA-to-MN-Key ::= < AVP Header: 332 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Key-Material } { MIP-Key-Lifetime } { AAA-SPI } <--- spi pointing to mn-aaa sec context * [ AVP ] MIP-MN-to-HA-Key ::= < AVP Header: 331 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Key-Material } { MIP-Key-Lifetime } { AAA-SPI } <--- spi pointing to mn-aaa sec context * [ AVP ] >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Joe Lau >Sent: den 3 oktober 2001 20:54 >To: cchen@erilab.com >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org >Subject: Re: [AAA-WG]: Section 8.1 > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, >why don't we >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the >> MIP-Peer-SPI ? In other words, see below >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > >> { MIP-FA-to-MN-SPI } >> { MIP-Algorithm-Type } >> { MIP-Session-Key } >> * [ AVP ] >> >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > >> { MIP-FA-to-HA-SPI } >> { MIP-Algorithm-Type } >> { MIP-Session-Key } >> * [ AVP ] >> By the way, I don't think we can impletement stateless diameter server by >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be >> returned in the HAA so it can be inserted into the AMA." and so on. >> Because in redirect case, there is no guarantee that whay avps >you send, you >> will see all of them from the redirect answer. So all the >diameter have to >> keep the state. please correct me if I am wrong. > >I agree with Michael that _all_ diameter have to keep state. >Another good example would be the following statement on section 1.2. > > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see figure 2). Of > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > initiated on behalf of a given mobile node's session. > >This will require the AAAH server to be stateful. > >Anyone disagree on this? > >Joe > > >> Joe Lau wrote: >> >> > > The general idea was that the HA modify the SPI value in the >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >> > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft >version 8, alpha. >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this >> > discussion? >> > >> > Joe >> >> --------------E9A36EF30F9B970D0F625B9D >> Content-Type: text/html; charset=us-ascii >> Content-Transfer-Encoding: 7bit >> >> >> >> We have defined MIP-FA-to-HA-SPI  >MIP-FA-to-MN-SPI  two AVPs, >> why don't we put these AVPs in the MIP-FA-to-HA-Key  >MIP-FA-to-MN-Key >> to replace the MIP-Peer-SPI ?    In other words, >see below >>
      MIP-FA-to-MN-Key ::= < >AVP Header: >> 326 > >> >
           >;            >      >> { MIP-FA-to-MN-SPI } >> >
           >;            >      >> { MIP-Algorithm-Type } >> >
           >;            >      >> { MIP-Session-Key } >> >
           >;            >    >> * [ AVP ] >>

      MIP-FA-to-HA-Key ::= < >AVP Header: >> 328 > >> >
           >;            >      >> { MIP-FA-to-HA-SPI } >> >
           >;            >      >> { MIP-Algorithm-Type } >> >
           >;            >      >> { MIP-Session-Key } >> >
           >;            >    >> * [ AVP ] >>
By the way, I don't think we can impletement stateless diameter >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR >> it must be returned in the HAA so it can be inserted into the AMA." and >> so on. >>
Because in redirect case, there is no guarantee that whay avps >> you send, you will see all of them from the redirect answer. So all the >> diameter have to keep the state. please correct me if I am >wrong. >>

-Michael >>
  >>

  >>

Joe Lau wrote: >>

> The general idea was that the HA modify the SPI >> value in the >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, >> alpha. >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing >> in this >>
discussion? >>

Joe

>> >> >> --------------E9A36EF30F9B970D0F625B9D-- >> >> From owner-aaa-wg@merit.edu Thu Oct 4 13:52:07 2001 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 NAA20470 for ; Thu, 4 Oct 2001 13:52:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E400291214; Thu, 4 Oct 2001 13:52:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7BFD91256; Thu, 4 Oct 2001 13:52: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 8920691214 for ; Thu, 4 Oct 2001 13:52:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 194AF5DDDD; Thu, 4 Oct 2001 13:52:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id 8DD9D5DDD4 for ; Thu, 4 Oct 2001 13:52:30 -0400 (EDT) Received: from erilab.com (eblcl57.erilab.com [192.168.174.197]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f94HjhI16182; Thu, 4 Oct 2001 10:45:43 -0700 (PDT) Message-ID: <3BBC978D.115110C2@erilab.com> Date: Thu, 04 Oct 2001 10:08:29 -0700 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Fredrik Johansson Cc: Joe Lau , aaa-wg@merit.edu, meklund@knox6039.cisco.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 References: Content-Type: multipart/alternative; boundary="------------0E2D1B7FFE0B028AC9725E6D" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------0E2D1B7FFE0B028AC9725E6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In aaa-key-08 draft, there is only MN-FA Key Material contain lifetime field so it's not necessary to put key-lifetime in all the key avps. Well, if we do, all the key-lifetime values are same, aren't they? So we only need send this avp to FA and HA. I would suggest add this MIP-Key-Lifetime AVP in HAR and AMA message instead of inlcude it in the group key AVPs. -Michael Fredrik Johansson wrote: > I agree that the AAAh must be statefull anyway so there is no > gain in sending the FA keys to the HA > > so, the key distribution avps will now look like this? > (adding the key lifetime avp as well) > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > { MIP-FA-to-HA-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > { MIP-Algorithm-Type } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } <--- spi pointing to mn-aaa sec context > * [ AVP ] > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } <--- spi pointing to mn-aaa sec context > * [ AVP ] > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Joe Lau > >Sent: den 3 oktober 2001 20:54 > >To: cchen@erilab.com > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > >why don't we > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > >> MIP-Peer-SPI ? In other words, see below > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > >> { MIP-FA-to-MN-SPI } > >> { MIP-Algorithm-Type } > >> { MIP-Session-Key } > >> * [ AVP ] > >> > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > >> { MIP-FA-to-HA-SPI } > >> { MIP-Algorithm-Type } > >> { MIP-Session-Key } > >> * [ AVP ] > >> By the way, I don't think we can impletement stateless diameter server by > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > >> returned in the HAA so it can be inserted into the AMA." and so on. > >> Because in redirect case, there is no guarantee that whay avps > >you send, you > >> will see all of them from the redirect answer. So all the > >diameter have to > >> keep the state. please correct me if I am wrong. > > > >I agree with Michael that _all_ diameter have to keep state. > >Another good example would be the following statement on section 1.2. > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see figure 2). Of > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > initiated on behalf of a given mobile node's session. > > > >This will require the AAAH server to be stateful. > > > >Anyone disagree on this? > > > >Joe > > > > > >> Joe Lau wrote: > >> > >> > > The general idea was that the HA modify the SPI value in the > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > >> > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > >version 8, alpha. > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > >> > discussion? > >> > > >> > Joe > >> > >> --------------E9A36EF30F9B970D0F625B9D > >> Content-Type: text/html; charset=us-ascii > >> Content-Transfer-Encoding: 7bit > >> > >> > >> > >> We have defined MIP-FA-to-HA-SPI  > >MIP-FA-to-MN-SPI  two AVPs, > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > >MIP-FA-to-MN-Key > >> to replace the MIP-Peer-SPI ?    In other words, > >see below > >>
      MIP-FA-to-MN-Key ::= < > >AVP Header: > >> 326 > > >> > >
           > >;            > >      > >> { MIP-FA-to-MN-SPI } > >> > >
           > >;            > >      > >> { MIP-Algorithm-Type } > >> > >
           > >;            > >      > >> { MIP-Session-Key } > >> > >
           > >;            > >    > >> * [ AVP ] > >>

      MIP-FA-to-HA-Key ::= < > >AVP Header: > >> 328 > > >> > >
           > >;            > >      > >> { MIP-FA-to-HA-SPI } > >> > >
           > >;            > >      > >> { MIP-Algorithm-Type } > >> > >
           > >;            > >      > >> { MIP-Session-Key } > >> > >
           > >;            > >    > >> * [ AVP ] > >>
By the way, I don't think we can impletement stateless diameter > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > >> it must be returned in the HAA so it can be inserted into the AMA." and > >> so on. > >>
Because in redirect case, there is no guarantee that whay avps > >> you send, you will see all of them from the redirect answer. So all the > >> diameter have to keep the state. please correct me if I am > >wrong. > >>

-Michael > >>
  > >>

  > >>

Joe Lau wrote: > >>

> The general idea was that the HA modify the SPI > >> value in the > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > >> alpha. > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > >> in this > >>
discussion? > >>

Joe

> >> > >> > >> --------------E9A36EF30F9B970D0F625B9D-- > >> > >> --------------0E2D1B7FFE0B028AC9725E6D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In aaa-key-08 draft, there is only MN-FA Key Material contain lifetime field so it's not necessary to put key-lifetime in all the key avps. Well, if we do, all the key-lifetime values are same, aren't they? So we only need send this avp to FA and HA. I would suggest add this MIP-Key-Lifetime AVP in HAR and AMA message instead of inlcude it in the group key AVPs.

-Michael
 
 

Fredrik Johansson wrote:

I agree that the AAAh must be statefull anyway so there is no
gain in sending the FA keys to the HA

so, the key distribution avps will now look like this?
(adding the key lifetime avp as well)

MIP-FA-to-MN-Key ::= < AVP Header: 326 >
                     { MIP-FA-to-MN-SPI }
                     { MIP-Algorithm-Type }
                     { MIP-Session-Key }
                     { MIP-Key-Lifetime }
                     * [ AVP ]

MIP-FA-to-HA-Key ::= < AVP Header: 328 >
                     { MIP-FA-to-HA-SPI }
                     { MIP-Algorithm-Type }
                     { MIP-Session-Key }
                     { MIP-Key-Lifetime }
                     * [ AVP ]

MIP-HA-to-FA-Key ::= < AVP Header: 329 >
                     { MIP-Algorithm-Type }
                     { MIP-Session-Key }
                     { MIP-Key-Lifetime }
                     * [ AVP ]

MIP-HA-to-MN-Key ::= < AVP Header: 332 >
                     { MIP-Algorithm-Type }
                     { MIP-Replay-Mode }
                     { MIP-Session-Key }
                     { MIP-Key-Lifetime }
                     * [ AVP ]

MIP-MN-to-FA-Key ::= < AVP Header: 325 >
                     { MIP-Algorithm-Type }
                     { MIP-Key-Material }
                     { MIP-Key-Lifetime }
                           { AAA-SPI } <--- spi pointing to mn-aaa sec context
                     * [ AVP ]

MIP-MN-to-HA-Key ::= < AVP Header: 331 >
                     { MIP-Algorithm-Type }
                     { MIP-Replay-Mode }
                     { MIP-Key-Material }
                     { MIP-Key-Lifetime }
                     { AAA-SPI } <--- spi pointing to mn-aaa sec context
                     * [ AVP ]

>-----Original Message-----
>From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of
>Joe Lau
>Sent: den 3 oktober 2001 20:54
>To: cchen@erilab.com
>Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com;
>jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org
>Subject: Re: [AAA-WG]: Section 8.1
>
>
>> We have defined MIP-FA-to-HA-SPI  MIP-FA-to-MN-SPI  two AVPs,
>why don't we
>> put these AVPs in the MIP-FA-to-HA-Key  MIP-FA-to-MN-Key to replace the
>> MIP-Peer-SPI ?    In other words, see below
>>       MIP-FA-to-MN-Key ::= < AVP Header: 326 >
>>                            { MIP-FA-to-MN-SPI }
>>                            { MIP-Algorithm-Type }
>>                            { MIP-Session-Key }
>>                          * [ AVP ]
>>
>>       MIP-FA-to-HA-Key ::= < AVP Header: 328 >
>>                            { MIP-FA-to-HA-SPI }
>>                            { MIP-Algorithm-Type }
>>                            { MIP-Session-Key }
>>                          * [ AVP ]
>> By the way, I don't think we can impletement stateless diameter server by
>> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be
>> returned in the HAA so it can be inserted into the AMA." and so on.
>> Because in redirect case, there is no guarantee that whay avps
>you send, you
>> will see all of them from the redirect answer. So all the
>diameter have to
>> keep the state. please correct me if I am wrong.
>
>I agree with Michael that _all_ diameter have to keep state.
>Another good example would be the following statement on section 1.2.
>
>   During the creation of the HAR, the AAAH MUST use a different session
>   identifier than the one used in the AMR/AMA (see figure 2). Of
>   course, the AAAH MUST use the _same_ session identifier for _all_ HARs
>   initiated on behalf of a given mobile node's session.
>
>This will require the AAAH server to be stateful.
>
>Anyone disagree on this?
>
>Joe
>
>
>> Joe Lau wrote:
>>
>> > > The general idea was that the HA modify the SPI value in the
>> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA.
>> >
>> > But there is no more MIP-FA-to-HA-Key in HAA on the draft
>version 8, alpha.
>> > Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing in this
>> > discussion?
>> >
>> > Joe
>>
>> --------------E9A36EF30F9B970D0F625B9D
>> Content-Type: text/html; charset=us-ascii
>> Content-Transfer-Encoding: 7bit
>>
>> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
>> <html>
>> <tt>We have defined MIP-FA-to-HA-SPI&nbsp;
>MIP-FA-to-MN-SPI&nbsp; two AVPs,
>> why don't we put these AVPs in the MIP-FA-to-HA-Key&nbsp;
>MIP-FA-to-MN-Key
>> to replace the MIP-Peer-SPI ?&nbsp;&nbsp;&nbsp; In other words,
>see below</tt>
>> <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIP-FA-to-MN-Key ::= &lt;
>AVP Header:
>> 326 ></tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>> { MIP-FA-to-MN-SPI }</tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>> { MIP-Algorithm-Type }</tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>> { MIP-Session-Key }</tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;
>> * [ AVP ]</tt><tt></tt>
>> <p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIP-FA-to-HA-Key ::= &lt;
>AVP Header:
>> 328 ></tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>> { MIP-FA-to-HA-SPI }</tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>> { MIP-Algorithm-Type }</tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>> { MIP-Session-Key }</tt>
>>
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;
>> * [ AVP ]</tt>
>> <br><tt>By the way, I don't think we can impletement stateless diameter
>> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR
>> it must be returned in the HAA so it can be inserted into the AMA." and
>> so on.</tt>
>> <br><tt>Because in redirect case, there is no guarantee that whay avps
>> you send, you will see all of them from the redirect answer. So all the
>> diameter have to keep the state. please correct me if I am
>wrong.</tt><tt></tt>
>> <p><tt>-Michael</tt>
>> <br><tt></tt>&nbsp;<tt></tt>
>> <p>&nbsp;
>> <p>Joe Lau wrote:
>> <blockquote TYPE=CITE>> The general idea was that the HA modify the SPI
>> value in the
>> <br>> MIP-FA-to-HA-Key, and return the updated AVP in the HAA.
>> <p>But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8,
>> alpha.
>> <br>Did you mean MIP-FA-to-HA-SPI instead?&nbsp; Or, did I miss somthing
>> in this
>> <br>discussion?
>> <p>Joe</blockquote>
>> </html>
>>
>> --------------E9A36EF30F9B970D0F625B9D--
>>
>>

--------------0E2D1B7FFE0B028AC9725E6D-- From owner-aaa-wg@merit.edu Thu Oct 4 14:07:29 2001 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 OAA20887 for ; Thu, 4 Oct 2001 14:07:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00A0891269; Thu, 4 Oct 2001 14:08:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C29839126E; Thu, 4 Oct 2001 14:08: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 8FC5191269 for ; Thu, 4 Oct 2001 14:08:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3656B5DDD8; Thu, 4 Oct 2001 14:08:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by segue.merit.edu (Postfix) with ESMTP id 7B67C5DDD4 for ; Thu, 4 Oct 2001 14:08:26 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 701937A4; Thu, 4 Oct 2001 11:07:12 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA01689; Thu, 4 Oct 2001 11:08:44 -0700 (PDT) Date: Thu, 4 Oct 2001 11:08:44 -0700 (PDT) From: Joe Lau Message-Id: <200110041808.LAA01689@strtio1.cup.hp.com> To: pcpcalhoun@diameter.org Subject: [AAA-WG]: Re: AAAH must be stateful Cc: aaa-wg@merit.edu, cchen@erilab.com, jlau@cup.hp.com, meklund@knox6039.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > I agree that the AAAh must be statefull anyway so there is no > gain in sending the FA keys to the HA Do you agree that AAAh must be statefull? So far, I have not heard disagreement from anyone. If you agree, can you put in a statement on the draft to make this requrirement clear so that implementors know that they MUST maintain session states on their AAAh server? Thanks! Regards, Joe Lau > so, the key distribution avps will now look like this? > (adding the key lifetime avp as well) > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > { MIP-FA-to-HA-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > { MIP-Algorithm-Type } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } <--- spi pointing to mn-aaa sec context > * [ AVP ] > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } <--- spi pointing to mn-aaa sec context > * [ AVP ] > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Joe Lau > >Sent: den 3 oktober 2001 20:54 > >To: cchen@erilab.com > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > >why don't we > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > >> MIP-Peer-SPI ? In other words, see below > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > >> { MIP-FA-to-MN-SPI } > >> { MIP-Algorithm-Type } > >> { MIP-Session-Key } > >> * [ AVP ] > >> > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > >> { MIP-FA-to-HA-SPI } > >> { MIP-Algorithm-Type } > >> { MIP-Session-Key } > >> * [ AVP ] > >> By the way, I don't think we can impletement stateless diameter server by > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > >> returned in the HAA so it can be inserted into the AMA." and so on. > >> Because in redirect case, there is no guarantee that whay avps > >you send, you > >> will see all of them from the redirect answer. So all the > >diameter have to > >> keep the state. please correct me if I am wrong. > > > >I agree with Michael that _all_ diameter have to keep state. > >Another good example would be the following statement on section 1.2. > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see figure 2). Of > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > initiated on behalf of a given mobile node's session. > > > >This will require the AAAH server to be stateful. > > > >Anyone disagree on this? > > > >Joe > > > > > >> Joe Lau wrote: > >> > >> > > The general idea was that the HA modify the SPI value in the > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > >> > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > >version 8, alpha. > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > >> > discussion? > >> > > >> > Joe > >> > >> --------------E9A36EF30F9B970D0F625B9D > >> Content-Type: text/html; charset=us-ascii > >> Content-Transfer-Encoding: 7bit > >> > >> > >> > >> We have defined MIP-FA-to-HA-SPI  > >MIP-FA-to-MN-SPI  two AVPs, > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > >MIP-FA-to-MN-Key > >> to replace the MIP-Peer-SPI ?    In other words, > >see below > >>
      MIP-FA-to-MN-Key ::= < > >AVP Header: > >> 326 > > >> > >
           > >;            > >      > >> { MIP-FA-to-MN-SPI } > >> > >
           > >;            > >      > >> { MIP-Algorithm-Type } > >> > >
           > >;            > >      > >> { MIP-Session-Key } > >> > >
           > >;            > >    > >> * [ AVP ] > >>

      MIP-FA-to-HA-Key ::= < > >AVP Header: > >> 328 > > >> > >
           > >;            > >      > >> { MIP-FA-to-HA-SPI } > >> > >
           > >;            > >      > >> { MIP-Algorithm-Type } > >> > >
           > >;            > >      > >> { MIP-Session-Key } > >> > >
           > >;            > >    > >> * [ AVP ] > >>
By the way, I don't think we can impletement stateless diameter > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > >> it must be returned in the HAA so it can be inserted into the AMA." and > >> so on. > >>
Because in redirect case, there is no guarantee that whay avps > >> you send, you will see all of them from the redirect answer. So all the > >> diameter have to keep the state. please correct me if I am > >wrong. > >>

-Michael > >>
  > >>

  > >>

Joe Lau wrote: > >>

> The general idea was that the HA modify the SPI > >> value in the > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > >> alpha. > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > >> in this > >>
discussion? > >>

Joe

> >> > >> > >> --------------E9A36EF30F9B970D0F625B9D-- > >> > >> > > From owner-aaa-wg@merit.edu Thu Oct 4 14:10:48 2001 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 OAA20986 for ; Thu, 4 Oct 2001 14:10:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 742249126E; Thu, 4 Oct 2001 14:11:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 440D79132C; Thu, 4 Oct 2001 14:11: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 1B4E39126E for ; Thu, 4 Oct 2001 14:11:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B57565DDD8; Thu, 4 Oct 2001 14:11:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by segue.merit.edu (Postfix) with ESMTP id 59DFF5DDD4 for ; Thu, 4 Oct 2001 14:11:34 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 264FE229; Thu, 4 Oct 2001 11:10:24 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA01727; Thu, 4 Oct 2001 11:11:56 -0700 (PDT) Date: Thu, 4 Oct 2001 11:11:56 -0700 (PDT) From: Joe Lau Message-Id: <200110041811.LAA01727@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: [AAA-WG]: Re: AAAH must be stateful Cc: aaa-wg@merit.edu, cchen@erilab.com, jlau@cup.hp.com, meklund@knox6039.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > I agree that the AAAh must be statefull anyway so there is no > gain in sending the FA keys to the HA Do you agree that AAAh must be statefull? So far, I have not heard disagreement from anyone. If you agree, can you put in a statement on the draft to make this requrirement clear so that implementors know that they MUST maintain session states on their AAAh server? Thanks! Regards, Joe Lau > so, the key distribution avps will now look like this? > (adding the key lifetime avp as well) > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > { MIP-FA-to-HA-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > { MIP-Algorithm-Type } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } <--- spi pointing to mn-aaa sec context > * [ AVP ] > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } <--- spi pointing to mn-aaa sec context > * [ AVP ] > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Joe Lau > >Sent: den 3 oktober 2001 20:54 > >To: cchen@erilab.com > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > >why don't we > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > >> MIP-Peer-SPI ? In other words, see below > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > >> { MIP-FA-to-MN-SPI } > >> { MIP-Algorithm-Type } > >> { MIP-Session-Key } > >> * [ AVP ] > >> > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > >> { MIP-FA-to-HA-SPI } > >> { MIP-Algorithm-Type } > >> { MIP-Session-Key } > >> * [ AVP ] > >> By the way, I don't think we can impletement stateless diameter server by > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > >> returned in the HAA so it can be inserted into the AMA." and so on. > >> Because in redirect case, there is no guarantee that whay avps > >you send, you > >> will see all of them from the redirect answer. So all the > >diameter have to > >> keep the state. please correct me if I am wrong. > > > >I agree with Michael that _all_ diameter have to keep state. > >Another good example would be the following statement on section 1.2. > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see figure 2). Of > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > initiated on behalf of a given mobile node's session. > > > >This will require the AAAH server to be stateful. > > > >Anyone disagree on this? > > > >Joe > > > > > >> Joe Lau wrote: > >> > >> > > The general idea was that the HA modify the SPI value in the > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > >> > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > >version 8, alpha. > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > >> > discussion? > >> > > >> > Joe > >> > >> --------------E9A36EF30F9B970D0F625B9D > >> Content-Type: text/html; charset=us-ascii > >> Content-Transfer-Encoding: 7bit > >> > >> > >> > >> We have defined MIP-FA-to-HA-SPI  > >MIP-FA-to-MN-SPI  two AVPs, > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > >MIP-FA-to-MN-Key > >> to replace the MIP-Peer-SPI ?    In other words, > >see below > >>
      MIP-FA-to-MN-Key ::= < > >AVP Header: > >> 326 > > >> > >
           > >;            > >      > >> { MIP-FA-to-MN-SPI } > >> > >
           > >;            > >      > >> { MIP-Algorithm-Type } > >> > >
           > >;            > >      > >> { MIP-Session-Key } > >> > >
           > >;            > >    > >> * [ AVP ] > >>

      MIP-FA-to-HA-Key ::= < > >AVP Header: > >> 328 > > >> > >
           > >;            > >      > >> { MIP-FA-to-HA-SPI } > >> > >
           > >;            > >      > >> { MIP-Algorithm-Type } > >> > >
           > >;            > >      > >> { MIP-Session-Key } > >> > >
           > >;            > >    > >> * [ AVP ] > >>
By the way, I don't think we can impletement stateless diameter > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > >> it must be returned in the HAA so it can be inserted into the AMA." and > >> so on. > >>
Because in redirect case, there is no guarantee that whay avps > >> you send, you will see all of them from the redirect answer. So all the > >> diameter have to keep the state. please correct me if I am > >wrong. > >>

-Michael > >>
  > >>

  > >>

Joe Lau wrote: > >>

> The general idea was that the HA modify the SPI > >> value in the > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > >> alpha. > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > >> in this > >>
discussion? > >>

Joe

> >> > >> > >> --------------E9A36EF30F9B970D0F625B9D-- > >> From owner-aaa-wg@merit.edu Thu Oct 4 14:17:25 2001 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 OAA21206 for ; Thu, 4 Oct 2001 14:17:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2A019126C; Thu, 4 Oct 2001 14:18:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A5D79132C; Thu, 4 Oct 2001 14:18: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 617A89126C for ; Thu, 4 Oct 2001 14:18:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 046CA5DDD4; Thu, 4 Oct 2001 14:18:06 -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 43A075DDB6 for ; Thu, 4 Oct 2001 14:18:04 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA28636; Thu, 4 Oct 2001 14:09:14 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id OAA01250; Thu, 4 Oct 2001 14:09:53 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15292.42481.15792.242470@gargle.gargle.HOWL> Date: Thu, 4 Oct 2001 14:09:53 -0400 To: Michael Chen Cc: Fredrik Johansson , Joe Lau , aaa-wg@merit.edu, meklund@knox6039.cisco.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 In-Reply-To: <3BBC978D.115110C2@erilab.com> References: <3BBC978D.115110C2@erilab.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael Chen writes: > In aaa-key-08 draft, there is only MN-FA Key Material contain lifetime field so > it's not necessary to put key-lifetime in all the key avps. Well, if we do, all That tricked me also. But I think you have to consider two drafts when deciding what is required. draft-ietf-mobileip-gen-key-01.txt: 5. Generalized MN-HA Key Reply Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-HA Key Reply Subtype Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-mobileip-aaa-key-08.txt: 6. Unsolicited MN-HA Key Material From AAA Subtype The Unsolicited MN-HA Key Material From AAA is subtype 1 of the Generalized MN-HA Key Reply Extension [12]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AAA SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm Identifier | Replay Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Material ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thus the lifetime is required because the Unsolicited MN-HA Key Material in encapsulated in the Generalized MN-HA Key Reply Extension which does require a lifetime. The same goes for the Generalized FA-HA Key Reply Extension. -mark > the key-lifetime values are same, aren't they? So we only need send this avp to FA > and HA. I would suggest add this MIP-Key-Lifetime AVP in HAR and AMA message > instead of inlcude it in the group key AVPs. > > -Michael > > > > Fredrik Johansson wrote: > > > I agree that the AAAh must be statefull anyway so there is no > > gain in sending the FA keys to the HA > > > > so, the key distribution avps will now look like this? > > (adding the key lifetime avp as well) > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > { MIP-FA-to-MN-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > { MIP-FA-to-HA-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > { MIP-Algorithm-Type } > > { MIP-Key-Material } > > { MIP-Key-Lifetime } > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > * [ AVP ] > > > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Key-Material } > > { MIP-Key-Lifetime } > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > * [ AVP ] > > > > >-----Original Message----- > > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > >Joe Lau > > >Sent: den 3 oktober 2001 20:54 > > >To: cchen@erilab.com > > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > > >why don't we > > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > > >> MIP-Peer-SPI ? In other words, see below > > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > >> { MIP-FA-to-MN-SPI } > > >> { MIP-Algorithm-Type } > > >> { MIP-Session-Key } > > >> * [ AVP ] > > >> > > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > >> { MIP-FA-to-HA-SPI } > > >> { MIP-Algorithm-Type } > > >> { MIP-Session-Key } > > >> * [ AVP ] > > >> By the way, I don't think we can impletement stateless diameter server by > > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > > >> returned in the HAA so it can be inserted into the AMA." and so on. > > >> Because in redirect case, there is no guarantee that whay avps > > >you send, you > > >> will see all of them from the redirect answer. So all the > > >diameter have to > > >> keep the state. please correct me if I am wrong. > > > > > >I agree with Michael that _all_ diameter have to keep state. > > >Another good example would be the following statement on section 1.2. > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > > > > >This will require the AAAH server to be stateful. > > > > > >Anyone disagree on this? > > > > > >Joe > > > > > > > > >> Joe Lau wrote: > > >> > > >> > > The general idea was that the HA modify the SPI value in the > > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > >> > > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > > >version 8, alpha. > > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > > >> > discussion? > > >> > > > >> > Joe > > >> > > >> --------------E9A36EF30F9B970D0F625B9D > > >> Content-Type: text/html; charset=us-ascii > > >> Content-Transfer-Encoding: 7bit > > >> > > >> > > >> > > >> We have defined MIP-FA-to-HA-SPI  > > >MIP-FA-to-MN-SPI  two AVPs, > > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > > >MIP-FA-to-MN-Key > > >> to replace the MIP-Peer-SPI ?    In other words, > > >see below > > >>
      MIP-FA-to-MN-Key ::= < > > >AVP Header: > > >> 326 > > > >> > > >
           > > >;            > > >      > > >> { MIP-FA-to-MN-SPI } > > >> > > >
           > > >;            > > >      > > >> { MIP-Algorithm-Type } > > >> > > >
           > > >;            > > >      > > >> { MIP-Session-Key } > > >> > > >
           > > >;            > > >    > > >> * [ AVP ] > > >>

      MIP-FA-to-HA-Key ::= < > > >AVP Header: > > >> 328 > > > >> > > >
           > > >;            > > >      > > >> { MIP-FA-to-HA-SPI } > > >> > > >
           > > >;            > > >      > > >> { MIP-Algorithm-Type } > > >> > > >
           > > >;            > > >      > > >> { MIP-Session-Key } > > >> > > >
           > > >;            > > >    > > >> * [ AVP ] > > >>
By the way, I don't think we can impletement stateless diameter > > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > > >> it must be returned in the HAA so it can be inserted into the AMA." and > > >> so on. > > >>
Because in redirect case, there is no guarantee that whay avps > > >> you send, you will see all of them from the redirect answer. So all the > > >> diameter have to keep the state. please correct me if I am > > >wrong. > > >>

-Michael > > >>
  > > >>

  > > >>

Joe Lau wrote: > > >>

> The general idea was that the HA modify the SPI > > >> value in the > > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > > >> alpha. > > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > > >> in this > > >>
discussion? > > >>

Joe

> > >> > > >> > > >> --------------E9A36EF30F9B970D0F625B9D-- > > >> > > >> > > > In aaa-key-08 draft, there is only MN-FA Key Material contain lifetime > field so it's not necessary to put key-lifetime in all the key avps. Well, > if we do, all the key-lifetime values are same, aren't they? So we only > need send this avp to FA and HA. I would suggest add this MIP-Key-Lifetime > AVP in HAR and AMA message instead of inlcude it in the group key AVPs. >

-Michael >
  >
  >

Fredrik Johansson wrote: >

I agree that the AAAh must be statefull anyway so > there is no >
gain in sending the FA keys to the HA >

so, the key distribution avps will now look like this? >
(adding the key lifetime avp as well) >

MIP-FA-to-MN-Key ::= < AVP Header: 326 > >
                     > { MIP-FA-to-MN-SPI } >
                     > { MIP-Algorithm-Type } >
                     > { MIP-Session-Key } >
                     > { MIP-Key-Lifetime } >
                     > * [ AVP ] >

MIP-FA-to-HA-Key ::= < AVP Header: 328 > >
                     > { MIP-FA-to-HA-SPI } >
                     > { MIP-Algorithm-Type } >
                     > { MIP-Session-Key } >
                     > { MIP-Key-Lifetime } >
                     > * [ AVP ] >

MIP-HA-to-FA-Key ::= < AVP Header: 329 > >
                     > { MIP-Algorithm-Type } >
                     > { MIP-Session-Key } >
                     > { MIP-Key-Lifetime } >
                     > * [ AVP ] >

MIP-HA-to-MN-Key ::= < AVP Header: 332 > >
                     > { MIP-Algorithm-Type } >
                     > { MIP-Replay-Mode } >
                     > { MIP-Session-Key } >
                     > { MIP-Key-Lifetime } >
                     > * [ AVP ] >

MIP-MN-to-FA-Key ::= < AVP Header: 325 > >
                     > { MIP-Algorithm-Type } >
                     > { MIP-Key-Material } >
                     > { MIP-Key-Lifetime } >
                           > { AAA-SPI } <--- spi pointing to mn-aaa sec context >
                     > * [ AVP ] >

MIP-MN-to-HA-Key ::= < AVP Header: 331 > >
                     > { MIP-Algorithm-Type } >
                     > { MIP-Replay-Mode } >
                     > { MIP-Key-Material } >
                     > { MIP-Key-Lifetime } >
                     > { AAA-SPI } <--- spi pointing to mn-aaa sec context >
                     > * [ AVP ] >

>-----Original Message----- >
>From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On > Behalf Of >
>Joe Lau >
>Sent: den 3 oktober 2001 20:54 >
>To: cchen@erilab.com >
>Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; >
>jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org >
>Subject: Re: [AAA-WG]: Section 8.1 >
> >
> >
>> We have defined MIP-FA-to-HA-SPI  MIP-FA-to-MN-SPI  two > AVPs, >
>why don't we >
>> put these AVPs in the MIP-FA-to-HA-Key  MIP-FA-to-MN-Key to > replace the >
>> MIP-Peer-SPI ?    In other words, see below >
>>       MIP-FA-to-MN-Key ::= < AVP > Header: 326 > >
>>                            > { MIP-FA-to-MN-SPI } >
>>                            > { MIP-Algorithm-Type } >
>>                            > { MIP-Session-Key } >
>>                          > * [ AVP ] >
>> >
>>       MIP-FA-to-HA-Key ::= < AVP > Header: 328 > >
>>                            > { MIP-FA-to-HA-SPI } >
>>                            > { MIP-Algorithm-Type } >
>>                            > { MIP-Session-Key } >
>>                          > * [ AVP ] >
>> By the way, I don't think we can impletement stateless diameter > server by >
>> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it > must be >
>> returned in the HAA so it can be inserted into the AMA." and so > on. >
>> Because in redirect case, there is no guarantee that whay avps >
>you send, you >
>> will see all of them from the redirect answer. So all the >
>diameter have to >
>> keep the state. please correct me if I am wrong. >
> >
>I agree with Michael that _all_ diameter have to keep state. >
>Another good example would be the following statement on section 1.2. >
> >
>   During the creation of the HAR, the AAAH MUST use a different > session >
>   identifier than the one used in the AMR/AMA (see figure > 2). Of >
>   course, the AAAH MUST use the _same_ session identifier > for _all_ HARs >
>   initiated on behalf of a given mobile node's session. >
> >
>This will require the AAAH server to be stateful. >
> >
>Anyone disagree on this? >
> >
>Joe >
> >
> >
>> Joe Lau wrote: >
>> >
>> > > The general idea was that the HA modify the SPI value in the >
>> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >
>> > >
>> > But there is no more MIP-FA-to-HA-Key in HAA on the draft >
>version 8, alpha. >
>> > Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > in this >
>> > discussion? >
>> > >
>> > Joe >
>> >
>> --------------E9A36EF30F9B970D0F625B9D >
>> Content-Type: text/html; charset=us-ascii >
>> Content-Transfer-Encoding: 7bit >
>> >
>> <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> >
>> <html> >
>> <tt>We have defined MIP-FA-to-HA-SPI&nbsp; >
>MIP-FA-to-MN-SPI&nbsp; two AVPs, >
>> why don't we put these AVPs in the MIP-FA-to-HA-Key&nbsp; >
>MIP-FA-to-MN-Key >
>> to replace the MIP-Peer-SPI ?&nbsp;&nbsp;&nbsp; In other > words, >
>see below</tt> >
>> <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > MIP-FA-to-MN-Key ::= &lt; >
>AVP Header: >
>> 326 ></tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>> { MIP-FA-to-MN-SPI }</tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>> { MIP-Algorithm-Type }</tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>> { MIP-Session-Key }</tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp; >
>> * [ AVP ]</tt><tt></tt> >
>> <p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > MIP-FA-to-HA-Key ::= &lt; >
>AVP Header: >
>> 328 ></tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>> { MIP-FA-to-HA-SPI }</tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>> { MIP-Algorithm-Type }</tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>> { MIP-Session-Key }</tt> >
>> >
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp >
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; >
>&nbsp;&nbsp;&nbsp; >
>> * [ AVP ]</tt> >
>> <br><tt>By the way, I don't think we can impletement stateless > diameter >
>> server by requesting for example "If the MIP-FA-to-HA-Key is in > the HAR >
>> it must be returned in the HAA so it can be inserted into the AMA." > and >
>> so on.</tt> >
>> <br><tt>Because in redirect case, there is no guarantee that > whay avps >
>> you send, you will see all of them from the redirect answer. So > all the >
>> diameter have to keep the state. please correct me if I am >
>wrong.</tt><tt></tt> >
>> <p><tt>-Michael</tt> >
>> <br><tt></tt>&nbsp;<tt></tt> >
>> <p>&nbsp; >
>> <p>Joe Lau wrote: >
>> <blockquote TYPE=CITE>> The general idea was that the HA modify > the SPI >
>> value in the >
>> <br>> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >
>> <p>But there is no more MIP-FA-to-HA-Key in HAA on the draft > version 8, >
>> alpha. >
>> <br>Did you mean MIP-FA-to-HA-SPI instead?&nbsp; Or, did > I miss somthing >
>> in this >
>> <br>discussion? >
>> <p>Joe</blockquote> >
>> </html> >
>> >
>> --------------E9A36EF30F9B970D0F625B9D-- >
>> >
>>

> From owner-aaa-wg@merit.edu Thu Oct 4 14:37:20 2001 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 OAA21861 for ; Thu, 4 Oct 2001 14:37:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C69F39121D; Thu, 4 Oct 2001 14:38:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 928D79132D; Thu, 4 Oct 2001 14:38:17 -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 65A819121D for ; Thu, 4 Oct 2001 14:38:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B6755DDE2; Thu, 4 Oct 2001 14:38:16 -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 4BF075DDB6 for ; Thu, 4 Oct 2001 14:38:15 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA29562; Thu, 4 Oct 2001 14:36:19 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id OAA01263; Thu, 4 Oct 2001 14:36:57 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15292.44105.745855.945470@gargle.gargle.HOWL> Date: Thu, 4 Oct 2001 14:36:57 -0400 To: Joe Lau Cc: pcpcalhoun@diameter.org, aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com Subject: Re: [AAA-WG]: Re: AAAH must be stateful In-Reply-To: <200110041808.LAA01689@strtio1.cup.hp.com> References: <200110041808.LAA01689@strtio1.cup.hp.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joe Lau writes: > Pat, > > > I agree that the AAAh must be statefull anyway so there is no > > gain in sending the FA keys to the HA > > Do you agree that AAAh must be statefull? So far, I have not > heard disagreement from anyone. If you agree, can you put in a > statement on the draft to make this requrirement clear so that > implementors know that they MUST maintain session states on their > AAAh server? I'm trying to think of when you must keep state. 1. To know which AMR to send when you receive a HAA. The base spec says, "A stateless agent is one that only maintains transaction state.". I would consider this transaction state (including the keys sent in the HAR), so this does not make the server stateful. 2. You receive an AMR for a session that you have already authenticated. Thus you must remember the previous Session-Id for the communication with the HAA. This would make you have to be stateful. But... If you send the Session-Id back in a Class attribute, you don't have to maintain state. Are there any reasons a server MUST maintain state? -mark > > Thanks! > > Regards, > > Joe Lau > > > so, the key distribution avps will now look like this? > > (adding the key lifetime avp as well) > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > { MIP-FA-to-MN-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > { MIP-FA-to-HA-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > { MIP-Algorithm-Type } > > { MIP-Key-Material } > > { MIP-Key-Lifetime } > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > * [ AVP ] > > > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Key-Material } > > { MIP-Key-Lifetime } > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > * [ AVP ] > > > > >-----Original Message----- > > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > >Joe Lau > > >Sent: den 3 oktober 2001 20:54 > > >To: cchen@erilab.com > > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > > >why don't we > > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > > >> MIP-Peer-SPI ? In other words, see below > > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > >> { MIP-FA-to-MN-SPI } > > >> { MIP-Algorithm-Type } > > >> { MIP-Session-Key } > > >> * [ AVP ] > > >> > > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > >> { MIP-FA-to-HA-SPI } > > >> { MIP-Algorithm-Type } > > >> { MIP-Session-Key } > > >> * [ AVP ] > > >> By the way, I don't think we can impletement stateless diameter server by > > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > > >> returned in the HAA so it can be inserted into the AMA." and so on. > > >> Because in redirect case, there is no guarantee that whay avps > > >you send, you > > >> will see all of them from the redirect answer. So all the > > >diameter have to > > >> keep the state. please correct me if I am wrong. > > > > > >I agree with Michael that _all_ diameter have to keep state. > > >Another good example would be the following statement on section 1.2. > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > > > > >This will require the AAAH server to be stateful. > > > > > >Anyone disagree on this? > > > > > >Joe > > > > > > > > >> Joe Lau wrote: > > >> > > >> > > The general idea was that the HA modify the SPI value in the > > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > >> > > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > > >version 8, alpha. > > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > > >> > discussion? > > >> > > > >> > Joe > > >> > > >> --------------E9A36EF30F9B970D0F625B9D > > >> Content-Type: text/html; charset=us-ascii > > >> Content-Transfer-Encoding: 7bit > > >> > > >> > > >> > > >> We have defined MIP-FA-to-HA-SPI  > > >MIP-FA-to-MN-SPI  two AVPs, > > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > > >MIP-FA-to-MN-Key > > >> to replace the MIP-Peer-SPI ?    In other words, > > >see below > > >>
      MIP-FA-to-MN-Key ::= < > > >AVP Header: > > >> 326 > > > >> > > >
           > > >;            > > >      > > >> { MIP-FA-to-MN-SPI } > > >> > > >
           > > >;            > > >      > > >> { MIP-Algorithm-Type } > > >> > > >
           > > >;            > > >      > > >> { MIP-Session-Key } > > >> > > >
           > > >;            > > >    > > >> * [ AVP ] > > >>

      MIP-FA-to-HA-Key ::= < > > >AVP Header: > > >> 328 > > > >> > > >
           > > >;            > > >      > > >> { MIP-FA-to-HA-SPI } > > >> > > >
           > > >;            > > >      > > >> { MIP-Algorithm-Type } > > >> > > >
           > > >;            > > >      > > >> { MIP-Session-Key } > > >> > > >
           > > >;            > > >    > > >> * [ AVP ] > > >>
By the way, I don't think we can impletement stateless diameter > > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > > >> it must be returned in the HAA so it can be inserted into the AMA." and > > >> so on. > > >>
Because in redirect case, there is no guarantee that whay avps > > >> you send, you will see all of them from the redirect answer. So all the > > >> diameter have to keep the state. please correct me if I am > > >wrong. > > >>

-Michael > > >>
  > > >>

  > > >>

Joe Lau wrote: > > >>

> The general idea was that the HA modify the SPI > > >> value in the > > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > > >> alpha. > > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > > >> in this > > >>
discussion? > > >>

Joe

> > >> > > >> > > >> --------------E9A36EF30F9B970D0F625B9D-- > > >> > > >> > > > > From owner-aaa-wg@merit.edu Thu Oct 4 14:56:48 2001 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 OAA22373 for ; Thu, 4 Oct 2001 14:56:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C7EC91330; Thu, 4 Oct 2001 14:57:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5C6991331; Thu, 4 Oct 2001 14:57: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 AFEFA91330 for ; Thu, 4 Oct 2001 14:57:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 569AC5DDD4; Thu, 4 Oct 2001 14:57:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 0B7145DDB6 for ; Thu, 4 Oct 2001 14:57:33 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id EED8A1F751; Thu, 4 Oct 2001 11:56:21 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA01837; Thu, 4 Oct 2001 11:57:54 -0700 (PDT) Date: Thu, 4 Oct 2001 11:57:54 -0700 (PDT) From: Joe Lau Message-Id: <200110041857.LAA01837@strtio1.cup.hp.com> To: meklund@cisco.com Subject: Re: [AAA-WG]: Re: AAAH must be stateful Cc: aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com, pcpcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, > Are there any reasons a server MUST maintain state? What about this one (as stated on draft 8, alpha)? During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see figure 2). Of course, the AAAH MUST use the _same_ session identifier for _all_ HARs initiated on behalf of a given mobile node's session. Joe Lau > -mark > > > > > Thanks! > > > > Regards, > > > > Joe Lau > > > > > so, the key distribution avps will now look like this? > > > (adding the key lifetime avp as well) > > > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > { MIP-FA-to-MN-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > { MIP-Key-Lifetime } > > > * [ AVP ] > > > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > > { MIP-FA-to-HA-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > { MIP-Key-Lifetime } > > > * [ AVP ] > > > > > > > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > { MIP-Key-Lifetime } > > > * [ AVP ] > > > > > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } > > > { MIP-Session-Key } > > > { MIP-Key-Lifetime } > > > * [ AVP ] > > > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > > { MIP-Algorithm-Type } > > > { MIP-Key-Material } > > > { MIP-Key-Lifetime } > > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > > * [ AVP ] > > > > > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } > > > { MIP-Key-Material } > > > { MIP-Key-Lifetime } > > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > > * [ AVP ] > > > > > > >-----Original Message----- > > > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > >Joe Lau > > > >Sent: den 3 oktober 2001 20:54 > > > >To: cchen@erilab.com > > > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > > > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > > > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > > > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > > > >why don't we > > > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > > > >> MIP-Peer-SPI ? In other words, see below > > > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > >> { MIP-FA-to-MN-SPI } > > > >> { MIP-Algorithm-Type } > > > >> { MIP-Session-Key } > > > >> * [ AVP ] > > > >> > > > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > > >> { MIP-FA-to-HA-SPI } > > > >> { MIP-Algorithm-Type } > > > >> { MIP-Session-Key } > > > >> * [ AVP ] > > > >> By the way, I don't think we can impletement stateless diameter server by > > > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > > > >> returned in the HAA so it can be inserted into the AMA." and so on. > > > >> Because in redirect case, there is no guarantee that whay avps > > > >you send, you > > > >> will see all of them from the redirect answer. So all the > > > >diameter have to > > > >> keep the state. please correct me if I am wrong. > > > > > > > >I agree with Michael that _all_ diameter have to keep state. > > > >Another good example would be the following statement on section 1.2. > > > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > > initiated on behalf of a given mobile node's session. > > > > > > > >This will require the AAAH server to be stateful. > > > > > > > >Anyone disagree on this? > > > > > > > >Joe > > > > > > > > > > > >> Joe Lau wrote: > > > >> > > > >> > > The general idea was that the HA modify the SPI value in the > > > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > >> > > > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > > > >version 8, alpha. > > > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > > > >> > discussion? > > > >> > > > > >> > Joe > > > >> > > > >> --------------E9A36EF30F9B970D0F625B9D > > > >> Content-Type: text/html; charset=us-ascii > > > >> Content-Transfer-Encoding: 7bit > > > >> > > > >> > > > >> > > > >> We have defined MIP-FA-to-HA-SPI  > > > >MIP-FA-to-MN-SPI  two AVPs, > > > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > > > >MIP-FA-to-MN-Key > > > >> to replace the MIP-Peer-SPI ?    In other words, > > > >see below > > > >>
      MIP-FA-to-MN-Key ::= < > > > >AVP Header: > > > >> 326 > > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-FA-to-MN-SPI } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Algorithm-Type } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Session-Key } > > > >> > > > >
           > > > >;            > > > >    > > > >> * [ AVP ] > > > >>

      MIP-FA-to-HA-Key ::= < > > > >AVP Header: > > > >> 328 > > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-FA-to-HA-SPI } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Algorithm-Type } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Session-Key } > > > >> > > > >
           > > > >;            > > > >    > > > >> * [ AVP ] > > > >>
By the way, I don't think we can impletement stateless diameter > > > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > > > >> it must be returned in the HAA so it can be inserted into the AMA." and > > > >> so on. > > > >>
Because in redirect case, there is no guarantee that whay avps > > > >> you send, you will see all of them from the redirect answer. So all the > > > >> diameter have to keep the state. please correct me if I am > > > >wrong. > > > >>

-Michael > > > >>
  > > > >>

  > > > >>

Joe Lau wrote: > > > >>

> The general idea was that the HA modify the SPI > > > >> value in the > > > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > > > >> alpha. > > > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > > > >> in this > > > >>
discussion? > > > >>

Joe

> > > >> > > > >> > > > >> --------------E9A36EF30F9B970D0F625B9D-- > > > >> > > > >> > > > > > > > From owner-aaa-wg@merit.edu Thu Oct 4 15:06:07 2001 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 PAA22638 for ; Thu, 4 Oct 2001 15:06:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 115159133D; Thu, 4 Oct 2001 15:06:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8BA291343; Thu, 4 Oct 2001 15:06: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 BEE0B9133D for ; Thu, 4 Oct 2001 15:06:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 653305DDD4; Thu, 4 Oct 2001 15:06:21 -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 A0B385DDB6 for ; Thu, 4 Oct 2001 15:06:20 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA00296; Thu, 4 Oct 2001 15:04:44 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA01303; Thu, 4 Oct 2001 15:05:09 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15292.45797.277816.854726@gargle.gargle.HOWL> Date: Thu, 4 Oct 2001 15:05:09 -0400 To: Joe Lau Cc: meklund@cisco.com, aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com, pcpcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: AAAH must be stateful In-Reply-To: <200110041857.LAA01837@strtio1.cup.hp.com> References: <200110041857.LAA01837@strtio1.cup.hp.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joe Lau writes: > Mark, > > > Are there any reasons a server MUST maintain state? > > What about this one (as stated on draft 8, alpha)? > > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see figure 2). Of > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > initiated on behalf of a given mobile node's session. If you send back the Session identifier that you created for the HAR as a class attribute in the AMA, the FA MUST return it in subsequent authentications. Thus you can extract it for the next amr and use it. I'm not saying this is a good method, just that it is a possible way of avoiding a stateful server. -mark > > Joe Lau > > > -mark > > > > > > > > Thanks! > > > > > > Regards, > > > > > > Joe Lau > > > > > > > so, the key distribution avps will now look like this? > > > > (adding the key lifetime avp as well) > > > > > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > > { MIP-FA-to-MN-SPI } > > > > { MIP-Algorithm-Type } > > > > { MIP-Session-Key } > > > > { MIP-Key-Lifetime } > > > > * [ AVP ] > > > > > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > > > { MIP-FA-to-HA-SPI } > > > > { MIP-Algorithm-Type } > > > > { MIP-Session-Key } > > > > { MIP-Key-Lifetime } > > > > * [ AVP ] > > > > > > > > > > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > > > { MIP-Algorithm-Type } > > > > { MIP-Session-Key } > > > > { MIP-Key-Lifetime } > > > > * [ AVP ] > > > > > > > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > > > { MIP-Algorithm-Type } > > > > { MIP-Replay-Mode } > > > > { MIP-Session-Key } > > > > { MIP-Key-Lifetime } > > > > * [ AVP ] > > > > > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > > > { MIP-Algorithm-Type } > > > > { MIP-Key-Material } > > > > { MIP-Key-Lifetime } > > > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > > > * [ AVP ] > > > > > > > > MIP-MN-to-HA-Key ::= < AVP Header: 331 > > > > > { MIP-Algorithm-Type } > > > > { MIP-Replay-Mode } > > > > { MIP-Key-Material } > > > > { MIP-Key-Lifetime } > > > > { AAA-SPI } <--- spi pointing to mn-aaa sec context > > > > * [ AVP ] > > > > > > > > >-----Original Message----- > > > > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > > > >Joe Lau > > > > >Sent: den 3 oktober 2001 20:54 > > > > >To: cchen@erilab.com > > > > >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; > > > > >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org > > > > >Subject: Re: [AAA-WG]: Section 8.1 > > > > > > > > > > > > > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, > > > > >why don't we > > > > >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the > > > > >> MIP-Peer-SPI ? In other words, see below > > > > >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > > >> { MIP-FA-to-MN-SPI } > > > > >> { MIP-Algorithm-Type } > > > > >> { MIP-Session-Key } > > > > >> * [ AVP ] > > > > >> > > > > >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > > > >> { MIP-FA-to-HA-SPI } > > > > >> { MIP-Algorithm-Type } > > > > >> { MIP-Session-Key } > > > > >> * [ AVP ] > > > > >> By the way, I don't think we can impletement stateless diameter server by > > > > >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be > > > > >> returned in the HAA so it can be inserted into the AMA." and so on. > > > > >> Because in redirect case, there is no guarantee that whay avps > > > > >you send, you > > > > >> will see all of them from the redirect answer. So all the > > > > >diameter have to > > > > >> keep the state. please correct me if I am wrong. > > > > > > > > > >I agree with Michael that _all_ diameter have to keep state. > > > > >Another good example would be the following statement on section 1.2. > > > > > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > > > initiated on behalf of a given mobile node's session. > > > > > > > > > >This will require the AAAH server to be stateful. > > > > > > > > > >Anyone disagree on this? > > > > > > > > > >Joe > > > > > > > > > > > > > > >> Joe Lau wrote: > > > > >> > > > > >> > > The general idea was that the HA modify the SPI value in the > > > > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > > >> > > > > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > > > > >version 8, alpha. > > > > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > > > > >> > discussion? > > > > >> > > > > > >> > Joe > > > > >> > > > > >> --------------E9A36EF30F9B970D0F625B9D > > > > >> Content-Type: text/html; charset=us-ascii > > > > >> Content-Transfer-Encoding: 7bit > > > > >> > > > > >> > > > > >> > > > > >> We have defined MIP-FA-to-HA-SPI  > > > > >MIP-FA-to-MN-SPI  two AVPs, > > > > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > > > > >MIP-FA-to-MN-Key > > > > >> to replace the MIP-Peer-SPI ?    In other words, > > > > >see below > > > > >>
      MIP-FA-to-MN-Key ::= < > > > > >AVP Header: > > > > >> 326 > > > > > >> > > > > >
           > > > > >;            > > > > >      > > > > >> { MIP-FA-to-MN-SPI } > > > > >> > > > > >
           > > > > >;            > > > > >      > > > > >> { MIP-Algorithm-Type } > > > > >> > > > > >
           > > > > >;            > > > > >      > > > > >> { MIP-Session-Key } > > > > >> > > > > >
           > > > > >;            > > > > >    > > > > >> * [ AVP ] > > > > >>

      MIP-FA-to-HA-Key ::= < > > > > >AVP Header: > > > > >> 328 > > > > > >> > > > > >
           > > > > >;            > > > > >      > > > > >> { MIP-FA-to-HA-SPI } > > > > >> > > > > >
           > > > > >;            > > > > >      > > > > >> { MIP-Algorithm-Type } > > > > >> > > > > >
           > > > > >;            > > > > >      > > > > >> { MIP-Session-Key } > > > > >> > > > > >
           > > > > >;            > > > > >    > > > > >> * [ AVP ] > > > > >>
By the way, I don't think we can impletement stateless diameter > > > > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > > > > >> it must be returned in the HAA so it can be inserted into the AMA." and > > > > >> so on. > > > > >>
Because in redirect case, there is no guarantee that whay avps > > > > >> you send, you will see all of them from the redirect answer. So all the > > > > >> diameter have to keep the state. please correct me if I am > > > > >wrong. > > > > >>

-Michael > > > > >>
  > > > > >>

  > > > > >>

Joe Lau wrote: > > > > >>

> The general idea was that the HA modify the SPI > > > > >> value in the > > > > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > > > > >> alpha. > > > > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > > > > >> in this > > > > >>
discussion? > > > > >>

Joe

> > > > >> > > > > >> > > > > >> --------------E9A36EF30F9B970D0F625B9D-- > > > > >> > > > > >> > > > > > > > > > > From owner-aaa-wg@merit.edu Thu Oct 4 15:40:03 2001 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 PAA23720 for ; Thu, 4 Oct 2001 15:40:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2640491334; Thu, 4 Oct 2001 15:40:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E39C391335; Thu, 4 Oct 2001 15:40: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 BD87991334 for ; Thu, 4 Oct 2001 15:40:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56DF35DDD4; Thu, 4 Oct 2001 15:40:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 4360D5DDB6 for ; Thu, 4 Oct 2001 15:40:51 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 254F87B; Thu, 4 Oct 2001 15:39:46 -0400 (EDT) From: "Bob Kopacz" To: "Joe Lau" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: AAAH must be stateful Date: Thu, 4 Oct 2001 15:37:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200110041927.MAA01964@strtio1.cup.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Joe Lau > Sent: Thursday, October 04, 2001 3:28 PM > To: meklund@cisco.com > Cc: aaa-wg@merit.edu; cchen@erilab.com; meklund@knox6039.cisco.com; > pcalhoun@diameter.org > Subject: Re: [AAA-WG]: Re: AAAH must be stateful > > I am very interested on learning how to achieve this w/o requiring the > AAAh to maintain session states because I am facing such a problem right > now. Can you give more details on how you can achieve your last statement? > > "Thus you can extract it for the next amr and use it." > > > Please use the following example. > > AMR(session_id_1) -------------------+ > | > +------------> AAAh (stateless) > | | | > AMR(session_id_2) -------------------+ | | > | | > HAR(sid_3)| | HAR(sid_4) > | | > v v > Home Agent > > The two AMR's came from different FA's, so session_id_1 != session_id_2 > But the draft says sid_3 must equal sid_4 on the HAR's. It seems like the HA must be able to deal with receiving different session-id's for the same session anyway, since the AMRs may go to different AAAH's. (Section 1.3 "Support for Mobile-IP Handoffs" says that "it is quite likely the AMR for a handoff will be received by a different AAAH".) > > Thank you. > > Joe Lau > From owner-aaa-wg@merit.edu Thu Oct 4 15:43:55 2001 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 PAA23814 for ; Thu, 4 Oct 2001 15:43:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B322491332; Thu, 4 Oct 2001 15:27:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A4CD91333; Thu, 4 Oct 2001 15:27:37 -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 5228C91332 for ; Thu, 4 Oct 2001 15:27:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6BFE5DDD4; Thu, 4 Oct 2001 15:27:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id A412C5DDB6 for ; Thu, 4 Oct 2001 15:27:35 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id 0A6911F63E; Thu, 4 Oct 2001 12:26:25 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA01964; Thu, 4 Oct 2001 12:27:57 -0700 (PDT) Date: Thu, 4 Oct 2001 12:27:57 -0700 (PDT) From: Joe Lau Message-Id: <200110041927.MAA01964@strtio1.cup.hp.com> To: meklund@cisco.com Subject: Re: [AAA-WG]: Re: AAAH must be stateful Cc: aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com, pcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, > > > Are there any reasons a server MUST maintain state? > > > > What about this one (as stated on draft 8, alpha)? > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see figure 2). Of > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > initiated on behalf of a given mobile node's session. > > If you send back the Session identifier that you created for the HAR > as a class attribute in the AMA, the FA MUST return it in subsequent > authentications. Thus you can extract it for the next amr and use it. I am very interested on learning how to achieve this w/o requiring the AAAh to maintain session states because I am facing such a problem right now. Can you give more details on how you can achieve your last statement? "Thus you can extract it for the next amr and use it." Please use the following example. AMR(session_id_1) -------------------+ | +------------> AAAh (stateless) | | | AMR(session_id_2) -------------------+ | | | | HAR(sid_3)| | HAR(sid_4) | | v v Home Agent The two AMR's came from different FA's, so session_id_1 != session_id_2 But the draft says sid_3 must equal sid_4 on the HAR's. Thank you. Joe Lau From owner-aaa-wg@merit.edu Thu Oct 4 15:48:20 2001 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 PAA23873 for ; Thu, 4 Oct 2001 15:48:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECD4C91335; Thu, 4 Oct 2001 15:49:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B826991336; Thu, 4 Oct 2001 15:49:09 -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 8FF8C91335 for ; Thu, 4 Oct 2001 15:49:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34B595DDD4; Thu, 4 Oct 2001 15:49:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id A68595DDB6 for ; Thu, 4 Oct 2001 15:49:07 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA29214 for ; Thu, 4 Oct 2001 12:47:57 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA10329 for ; Thu, 4 Oct 2001 12:47:51 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 4 Oct 2001 14:47:50 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Fredrik Johansson'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: General question on MIP and AAA interaction Date: Thu, 4 Oct 2001 14:47:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks Fredrik. I'll need a little more help though... :) So what you are saying is that the MN should have two "registration lifetime" timers running. One with AAAH (aaa-lifetime) and one with HA (mip-lifetime). They start off with the same value at the same time but then they diverge (both in value and expiration times). I understand why aaa-lifetime makes sense to be greater than mip-lifetime, but why multiple? Even if aaa-lifetime is a multiple of mip-lifetime, you still can not guarantee that aaa-lifetime will expire at the same time that mip-lifetime does. The reason is because mip-lifetime is refreshed not only upon its expiration but also upon handoff times, which are stochastic. So after a while these two timers will run independent of each other. The MN would have to re-register: (1) upon aaa-lifetime expiration (with AAAH) (2) upon mip-lifetime expiration (with HA) (3) upon handoff, (with HA) Is that what you have in mind? Thanks again! -Panos -----Original Message----- From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] Sent: Thursday, October 04, 2001 2:48 AM To: Thomas Panagiotis-PTHOMAS1; aaa-wg@merit.edu Subject: RE: [AAA-WG]: General question on MIP and AAA interaction > >Hi, > >As noted in many places, mobility agents (FA,HA) do not have to >interact with the AAA infrastructure every time a mobile is >sending a Registration Request. To my understanding, this implies >that whenever a AAA infrastructure is available and used, the HA >does NOT have the authority to extend the registration lifetime. >In other words, >(i) either the MN ignores the lifetime field in Registration > Replies coming directly from the HA, or No, it will not ignore the lifetime field in the Reg Reply >(ii) Registration Replies sent directly to the MN MUST have the > lifetime field set to: > (Authorization-Lifetime in last received HAR) minus > (Time elapsed since last HAR was received) minus > (some delays) The Lifetime field in the registration reply should be set so that the Authorization-Lifetime is a multiple of the lifetime in the reg-reply. This way the mobile node will be able to do periodic tunnel updates without involving AAA. AAA is only involved when the Authorization-Lifetime expires. Hope this clarifies /Fredrik > >Is that how it's supposed to work or am I way off on this? :) > >Thanks, > >-Panos From owner-aaa-wg@merit.edu Thu Oct 4 15:57:42 2001 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 PAA23990 for ; Thu, 4 Oct 2001 15:57:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D119291336; Thu, 4 Oct 2001 15:58:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C53D91337; Thu, 4 Oct 2001 15:58: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 7E5F391336 for ; Thu, 4 Oct 2001 15:58:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 118025DDD4; Thu, 4 Oct 2001 15:58:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id E03445DDB6 for ; Thu, 4 Oct 2001 15:58:27 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id 78EF41F531; Thu, 4 Oct 2001 12:57:12 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA02081; Thu, 4 Oct 2001 12:58:44 -0700 (PDT) Date: Thu, 4 Oct 2001 12:58:44 -0700 (PDT) From: Joe Lau Message-Id: <200110041958.MAA02081@strtio1.cup.hp.com> To: BKopacz@InterlinkNetworks.com Subject: Re: [AAA-WG]: Re: AAAH must be stateful Cc: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > I am very interested on learning how to achieve this w/o requiring the > > AAAh to maintain session states because I am facing such a problem right > > now. Can you give more details on how you can achieve your last statement? > > > > "Thus you can extract it for the next amr and use it." > > > > > > Please use the following example. > > > > AMR(session_id_1) -------------------+ > > | > > +------------> AAAh (stateless) > > | | | > > AMR(session_id_2) -------------------+ | | > > | | > > HAR(sid_3)| | HAR(sid_4) > > | | > > v v > > Home Agent > > > > The two AMR's came from different FA's, so session_id_1 != session_id_2 > > But the draft says sid_3 must equal sid_4 on the HAR's. > > It seems like the HA must be able to deal with receiving different > session-id's for the same session anyway, since the AMRs may go to > different AAAH's. (Section 1.3 "Support for Mobile-IP Handoffs" says > that "it is quite likely the AMR for a handoff will be received by > a different AAAH".) The HA is not is the question on the table :=) The question is the draft says: ... ,the AAAH MUST use the _same_ session id for _all_ HARs initialed on behalf of a given mobile node's session. Since this is a MUST, then we need to know how to achieve this requirement on a stateless AAAh (if AAAh is not required to be stateful). This is the problem statement for our current discussion. Joe Lau From owner-aaa-wg@merit.edu Thu Oct 4 16:44:01 2001 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 QAA24630 for ; Thu, 4 Oct 2001 16:44:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88BEE91277; Thu, 4 Oct 2001 16:44:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5060191278; Thu, 4 Oct 2001 16:44: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 137A891277 for ; Thu, 4 Oct 2001 16:44:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABD2A5DDD0; Thu, 4 Oct 2001 16:44:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 924485DDB6 for ; Thu, 4 Oct 2001 16:44:56 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 64A007B; Thu, 4 Oct 2001 16:43:51 -0400 (EDT) From: "Bob Kopacz" To: "Joe Lau" Cc: Subject: RE: [AAA-WG]: Re: AAAH must be stateful Date: Thu, 4 Oct 2001 16:41:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200110041958.MAA02081@strtio1.cup.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Joe, > -----Original Message----- > From: Joe Lau [mailto:jlau@cup.hp.com] > Sent: Thursday, October 04, 2001 3:59 PM > To: BKopacz@InterlinkNetworks.com > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Re: AAAH must be stateful > > > > > I am very interested on learning how to achieve this w/o requiring the > > > AAAh to maintain session states because I am facing such a problem right > > > now. Can you give more details on how you can achieve your last > statement? > > > > > > "Thus you can extract it for the next amr and use it." > > > > > > > > > Please use the following example. > > > > > > AMR(session_id_1) -------------------+ > > > | > > > +------------> AAAh > (stateless) > > > | | | > > > AMR(session_id_2) -------------------+ | | > > > | | > > > HAR(sid_3)| | > HAR(sid_4) > > > | | > > > v v > > > Home Agent > > > > > > The two AMR's came from different FA's, so session_id_1 != session_id_2 > > > But the draft says sid_3 must equal sid_4 on the HAR's. > > > > It seems like the HA must be able to deal with receiving different > > session-id's for the same session anyway, since the AMRs may go to > > different AAAH's. (Section 1.3 "Support for Mobile-IP Handoffs" says > > that "it is quite likely the AMR for a handoff will be received by > > a different AAAH".) > > The HA is not is the question on the table :=) > > The question is the draft says: > > ... ,the AAAH MUST use the _same_ session id for _all_ HARs > initialed on behalf of a given mobile node's session. > > Since this is a MUST, then we need to know how to achieve this requirement > on a stateless AAAh (if AAAh is not required to be stateful). Alternatively, we could question why the above statement is a MUST. If the HA has to deal with receiving different session-id's for the same session (in the case where a handoff AMR goes to a different AAAH), then what does the above requirement buy you? This is just a draft, where MUSTs are revised to MAYs and vice versa. I think the real question you raised, which is a very good one, is whether the AAAH MUST be session stateful, or whether a reasonable implementation could be done with a session-stateless server. Then statements such as the above could be made consistent with that decision. Thank you for pushing this stateful-v-stateless question; hopefully it will be resolved soon. > This is the problem statement for our current discussion. > Joe Lau Take care, Bob K. From owner-aaa-wg@merit.edu Thu Oct 4 18:02:40 2001 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 SAA25743 for ; Thu, 4 Oct 2001 18:02:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D02FF91220; Thu, 4 Oct 2001 18:03:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C0E39127A; Thu, 4 Oct 2001 18:03: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 6F3C691220 for ; Thu, 4 Oct 2001 18:03:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 088DD5DDB6; Thu, 4 Oct 2001 18:03:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id BE3995DDA7 for ; Thu, 4 Oct 2001 18:03:33 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel13.hp.com (Postfix) with ESMTP id A9E521FA16 for ; Thu, 4 Oct 2001 15:02:22 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA02317 for aaa-wg@merit.edu; Thu, 4 Oct 2001 15:03:55 -0700 (PDT) Date: Thu, 4 Oct 2001 15:03:55 -0700 (PDT) From: Joe Lau Message-Id: <200110042203.PAA02317@strtio1.cup.hp.com> To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: AAAH must be stateful Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > > I am very interested on learning how to achieve this w/o requiring the > > > > AAAh to maintain session states because I am facing such a problem right > > > > now. Can you give more details on how you can achieve your last > > statement? > > > > > > > > "Thus you can extract it for the next amr and use it." > > > > > > > > > > > > Please use the following example. > > > > > > > > AMR(session_id_1) -------------------+ > > > > | > > > > +------------> AAAh > > (stateless) > > > > | | | > > > > AMR(session_id_2) -------------------+ | | > > > > | | > > > > HAR(sid_3)| | > > HAR(sid_4) > > > > | | > > > > v v > > > > Home Agent > > > > > > > > The two AMR's came from different FA's, so session_id_1 != session_id_2 > > > > But the draft says sid_3 must equal sid_4 on the HAR's. > > > > > > It seems like the HA must be able to deal with receiving different > > > session-id's for the same session anyway, since the AMRs may go to > > > different AAAH's. (Section 1.3 "Support for Mobile-IP Handoffs" says > > > that "it is quite likely the AMR for a handoff will be received by > > > a different AAAH".) > > > > The HA is not is the question on the table :=) > > > > The question is the draft says: > > > > ... ,the AAAH MUST use the _same_ session id for _all_ HARs > > initialed on behalf of a given mobile node's session. I assume there is a technical reason for the above "MUST" requirement. Can someone shed some light on this? This will lead us to the answer whether AAAh must be stateful or not. Thanks. Joe Lau > > > > Since this is a MUST, then we need to know how to achieve this requirement > > on a stateless AAAh (if AAAh is not required to be stateful). > > Alternatively, we could question why the above statement is a MUST. If the > HA has to deal with receiving different session-id's for the same session > (in the case where a handoff AMR goes to a different AAAH), then what > does the above requirement buy you? This is just a draft, where MUSTs > are revised to MAYs and vice versa. > > I think the real question you raised, which is a very good one, is whether > the AAAH MUST be session stateful, or whether a reasonable implementation could > be done with a session-stateless server. Then statements such as the > above could be made consistent with that decision. > > Thank you for pushing this stateful-v-stateless question; hopefully > it will be resolved soon. > > > This is the problem statement for our current discussion. > > > Joe Lau > > Take care, > Bob K. > > From owner-aaa-wg@merit.edu Fri Oct 5 03:52:45 2001 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 DAA16877 for ; Fri, 5 Oct 2001 03:52:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90BE59122C; Fri, 5 Oct 2001 03:53:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EA4691231; Fri, 5 Oct 2001 03:53: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 2FCEE9122C for ; Fri, 5 Oct 2001 03:53:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B95985DD9E; Fri, 5 Oct 2001 03:53:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B99025DD97 for ; Fri, 5 Oct 2001 03:53:38 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA14561; Fri, 5 Oct 2001 09:50:13 +0200 From: "Fredrik Johansson" To: "Michael Chen" Cc: "Joe Lau" , , , Subject: RE: [AAA-WG]: Section 8.1 Date: Fri, 5 Oct 2001 09:50:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01C14D83.345F2630" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3BBC978D.115110C2@erilab.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0178_01C14D83.345F2630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You're right, it would be better to just have one MIP-Key-Lifetime AVP in the HAR and AMA to prevent the lifetimes from being different on the different keys. The only trick with that is to mandate it's presens when there is a MIP-...-Key AVP present in the HAR or AMA. Pat, has there been a decision on having a Key Lifetime AVP instead of the authorization lifetime? /Fredrik -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Michael Chen Sent: den 4 oktober 2001 19:08 To: Fredrik Johansson Cc: Joe Lau; aaa-wg@merit.edu; meklund@knox6039.cisco.com; pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 In aaa-key-08 draft, there is only MN-FA Key Material contain lifetime field so it's not necessary to put key-lifetime in all the key avps. Well, if we do, all the key-lifetime values are same, aren't they? So we only need send this avp to FA and HA. I would suggest add this MIP-Key-Lifetime AVP in HAR and AMA message instead of inlcude it in the group key AVPs. -Michael Fredrik Johansson wrote: I agree that the AAAh must be statefull anyway so there is no gain in sending the FA keys to the HA so, the key distribution avps will now look like this? (adding the key lifetime avp as well) MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-FA-to-MN-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-FA-to-HA-Key ::= < AVP Header: 328 > { MIP-FA-to-HA-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-HA-to-FA-Key ::= < AVP Header: 329 > { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-HA-to-MN-Key ::= < AVP Header: 332 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Key-Material } { MIP-Key-Lifetime } { AAA-SPI } <--- spi pointing to mn-aaa sec context * [ AVP ] MIP-MN-to-HA-Key ::= < AVP Header: 331 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Key-Material } { MIP-Key-Lifetime } { AAA-SPI } <--- spi pointing to mn-aaa sec context * [ AVP ] >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Joe Lau >Sent: den 3 oktober 2001 20:54 >To: cchen@erilab.com >Cc: aaa-wg@merit.edu; fredrik.johansson@ipunplugged.com; >jlau@cup.hp.com; meklund@knox6039.cisco.com; pcalhoun@diameter.org >Subject: Re: [AAA-WG]: Section 8.1 > > >> We have defined MIP-FA-to-HA-SPI MIP-FA-to-MN-SPI two AVPs, >why don't we >> put these AVPs in the MIP-FA-to-HA-Key MIP-FA-to-MN-Key to replace the >> MIP-Peer-SPI ? In other words, see below >> MIP-FA-to-MN-Key ::= < AVP Header: 326 > >> { MIP-FA-to-MN-SPI } >> { MIP-Algorithm-Type } >> { MIP-Session-Key } >> * [ AVP ] >> >> MIP-FA-to-HA-Key ::= < AVP Header: 328 > >> { MIP-FA-to-HA-SPI } >> { MIP-Algorithm-Type } >> { MIP-Session-Key } >> * [ AVP ] >> By the way, I don't think we can impletement stateless diameter server by >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be >> returned in the HAA so it can be inserted into the AMA." and so on. >> Because in redirect case, there is no guarantee that whay avps >you send, you >> will see all of them from the redirect answer. So all the >diameter have to >> keep the state. please correct me if I am wrong. > >I agree with Michael that _all_ diameter have to keep state. >Another good example would be the following statement on section 1.2. > > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see figure 2). Of > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > initiated on behalf of a given mobile node's session. > >This will require the AAAH server to be stateful. > >Anyone disagree on this? > >Joe > > >> Joe Lau wrote: >> >> > > The general idea was that the HA modify the SPI value in the >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >> > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft >version 8, alpha. >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this >> > discussion? >> > >> > Joe >> >> --------------E9A36EF30F9B970D0F625B9D >> Content-Type: text/html; charset=us-ascii >> Content-Transfer-Encoding: 7bit >> >> >> >> We have defined MIP-FA-to-HA-SPI  >MIP-FA-to-MN-SPI  two AVPs, >> why don't we put these AVPs in the MIP-FA-to-HA-Key  >MIP-FA-to-MN-Key >> to replace the MIP-Peer-SPI ?    In other words, >see below >>
      MIP-FA-to-MN-Key ::= < >AVP Header: >> 326 > >> >
           >;            >      >> { MIP-FA-to-MN-SPI } >> >
           >;            >      >> { MIP-Algorithm-Type } >> >
           >;            >      >> { MIP-Session-Key } >> >
           >;            >    >> * [ AVP ] >>

      MIP-FA-to-HA-Key ::= < >AVP Header: >> 328 > >> >
           >;            >      >> { MIP-FA-to-HA-SPI } >> >
           >;            >      >> { MIP-Algorithm-Type } >> >
           >;            >      >> { MIP-Session-Key } >> >
           >;            >    >> * [ AVP ] >>
By the way, I don't think we can impletement stateless diameter >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR >> it must be returned in the HAA so it can be inserted into the AMA." and >> so on. >>
Because in redirect case, there is no guarantee that whay avps >> you send, you will see all of them from the redirect answer. So all the >> diameter have to keep the state. please correct me if I am >wrong. >>

-Michael >>
  >>

  >>

Joe Lau wrote: >>

> The general idea was that the HA modify the SPI >> value in the >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, >> alpha. >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing >> in this >>
discussion? >>

Joe

>> >> >> --------------E9A36EF30F9B970D0F625B9D-- >> >> ------=_NextPart_000_0178_01C14D83.345F2630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
You're=20 right, it would be better to just have one MIP-Key-Lifetime AVP in the = HAR and=20 AMA to prevent the lifetimes from being different on the different=20 keys.
The=20 only trick with that is to mandate it's presens when there is a = MIP-...-Key AVP=20 present in the HAR or AMA.
 
Pat,=20 has there been a decision on having a Key Lifetime AVP instead of the=20 authorization lifetime?
 
/Fredrik
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Michael=20 Chen
Sent: den 4 oktober 2001 19:08
To: Fredrik=20 Johansson
Cc: Joe Lau; aaa-wg@merit.edu; = meklund@knox6039.cisco.com;=20 pcalhoun@diameter.org
Subject: Re: [AAA-WG]: Section=20 8.1

In aaa-key-08 draft, there is only MN-FA = Key=20 Material contain lifetime field so it's not necessary to put = key-lifetime in=20 all the key avps. Well, if we do, all the key-lifetime values are = same, aren't=20 they? So we only need send this avp to FA and HA. I would suggest add = this=20 MIP-Key-Lifetime AVP in HAR and AMA message instead of inlcude it in = the group=20 key AVPs.=20

-Michael
 
 =20

Fredrik Johansson wrote:=20

I agree that the AAAh must be statefull = anyway so=20 there is no
gain in sending the FA keys to the HA=20

so, the key distribution avps will now look like this? =
(adding the=20 key lifetime avp as well)=20

MIP-FA-to-MN-Key ::=3D < AVP Header: 326 >=20 =
           &nb= sp;        =20 { MIP-FA-to-MN-SPI }=20 =
           &nb= sp;        =20 { MIP-Algorithm-Type }=20 =
           &nb= sp;        =20 { MIP-Session-Key }=20 =
           &nb= sp;        =20 { MIP-Key-Lifetime }=20 =
           &nb= sp;        =20 * [ AVP ]=20

MIP-FA-to-HA-Key ::=3D < AVP Header: 328 >=20 =
           &nb= sp;        =20 { MIP-FA-to-HA-SPI }=20 =
           &nb= sp;        =20 { MIP-Algorithm-Type }=20 =
           &nb= sp;        =20 { MIP-Session-Key }=20 =
           &nb= sp;        =20 { MIP-Key-Lifetime }=20 =
           &nb= sp;        =20 * [ AVP ]=20

MIP-HA-to-FA-Key ::=3D < AVP Header: 329 >=20 =
           &nb= sp;        =20 { MIP-Algorithm-Type }=20 =
           &nb= sp;        =20 { MIP-Session-Key }=20 =
           &nb= sp;        =20 { MIP-Key-Lifetime }=20 =
           &nb= sp;        =20 * [ AVP ]=20

MIP-HA-to-MN-Key ::=3D < AVP Header: 332 >=20 =
           &nb= sp;        =20 { MIP-Algorithm-Type }=20 =
           &nb= sp;        =20 { MIP-Replay-Mode }=20 =
           &nb= sp;        =20 { MIP-Session-Key }=20 =
           &nb= sp;        =20 { MIP-Key-Lifetime }=20 =
           &nb= sp;        =20 * [ AVP ]=20

MIP-MN-to-FA-Key ::=3D < AVP Header: 325 >=20 =
           &nb= sp;        =20 { MIP-Algorithm-Type }=20 =
           &nb= sp;        =20 { MIP-Key-Material }=20 =
           &nb= sp;        =20 { MIP-Key-Lifetime }=20 =
           &nb= sp;           &nbs= p;  =20 { AAA-SPI } <--- spi pointing to mn-aaa sec context=20 =
           &nb= sp;        =20 * [ AVP ]=20

MIP-MN-to-HA-Key ::=3D < AVP Header: 331 >=20 =
           &nb= sp;        =20 { MIP-Algorithm-Type }=20 =
           &nb= sp;        =20 { MIP-Replay-Mode }=20 =
           &nb= sp;        =20 { MIP-Key-Material }=20 =
           &nb= sp;        =20 { MIP-Key-Lifetime }=20 =
           &nb= sp;        =20 { AAA-SPI } <--- spi pointing to mn-aaa sec context=20 =
           &nb= sp;        =20 * [ AVP ]=20

>-----Original Message-----
>From: = owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]= On=20 Behalf Of
>Joe Lau
>Sent: den 3 oktober 2001 20:54 =
>To:=20 cchen@erilab.com
>Cc: aaa-wg@merit.edu;=20 fredrik.johansson@ipunplugged.com;
>jlau@cup.hp.com;=20 meklund@knox6039.cisco.com; pcalhoun@diameter.org
>Subject: = Re:=20 [AAA-WG]: Section 8.1
>
>
>> We have defined = MIP-FA-to-HA-SPI  MIP-FA-to-MN-SPI  two AVPs,
>why = don't we=20
>> put these AVPs in the MIP-FA-to-HA-Key  = MIP-FA-to-MN-Key=20 to replace the
>> MIP-Peer-SPI ?    In = other words,=20 see below
>>       = MIP-FA-to-MN-Key=20 ::=3D < AVP Header: 326 >=20 =
>>          &= nbsp;           &n= bsp;    =20 { MIP-FA-to-MN-SPI }=20 =
>>          &= nbsp;           &n= bsp;    =20 { MIP-Algorithm-Type }=20 =
>>          &= nbsp;           &n= bsp;    =20 { MIP-Session-Key }=20 =
>>          &= nbsp;           &n= bsp;  =20 * [ AVP ]
>> =
>>      =20 MIP-FA-to-HA-Key ::=3D < AVP Header: 328 >=20 =
>>          &= nbsp;           &n= bsp;    =20 { MIP-FA-to-HA-SPI }=20 =
>>          &= nbsp;           &n= bsp;    =20 { MIP-Algorithm-Type }=20 =
>>          &= nbsp;           &n= bsp;    =20 { MIP-Session-Key }=20 =
>>          &= nbsp;           &n= bsp;  =20 * [ AVP ]
>> By the way, I don't think we can impletement=20 stateless diameter server by
>> requesting for example "If = the=20 MIP-FA-to-HA-Key is in the HAR it must be
>> returned in = the HAA=20 so it can be inserted into the AMA." and so on.
>> Because = in=20 redirect case, there is no guarantee that whay avps
>you = send, you=20
>> will see all of them from the redirect answer. So all = the=20
>diameter have to
>> keep the state. please correct = me if I=20 am wrong.
>
>I agree with Michael that _all_ diameter = have to=20 keep state.
>Another good example would be the following = statement on=20 section 1.2.
>
>   During the creation of = the HAR,=20 the AAAH MUST use a different session
>   = identifier than=20 the one used in the AMR/AMA (see figure 2). Of
>   = course,=20 the AAAH MUST use the _same_ session identifier for _all_ HARs=20
>   initiated on behalf of a given mobile node's = session.=20
>
>This will require the AAAH server to be stateful. =
>=20
>Anyone disagree on this?
>
>Joe
> =
>=20
>> Joe Lau wrote:
>>
>> > > The = general=20 idea was that the HA modify the SPI value in the
>> > = >=20 MIP-FA-to-HA-Key, and return the updated AVP in the HAA. =
>> >=20
>> > But there is no more MIP-FA-to-HA-Key in HAA on = the draft=20
>version 8, alpha.
>> > Did you mean = MIP-FA-to-HA-SPI=20 instead?  Or, did I miss somthing in this
>> > = discussion?=20
>> >
>> > Joe
>>
>>=20 --------------E9A36EF30F9B970D0F625B9D
>> Content-Type: = text/html;=20 charset=3Dus-ascii
>> Content-Transfer-Encoding: 7bit =
>>=20
>> <!doctype html public "-//w3c//dtd html 4.0=20 transitional//en">
>> <html>
>> = <tt>We=20 have defined MIP-FA-to-HA-SPI&nbsp; =
>MIP-FA-to-MN-SPI&nbsp;=20 two AVPs,
>> why don't we put these AVPs in the=20 MIP-FA-to-HA-Key&nbsp;
>MIP-FA-to-MN-Key
>> to = replace=20 the MIP-Peer-SPI ?&nbsp;&nbsp;&nbsp; In other words, =
>see=20 below</tt>
>>=20 = <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 MIP-FA-to-MN-Key ::=3D &lt;
>AVP Header:
>> 326 = ></tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>> {=20 MIP-FA-to-MN-SPI }</tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>> {=20 MIP-Algorithm-Type }</tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>> {=20 MIP-Session-Key }</tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;
>> * [ AVP=20 ]</tt><tt></tt>
>>=20 = <p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 MIP-FA-to-HA-Key ::=3D &lt;
>AVP Header:
>> 328 = ></tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>> {=20 MIP-FA-to-HA-SPI }</tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>> {=20 MIP-Algorithm-Type }</tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
>> {=20 MIP-Session-Key }</tt>
>>=20 =
><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=20 =
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
>&nbsp;&nbsp;&nbsp;
>> * [ AVP = ]</tt>=20
>> <br><tt>By the way, I don't think we can=20 impletement stateless diameter
>> server by requesting for = example=20 "If the MIP-FA-to-HA-Key is in the HAR
>> it must be = returned in=20 the HAA so it can be inserted into the AMA." and
>> so=20 on.</tt>
>> <br><tt>Because in redirect = case,=20 there is no guarantee that whay avps
>> you send, you will = see all=20 of them from the redirect answer. So all the
>> diameter = have to=20 keep the state. please correct me if I am=20
>wrong.</tt><tt></tt>
>>=20 <p><tt>-Michael</tt>
>>=20 <br><tt></tt>&nbsp;<tt></tt> =
>>=20 <p>&nbsp;
>> <p>Joe Lau wrote: =
>>=20 <blockquote TYPE=3DCITE>> The general idea was that the HA = modify the=20 SPI
>> value in the
>> <br>> = MIP-FA-to-HA-Key,=20 and return the updated AVP in the HAA.
>> <p>But = there is no=20 more MIP-FA-to-HA-Key in HAA on the draft version 8,
>> = alpha.=20
>> <br>Did you mean MIP-FA-to-HA-SPI = instead?&nbsp; Or,=20 did I miss somthing
>> in this
>> = <br>discussion?=20
>> <p>Joe</blockquote>
>> = </html>=20
>>
>> --------------E9A36EF30F9B970D0F625B9D--=20
>> =
>>

------=_NextPart_000_0178_01C14D83.345F2630-- From owner-aaa-wg@merit.edu Fri Oct 5 04:15:49 2001 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 EAA17049 for ; Fri, 5 Oct 2001 04:15:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7247B91231; Fri, 5 Oct 2001 04:16:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 380E591236; Fri, 5 Oct 2001 04:16:40 -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 D8CF591231 for ; Fri, 5 Oct 2001 04:16:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65EF75DD9E; Fri, 5 Oct 2001 04:16:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 589B05DD97 for ; Fri, 5 Oct 2001 04:16:37 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA15334; Fri, 5 Oct 2001 10:15:43 +0200 From: "Fredrik Johansson" To: "Thomas Panagiotis-PTHOMAS1" , Subject: RE: [AAA-WG]: General question on MIP and AAA interaction Date: Fri, 5 Oct 2001 10:16:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >Thanks Fredrik. I'll need a little more help though... :) > >So what you are saying is that the MN should have two >"registration lifetime" timers running. One with AAAH >(aaa-lifetime) and one with HA (mip-lifetime). They >start off with the same value at the same time but then >they diverge (both in value and expiration times). yes, there will be one timer to keep track of the tunnel lifetime and one to handle registration keys. > >I understand why aaa-lifetime makes sense to be greater >than mip-lifetime, but why multiple? Even if aaa-lifetime >is a multiple of mip-lifetime, you still can not guarantee >that aaa-lifetime will expire at the same time that >mip-lifetime does. The reason is because mip-lifetime is >refreshed not only upon its expiration but also upon handoff >times, which are stochastic. So after a while these two timers >will run independent of each other. The MN would have to >re-register: >(1) upon aaa-lifetime expiration (with AAAH) >(2) upon mip-lifetime expiration (with HA) >(3) upon handoff, (with HA) > >Is that what you have in mind? Yes, you're right, the mn has to re-register at, tunnel expiration, key expiration and upon handoff to another FA I guess that the key lifetime being a multiple of the tunnel lifetime just makes sence if you always give out new keys to all nodes upon handoff. In that case both timers will expire at the same time. So making it a recomendation might be the best we can do, that will help for MNs connected to the same FA for longer periods of time. /Fredrik > >Thanks again! > >-Panos > >-----Original Message----- >From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] >Sent: Thursday, October 04, 2001 2:48 AM >To: Thomas Panagiotis-PTHOMAS1; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: General question on MIP and AAA interaction > > >> >>Hi, >> >>As noted in many places, mobility agents (FA,HA) do not have to >>interact with the AAA infrastructure every time a mobile is >>sending a Registration Request. To my understanding, this implies >>that whenever a AAA infrastructure is available and used, the HA >>does NOT have the authority to extend the registration lifetime. >>In other words, >>(i) either the MN ignores the lifetime field in Registration >> Replies coming directly from the HA, or > >No, it will not ignore the lifetime field in the Reg Reply > >>(ii) Registration Replies sent directly to the MN MUST have the >> lifetime field set to: >> (Authorization-Lifetime in last received HAR) minus >> (Time elapsed since last HAR was received) minus >> (some delays) > >The Lifetime field in the registration reply should be set so that >the Authorization-Lifetime is a multiple of the lifetime in the >reg-reply. This way the mobile node will be able to do periodic >tunnel updates without involving AAA. AAA is only involved when >the Authorization-Lifetime expires. > >Hope this clarifies > >/Fredrik > >> >>Is that how it's supposed to work or am I way off on this? :) >> >>Thanks, >> >>-Panos From owner-aaa-wg@merit.edu Fri Oct 5 09:25:14 2001 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 JAA21555 for ; Fri, 5 Oct 2001 09:25:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCB0A9122F; Fri, 5 Oct 2001 09:26:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0AA291234; Fri, 5 Oct 2001 09:26:03 -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 962929122F for ; Fri, 5 Oct 2001 09:26:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A1AD5DDAC; Fri, 5 Oct 2001 09:26:02 -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 288525DDA5 for ; Fri, 5 Oct 2001 09:26:01 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f95DPLf10738 for ; Fri, 5 Oct 2001 16:25:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Oct 2001 16:24:44 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 5 Oct 2001 16:24:47 +0300 Message-ID: From: henry.haverinen@nokia.com To: gwz@cisco.com, aaa-wg@merit.edu Subject: [AAA-WG]: RE: Do we need a NAS-Ciphersuite-Capabilities AVP? Date: Fri, 5 Oct 2001 16:24:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > From: ext Glen Zorn [mailto:gwz@cisco.com] > > If the EAP type is supposed to negotiate the ciphersuite, > > then I guess we need to specify a new AVP for NAS capabilities. > > This seems like a reasonable idea at first glance, but I have > some concerns. > > 1) Since the cryptosystem is being negotiated in EAP and the > EAP server and > Diameter server may likely be distinct entities, this would > seem to add > interface requirements to EAP servers. That's true. But negotiating cryptosystems in EAP will require interfaces between EAP and Diameter anyway. The result of the negotiation will have to be passed from the EAP server to the Diameter server, and from the Diameter client to the packet security subsystem of the NAS. > 2) EAP should probably not be allowed to negotiate just any > cryptosystem it > likes: there seems to be an authorization issue as well. For example, > suppose that EAP negotiates 40-bit RC4 but the user is only allowed to > connect using 128-bit AES. How would this restriction be enforced? I don't think that knowing the NAS ciphersuite capabilities has to stop the Diameter server from enforcing this restriction. It could always say Access-Reject. Or it could filter out any undesired ciphersuites from the NAS-Ciphersuite-Capabilities AVP before giving them to the EAP server. Ideally, all the entities (the client, the NAS and the AAA server) should be able to have their own policies. It is conceivable that 40-bit RC4 could be fine for the everyone but everyone would prefer 128-bit AES. In this case, the network entity that negotiates the cryptosystem needs to know the capabilities of the NAS. > Both these concerns seem to suggest that EAP cannot be treated > simply as a "pass-through" any more... Unless the cryptosystem is negotiated between the client and the NAS. Authorization issues could still be handled with a Diameter AVP. Regards, Henry From owner-aaa-wg@merit.edu Fri Oct 5 09:40:17 2001 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 JAA21971 for ; Fri, 5 Oct 2001 09:40:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 679A091218; Fri, 5 Oct 2001 09:41:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 358FD91234; Fri, 5 Oct 2001 09:41: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 271E691218 for ; Fri, 5 Oct 2001 09:41:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6B355DDED; Fri, 5 Oct 2001 09:41: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 E40965DDB8 for ; Fri, 5 Oct 2001 09:41:04 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f95DePf20400 for ; Fri, 5 Oct 2001 16:40:25 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 5 Oct 2001 16:39:52 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 5 Oct 2001 16:39:51 +0300 Message-ID: From: henry.haverinen@nokia.com To: aboba@internaut.com, gwz@cisco.com Cc: yohba@tari.toshiba.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issues 188, 189 and 190 Date: Fri, 5 Oct 2001 16:39:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > From: ext Glen Zorn [mailto:gwz@cisco.com] > What I'm saying is that just saying "MASTER_KEY" w/o further > qualification > is by definition more ambiguous that saying either "ENCRYPTION_KEY" or > "INTEGRITY_KEY". Furthermore, I can't find in the definition of the > NAS-Key-Type AVP any requirement (either explicit or implied) > that the key > material therein be used w/o modification or any prohibition of the > derivation of other keys from that material. The NAS-Key-Binding AVP and the fact that it must be included are the reasons why I thought that the transported keys are always the actual encryption and integrity protection keys. Maybe I made a hasty conclusion. I don't mind calling the master keys ENCRYPTION_KEY and INTEGRITY_KEY, if they are used to derive encryption keys and integrity keys. To me it would make sense to transport master keys only.. Regards, Henry From owner-aaa-wg@merit.edu Fri Oct 5 15:14:13 2001 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 PAA29412 for ; Fri, 5 Oct 2001 15:14:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A61289128C; Fri, 5 Oct 2001 15:04:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75B89912BF; Fri, 5 Oct 2001 15:04:06 -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 6FCC29128C for ; Fri, 5 Oct 2001 15:04:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 043385DDBB; Fri, 5 Oct 2001 15:04:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id BA5A55DDA5 for ; Fri, 5 Oct 2001 15:04:04 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id 4F9081F5DE; Fri, 5 Oct 2001 12:02:10 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA03536; Fri, 5 Oct 2001 12:03:38 -0700 (PDT) Date: Fri, 5 Oct 2001 12:03:38 -0700 (PDT) From: Joe Lau Message-Id: <200110051903.MAA03536@strtio1.cup.hp.com> To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: AAAH must be stateful Cc: cchen@erilab.com, meklund@cisco.com, pcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Are there any reasons a server MUST maintain state? > > > What about this one (as stated on draft 8, alpha)? > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see figure 2). Of > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > initiated on behalf of a given mobile node's session. I was disappointed to the lack of response/discussion to this important issue. Can we all have a discussion on this important issue? 1) The reasons for the above MUST requirement on the AAAH 2) Whether AAAH must be stateful to meet the above requirement In addition, it will be very helpful to the AAA server implementors if we can add a section to the Diameter Mobile IP draft describing when the AAA server must be stateful and when not. Thanks! Joe Lau From owner-aaa-wg@merit.edu Fri Oct 5 17:03:53 2001 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 RAA01517 for ; Fri, 5 Oct 2001 17:03:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 684C991338; Fri, 5 Oct 2001 17:04:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39B6091339; Fri, 5 Oct 2001 17:04: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 3206391338 for ; Fri, 5 Oct 2001 17:04:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B63E35DDAC; Fri, 5 Oct 2001 17:04:41 -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 CCA765DDA5 for ; Fri, 5 Oct 2001 17:04:40 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00344; Fri, 5 Oct 2001 17:03:11 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id RAA02094; Fri, 5 Oct 2001 17:03:52 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15294.8248.176661.916039@gargle.gargle.HOWL> Date: Fri, 5 Oct 2001 17:03:52 -0400 To: Joe Lau Cc: aaa-wg@merit.edu, cchen@erilab.com, meklund@cisco.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: AAAH must be stateful In-Reply-To: <200110051903.MAA03536@strtio1.cup.hp.com> References: <200110051903.MAA03536@strtio1.cup.hp.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joe Lau writes: > > > Are there any reasons a server MUST maintain state? > > > > > What about this one (as stated on draft 8, alpha)? > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > I was disappointed to the lack of response/discussion to this important issue. > > Can we all have a discussion on this important issue? > > 1) The reasons for the above MUST requirement on the AAAH I can't think of a reason for this to be a MUST. Is there ever a situation where the HA will not be able to determine if this is a continuation of a connection or a new connection? If so, that would be a reason for the MUST. I would think the MIP-Mobile-Node-Address would be a good indicator. If the HA has a connection established with the MIP-Mobile-Node-Address, then it is a continuation. I think the MUST should be at least a SHOULD for one reason. It will reduce the number of STRs sent. Every time the session-id changes for the connection, a STR will have to be sent for the previous session-id. If the session-id doesn't change because of re-auth. > 2) Whether AAAH must be stateful to meet the above requirement I can think of three reasons that you would get communications for the same connection. 1. Mobile IP Handoffs 2. Re-authorization 3. Key lifetime expiration and update. Mobile IP Handoffs always causes generation of a new HAR session ID so it doesn't count in the session state discussion. If your server always gives an infinite lifetime for the authorization and keys, then 2 and 3 shouldn't happen. Because of this, the AAAH should not have to keep session state. Even if there are either re-authorizations, or key lifetime expiration updates, I think the session id can be preserved without the AAAH having to keep state. This can be done with the Class AVP (section 8.20) of the base draft. You simply send the Home agent session in a Class AVP in your AMA. All subsequent AMR re-auths will have to include it and the stateless AAAH can extract the session-id and use it when communicating with the HA. -mark > > In addition, it will be very helpful to the AAA server implementors if > we can add a section to the Diameter Mobile IP draft describing when the > AAA server must be stateful and when not. > > Thanks! > > Joe Lau From owner-aaa-wg@merit.edu Fri Oct 5 18:04:47 2001 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 SAA02312 for ; Fri, 5 Oct 2001 18:04:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DF1D91339; Fri, 5 Oct 2001 18:05:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB48F9133A; Fri, 5 Oct 2001 18:05:37 -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 A121391339 for ; Fri, 5 Oct 2001 18:05:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 376665DDE3; Fri, 5 Oct 2001 18:05:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 9C1225DDBC for ; Fri, 5 Oct 2001 18:05:35 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA17028 for ; Fri, 5 Oct 2001 14:55:50 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA05199 for ; Fri, 5 Oct 2001 15:04:20 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4KW8MJGW>; Fri, 5 Oct 2001 17:04:20 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Mark Eklund'" , Joe Lau Cc: aaa-wg@merit.edu, cchen@erilab.com, pcalhoun@diameter.org Subject: RE: [AAA-WG]: Re: AAAH must be stateful Date: Fri, 5 Oct 2001 17:04:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk I would also vote for a SHOULD in the "AAAH MUST/SHOULD keep session state" question. For example, if (i) you don't care about accounting, and (ii) you don't care about the mobile-foreign, foreign-home auth extensions, and (iii) you set the mobile-home key lifetime to infinity, then you can interact with AAA (ok AA) only upon initial registration (for user authentication and mobile-home key distribution) and then forget about it. -Panos -----Original Message----- From: Mark Eklund [mailto:meklund@cisco.com] Sent: Friday, October 05, 2001 4:04 PM To: Joe Lau Cc: aaa-wg@merit.edu; cchen@erilab.com; meklund@cisco.com; pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: AAAH must be stateful Joe Lau writes: > > > Are there any reasons a server MUST maintain state? > > > > > What about this one (as stated on draft 8, alpha)? > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > I was disappointed to the lack of response/discussion to this important issue. > > Can we all have a discussion on this important issue? > > 1) The reasons for the above MUST requirement on the AAAH I can't think of a reason for this to be a MUST. Is there ever a situation where the HA will not be able to determine if this is a continuation of a connection or a new connection? If so, that would be a reason for the MUST. I would think the MIP-Mobile-Node-Address would be a good indicator. If the HA has a connection established with the MIP-Mobile-Node-Address, then it is a continuation. I think the MUST should be at least a SHOULD for one reason. It will reduce the number of STRs sent. Every time the session-id changes for the connection, a STR will have to be sent for the previous session-id. If the session-id doesn't change because of re-auth. > 2) Whether AAAH must be stateful to meet the above requirement I can think of three reasons that you would get communications for the same connection. 1. Mobile IP Handoffs 2. Re-authorization 3. Key lifetime expiration and update. Mobile IP Handoffs always causes generation of a new HAR session ID so it doesn't count in the session state discussion. If your server always gives an infinite lifetime for the authorization and keys, then 2 and 3 shouldn't happen. Because of this, the AAAH should not have to keep session state. Even if there are either re-authorizations, or key lifetime expiration updates, I think the session id can be preserved without the AAAH having to keep state. This can be done with the Class AVP (section 8.20) of the base draft. You simply send the Home agent session in a Class AVP in your AMA. All subsequent AMR re-auths will have to include it and the stateless AAAH can extract the session-id and use it when communicating with the HA. -mark > > In addition, it will be very helpful to the AAA server implementors if > we can add a section to the Diameter Mobile IP draft describing when the > AAA server must be stateful and when not. > > Thanks! > > Joe Lau From owner-aaa-wg@merit.edu Fri Oct 5 18:56:18 2001 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 SAA03447 for ; Fri, 5 Oct 2001 18:56:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA6D491208; Fri, 5 Oct 2001 18:57:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E63C9133B; Fri, 5 Oct 2001 18:57: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 7013091208 for ; Fri, 5 Oct 2001 18:57:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F15645DDF0; Fri, 5 Oct 2001 18:57:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by segue.merit.edu (Postfix) with ESMTP id 8403D5DDBC for ; Fri, 5 Oct 2001 18:57:19 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id 709FE1FB90; Fri, 5 Oct 2001 15:56:05 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA03986; Fri, 5 Oct 2001 15:57:37 -0700 (PDT) Date: Fri, 5 Oct 2001 15:57:37 -0700 (PDT) From: Joe Lau Message-Id: <200110052257.PAA03986@strtio1.cup.hp.com> To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: AAAH must be stateful Cc: cchen@erilab.com, jlau@cup.hp.com, meklund@cisco.com, panos.thomas@motorola.com, pcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit At this point, I guess I would like to turn the table around and ask under what situation will the AAA server (in particular the AAAH), MUST maintain session states. Once we have collected sufficient information, I recommend that we summary them in a new section on the Diameter Mobile IP Application draft. One question I have in mind is will the statefulness of a AAA server affect interoperability with other AAA server? Please participate, folks. Thanks. Joe Lau > I would also vote for a SHOULD in the "AAAH MUST/SHOULD keep session > state" question. For example, if (i) you don't care about accounting, and > (ii) you don't care about the mobile-foreign, foreign-home auth extensions, > and (iii) you set the mobile-home key lifetime to infinity, then you can > interact with AAA (ok AA) only upon initial registration (for user > authentication and mobile-home key distribution) and then forget about it. > > -Panos > > -----Original Message----- > From: Mark Eklund [mailto:meklund@cisco.com] > Sent: Friday, October 05, 2001 4:04 PM > To: Joe Lau > Cc: aaa-wg@merit.edu; cchen@erilab.com; meklund@cisco.com; > pcalhoun@diameter.org > Subject: Re: [AAA-WG]: Re: AAAH must be stateful > > > Joe Lau writes: > > > > Are there any reasons a server MUST maintain state? > > > > > > > What about this one (as stated on draft 8, alpha)? > > > > > > > > During the creation of the HAR, the AAAH MUST use a different > session > > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > > course, the AAAH MUST use the _same_ session identifier for _all_ > HARs > > > > initiated on behalf of a given mobile node's session. > > > > I was disappointed to the lack of response/discussion to this important > issue. > > > > Can we all have a discussion on this important issue? > > > > 1) The reasons for the above MUST requirement on the AAAH > > I can't think of a reason for this to be a MUST. Is there ever a > situation where the HA will not be able to determine if this is a > continuation of a connection or a new connection? If so, that would > be a reason for the MUST. I would think the MIP-Mobile-Node-Address > would be a good indicator. If the HA has a connection established > with the MIP-Mobile-Node-Address, then it is a continuation. > > I think the MUST should be at least a SHOULD for one reason. It will > reduce the number of STRs sent. Every time the session-id changes > for the connection, a STR will have to be sent for the previous > session-id. If the session-id doesn't change because of re-auth. > > > 2) Whether AAAH must be stateful to meet the above requirement > > I can think of three reasons that you would get communications for the > same connection. > > 1. Mobile IP Handoffs > 2. Re-authorization > 3. Key lifetime expiration and update. > > Mobile IP Handoffs always causes generation of a new HAR session ID so > it doesn't count in the session state discussion. > > If your server always gives an infinite lifetime for the authorization > and keys, then 2 and 3 shouldn't happen. Because of this, the AAAH > should not have to keep session state. > > Even if there are either re-authorizations, or key lifetime expiration > updates, I think the session id can be preserved without the AAAH > having to keep state. This can be done with the Class AVP (section > 8.20) of the base draft. You simply send the Home agent session in a > Class AVP in your AMA. All subsequent AMR re-auths will have to include > it and the stateless AAAH can extract the session-id and use it when > communicating with the HA. > > -mark > > > > > In addition, it will be very helpful to the AAA server implementors if > > we can add a section to the Diameter Mobile IP draft describing when the > > AAA server must be stateful and when not. > > > > Thanks! > > > > Joe Lau > From owner-aaa-wg@merit.edu Fri Oct 5 19:01:42 2001 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 TAA03521 for ; Fri, 5 Oct 2001 19:01:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D86C59133B; Fri, 5 Oct 2001 19:02:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADE4F9133C; Fri, 5 Oct 2001 19:02: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 5BAD59133B for ; Fri, 5 Oct 2001 19:02:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF9745DDF1; Fri, 5 Oct 2001 19:02:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 4DAC15DDBC for ; Fri, 5 Oct 2001 19:02:27 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id SAA05833; Fri, 5 Oct 2001 18:54:39 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id TAA18129; Fri, 5 Oct 2001 19:02:23 -0400 (EDT) From: "Mark Jones" To: "Joe Lau" , Cc: , , Subject: RE: [AAA-WG]: Re: AAAH must be stateful Date: Fri, 5 Oct 2001 19:02:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200110051903.MAA03536@strtio1.cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joe, > > > Are there any reasons a server MUST maintain state? > > > > > What about this one (as stated on draft 8, alpha)? > > > > > > During the creation of the HAR, the AAAH MUST use a > different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier > for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > I was disappointed to the lack of response/discussion to this > important issue. > > Can we all have a discussion on this important issue? > > 1) The reasons for the above MUST requirement on the AAAH I too am confused why this requirement is a MUST. The text seems to suggest that it is because the HA is tracking a single session regardless of how many handoffs occur. However, the HA can always determine whether a HAR relates to a new or continued session so I fail to see why the AAAH MUST remember the session id it added to the original HAR. I do have a question on the STR generation though: Assuming the AAAH included Auth-Session-State=NO_STATE_MAINTAINED in the HAR and a handoff results in the AMR being sent to a different AAAH than that which originally authorized the session, does this imply that the HA is not required to send an STR to the original AAAH? > 2) Whether AAAH must be stateful to meet the above requirement > If the requirement in (1) remains a MUST, I believe the AAAH MUST also be stateful. I don't think the Class attribute would help here unless it was somehow being passed down to the MN which echoed it back in subsequent MIP messages for the same session (regardless of FA). Regards, Mark From owner-aaa-wg@merit.edu Fri Oct 5 19:10:37 2001 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 TAA03624 for ; Fri, 5 Oct 2001 19:10:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 193149133C; Fri, 5 Oct 2001 19:11:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D48929133E; Fri, 5 Oct 2001 19:11: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 DF3209133C for ; Fri, 5 Oct 2001 19:11:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 754445DDF1; Fri, 5 Oct 2001 19:11:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by segue.merit.edu (Postfix) with ESMTP id 4E6565DDBC for ; Fri, 5 Oct 2001 19:11:27 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id D92068D6; Fri, 5 Oct 2001 16:10:09 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA04052; Fri, 5 Oct 2001 16:11:36 -0700 (PDT) Date: Fri, 5 Oct 2001 16:11:36 -0700 (PDT) From: Joe Lau Message-Id: <200110052311.QAA04052@strtio1.cup.hp.com> To: mjones@matrixmuse.com Subject: Re: [AAA-WG]: Re: AAAH must be stateful Cc: aaa-wg@merit.edu, cchen@erilab.com, jlau@cup.hp.com, meklund@cisco.com, pcalhoun@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, > I do have a question on the STR generation though: Assuming the AAAH > included Auth-Session-State=NO_STATE_MAINTAINED in the HAR and a handoff > results in the AMR being sent to a different AAAH than that which originally > authorized the session, does this imply that the HA is not required to send > an STR to the original AAAH? Good question. This needs to be clarified in the draft. > > 2) Whether AAAH must be stateful to meet the above requirement > > If the requirement in (1) remains a MUST, I believe the AAAH MUST also be > stateful. I don't think the Class attribute would help here unless it was > somehow being passed down to the MN which echoed it back in subsequent MIP > messages for the same session (regardless of FA). I agree. Regards, Joe Lau From owner-aaa-wg@merit.edu Sat Oct 6 01:01:36 2001 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 BAA09089 for ; Sat, 6 Oct 2001 01:01:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D088C91213; Sat, 6 Oct 2001 01:02:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A48EA91216; Sat, 6 Oct 2001 01:02:32 -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 83E0B91213 for ; Sat, 6 Oct 2001 01:02:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27DFA5DDB7; Sat, 6 Oct 2001 01:02:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7E63E5DDAC for ; Sat, 6 Oct 2001 01:02:29 -0400 (EDT) Received: (qmail 15876 invoked by uid 500); 6 Oct 2001 04:46:44 -0000 Date: Fri, 5 Oct 2001 21:46:44 -0700 From: Pat Calhoun To: Jari Arkko Cc: gwz@cisco.com, Jari Arkko , Pat Calhoun , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011005214644.K15363@charizard.diameter.org> Mail-Followup-To: Jari Arkko , gwz@cisco.com, Jari Arkko , Pat Calhoun , "Harri Hakala (LMF)" , aaa-wg@merit.edu References: <3BBC36A1.75424CEF@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BBC36A1.75424CEF@lmf.ericsson.se>; from Jari.Arkko@lmf.ericsson.se on Thu, Oct 04, 2001 at 01:14:57PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 04, 2001 at 01:14:57PM +0300, Jari Arkko wrote: > >What do you mean by "acct app value"? Do you mean a "generic" value for > >accounting? If so, I disagree... > > Given that Acct-Application-Id AVP is mandatory in accounting > messages, we need *some* value for that. This we can propably > agree on, or? > > Then it is another question what the value should be. My > preference is at the moment that user groups should be able > to create new apps, and allocate new values that they use > here. This seems to match your desire, or? This seems to be the best way forward. PatC From owner-aaa-wg@merit.edu Sat Oct 6 01:03:09 2001 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 BAA09119 for ; Sat, 6 Oct 2001 01:03:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B890B91216; Sat, 6 Oct 2001 01:04:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C8EF9121E; Sat, 6 Oct 2001 01:04: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 740ED91216 for ; Sat, 6 Oct 2001 01:04:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB5935DDB7; Sat, 6 Oct 2001 01:04:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9F3995DDAC for ; Sat, 6 Oct 2001 01:04:05 -0400 (EDT) Received: (qmail 15907 invoked by uid 500); 6 Oct 2001 04:48:20 -0000 Date: Fri, 5 Oct 2001 21:48:20 -0700 From: Pat Calhoun To: Randy Bush Cc: Pat Calhoun , Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011005214820.L15363@charizard.diameter.org> Mail-Followup-To: Randy Bush , Pat Calhoun , Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" References: <3BBAE31D.88CF01C5@lmf.ericsson.se> <20011003093010.I32101@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Thu, Oct 04, 2001 at 09:48:58AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 04, 2001 at 09:48:58AM +0200, Randy Bush wrote: > > This is the way it used to work.... then Glen argued to bundle it into the > > base spec, and remove the separate appl-id, and we created the acct-appl-id. > > > > Is reversing on a WG decision we made over 8 months ago really the right > > thing to do here? > > what is the technically right thing to do? six of one, half a dozen of another. I think there is a better fix than reverting to prehistoric ages. I've proposed it, and other folks tend to agree with it. PatC From owner-aaa-wg@merit.edu Sat Oct 6 01:06:04 2001 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 BAA09207 for ; Sat, 6 Oct 2001 01:06:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C57E69121E; Sat, 6 Oct 2001 01:06:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 957DD91226; Sat, 6 Oct 2001 01:06: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 810269121E for ; Sat, 6 Oct 2001 01:06:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 168C75DDB7; Sat, 6 Oct 2001 01:06:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 659035DDAC for ; Sat, 6 Oct 2001 01:06:55 -0400 (EDT) Received: (qmail 15944 invoked by uid 500); 6 Oct 2001 04:51:10 -0000 Date: Fri, 5 Oct 2001 21:51:10 -0700 From: Pat Calhoun To: Randy Bush , Pat Calhoun , Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011005215109.N15363@charizard.diameter.org> Mail-Followup-To: Randy Bush , Pat Calhoun , Bernard Aboba , Jari Arkko , "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" References: <3BBAE31D.88CF01C5@lmf.ericsson.se> <20011003093010.I32101@charizard.diameter.org> <20011005214820.L15363@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011005214820.L15363@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Oct 05, 2001 at 09:48:20PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > six of one, half a dozen of another. > > I think there is a better fix than reverting to prehistoric ages. I've > proposed it, and other folks tend to agree with it. I can't even understand my own response. Folks tend to agree with allowing for application ids to be allocated for accounting purposes without requiring a new command code. Some new text was sent out that folks appear to like. I think that's the better fix. PatC From owner-aaa-wg@merit.edu Sun Oct 7 10:43:36 2001 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 KAA23680 for ; Sun, 7 Oct 2001 10:43:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5849B9123C; Sun, 7 Oct 2001 10:44:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 263F19125A; Sun, 7 Oct 2001 10:44: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 F18DF9123C for ; Sun, 7 Oct 2001 10:44:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D2595DDF5; Sun, 7 Oct 2001 10:44:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EA65C5DD93 for ; Sun, 7 Oct 2001 10:44:31 -0400 (EDT) Received: (qmail 29410 invoked by uid 500); 7 Oct 2001 14:28:37 -0000 Date: Sun, 7 Oct 2001 07:28:37 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: gwz@cisco.com, Harri.Hakala@lmf.ericsson.se, Jari.Arkko@lmf.ericsson.se, pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011007072837.B29389@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, gwz@cisco.com, Harri.Hakala@lmf.ericsson.se, Jari.Arkko@lmf.ericsson.se, pcalhoun@diameter.org, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2E@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2E@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Thu, Oct 04, 2001 at 03:31:17PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk re-reading this fix, it requires an accounting command code. I believe that relaxing the rules on application specifications to allow for accounting only ones (that don't need to define command codes), is a better approach. PatC On Thu, Oct 04, 2001 at 03:31:17PM +0300, jaakko.rajaniemi@nokia.com wrote: > Hi, > > Now that we are clarifying these issues regarding new applications and their > accounting extensions I have one proposal to add. > > Because it is possible that a service only makes use of the Accounting > portion of the Diameter application then the application must clearly > described in the application specification which part contains the > accounting portion. The current text describes in the section 9.3 > (Application document requirements) clearly how new accounting AVPs must be > described in new applications but it does say anything how new accounting > command codes (if exist) should be described. One way to enforce that this > is clearly described in the new applications is to modify the section 9.3 in > the following way: > > "Each Diameter application (e.g. NASREQ, MobileIP), MUST define their > Service-Specific accounting part in a section entitled "Accounting". Under > the section "Accounting" they MUST define their Service-Specific AVPs that > MUST be present in the Accounting-Request message in a section entitled > "Accounting AVPs" and their Service-Specific command codes if exists in a > section entitled "Accounting Command-Codes". The application MUST assume > that the AVPs described in this document will be present in all Accounting > messages, so only their respective service-specific AVPs need to be defined > in this section." > > Best Regards, Jaakko From owner-aaa-wg@merit.edu Sun Oct 7 10:52:39 2001 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 KAA23705 for ; Sun, 7 Oct 2001 10:52:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 425FB9125A; Sun, 7 Oct 2001 10:53:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 101A49125E; Sun, 7 Oct 2001 10:53: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 EFFA59125A for ; Sun, 7 Oct 2001 10:53:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C6FF5DDF9; Sun, 7 Oct 2001 10:53:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DAEF05DD93 for ; Sun, 7 Oct 2001 10:53:30 -0400 (EDT) Received: (qmail 29443 invoked by uid 500); 7 Oct 2001 14:37:21 -0000 Date: Sun, 7 Oct 2001 07:37:21 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011007073721.C29389@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> <20011003093845.L32101@charizard.diameter.org> <004d01c14c39$88d51f80$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004d01c14c39$88d51f80$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Wed, Oct 03, 2001 at 09:30:53PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk > So in conclusion, how about the following: > > 1. Introduce a new section between 2.3.2 and 2.3.3 that tells > you how you can make new applications for accounting > 2. Allow the allocation of apps ids for these. ok so far. > 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for > Diameter servers. what does this fix have anything to do with this issue? This is a much larger change that can have many other side effects. What is the purpose for this request? PatC From owner-aaa-wg@merit.edu Sun Oct 7 10:57:41 2001 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 KAA23800 for ; Sun, 7 Oct 2001 10:57:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 72ED69125E; Sun, 7 Oct 2001 10:58:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AD879125F; Sun, 7 Oct 2001 10:58:41 -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 3A9929125E for ; Sun, 7 Oct 2001 10:58:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDA285DDF5; Sun, 7 Oct 2001 10:58:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7A3FD5DD93 for ; Sun, 7 Oct 2001 10:58:39 -0400 (EDT) Received: (qmail 29479 invoked by uid 500); 7 Oct 2001 14:42:45 -0000 Date: Sun, 7 Oct 2001 07:42:45 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 194: Add Termination-Cause Message-ID: <20011007074245.D29389@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here's what I have added to the base spec, as requested in this issue: DIAMETER_AUTH_EXPIRED 6 The user's access was terminated since its authorized session time has expired. DIAMETER_USER_MOVED 7 The user is receiving services from another access device. PatC From owner-aaa-wg@merit.edu Sun Oct 7 11:15:45 2001 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 LAA23959 for ; Sun, 7 Oct 2001 11:15:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A588B9125F; Sun, 7 Oct 2001 11:16:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7963091260; Sun, 7 Oct 2001 11:16: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 3C7D09125F for ; Sun, 7 Oct 2001 11:16:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD4335DDF5; Sun, 7 Oct 2001 11:16:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 265CB5DD93 for ; Sun, 7 Oct 2001 11:16:51 -0400 (EDT) Received: (qmail 29578 invoked by uid 500); 7 Oct 2001 15:00:56 -0000 Date: Sun, 7 Oct 2001 08:00:56 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 162: Error replies to requests with no session ids Message-ID: <20011007080056.G29389@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, In this issue, the author stated that section 7.2 was incorrect since it implied that the session id was mandatory (given the ABNF provided). I have looked at the ABNF further, and found that fixed position AVPs are not mandatory, and have a qualifier prefixed. Therefore, the correct fix for this issue is the following: ::= < Diameter Header: code, ERR [PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Reporting-Host ] [ Proxy-Info ] * [ AVP ] PatC From owner-aaa-wg@merit.edu Sun Oct 7 11:25:22 2001 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 LAA24019 for ; Sun, 7 Oct 2001 11:25:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE54191260; Sun, 7 Oct 2001 11:26:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E28C91261; Sun, 7 Oct 2001 11:26:22 -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 71F2E91260 for ; Sun, 7 Oct 2001 11:26:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3DFC5DDF8; Sun, 7 Oct 2001 11:26:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A0F935DD93 for ; Sun, 7 Oct 2001 11:26:20 -0400 (EDT) Received: (qmail 29629 invoked by uid 500); 7 Oct 2001 15:10:26 -0000 Date: Sun, 7 Oct 2001 08:10:26 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 181: Digital encryption + signature in CMS-Sec Message-ID: <20011007081026.H29389@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Is the current text in section 6.3 not sufficient to handle this case? Essentially, what it is stating is that it is OK to sign AVPs that weren't intended to be signed when such a case arises. PatC From owner-aaa-wg@merit.edu Sun Oct 7 11:31:53 2001 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 LAA24079 for ; Sun, 7 Oct 2001 11:31:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 155BA91261; Sun, 7 Oct 2001 11:32:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D94C091262; Sun, 7 Oct 2001 11:32: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 C4FBA91261 for ; Sun, 7 Oct 2001 11:32:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 558E95DDF8; Sun, 7 Oct 2001 11:32:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0E3D85DD93 for ; Sun, 7 Oct 2001 11:32:57 -0400 (EDT) Received: (qmail 29644 invoked by uid 500); 7 Oct 2001 15:17:02 -0000 Date: Sun, 7 Oct 2001 08:17:02 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 184: CMS-Data AVPs in base protocol Message-ID: <20011007081702.I29389@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk I have modified the paragraphs requested by this issue, but the first paragraph in section 9.5 has been modified to the following: In all accounting records the Session-Id and User-Name AVPs MUST be present. If strong authentication across agents is required, as described in [11], the CMS-Signed-Data AVP may be used to authenticate the Accounting Data and Service Specific AVPs. It is not typically necessary that the CMS-Signed-Data AVP cover any additional AVPs, but it is permitted as long as the AVPs protected are defined to have their 'P' bit set. PatC From owner-aaa-wg@merit.edu Sun Oct 7 11:45:32 2001 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 LAA24160 for ; Sun, 7 Oct 2001 11:45:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF5AC91262; Sun, 7 Oct 2001 11:46:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9337091263; Sun, 7 Oct 2001 11:46: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 5EEFB91262 for ; Sun, 7 Oct 2001 11:46:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB9595DDF8; Sun, 7 Oct 2001 11:46:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 895F75DD93 for ; Sun, 7 Oct 2001 11:46:41 -0400 (EDT) Received: (qmail 29693 invoked by uid 500); 7 Oct 2001 15:30:47 -0000 Date: Sun, 7 Oct 2001 08:30:47 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 195: Clarifications on key generation Message-ID: <20011007083047.J29389@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, This issue contains three requests: 1. change registration key -> session key for consistency ok 2. add text on key derivation in section 5.3 This key is not derived. The actual session key is added to to the message, as are all other keys destined for the Diameter nodes. So this request is denied 3. change in aaa-key-08 I will send a note to Charlie, who currently owns the source to consider this change. If folks agree with 1&2, I can close this issue. PatC From owner-aaa-wg@merit.edu Sun Oct 7 12:00:16 2001 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 MAA24262 for ; Sun, 7 Oct 2001 12:00:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 05BF191264; Sun, 7 Oct 2001 12:01:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9AEE91265; Sun, 7 Oct 2001 12:01:03 -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 4DD6391264 for ; Sun, 7 Oct 2001 12:01:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0BB75DDF9; Sun, 7 Oct 2001 12:01:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6609F5DDF8 for ; Sun, 7 Oct 2001 12:01:01 -0400 (EDT) Received: (qmail 29723 invoked by uid 500); 7 Oct 2001 15:45:06 -0000 Date: Sun, 7 Oct 2001 08:45:06 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 163: Error codes (recap) Message-ID: <20011007084506.K29389@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk The author of this issue has listed a set of error conditions, and the following request: a) Decide if all the situations quoted in which no error codes is mentioned needs a new error code (if so create them) [ed: and now the list of these error codes] 6. A Diameter node not supporting certificate revocation checks has calculated a safe period based on the expiration dates of the certificates. Once this safe period has finished, a CMS-Signed-Data arrives without any certificate. Q: How is this *any* different from a message that doesn't include a cert? It seems like if the cert has expired, so is the DSA (as per other rules in the spec). Therefore, the correct error is that the DSA has expired. 8. A Diameter message containing a CMS-Signed-Data AVP but with a different set of AVPs with its 'P' bit set to the ones chosen in the DSA establishment. Q: We've already agreed that if more than what was requested is present, it is ok. So this doesn't appear to be a problem 14. A Diameter message containing a CMS-Encrypted-Data AVP. The recipient isn't on the list of recipients specified in the RecipientInfos of the EnvelopedData and decides to indicate an error. Q: Why would this be an error? More likely, if there are AVPs missing (because they are encrypted for another node), DIAMETER_MISSING_AVPs would be returned. Don't believe a separate error is required here. 15. A Diameter message containing a CMS-Encrypted-Data AVP. An error occurs during decryption. Q: I belive you've stated after this issue was submitted that this is an invalid case. So, given the above, it looks like this issue should be rejected. PatC From owner-aaa-wg@merit.edu Sun Oct 7 12:25:27 2001 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 MAA24402 for ; Sun, 7 Oct 2001 12:25:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4462791265; Sun, 7 Oct 2001 12:26:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 163B791266; Sun, 7 Oct 2001 12:26: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 B594691265 for ; Sun, 7 Oct 2001 12:26:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 302505DDF8; Sun, 7 Oct 2001 12:26:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by segue.merit.edu (Postfix) with ESMTP id 48F165DD90 for ; Sun, 7 Oct 2001 12:26:23 -0400 (EDT) Received: from jariws1 ([62.248.239.236]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011007162502.WHUV15145.fep07-app.kolumbus.fi@jariws1>; Sun, 7 Oct 2001 19:25:02 +0300 Message-ID: <002201c14f4c$9e0ac7e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" Cc: "Glen Zorn" , "Harri Hakala (LMF)" , References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> <20011003093845.L32101@charizard.diameter.org> <004d01c14c39$88d51f80$8a1b6e0a@arenanet.fi> <20011007073721.C29389@charizard.diameter.org> Subject: Re: [AAA-WG]: How to use Diameter Accounting Date: Sun, 7 Oct 2001 19:25:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for > > Diameter servers. > > what does this fix have anything to do with this issue? This is a much larger > change that can have many other side effects. What is the purpose for this > request? Well... yes. I admit this isn't directly the issue at hand. I just went through the situation, and saw that in order to build a general-purpose account-record-saving device, it would have to announce a particular application. This change would only be relevant for the accounting servers, as clients obviously have to be application aware. This isn't a major issue for me, we could propably manage well with the first two parts of the proposed solution. Even if you had a general purpose account-record-saving device, you could still easily configure it with the app ids. On the other hand, I don't at present see the 'many other side effects'. Did you have any specific fears about them? Jari From owner-aaa-wg@merit.edu Sun Oct 7 15:05:23 2001 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 PAA25036 for ; Sun, 7 Oct 2001 15:05:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1F6C9126D; Sun, 7 Oct 2001 15:06:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FBAB91271; Sun, 7 Oct 2001 15:06: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 596369126D for ; Sun, 7 Oct 2001 15:06:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CAB3B5DD96; Sun, 7 Oct 2001 15:06:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6E3575DD95 for ; Sun, 7 Oct 2001 15:06:29 -0400 (EDT) Received: (qmail 29947 invoked by uid 500); 7 Oct 2001 18:50:33 -0000 Date: Sun, 7 Oct 2001 11:50:33 -0700 From: Pat Calhoun To: Jari Arkko Cc: Pat Calhoun , Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: How to use Diameter Accounting Message-ID: <20011007115033.A29936@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Pat Calhoun , Glen Zorn , "Harri Hakala (LMF)" , aaa-wg@merit.edu References: <0154633DAF7BD4119C360002A513AA03441CBE@efijont102> <20011003093845.L32101@charizard.diameter.org> <004d01c14c39$88d51f80$8a1b6e0a@arenanet.fi> <20011007073721.C29389@charizard.diameter.org> <002201c14f4c$9e0ac7e0$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002201c14f4c$9e0ac7e0$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Sun, Oct 07, 2001 at 07:25:02PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sun, Oct 07, 2001 at 07:25:02PM +0300, Jari Arkko wrote: > > > > 3. Modify 2.5 for allowing Relay for Acct-Application-Id also for > > > Diameter servers. > > > > what does this fix have anything to do with this issue? This is a much larger > > change that can have many other side effects. What is the purpose for this > > request? > > Well... yes. I admit this isn't directly the issue at hand. I just went through the situation, > and saw that in order to build a general-purpose account-record-saving device, > it would have to announce a particular application. This change would only be > relevant for the accounting servers, as clients obviously have to be application > aware. > > This isn't a major issue for me, we could propably manage well with the > first two parts of the proposed solution. Even if you had a general purpose > account-record-saving device, you could still easily configure it with the > app ids. > > On the other hand, I don't at present see the 'many other side effects'. Did > you have any specific fears about them? well, the issue here is one would then advertise for *all* accounting applications, instead of individually. One may receive more than it asked for :( The protocol can already advertise the acct apps it supports, without any changes to the spec. PatC From owner-aaa-wg@merit.edu Sun Oct 7 18:04:52 2001 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 SAA25647 for ; Sun, 7 Oct 2001 18:04:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55B1F9124A; Sun, 7 Oct 2001 18:05:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B5569127B; Sun, 7 Oct 2001 18:05: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 F10549124A for ; Sun, 7 Oct 2001 18:05:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BDE15DD9B; Sun, 7 Oct 2001 18:05:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E58425DD90 for ; Sun, 7 Oct 2001 18:05:54 -0400 (EDT) Received: (qmail 30208 invoked by uid 500); 7 Oct 2001 21:49:58 -0000 Date: Sun, 7 Oct 2001 14:49:58 -0700 From: Pat Calhoun To: Mark Eklund Cc: Joe Lau , pcpcalhoun@diameter.org, aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com Subject: Re: [AAA-WG]: Re: AAAH must be stateful Message-ID: <20011007144958.C30157@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Joe Lau , pcpcalhoun@diameter.org, aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com References: <200110041808.LAA01689@strtio1.cup.hp.com> <15292.44105.745855.945470@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15292.44105.745855.945470@gargle.gargle.HOWL>; from meklund@cisco.com on Thu, Oct 04, 2001 at 02:36:57PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 04, 2001 at 02:36:57PM -0400, Mark Eklund wrote: > Joe Lau writes: > > Pat, > > > > > I agree that the AAAh must be statefull anyway so there is no > > > gain in sending the FA keys to the HA > > > > Do you agree that AAAh must be statefull? So far, I have not > > heard disagreement from anyone. If you agree, can you put in a > > statement on the draft to make this requrirement clear so that > > implementors know that they MUST maintain session states on their > > AAAh server? > > I'm trying to think of when you must keep state. first, I meant transaction state. Let me explain. If the AAAh keeps transaction state on both the AMR and the HAR, it can easily create a pointer to have a relationship with both messages. Furthermore, part of the transaction state is to maintain the keys. This isn't rocket science, and it seems like this whole thread evolved into what is a problem that we fixed quite some time ago. Specifically, how the HA finds the session when the session-ids has changed. We've already handled this problem a long time ago in order to support handoffs in MIP. So, after reading the whole thread, and is still unclear to me that any additional work is required. > > 1. To know which AMR to send when you receive a HAA. The base spec > says, "A stateless agent is one that only maintains transaction > state.". I would consider this transaction state (including the > keys sent in the HAR), so this does not make the server stateful. ok, my mistake. I meant stateful as in transactions only, not session. > > 2. You receive an AMR for a session that you have already authenticated. > Thus you must remember the previous Session-Id for the communication > with the HAA. This would make you have to be stateful. But... > If you send the Session-Id back in a Class attribute, you don't have > to maintain state. this is trivial, and is part of transaction state. > > Are there any reasons a server MUST maintain state? no. PatC > > > > > > > >> Joe Lau wrote: > > > >> > > > >> > > The general idea was that the HA modify the SPI value in the > > > >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > >> > > > > >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft > > > >version 8, alpha. > > > >> > Did you mean MIP-FA-to-HA-SPI instead? Or, did I miss somthing in this > > > >> > discussion? > > > >> > > > > >> > Joe > > > >> > > > >> --------------E9A36EF30F9B970D0F625B9D > > > >> Content-Type: text/html; charset=us-ascii > > > >> Content-Transfer-Encoding: 7bit > > > >> > > > >> > > > >> > > > >> We have defined MIP-FA-to-HA-SPI  > > > >MIP-FA-to-MN-SPI  two AVPs, > > > >> why don't we put these AVPs in the MIP-FA-to-HA-Key  > > > >MIP-FA-to-MN-Key > > > >> to replace the MIP-Peer-SPI ?    In other words, > > > >see below > > > >>
      MIP-FA-to-MN-Key ::= < > > > >AVP Header: > > > >> 326 > > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-FA-to-MN-SPI } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Algorithm-Type } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Session-Key } > > > >> > > > >
           > > > >;            > > > >    > > > >> * [ AVP ] > > > >>

      MIP-FA-to-HA-Key ::= < > > > >AVP Header: > > > >> 328 > > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-FA-to-HA-SPI } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Algorithm-Type } > > > >> > > > >
           > > > >;            > > > >      > > > >> { MIP-Session-Key } > > > >> > > > >
           > > > >;            > > > >    > > > >> * [ AVP ] > > > >>
By the way, I don't think we can impletement stateless diameter > > > >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR > > > >> it must be returned in the HAA so it can be inserted into the AMA." and > > > >> so on. > > > >>
Because in redirect case, there is no guarantee that whay avps > > > >> you send, you will see all of them from the redirect answer. So all the > > > >> diameter have to keep the state. please correct me if I am > > > >wrong. > > > >>

-Michael > > > >>
  > > > >>

  > > > >>

Joe Lau wrote: > > > >>

> The general idea was that the HA modify the SPI > > > >> value in the > > > >>
> MIP-FA-to-HA-Key, and return the updated AVP in the HAA. > > > >>

But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8, > > > >> alpha. > > > >>
Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing > > > >> in this > > > >>
discussion? > > > >>

Joe

> > > >> > > > >> > > > >> --------------E9A36EF30F9B970D0F625B9D-- > > > >> > > > >> > > > > > > From owner-aaa-wg@merit.edu Sun Oct 7 18:05:46 2001 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 SAA25662 for ; Sun, 7 Oct 2001 18:05:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13B209127B; Sun, 7 Oct 2001 18:06:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9A2A9127C; Sun, 7 Oct 2001 18:06:50 -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 C96869127B for ; Sun, 7 Oct 2001 18:06:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55F555DD9B; Sun, 7 Oct 2001 18:06:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0BFE35DD90 for ; Sun, 7 Oct 2001 18:06:49 -0400 (EDT) Received: (qmail 30228 invoked by uid 500); 7 Oct 2001 21:50:52 -0000 Date: Sun, 7 Oct 2001 14:50:52 -0700 From: Pat Calhoun To: Joe Lau Cc: meklund@cisco.com, aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: AAAH must be stateful Message-ID: <20011007145052.D30157@charizard.diameter.org> Mail-Followup-To: Joe Lau , meklund@cisco.com, aaa-wg@merit.edu, cchen@erilab.com, meklund@knox6039.cisco.com, pcalhoun@diameter.org References: <200110041927.MAA01964@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110041927.MAA01964@strtio1.cup.hp.com>; from jlau@cup.hp.com on Thu, Oct 04, 2001 at 12:27:57PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 04, 2001 at 12:27:57PM -0700, Joe Lau wrote: > Mark, > > > > > Are there any reasons a server MUST maintain state? > > > > > > What about this one (as stated on draft 8, alpha)? > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > > > If you send back the Session identifier that you created for the HAR > > as a class attribute in the AMA, the FA MUST return it in subsequent > > authentications. Thus you can extract it for the next amr and use it. > > I am very interested on learning how to achieve this w/o requiring the > AAAh to maintain session states because I am facing such a problem right > now. Can you give more details on how you can achieve your last statement? > > "Thus you can extract it for the next amr and use it." > > > Please use the following example. > > AMR(session_id_1) -------------------+ > | > +------------> AAAh (stateless) > | | | > AMR(session_id_2) -------------------+ | | > | | > HAR(sid_3)| | HAR(sid_4) > | | > v v > Home Agent > > The two AMR's came from different FA's, so session_id_1 != session_id_2 > But the draft says sid_3 must equal sid_4 on the HAR's. Right, and this is already handled in the protocol. We added such provisions in the protocol to handle handoffs across foreign agents. PatC From owner-aaa-wg@merit.edu Sun Oct 7 18:07:27 2001 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 SAA25685 for ; Sun, 7 Oct 2001 18:07:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B08049127C; Sun, 7 Oct 2001 18:08:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 845499127D; Sun, 7 Oct 2001 18:08: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 700B89127C for ; Sun, 7 Oct 2001 18:08:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F08CA5DD9B; Sun, 7 Oct 2001 18:08:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8E7205DD90 for ; Sun, 7 Oct 2001 18:08:32 -0400 (EDT) Received: (qmail 30250 invoked by uid 500); 7 Oct 2001 21:52:36 -0000 Date: Sun, 7 Oct 2001 14:52:36 -0700 From: Pat Calhoun To: Joe Lau Cc: mjones@matrixmuse.com, aaa-wg@merit.edu, cchen@erilab.com, meklund@cisco.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: AAAH must be stateful Message-ID: <20011007145236.E30157@charizard.diameter.org> Mail-Followup-To: Joe Lau , mjones@matrixmuse.com, aaa-wg@merit.edu, cchen@erilab.com, meklund@cisco.com, pcalhoun@diameter.org References: <200110052311.QAA04052@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110052311.QAA04052@strtio1.cup.hp.com>; from jlau@cup.hp.com on Fri, Oct 05, 2001 at 04:11:36PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Don't see why one would use NO_STATE_MAINTAINED for MIP application. It was specifically designed to handle other apps that do not require any state. PatC On Fri, Oct 05, 2001 at 04:11:36PM -0700, Joe Lau wrote: > Mark, > > > I do have a question on the STR generation though: Assuming the AAAH > > included Auth-Session-State=NO_STATE_MAINTAINED in the HAR and a handoff > > results in the AMR being sent to a different AAAH than that which originally > > authorized the session, does this imply that the HA is not required to send > > an STR to the original AAAH? > > Good question. This needs to be clarified in the draft. > > > > 2) Whether AAAH must be stateful to meet the above requirement > > > > If the requirement in (1) remains a MUST, I believe the AAAH MUST also be > > stateful. I don't think the Class attribute would help here unless it was > > somehow being passed down to the MN which echoed it back in subsequent MIP > > messages for the same session (regardless of FA). > > I agree. > > Regards, > > Joe Lau From owner-aaa-wg@merit.edu Sun Oct 7 18:09:09 2001 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 SAA25707 for ; Sun, 7 Oct 2001 18:09:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B2089127D; Sun, 7 Oct 2001 18:10:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66ED49127E; Sun, 7 Oct 2001 18:10: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 5AAAF9127D for ; Sun, 7 Oct 2001 18:10:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAD9B5DD9B; Sun, 7 Oct 2001 18:10:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 555EC5DD90 for ; Sun, 7 Oct 2001 18:10:14 -0400 (EDT) Received: (qmail 30282 invoked by uid 500); 7 Oct 2001 21:54:18 -0000 Date: Sun, 7 Oct 2001 14:54:18 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP Message-ID: <20011007145418.G30157@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2F@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA2F@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Thu, Oct 04, 2001 at 05:05:31PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk > After this long talk my question here is that, is there a specific reason > why the User-Name AVP is included into some of the base protocol commands as > a mandatory AVP and some of them don't have it? because some messages have nothing to do with specific users (e.g. watchdog messages). PatC From owner-aaa-wg@merit.edu Sun Oct 7 18:12:21 2001 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 SAA25751 for ; Sun, 7 Oct 2001 18:12:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDFFD9127E; Sun, 7 Oct 2001 18:13:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9C449127F; Sun, 7 Oct 2001 18:13: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 997A99127E for ; Sun, 7 Oct 2001 18:13:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 246085DD9B; Sun, 7 Oct 2001 18:13:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8460D5DD90 for ; Sun, 7 Oct 2001 18:13:26 -0400 (EDT) Received: (qmail 30317 invoked by uid 500); 7 Oct 2001 21:57:30 -0000 Date: Sun, 7 Oct 2001 14:57:30 -0700 From: Pat Calhoun To: Joe Lau Cc: cchen@erilab.com, aaa-wg@merit.edu, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com, pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 Message-ID: <20011007145730.I30157@charizard.diameter.org> Mail-Followup-To: Joe Lau , cchen@erilab.com, aaa-wg@merit.edu, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com, pcalhoun@diameter.org References: <200110031853.LAA00424@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110031853.LAA00424@strtio1.cup.hp.com>; from jlau@cup.hp.com on Wed, Oct 03, 2001 at 11:53:52AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree with Michael that _all_ diameter have to keep state. > Another good example would be the following statement on section 1.2. > > During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see figure 2). Of > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > initiated on behalf of a given mobile node's session. > > This will require the AAAH server to be stateful. > > Anyone disagree on this? I do. Keeping transaction state is sufficient to handle this. PatC From owner-aaa-wg@merit.edu Sun Oct 7 22:33:56 2001 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 WAA29317 for ; Sun, 7 Oct 2001 22:33:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2818891280; Sun, 7 Oct 2001 22:34:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDEF291281; Sun, 7 Oct 2001 22:34: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 C985391280 for ; Sun, 7 Oct 2001 22:34:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4378C5DDCD; Sun, 7 Oct 2001 22:34:55 -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 994475DDAE for ; Sun, 7 Oct 2001 22:34:54 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f982VpY03996 for ; Mon, 8 Oct 2001 05:31:51 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Oct 2001 05:33:32 +0300 Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 8 Oct 2001 05:33:32 +0300 Message-ID: <95A2D1413F29D311B3450008C773628903740121@beeis03nok> From: qing.roger.liu@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: Missing Session Termination Cause in Section 8.1 5 Date: Mon, 8 Oct 2001 05:33:29 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Liu Qing Submitter email address: qing.roger.liu@nokia.com Date first submitted: 2001-10-08 Reference: Document: base-08-alpha Comment type: T Priority: 1 Section: 8.15 Rationale/Explanation of issue: What termination cause should be sent when terminating a session due to the "Session-Timeout expire on Access Device"? (refer to the 8.1: "OPEN Session-Timeout Expires on Access Device send STR Discon") Requested change: Add new termination cause code, e.g. DIAMETER_SESSION_TIMEOUT 6 Access Device terminate the session when session-timeout expires. From owner-aaa-wg@merit.edu Sun Oct 7 23:08:21 2001 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 XAA29623 for ; Sun, 7 Oct 2001 23:08:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF01491282; Sun, 7 Oct 2001 23:09:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92B0391283; Sun, 7 Oct 2001 23:09: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 92DC791282 for ; Sun, 7 Oct 2001 23:09:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2103B5DDAE; Sun, 7 Oct 2001 23:09:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5D8E55DD9A for ; Sun, 7 Oct 2001 23:09:25 -0400 (EDT) Received: (qmail 30928 invoked by uid 500); 8 Oct 2001 02:53:27 -0000 Date: Sun, 7 Oct 2001 19:53:27 -0700 From: Pat Calhoun To: qing.roger.liu@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Missing Session Termination Cause in Section 8.1 5 Message-ID: <20011007195327.A30915@charizard.diameter.org> Mail-Followup-To: qing.roger.liu@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: <95A2D1413F29D311B3450008C773628903740121@beeis03nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <95A2D1413F29D311B3450008C773628903740121@beeis03nok>; from qing.roger.liu@nokia.com on Mon, Oct 08, 2001 at 05:33:29AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk I have taken care of this issue already, but will log it tomorrow. PatC On Mon, Oct 08, 2001 at 05:33:29AM +0300, qing.roger.liu@nokia.com wrote: > Submitter name: Liu Qing > Submitter email address: qing.roger.liu@nokia.com > Date first submitted: 2001-10-08 > Reference: > Document: base-08-alpha > Comment type: T > Priority: 1 > Section: 8.15 > Rationale/Explanation of issue: > > What termination cause should be sent when terminating a session due to the > "Session-Timeout expire on Access Device"? > (refer to the 8.1: "OPEN Session-Timeout Expires on Access Device send > STR Discon") > > Requested change: > > Add new termination cause code, e.g. > > DIAMETER_SESSION_TIMEOUT 6 > Access Device terminate the session when session-timeout expires. From owner-aaa-wg@merit.edu Mon Oct 8 08:40:44 2001 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 IAA20109 for ; Mon, 8 Oct 2001 08:40:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C49F91297; Mon, 8 Oct 2001 08:41:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01E1191298; Mon, 8 Oct 2001 08: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 69B6D91297 for ; Mon, 8 Oct 2001 08:41:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB1395DDAB; Mon, 8 Oct 2001 08:41:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C72965DD9D for ; Mon, 8 Oct 2001 08:41:52 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA30783 for ; Mon, 8 Oct 2001 14:40:46 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Possible to do handover with HA in foreign network and multiple AAAH in realm? Date: Mon, 8 Oct 2001 14:41:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The scenario is as follows: The mobile node authenticates with AAAH1 via FA1 and is allocated a home agent in the foreign network. The MN then moves to FA2 and passes it the HA-address. FA2 sends an AMR that is handled by AAAH2 serving the same realm as AAAH1. Neither FA2 nor AAAH2 has any knowledge of the existing session beyond that of the MIP-Mobile-Home-Agent avp. Note that this is the ip address of the interface that the home agent uses to tunnel Mobile Ip traffic. There is no reason to expect this to be the same interface used for diameter traffic, in fact this is even unlikely. Since the mobile node has no knowledge of anything but Mobile Ip it cannot be expected to pass the diameter uri of the HA. Is this problem even solvable? If the HA were in a home network you could potentially use configured knowledge to map from ip to uri. If not the only reasonable response seems to be to reject the authentication due to lack of information. j From owner-aaa-wg@merit.edu Mon Oct 8 11:01:33 2001 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 LAA23175 for ; Mon, 8 Oct 2001 11:01:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF8489129D; Mon, 8 Oct 2001 11:02:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFAB99129E; Mon, 8 Oct 2001 11:02:41 -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 277B49129D for ; Mon, 8 Oct 2001 11:02:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B4385DDB7; Mon, 8 Oct 2001 11:02:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 16B615DDCE for ; Mon, 8 Oct 2001 11:02:26 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA21008 for ; Mon, 8 Oct 2001 08:01:03 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA25360 for ; Mon, 8 Oct 2001 08:01:02 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0B2FHT>; Mon, 8 Oct 2001 10:01:02 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Fredrik Johansson'" , AAA Listan Subject: RE: [AAA-WG]: Possible to do handover with HA in foreign network and multiple AAAH in realm? Date: Mon, 8 Oct 2001 10:00:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > Is this problem even solvable? If the HA were in a home network you > could potentially use configured knowledge to map from ip to uri. If not > the only reasonable response seems to be to reject the authentication > due to lack of information. or forward the AMR to an AAAH in your domain that may know something. Multiple AAAHs in home domain must somehow be able to share information. Protocol itself will not do much without proper configuration. -Panos -----Original Message----- From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] Sent: Monday, October 08, 2001 7:41 AM To: AAA Listan Subject: [AAA-WG]: Possible to do handover with HA in foreign network and multiple AAAH in realm? The scenario is as follows: The mobile node authenticates with AAAH1 via FA1 and is allocated a home agent in the foreign network. The MN then moves to FA2 and passes it the HA-address. FA2 sends an AMR that is handled by AAAH2 serving the same realm as AAAH1. Neither FA2 nor AAAH2 has any knowledge of the existing session beyond that of the MIP-Mobile-Home-Agent avp. Note that this is the ip address of the interface that the home agent uses to tunnel Mobile Ip traffic. There is no reason to expect this to be the same interface used for diameter traffic, in fact this is even unlikely. Since the mobile node has no knowledge of anything but Mobile Ip it cannot be expected to pass the diameter uri of the HA. Is this problem even solvable? If the HA were in a home network you could potentially use configured knowledge to map from ip to uri. If not the only reasonable response seems to be to reject the authentication due to lack of information. j From owner-aaa-wg@merit.edu Mon Oct 8 11:40:19 2001 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 LAA23925 for ; Mon, 8 Oct 2001 11:40:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1E439121A; Mon, 8 Oct 2001 11:41:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97F169129E; Mon, 8 Oct 2001 11:41: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 99CBE9121A for ; Mon, 8 Oct 2001 11:41:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22B815DDB7; Mon, 8 Oct 2001 11:41:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D455C5DDAB for ; Mon, 8 Oct 2001 11:41:29 -0400 (EDT) Received: (qmail 4885 invoked by uid 500); 8 Oct 2001 15:25:25 -0000 Date: Mon, 8 Oct 2001 08:25:25 -0700 From: Pat Calhoun To: Ext-Venkata.Ghadiyaram@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Outstanding unanswered requests. Message-ID: <20011008082525.A4639@charizard.diameter.org> Mail-Followup-To: Ext-Venkata.Ghadiyaram@nokia.com, aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B202306CF69@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9E3407CE45911B4097632389B77B202306CF69@esebe014.NOE.Nokia.com>; from Ext-Venkata.Ghadiyaram@nokia.com on Thu, Oct 04, 2001 at 10:44:43AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Is there any limit on the number of outstanding unanswered requests within a > single session at a diameter server. yes, 2^32 PatC From owner-aaa-wg@merit.edu Mon Oct 8 15:11:01 2001 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 PAA29181 for ; Mon, 8 Oct 2001 15:11:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBA7A9121F; Mon, 8 Oct 2001 15:12:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FB53912A0; Mon, 8 Oct 2001 15:12: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 996EA9121F for ; Mon, 8 Oct 2001 15:12:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 145825DDBB; Mon, 8 Oct 2001 15:12:04 -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 323805DDAD for ; Mon, 8 Oct 2001 15:12:03 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA08419; Mon, 8 Oct 2001 15:10:22 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA03531; Mon, 8 Oct 2001 15:11:04 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15297.64072.168855.255597@gargle.gargle.HOWL> Date: Mon, 8 Oct 2001 15:11:04 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: MIP-FA-to-[HA|MN]-Key not needed in HAR X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 8-Oct-01 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00029.html Document: mobileip Comment type: Technical Priority: 1 Section: 8.1 Rationale/Explanation of issue: Since the home agent has no use for the MIP-FA-to-HA-Key or the MIP-FA-to-MN-key, there is no need to send it to the home agent. Requested change: Change the 0-1 in the HAR column for rows MIP-FA-to-HA-Key and MIP-FA-to-MN-key to 0. From owner-aaa-wg@merit.edu Mon Oct 8 15:21:47 2001 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 PAA29388 for ; Mon, 8 Oct 2001 15:21:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9805D91221; Mon, 8 Oct 2001 15:22:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63EB9912A0; Mon, 8 Oct 2001 15:22:49 -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 5389E91221 for ; Mon, 8 Oct 2001 15:22:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B773B5DDBB; Mon, 8 Oct 2001 15:22:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 32E4C5DDAD for ; Mon, 8 Oct 2001 15:22:47 -0400 (EDT) Received: (qmail 6198 invoked by uid 500); 8 Oct 2001 19:06:41 -0000 Date: Mon, 8 Oct 2001 12:06:41 -0700 From: Pat Calhoun To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: MIP-FA-to-[HA|MN]-Key not needed in HAR Message-ID: <20011008120641.B6178@charizard.diameter.org> Mail-Followup-To: Mark Eklund , aaa-wg@merit.edu References: <15297.64072.168855.255597@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15297.64072.168855.255597@gargle.gargle.HOWL>; from meklund@cisco.com on Mon, Oct 08, 2001 at 03:11:04PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Seems like we've gone back and forth on this issue in the past months. Do folks agree with this one, which requires the aaah to add the AVP in the associated AMA? PatC On Mon, Oct 08, 2001 at 03:11:04PM -0400, Mark Eklund wrote: > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 8-Oct-01 > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00029.html > Document: mobileip > Comment type: Technical > Priority: 1 > Section: 8.1 > Rationale/Explanation of issue: > Since the home agent has no use for the MIP-FA-to-HA-Key or the > MIP-FA-to-MN-key, there is no need to send it to the home agent. > > Requested change: > Change the 0-1 in the HAR column for rows MIP-FA-to-HA-Key and > MIP-FA-to-MN-key to 0. > From owner-aaa-wg@merit.edu Mon Oct 8 15:39:59 2001 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 PAA29676 for ; Mon, 8 Oct 2001 15:39:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0CDC912A0; Mon, 8 Oct 2001 15:41:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A84CE912A2; Mon, 8 Oct 2001 15:41:02 -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 A66CF912A0 for ; Mon, 8 Oct 2001 15:41:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 282855DDBB; Mon, 8 Oct 2001 15:41:01 -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 4A2CE5DDAD for ; Mon, 8 Oct 2001 15:41:00 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA09202; Mon, 8 Oct 2001 15:39:16 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA03545; Mon, 8 Oct 2001 15:40:00 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15298.272.23680.7743@gargle.gargle.HOWL> Date: Mon, 8 Oct 2001 15:40:00 -0400 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: Required AVPs in grouped key AVPs X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 8-Oct-01 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html Document: mobileip Comment type: Technical Priority: 1 Section: 6.0 Rationale/Explanation of issue: These changes came out as a result of a discussion as to what AVPs would be needed with respect to keyed avps. 1. Create a new AVP, MIP-AAA-SPI (or reuse MIP-MN-AAA-SPI) and add it to MIP-MN-to-FA-Key and MIP-MN-to-HA-Key. This will be used the AAA SPI in the Unsolicited MN-[HA|FA] key material request. 2. Remove the MIP-Peer-SPI AVP 3. Replace MIP-Peer-SPI in MIP-FA-to-MN-Key with MIP-FA-to-MN-SPI. 4. Replace MIP-Peer-SPI in MIP-FA-to-HA-Key with MIP-FA-to-HA-SPI. Requested change: See the Reference: above for a summary of the required AVPs. MIP-Key-Lifetime is in flux as to if there will only be one per diameter packet or one per key AVP, so this will have to be addressed elsewhere. From owner-aaa-wg@merit.edu Mon Oct 8 17:17:28 2001 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 RAA02469 for ; Mon, 8 Oct 2001 17:17:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96A66912A8; Mon, 8 Oct 2001 17:18:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62346912A9; Mon, 8 Oct 2001 17:18: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 5A3EC912A8 for ; Mon, 8 Oct 2001 17:18:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB60F5DDC6; Mon, 8 Oct 2001 17:18:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 7BC185DDB2 for ; Mon, 8 Oct 2001 17:18:43 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id 3E0821F7F5; Mon, 8 Oct 2001 14:17:19 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id OAA05963; Mon, 8 Oct 2001 14:18:50 -0700 (PDT) Date: Mon, 8 Oct 2001 14:18:50 -0700 (PDT) From: Joe Lau Message-Id: <200110082118.OAA05963@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 Cc: aaa-wg@merit.edu, cchen@erilab.com, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, > > I agree with Michael that _all_ diameter have to keep state. > > Another good example would be the following statement on section 1.2. > > > > During the creation of the HAR, the AAAH MUST use a different session > > identifier than the one used in the AMR/AMA (see figure 2). Of > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > initiated on behalf of a given mobile node's session. > > > > This will require the AAAH server to be stateful. > > > > Anyone disagree on this? > > I do. Keeping transaction state is sufficient to handle this. I need help to understand two things: 1) Why must the AAAH use the _same_ session id for _all_ HARs initiated on behalf of a given MN's session? 2) Can you give an example where an AAAh _must_ keep _sesssion_ state? Regards, Joe Lau From owner-aaa-wg@merit.edu Mon Oct 8 17:56:24 2001 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 RAA03124 for ; Mon, 8 Oct 2001 17:56:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E55DE912A7; Mon, 8 Oct 2001 17:57:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0E50912A9; Mon, 8 Oct 2001 17:57: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 96B20912A7 for ; Mon, 8 Oct 2001 17:57:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E1DE5DDB2; Mon, 8 Oct 2001 17:57:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7FC135DDA8 for ; Mon, 8 Oct 2001 17:57:36 -0400 (EDT) Received: (qmail 7305 invoked by uid 500); 8 Oct 2001 21:41:32 -0000 Date: Mon, 8 Oct 2001 14:41:32 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, cchen@erilab.com, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com Subject: Re: [AAA-WG]: Section 8.1 Message-ID: <20011008144132.A7268@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu, cchen@erilab.com, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com References: <200110082118.OAA05963@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110082118.OAA05963@strtio1.cup.hp.com>; from jlau@cup.hp.com on Mon, Oct 08, 2001 at 02:18:50PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Oct 08, 2001 at 02:18:50PM -0700, Joe Lau wrote: > Hi Pat, > > > > I agree with Michael that _all_ diameter have to keep state. > > > Another good example would be the following statement on section 1.2. > > > > > > During the creation of the HAR, the AAAH MUST use a different session > > > identifier than the one used in the AMR/AMA (see figure 2). Of > > > course, the AAAH MUST use the _same_ session identifier for _all_ HARs > > > initiated on behalf of a given mobile node's session. > > > > > > This will require the AAAH server to be stateful. > > > > > > Anyone disagree on this? > > > > I do. Keeping transaction state is sufficient to handle this. > > I need help to understand two things: > > 1) Why must the AAAH use the _same_ session id for _all_ HARs initiated on > behalf of a given MN's session? it doesn't. Since we knew that mobiles could move from one FA to another, we could never guarantee that the same AAAh would be hit each time. Therefore, since this is not a constant, there is no guarantee that the HA would always receive the same session id in the HAR. For that reason, we allow different session ids in the HAR, and the HA must do some checking. > 2) Can you give an example where an AAAh _must_ keep _sesssion_ state? sure. limiting the number of active sessions a user has. PatC From owner-aaa-wg@merit.edu Mon Oct 8 18:09:19 2001 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 SAA03266 for ; Mon, 8 Oct 2001 18:09:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C9EA912A9; Mon, 8 Oct 2001 18:10:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E4C6912AA; Mon, 8 Oct 2001 18:10:33 -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 3C70A912A9 for ; Mon, 8 Oct 2001 18:10:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B161B5DDB2; Mon, 8 Oct 2001 18:10:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by segue.merit.edu (Postfix) with ESMTP id 8B92A5DDA8 for ; Mon, 8 Oct 2001 18:10:31 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 57E72FCC; Mon, 8 Oct 2001 15:09:07 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id PAA06036; Mon, 8 Oct 2001 15:10:38 -0700 (PDT) Date: Mon, 8 Oct 2001 15:10:38 -0700 (PDT) From: Joe Lau Message-Id: <200110082210.PAA06036@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [AAA-WG]: Section 8.1 Cc: aaa-wg@merit.edu, cchen@erilab.com, fredrik.johansson@ipunplugged.com, meklund@knox6039.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, > > 2) Can you give an example where an AAAh _must_ keep _sesssion_ state? > > sure. limiting the number of active sessions a user has. Can you give another example please. I am greedy :=). Thank! Joe Lau From owner-aaa-wg@merit.edu Mon Oct 8 18:10:52 2001 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 SAA03319 for ; Mon, 8 Oct 2001 18:10:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EE1F912AA; Mon, 8 Oct 2001 18:12:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6080E912AB; Mon, 8 Oct 2001 18:12:02 -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 551E2912AA for ; Mon, 8 Oct 2001 18:12:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BABD75DDB2; Mon, 8 Oct 2001 18:11:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A82935DDA8 for ; Mon, 8 Oct 2001 18:11:59 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E279574 for ; Mon, 8 Oct 2001 18:10:40 -0400 (EDT) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: CMS Security for Mobile-IP Session Keys Date: Mon, 8 Oct 2001 18:08:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a couple rookie questions about CMS security as applied to Diameter Mobile-IP messages. Q1: Suppose the AAAH receives an AMR from some FA, and the AAAH wants to hide the session keys being returned in the AMA, but the FA has not previously set up a DSA with the AAAH. Does the AAAH then reject the AMR with a Result-Code of DIAMETER_NO_DSA_ESTABLISHED? Or is it the FA that dictates whether CMS will be used, i.e. if no DSA has been set up by the FA, then the AAAH can't hide his AMA's session keys? Q2: Suppose a Diameter Mobile-IP AAA Home server receives an AMR in which the AAAF has offered to allocate the HA in the visited network. Suppose the AAAH wants to accept the offer, and the AAAH wants to use CMS to hide the session keys he will be sending to the foreign HA via the HAR. Before sending the HAR, the AAAH will want to first set up a DSA with the HA by sending a DSAR. But the AAAH doesn't yet know who the HA is. The best he can do is to send the DSAR with the Destination-Realm set to the AMR's Origin-Realm, and with no Destination-Host. In this case, it seems the DSAR would be consumed by some AAA server in the foreign network, so the AAAH would end up with a DSA with some AAAF, rather than with the HA. Bob K. From owner-aaa-wg@merit.edu Tue Oct 9 02:25:45 2001 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 CAA22677 for ; Tue, 9 Oct 2001 02:25:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FE6091206; Tue, 9 Oct 2001 02:26:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E41B79122A; Tue, 9 Oct 2001 02:26:49 -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 DDC1591206 for ; Tue, 9 Oct 2001 02:26:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 681145DDB4; Tue, 9 Oct 2001 02:26:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 9AB145DDA2 for ; Tue, 9 Oct 2001 02:26:47 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA21729; Tue, 9 Oct 2001 08:25:21 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , "Mark Eklund" Cc: Subject: RE: [AAA-WG]: Issue: MIP-FA-to-[HA|MN]-Key not needed in HAR Date: Tue, 9 Oct 2001 08:25:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011008120641.B6178@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Seems like that's the only way to go, since not all information is available in the AAAh when creating the HAR, the SPI is allocated by the HA. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 8 oktober 2001 21:07 >To: Mark Eklund >Cc: aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Issue: MIP-FA-to-[HA|MN]-Key not needed in HAR > > >Seems like we've gone back and forth on this issue in the past >months. Do folks >agree with this one, which requires the aaah to add the AVP in the >associated >AMA? > >PatC >On Mon, Oct 08, 2001 at 03:11:04PM -0400, Mark Eklund wrote: >> Submitter name: Mark Eklund >> Submitter email address: meklund@cisco.com >> Date first submitted: 8-Oct-01 >> Reference: >http://www.merit.edu/mail.archives/aaa-wg/2001->10/msg00029.html >> >Document: mobileip >> Comment type: Technical >> >Priority: 1 >> Section: 8.1 >> Rationale/Explanation of issue: >> Since the home agent has no use for the MIP-FA-to-HA-Key or the >> MIP-FA-to-MN-key, there is no need to send it to the home agent. >> >> Requested change: >> Change the 0-1 in the HAR column for rows MIP-FA-to-HA-Key and >> MIP-FA-to-MN-key to 0. >> From owner-aaa-wg@merit.edu Tue Oct 9 03:15:52 2001 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 DAA25548 for ; Tue, 9 Oct 2001 03:15:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 47C3E9122B; Tue, 9 Oct 2001 03:17:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FAD09122E; Tue, 9 Oct 2001 03:17:06 -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 B05489122B for ; Tue, 9 Oct 2001 03:17:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13B7C5DDB4; Tue, 9 Oct 2001 03:17: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 14CFC5DDA2 for ; Tue, 9 Oct 2001 03:17:04 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f997GCf25693 for ; Tue, 9 Oct 2001 10:16:12 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Oct 2001 10:15:33 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M649LW5>; Tue, 9 Oct 2001 10:14:56 +0300 Message-ID: <9E3407CE45911B4097632389B77B202306CF71@esebe014.NOE.Nokia.com> From: Ext-Venkata.Ghadiyaram@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Outstanding unanswered requests. Date: Tue, 9 Oct 2001 10:14:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Does this mean that a diameter client, within a single session, can send upto 2^32 messages without receiving an answer. In this case what action is to be taken by the server if processing of one of these messages results in an error answer. What should be done to the subsequent messages? Should they be processed or ignored. Regards, Kishore -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: 08. October 2001 18:25 To: Ghadiyaram Venkata (EXT-TataConsultancy/Helsinki) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Outstanding unanswered requests. > Is there any limit on the number of outstanding unanswered requests within a > single session at a diameter server. yes, 2^32 PatC From owner-aaa-wg@merit.edu Tue Oct 9 05:39:49 2001 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 FAA26374 for ; Tue, 9 Oct 2001 05:39:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 173E39122E; Tue, 9 Oct 2001 05:40:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB65F91230; Tue, 9 Oct 2001 05: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 B09369122E for ; Tue, 9 Oct 2001 05:40:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34CAA5DDB1; Tue, 9 Oct 2001 05:40:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 42BB75DD90 for ; Tue, 9 Oct 2001 05:40:51 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f999dKC19294 for ; Tue, 9 Oct 2001 11:39:20 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA12048; Tue, 9 Oct 2001 11:39:16 +0200 (MET DST) Message-ID: <3BC2C607.7734CE7A@rioja.ericsson.se> Date: Tue, 09 Oct 2001 11:40:23 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 181: Digital encryption + signature in CMS-Sec References: <20011007081026.H29389@charizard.diameter.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Pat Calhoun wrote: > > All, > > Is the current text in section 6.3 not sufficient to handle this case? > Essentially, what it is stating is that it is OK to sign AVPs that > weren't intended to be signed when such a case arises. Hi Pat, sorry for the latency... it's OK for me. What I was suggesting is a natural consequence of text in section 6.3. No sense to explain everything ad infinitum :-)) Regards // M.A. -- Miguel Angel Monjas Llorente Systems Engineer, GSM/UMTS Systems Management Ericsson España, S.A. (EEM) UMTS/GSM Databases Tel: +34 91 3393605 Mob: +34 629 570196 Fax: +34 91 3392538 Ombú 3, 10th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Tue Oct 9 05:43:09 2001 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 FAA26411 for ; Tue, 9 Oct 2001 05:43:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A08DA91230; Tue, 9 Oct 2001 05:44:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C64A91232; Tue, 9 Oct 2001 05: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 3781191230 for ; Tue, 9 Oct 2001 05:44:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B54D85DDB1; Tue, 9 Oct 2001 05:44:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by segue.merit.edu (Postfix) with ESMTP id 79FCB5DD90 for ; Tue, 9 Oct 2001 05:44:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by dummy.domain.name (Sendmail-smtprelay) with SMTP id 74719178FF for ; Tue, 9 Oct 2001 10:42:46 +0100 (WEST) Received: from ua.pt (mail.ua.pt [193.136.80.80]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id E4CD9178FB for ; Tue, 9 Oct 2001 10:42:45 +0100 (WEST) Received: from [193.136.92.216] (HELO newton) by ua.pt (CommuniGate Pro SMTP 3.5b3) with SMTP id 10430208 for aaa-wg@merit.edu; Tue, 09 Oct 2001 10:42:44 +0100 Message-ID: <009901c150a6$d8769d90$d85c88c1@newton> From: "Susana Sargento" To: References: <20011007081026.H29389@charizard.diameter.org> <3BC2C607.7734CE7A@rioja.ericsson.se> Subject: [AAA-WG]: DIAMETER functions Date: Tue, 9 Oct 2001 10:43:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I would like some help on DIAMETER. In the Internet Draft: AAA Requirements for IP Telephony/Multimedia, it is explained how SIP interacts with the AAA (DIAMETER). In the Register phase how is the AAA message from the proxy server to the DIAMETER? Is the SIP message included as an AVP? In the INVITE phase, the SIP server sends an authorization request to the DIAMETER which may include policy decisions. Is there any document where I can find more detail about this? Because it is said in general, but it is not specified exactly how it is done. Is there any implementation of DIAMETER with SIP and QoS policy authentication? Also in this draft it is said that there are some policy functions that should be included in DIAMETER, like performing authentication taking into account the time of day, etc. Is there any document that specifies the messages that are sent to and from the DIAMETER server which include those policy decisions? Also, how to authenticate with DIAMETER taking into account the bandwidth required for the session as well as the QoS requirements? Thanks for your attention, Susana From owner-aaa-wg@merit.edu Tue Oct 9 05:56:52 2001 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 FAA26483 for ; Tue, 9 Oct 2001 05:56:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7901891232; Tue, 9 Oct 2001 05:58:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46EFD91235; Tue, 9 Oct 2001 05:58: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 01C3F91232 for ; Tue, 9 Oct 2001 05:58:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 701025DDB1; Tue, 9 Oct 2001 05:58:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 7C8C95DD90 for ; Tue, 9 Oct 2001 05:58:04 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f999uUL02391; Tue, 9 Oct 2001 11:56:31 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA13460; Tue, 9 Oct 2001 11:55:53 +0200 (MET DST) Message-ID: <3BC2C9EC.6EB5F062@rioja.ericsson.se> Date: Tue, 09 Oct 2001 11:57:00 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 163: Error codes (recap) References: <20011007084506.K29389@charizard.diameter.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Pat Calhoun wrote: > > The author of this issue has listed a set of error conditions, and the > following request: > > a) Decide if all the situations quoted in which no error codes is > mentioned needs a new error code (if so create them) > > [ed: and now the list of these error codes] > > 6. A Diameter node not supporting certificate revocation checks has > calculated a safe period based on the expiration dates of the > certificates. Once this safe period has finished, a CMS-Signed-Data > arrives without any certificate. > > Q: How is this *any* different from a message that doesn't include a cert? > It seems like if the cert has expired, so is the DSA (as per other rules > in the spec). Therefore, the correct error is that the DSA has expired. Right. > 8. A Diameter message containing a CMS-Signed-Data AVP but with a different > set of AVPs with its 'P' bit set to the ones chosen in the DSA establishment. > > Q: We've already agreed that if more than what was requested is present, > it is ok. So this doesn't appear to be a problem You're supposing that more AVPs than the specified by means of Expected-Signed-AVP AVPs are being signed. In such a scenario, your comment is true. What happens if not all the AVPs requested as signed are actually signed (that is, they don't have its 'P' bit set). > 14. A Diameter message containing a CMS-Encrypted-Data AVP. The recipient > isn't on the list of recipients specified in the RecipientInfos of the > EnvelopedData and decides to indicate an error. > > Q: Why would this be an error? More likely, if there are AVPs missing (because > they are encrypted for another node), DIAMETER_MISSING_AVPs would be > returned. Don't believe a separate error is required here. OK. I was only quoting the previous version of specification that said: "the recipient MUST check to see if it is on the list of recipients specified in the RecipientInfos of the EnvelopedData. If not, the recipient MAY choose to process the message or indicate an error." Nowadays it has been changed using an specific error code: DIAMETER_NO_DSA_RECIPIENT > 15. A Diameter message containing a CMS-Encrypted-Data AVP. An error > occurs during decryption. > > Q: I belive you've stated after this issue was submitted that this is an > invalid case. Yes... > So, given the above, it looks like this issue should be rejected. Yes. It only remains some obscurity on error situation #8. The rest is fine. Regards // M.A. -- Miguel Angel Monjas Llorente Systems Engineer, GSM/UMTS Systems Management Ericsson España, S.A. (EEM) UMTS/GSM Databases Tel: +34 91 3393605 Mob: +34 629 570196 Fax: +34 91 3392538 Ombú 3, 10th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Tue Oct 9 07:19:07 2001 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 HAA27385 for ; Tue, 9 Oct 2001 07:19:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 670AD91235; Tue, 9 Oct 2001 07:20:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32EA791237; Tue, 9 Oct 2001 07:20: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 36D9A91235 for ; Tue, 9 Oct 2001 07:20:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD6B35DDA1; Tue, 9 Oct 2001 07:20:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 8842B5DD90 for ; Tue, 9 Oct 2001 07:20:11 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15qutx-0007Se-00; Tue, 09 Oct 2001 04:18:21 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Susana Sargento" Cc: Subject: Re: [AAA-WG]: DIAMETER functions References: <20011007081026.H29389@charizard.diameter.org> <3BC2C607.7734CE7A@rioja.ericsson.se> <009901c150a6$d8769d90$d85c88c1@newton> Message-Id: Date: Tue, 09 Oct 2001 04:18:21 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > To: > In the Internet Draft: AAA Requirements for IP Telephony/Multimedia isn't this a sip wg document? have you asked that wg? what's that wg say? randy From owner-aaa-wg@merit.edu Tue Oct 9 07:49:40 2001 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 HAA28116 for ; Tue, 9 Oct 2001 07:49:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 197E791237; Tue, 9 Oct 2001 07:50:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D57A09123A; Tue, 9 Oct 2001 07:50: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 841D091237 for ; Tue, 9 Oct 2001 07:50:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 064AC5DDA1; Tue, 9 Oct 2001 07:50:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by segue.merit.edu (Postfix) with ESMTP id 677975DD8F for ; Tue, 9 Oct 2001 07:50:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by dummy.domain.name (Sendmail-smtprelay) with SMTP id 8949B17622; Tue, 9 Oct 2001 12:49:17 +0100 (WEST) Received: from ua.pt (mail.ua.pt [193.136.80.80]) by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id 1660A178E5; Tue, 9 Oct 2001 12:49:16 +0100 (WEST) Received: from [193.136.92.216] (HELO newton) by ua.pt (CommuniGate Pro SMTP 3.5b3) with SMTP id 10432500; Tue, 09 Oct 2001 12:49:14 +0100 Message-ID: <00e401c150b8$845ce6d0$d85c88c1@newton> From: "Susana Sargento" To: "Randy Bush" Cc: References: <20011007081026.H29389@charizard.diameter.org><3BC2C607.7734CE7A@rioja.ericsson.se><009901c150a6$d8769d90$d85c88c1@newton> Subject: Re: [AAA-WG]: DIAMETER functions Date: Tue, 9 Oct 2001 12:49:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit It is a draft made by Pat Calhoun, the Diameter person. It is a sip-aaa draft. I was expecting that the aaa wg people could tell me if what is said in the draft is possible to be done solely with Diameter. Thanks, Susana ----- Original Message ----- From: "Randy Bush" To: "Susana Sargento" Cc: Sent: Tuesday, October 09, 2001 12:18 PM Subject: Re: [AAA-WG]: DIAMETER functions > > To: > > In the Internet Draft: AAA Requirements for IP Telephony/Multimedia > > isn't this a sip wg document? have you asked that wg? what's that wg say? > > randy From owner-aaa-wg@merit.edu Tue Oct 9 09:53:00 2001 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 JAA03230 for ; Tue, 9 Oct 2001 09:53:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A10C89120E; Tue, 9 Oct 2001 09:54:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CF2C9123A; Tue, 9 Oct 2001 09:54: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 21B239120E for ; Tue, 9 Oct 2001 09:54:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9094C5DD8F; Tue, 9 Oct 2001 09:54:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id F068F5DDA8 for ; Tue, 9 Oct 2001 09:54:13 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id JAA21814; Tue, 9 Oct 2001 09:46:36 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id JAA04047; Tue, 9 Oct 2001 09:54:19 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 195: Clarifications on key generation Date: Tue, 9 Oct 2001 09:54:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <20011007083047.J29389@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > 2. add text on key derivation in section 5.3 > > This key is not derived. The actual session key is added to > to the message, as are all other keys destined for the > Diameter nodes. So this request is denied > My original question was how this actual session key was generated. If the Foreign-Home session key generation is considered outside the scope of the draft, it would be helpful if this was explicitly stated in the draft. The generation of the Mobile-Home and Mobile-Foreign session keys is described (via a reference to the MIPv4 AAA keys draft) so one would expect the Foreign-Home session key generation to be described too. Regards, Mark From owner-aaa-wg@merit.edu Tue Oct 9 10:45:38 2001 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 KAA05113 for ; Tue, 9 Oct 2001 10:45:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7865191229; Tue, 9 Oct 2001 10:46:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C6E1912AE; Tue, 9 Oct 2001 10:46: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 6EB6591229 for ; Tue, 9 Oct 2001 10:46:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A26C75DD96; Tue, 9 Oct 2001 10:45:59 -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 E9D655DD8F for ; Tue, 9 Oct 2001 10:45:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA52732; Tue, 9 Oct 2001 07:35:17 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 9 Oct 2001 07:35:17 -0700 (PDT) From: Bernard Aboba To: Susana Sargento Cc: Randy Bush , aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER functions In-Reply-To: <00e401c150b8$845ce6d0$d85c88c1@newton> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The draft you refer to, draft-calhoun-sip-aaa-reqs-02.txt, is an individual submission, and as such has not been adopted by any IETF working group. It therefore has no IETF status, and it is not clear whether the draft in question represents the consensus of any of the SIP-related working groups. In general, requirements documents are produced in the relevant area WG, rather than in the AAA WG, so this WG has no say in the eventual disposition of this draft. While it is conceivable that the approach outlined in the draft will be adopted, if and when the subject becomes a WG charter item, it is also conceivable that upon consideration, the relevant WG will decide to do something completely different. Since the approach to SIP/AAA interaction has not yet been decided, and since the AAA WG is currently focused on completing Diameter applications relating to network access, the AAA WG does not have any items relating to SIP in its charter. In general, the AAA WG is the consumer of requirements documents that have garnered consensus within the area WGs, but does not produce them. > It is a draft made by Pat Calhoun, the "Diameter person". > It is a sip-aaa draft. > I was expecting that the aaa wg people could tell me if what is said in the > draft is possible to be done solely with Diameter. > Thanks, > Susana > > ----- Original Message ----- > From: "Randy Bush" > To: "Susana Sargento" > Cc: > Sent: Tuesday, October 09, 2001 12:18 PM > Subject: Re: [AAA-WG]: DIAMETER functions > > > > > To: > > > In the Internet Draft: AAA Requirements for IP Telephony/Multimedia > > > > isn't this a sip wg document? have you asked that wg? what's that wg > say? > > > > randy > > From owner-aaa-wg@merit.edu Tue Oct 9 11:15:12 2001 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 LAA05756 for ; Tue, 9 Oct 2001 11:15:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FA61912AE; Tue, 9 Oct 2001 11:15:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF590912AD; Tue, 9 Oct 2001 11: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 8A8A3912AE for ; Tue, 9 Oct 2001 11:15:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 09E995DD96; Tue, 9 Oct 2001 11:15:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 04B785DDA8 for ; Tue, 9 Oct 2001 11:15:51 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA05203 for ; Tue, 9 Oct 2001 17:14:40 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue: Missing UserName AVP in table in section 10.2 Date: Tue, 9 Oct 2001 17:15:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Fredrik Johansson Submitter email address: fredrik@ipunplugged.com Date first submitted: 9-Oct-01 Reference: Document: base-08-alpha Comment type: editorial Priority: 1 Section: 10.2 Rationale/Explanation of issue: The User Name AVP is not available in the table in section 10.2, but it's present in the ABNF for the accounting messages Requested change: Add User Name AVP From owner-aaa-wg@merit.edu Tue Oct 9 13:41:49 2001 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 NAA10091 for ; Tue, 9 Oct 2001 13:41:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1BF69120E; Tue, 9 Oct 2001 13:42:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DB5591213; Tue, 9 Oct 2001 13:42: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 44E279120E for ; Tue, 9 Oct 2001 13:42:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C520E5DD96; Tue, 9 Oct 2001 13:42: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 27EF55DD8F for ; Tue, 9 Oct 2001 13:42:53 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f99Hfuf07592 for ; Tue, 9 Oct 2001 20:41:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 9 Oct 2001 20:41:21 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M640H64>; Tue, 9 Oct 2001 20:41:22 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA3B@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP Date: Tue, 9 Oct 2001 20:41:18 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Right, however I was mainly thinking of the base protocol commands which are part of the user session like Session-Termination, Abort-Session and Re-auth. Those are defined differently with regard to User-Name AVP. Best Regards, Jaakko > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 08 October, 2001 0:54 > To: Rajaniemi Jaakko (NET/Espoo) > Cc: pcalhoun@diameter.org; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > > After this long talk my question here is that, is there a > specific reason > > why the User-Name AVP is included into some of the base > protocol commands as > > a mandatory AVP and some of them don't have it? > > because some messages have nothing to do with specific users > (e.g. watchdog > messages). > > PatC > From owner-aaa-wg@merit.edu Tue Oct 9 13:47:51 2001 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 NAA10366 for ; Tue, 9 Oct 2001 13:47:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2249291213; Tue, 9 Oct 2001 13:49:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E049591214; Tue, 9 Oct 2001 13:49: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 C7C9491213 for ; Tue, 9 Oct 2001 13:49:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45EC05DD96; Tue, 9 Oct 2001 13:49:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id E72AC5DD8F for ; Tue, 9 Oct 2001 13:49:05 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA08930 for ; Tue, 9 Oct 2001 10:47:38 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA12337 for ; Tue, 9 Oct 2001 10:38:41 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0BJBSX>; Tue, 9 Oct 2001 12:47:37 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ED041@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'jaakko.rajaniemi@nokia.com'" , pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP Date: Tue, 9 Oct 2001 12:47:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Jaakko, I would guess that once you've seen a Session-Id AVP with a User-Name AVP (in a session initiation command, e.g.), you probably wouldn't need to retransmit the User-Name in a subsequent session command (like STR/A, ASR/A), as the other side should (or at least could) have associated Session-Id with characteristics like User-Name. If you wanted to sacrifice local memory in favor of a narrower bandwidth, that might be a good way to go. -Brian > -----Original Message----- > From: jaakko.rajaniemi@nokia.com [mailto:jaakko.rajaniemi@nokia.com] > Sent: Tuesday, October 09, 2001 12:41 PM > To: pcalhoun@diameter.org > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > Hi, > > Right, however I was mainly thinking of the base protocol > commands which are > part of the user session like Session-Termination, Abort-Session and > Re-auth. Those are defined differently with regard to User-Name AVP. > > Best Regards, Jaakko > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: 08 October, 2001 0:54 > > To: Rajaniemi Jaakko (NET/Espoo) > > Cc: pcalhoun@diameter.org; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > > > > > After this long talk my question here is that, is there a > > specific reason > > > why the User-Name AVP is included into some of the base > > protocol commands as > > > a mandatory AVP and some of them don't have it? > > > > because some messages have nothing to do with specific users > > (e.g. watchdog > > messages). > > > > PatC > > > From owner-aaa-wg@merit.edu Wed Oct 10 06:27:27 2001 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 GAA07575 for ; Wed, 10 Oct 2001 06:27:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1516E9125F; Wed, 10 Oct 2001 06:27:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8FEC91260; Wed, 10 Oct 2001 06:27: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 A442B9125F for ; Wed, 10 Oct 2001 06:27:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F8125DD9E; Wed, 10 Oct 2001 06:27:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id AA61D5DD97 for ; Wed, 10 Oct 2001 06:27:10 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA00783 for ; Wed, 10 Oct 2001 12:27:27 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue: wdRecoveryCount used for triggering failover procedures Date: Wed, 10 Oct 2001 12:27:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Fredrik Johansson Submitter email address: fredrik@ipunplugged.com Date first submitted: 10-Oct-01 Reference: Document: base-08-alpha Comment type: technical Priority: 1 Section: 5.5.3 Rationale/Explanation of issue: The wdRecoveryCount is used for both taking us from SUSPECT to OKAY and for triggering failover procedures. Requested change: add new counter to trigger failover procedures OnTimerElapsed(pcb) { if pcb->Status = OKAY SendWatchdog(pcb) pcb->Status = WAIT_DWA T = Tw else if pcb->Status = WAIT_DWA pcb->Status = SUSPECT T = Td else if pcb->Status = SUSPECT ---->>> if pcb->noDWRSentInSuspect++ == 2 StopConnection(pcb) FailoverProcedures(pcb) else SendWatchdog(pcb) } From owner-aaa-wg@merit.edu Wed Oct 10 09:27:14 2001 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 JAA09539 for ; Wed, 10 Oct 2001 09:27:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64BCB91262; Wed, 10 Oct 2001 09:27:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3481C91264; Wed, 10 Oct 2001 09:27: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 07E2191262 for ; Wed, 10 Oct 2001 09:26:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C73615DDC2; Wed, 10 Oct 2001 09:26:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 3CF465DD9E for ; Wed, 10 Oct 2001 09:26:58 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9ADQvr76259 for aaa-wg@merit.edu; Wed, 10 Oct 2001 09:26:57 -0400 (EDT) (envelope-from barney) Date: Wed, 10 Oct 2001 09:26:57 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: wdRecoveryCount used for triggering failover procedures Message-ID: <20011010092657.A76152@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Wed, Oct 10, 2001 at 12:27:58PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk I agree that the counter is needed, but I think it should be ++pcb->xxx rather than xxx++, as there has already been one timeout taking us from WAIT_DWA to SUSPECT. Also, the counter has to be initialized, at the timeout in WAIT_DWA. Why is SendWatchdog called again in SUSPECT? I thought with reliable transport only one watchdog was sent. Barney Wolff On Wed, Oct 10, 2001 at 12:27:58PM +0200, Fredrik Johansson wrote: > Submitter name: Fredrik Johansson > Submitter email address: fredrik@ipunplugged.com > Date first submitted: 10-Oct-01 > Reference: > Document: base-08-alpha > Comment type: technical > Priority: 1 > Section: 5.5.3 > Rationale/Explanation of issue: > The wdRecoveryCount is used for both taking us from SUSPECT to OKAY and > for triggering failover procedures. > > Requested change: > add new counter to trigger failover procedures > > OnTimerElapsed(pcb) > { > if pcb->Status = OKAY > SendWatchdog(pcb) > pcb->Status = WAIT_DWA > T = Tw > else if pcb->Status = WAIT_DWA > pcb->Status = SUSPECT > T = Td > else if pcb->Status = SUSPECT > ---->>> if pcb->noDWRSentInSuspect++ == 2 > StopConnection(pcb) > FailoverProcedures(pcb) > else SendWatchdog(pcb) > } > From owner-aaa-wg@merit.edu Wed Oct 10 10:38:43 2001 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 KAA11288 for ; Wed, 10 Oct 2001 10:38:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84F2E91236; Wed, 10 Oct 2001 10:38:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52D9E9123E; Wed, 10 Oct 2001 10:38: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 1BF5191236 for ; Wed, 10 Oct 2001 10:38:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E04435DDC2; Wed, 10 Oct 2001 10:38:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8758B5DD9E for ; Wed, 10 Oct 2001 10:38:24 -0400 (EDT) Received: (qmail 26421 invoked by uid 500); 10 Oct 2001 14:23:35 -0000 Date: Wed, 10 Oct 2001 07:23:34 -0700 From: Pat Calhoun To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation Message-ID: <20011010072334.A26284@charizard.diameter.org> Mail-Followup-To: Mark Jones , Pat Calhoun , aaa-wg@merit.edu References: <20011007083047.J29389@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjones@matrixmuse.com on Tue, Oct 09, 2001 at 09:54:15AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 09, 2001 at 09:54:15AM -0400, Mark Jones wrote: > Pat, > > > 2. add text on key derivation in section 5.3 > > > > This key is not derived. The actual session key is added to > > to the message, as are all other keys destined for the > > Diameter nodes. So this request is denied > > > > My original question was how this actual session key was generated. If the > Foreign-Home session key generation is considered outside the scope of the > draft, it would be helpful if this was explicitly stated in the draft. > > The generation of the Mobile-Home and Mobile-Foreign session keys is > described (via a reference to the MIPv4 AAA keys draft) so one would expect > the Foreign-Home session key generation to be described too. section 5.3 states: "If the home agent is in the home realm, then AAAH has to generate the Foreign-Home session key. Otherwise, it is generated by AAAF. In either case, the AAA server encodes the session key into a MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message sent to the home agent, and waits for the HAA message to be returned. Upon receipt of the HAR, the home agent recovers the Foreign-Home session key, allocates an SPI to be used with the key. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. ..." So the question is how the key is created, right? This, btw, is no different than the Mobile-Foreign and Mobile-Home key that is sent to the FA and HA, respectively. So, perhaps some additional text on key creation, and the fact that it is a random value of at least 128 bits. Would this be sufficient? Could this be added to section 6.8, with the necessary references in 5.x? PatC From owner-aaa-wg@merit.edu Wed Oct 10 10:41:28 2001 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 KAA11343 for ; Wed, 10 Oct 2001 10:41:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95B639123E; Wed, 10 Oct 2001 10:41:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6381D9123F; Wed, 10 Oct 2001 10:41: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 3CF3F9123E for ; Wed, 10 Oct 2001 10:41:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 224135DDC2; Wed, 10 Oct 2001 10:41:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7944E5DD9E for ; Wed, 10 Oct 2001 10:41:05 -0400 (EDT) Received: (qmail 26453 invoked by uid 500); 10 Oct 2001 14:26:20 -0000 Date: Wed, 10 Oct 2001 07:26:20 -0700 From: Pat Calhoun To: Ext-Venkata.Ghadiyaram@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Outstanding unanswered requests. Message-ID: <20011010072620.B26284@charizard.diameter.org> Mail-Followup-To: Ext-Venkata.Ghadiyaram@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B202306CF71@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9E3407CE45911B4097632389B77B202306CF71@esebe014.NOE.Nokia.com>; from Ext-Venkata.Ghadiyaram@nokia.com on Tue, Oct 09, 2001 at 10:14:52AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Does this mean that a diameter client, within a single session, can send > upto 2^32 messages without receiving an answer. In this case what action is > to be taken by the server if processing of one of these messages results in > an error answer. What should be done to the subsequent messages? Should they > be processed or ignored. the 2^32 is for all messages from the access device, whether it is for a single session or multiple session. each request is completely independent of others. The state machine in the base protocol spec (in section 8.x) details how to handle state transition when errors are received. PatC From owner-aaa-wg@merit.edu Wed Oct 10 10:52:21 2001 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 KAA11658 for ; Wed, 10 Oct 2001 10:52:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07BF69123F; Wed, 10 Oct 2001 10:51:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFE9291265; Wed, 10 Oct 2001 10:51: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 9AF819123F for ; Wed, 10 Oct 2001 10:51:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 726E15DDC2; Wed, 10 Oct 2001 10:51:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1AE825DD9E for ; Wed, 10 Oct 2001 10:51:57 -0400 (EDT) Received: (qmail 26619 invoked by uid 500); 10 Oct 2001 14:37:11 -0000 Date: Wed, 10 Oct 2001 07:37:11 -0700 From: Pat Calhoun To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: wdRecoveryCount used for triggering failover procedures Message-ID: <20011010073710.G26284@charizard.diameter.org> Mail-Followup-To: Barney Wolff , aaa-wg@merit.edu References: <20011010092657.A76152@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011010092657.A76152@tp.databus.com>; from barney@databus.com on Wed, Oct 10, 2001 at 09:26:57AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, As I previously noted, all of this text will be pushed into the AAA transports draft. I believe that this draft will soon be available with the latest transport text, and I believe it does include this fix. I will log it, but against the aaa transport draft. PatC On Wed, Oct 10, 2001 at 09:26:57AM -0400, Barney Wolff wrote: > I agree that the counter is needed, but I think it should be > ++pcb->xxx rather than xxx++, as there has already been one timeout > taking us from WAIT_DWA to SUSPECT. Also, the counter has to be > initialized, at the timeout in WAIT_DWA. > > Why is SendWatchdog called again in SUSPECT? I thought with reliable > transport only one watchdog was sent. > > Barney Wolff > > On Wed, Oct 10, 2001 at 12:27:58PM +0200, Fredrik Johansson wrote: > > Submitter name: Fredrik Johansson > > Submitter email address: fredrik@ipunplugged.com > > Date first submitted: 10-Oct-01 > > Reference: > > Document: base-08-alpha > > Comment type: technical > > Priority: 1 > > Section: 5.5.3 > > Rationale/Explanation of issue: > > The wdRecoveryCount is used for both taking us from SUSPECT to OKAY and > > for triggering failover procedures. > > > > Requested change: > > add new counter to trigger failover procedures > > > > OnTimerElapsed(pcb) > > { > > if pcb->Status = OKAY > > SendWatchdog(pcb) > > pcb->Status = WAIT_DWA > > T = Tw > > else if pcb->Status = WAIT_DWA > > pcb->Status = SUSPECT > > T = Td > > else if pcb->Status = SUSPECT > > ---->>> if pcb->noDWRSentInSuspect++ == 2 > > StopConnection(pcb) > > FailoverProcedures(pcb) > > else SendWatchdog(pcb) > > } > > From owner-aaa-wg@merit.edu Wed Oct 10 11:37:52 2001 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 LAA12568 for ; Wed, 10 Oct 2001 11:37:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C891591240; Wed, 10 Oct 2001 11:37:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9455991269; Wed, 10 Oct 2001 11:37: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 4115C91240 for ; Wed, 10 Oct 2001 11:37:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18B675DDC5; Wed, 10 Oct 2001 11:37:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id A36765DD9E for ; Wed, 10 Oct 2001 11:37:40 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA32121; Wed, 10 Oct 2001 11:31:18 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id LAA15539; Wed, 10 Oct 2001 11:39:01 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 195: Clarifications on key generation Date: Wed, 10 Oct 2001 11:39:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20011010072334.A26284@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > So the question is how the key is created, right? This, btw, is > no different > than the Mobile-Foreign and Mobile-Home key that is sent to the FA and HA, > respectively. So, perhaps some additional text on key creation, > and the fact that > it is a random value of at least 128 bits. > This is the second time you've stated that the Foreign-Home key creation is no different than the Mobile-Foreign and Mobile-Home key creation and I still fail to see the commonality. Please could you review my assumptions on Mobile-Foreign and Mobile-Home key generation (from aaa-key-09) so I can see where I'm mistaken. + The Mobile-Foreign and Mobile-Home Key Material is a random value of at least 64 bits. + The Mobile-Foreign and Mobile-Home Session Key is the result of a cryptographic algorithm (default: HMAC_MD5) applied over some combination of node address, AAA-key and the key material. So when you say "it is a random value of at least 128 bits", are you referring to the Foreign-Home Key Material or the Foreign-Home Session Key itself? This is the first time I've seen mention of a random value of 128 bits used in key creation. Did you mean 64 bits? > Would this be sufficient? Could this be added to section 6.8, > with the necessary > references in 5.x? > If all session keys are created in the same way then I'd add the description (or reference) to section 6.8 (MIP-Session-Key AVP). If they are not, I'd describe their creation in the appropriate 5.x section. Regards, Mark From owner-aaa-wg@merit.edu Wed Oct 10 12:49:52 2001 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 MAA14376 for ; Wed, 10 Oct 2001 12:49:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 832359122A; Wed, 10 Oct 2001 12:49:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44DCB91235; Wed, 10 Oct 2001 12:49: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 120129122A for ; Wed, 10 Oct 2001 12:49:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DED145DDCA; Wed, 10 Oct 2001 12:49:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 54D115DD9E for ; Wed, 10 Oct 2001 12:49:27 -0400 (EDT) Received: (qmail 27351 invoked by uid 500); 10 Oct 2001 16:34:32 -0000 Date: Wed, 10 Oct 2001 09:34:32 -0700 From: Pat Calhoun To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation Message-ID: <20011010093432.A27333@charizard.diameter.org> Mail-Followup-To: Mark Jones , Pat Calhoun , aaa-wg@merit.edu References: <20011010072334.A26284@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjones@matrixmuse.com on Wed, Oct 10, 2001 at 11:39:00AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk the draft that refer to below (aaa-keys) describes how the keys are sent to the mobile node, not to the FA or HA. So, let's look at an example: 1. aaah creates key material 2. session key is created from key material by aaah, and sent to HA and FA via Diameter 3. key material is sent from aaah to ha 3. key material is sent to mobile node in reg reply 4. session key is created from key material by mobile node So, keys destined for the FA and the HA are session keys, not the key material. and yes, I meant 64 bits, not 128 (sorry) PatC On Wed, Oct 10, 2001 at 11:39:00AM -0400, Mark Jones wrote: > Pat, > > > So the question is how the key is created, right? This, btw, is > > no different > > than the Mobile-Foreign and Mobile-Home key that is sent to the FA and HA, > > respectively. So, perhaps some additional text on key creation, > > and the fact that > > it is a random value of at least 128 bits. > > > > This is the second time you've stated that the Foreign-Home key creation is > no different than the Mobile-Foreign and Mobile-Home key creation and I > still fail to see the commonality. Please could you review my assumptions on > Mobile-Foreign and Mobile-Home key generation (from aaa-key-09) so I can see > where I'm mistaken. > > + The Mobile-Foreign and Mobile-Home Key Material is a random value of at > least 64 bits. > > + The Mobile-Foreign and Mobile-Home Session Key is the result of a > cryptographic algorithm (default: HMAC_MD5) applied over some combination of > node address, AAA-key and the key material. > > So when you say "it is a random value of at least 128 bits", are you > referring to the Foreign-Home Key Material or the Foreign-Home Session Key > itself? > > This is the first time I've seen mention of a random value of 128 bits used > in key creation. Did you mean 64 bits? > > > Would this be sufficient? Could this be added to section 6.8, > > with the necessary > > references in 5.x? > > > > If all session keys are created in the same way then I'd add the description > (or reference) to section 6.8 (MIP-Session-Key AVP). If they are not, I'd > describe their creation in the appropriate 5.x section. > > Regards, > Mark > From owner-aaa-wg@merit.edu Wed Oct 10 12:55:57 2001 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 MAA14522 for ; Wed, 10 Oct 2001 12:55:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C38BE91235; Wed, 10 Oct 2001 12:55:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 917AC91243; Wed, 10 Oct 2001 12:55: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 7F17091235 for ; Wed, 10 Oct 2001 12:55:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FE875DDCA; Wed, 10 Oct 2001 12:55:41 -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 B44745DD9E for ; Wed, 10 Oct 2001 12:55:40 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9AGuBf16821 for ; Wed, 10 Oct 2001 19:56:11 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Oct 2001 19:55:35 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VALCH>; Wed, 10 Oct 2001 19:55:35 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA4B@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: Brian.Cain@motorola.com, pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP Date: Wed, 10 Oct 2001 19:55:24 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Brian, That's one way. If the bandwidth is not the concern then you could include the User-Name AVP to those messages because of some benefits which it may bring to you (see my previous mail dated 04.10). For some other commands e.g. Accounting, which may be used real-time, the bandwitdh may be bigger concern. Best Regards, Jaakko > -----Original Message----- > From: ext Cain Brian-BCAIN1 [mailto:Brian.Cain@motorola.com] > Sent: 09 October, 2001 20:48 > To: Rajaniemi Jaakko (NET/Espoo); pcalhoun@diameter.org > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > Jaakko, > > I would guess that once you've seen a Session-Id AVP with a > User-Name AVP > (in a session initiation command, e.g.), you probably wouldn't need to > retransmit the User-Name in a subsequent session command (like STR/A, > ASR/A), as the other side should (or at least could) have associated > Session-Id with characteristics like User-Name. If you > wanted to sacrifice > local memory in favor of a narrower bandwidth, that might be > a good way to > go. > > -Brian > > > -----Original Message----- > > From: jaakko.rajaniemi@nokia.com [mailto:jaakko.rajaniemi@nokia.com] > > Sent: Tuesday, October 09, 2001 12:41 PM > > To: pcalhoun@diameter.org > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > > > > Hi, > > > > Right, however I was mainly thinking of the base protocol > > commands which are > > part of the user session like Session-Termination, Abort-Session and > > Re-auth. Those are defined differently with regard to > User-Name AVP. > > > > Best Regards, Jaakko > > > -----Original Message----- > > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: 08 October, 2001 0:54 > > > To: Rajaniemi Jaakko (NET/Espoo) > > > Cc: pcalhoun@diameter.org; aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > > > > > > > > After this long talk my question here is that, is there a > > > specific reason > > > > why the User-Name AVP is included into some of the base > > > protocol commands as > > > > a mandatory AVP and some of them don't have it? > > > > > > because some messages have nothing to do with specific users > > > (e.g. watchdog > > > messages). > > > > > > PatC > > > > > > From owner-aaa-wg@merit.edu Wed Oct 10 13:07:09 2001 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 NAA14926 for ; Wed, 10 Oct 2001 13:07:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D66E091243; Wed, 10 Oct 2001 13:06:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A649591248; Wed, 10 Oct 2001 13:06: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 7DA0091243 for ; Wed, 10 Oct 2001 13:06:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47F835DDCA; Wed, 10 Oct 2001 13:06:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id BB21B5DD9E for ; Wed, 10 Oct 2001 13:06:53 -0400 (EDT) Received: from erilab.com (eblcl57.erilab.com [192.168.174.197]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f9AH8tI23791; Wed, 10 Oct 2001 10:08:55 -0700 (PDT) Message-ID: <3BC4806A.C65CFBD0@erilab.com> Date: Wed, 10 Oct 2001 10:07:54 -0700 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is aaa-key-09 available? Or it's just a typo by Mark? Mark Jones wrote: > ...... > still fail to see the commonality. Please could you review my assumptions on > Mobile-Foreign and Mobile-Home key generation (from aaa-key-09) so I can see > where I'm mistaken. > ------ From owner-aaa-wg@merit.edu Wed Oct 10 13:30:08 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15854 for ; Wed, 10 Oct 2001 13:30:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9110091269; Wed, 10 Oct 2001 13:29:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58B589126C; Wed, 10 Oct 2001 13:29:32 -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 0991791269 for ; Wed, 10 Oct 2001 13:29:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E42575DDB1; Wed, 10 Oct 2001 13:29:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 74A735DD9E for ; Wed, 10 Oct 2001 13:29:30 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id NAA00624; Wed, 10 Oct 2001 13:23:15 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA29124; Wed, 10 Oct 2001 13:30:58 -0400 (EDT) From: "Mark Jones" To: "Michael Chen" Cc: Subject: RE: [AAA-WG]: Issue 195: Clarifications on key generation Date: Wed, 10 Oct 2001 13:30:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BC4806A.C65CFBD0@erilab.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael, See the post by Charles Perkins on the mobile ip mailing list dated October 8th. http://people.nokia.net/charliep/txt/mobilekey/mip-key.txt Regards, Mark > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Michael Chen > Sent: October 10, 2001 1:08 PM > To: Mark Jones > Cc: Pat Calhoun; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation > > > Is aaa-key-09 available? Or it's just a typo by Mark? > > > > Mark Jones wrote: > > > ...... > > still fail to see the commonality. Please could you review my > assumptions on > > Mobile-Foreign and Mobile-Home key generation (from aaa-key-09) > so I can see > > where I'm mistaken. > > ------ > > > > From owner-aaa-wg@merit.edu Thu Oct 11 11:21:29 2001 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 LAA18026 for ; Thu, 11 Oct 2001 11:21:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B090491238; Thu, 11 Oct 2001 11:21:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C7709123D; Thu, 11 Oct 2001 11:21: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 6C02F91238 for ; Thu, 11 Oct 2001 11:21:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3ECE05DDC8; Thu, 11 Oct 2001 11:21:03 -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 5E89E5DDAA for ; Thu, 11 Oct 2001 11:21:02 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9BFLaf19622 for ; Thu, 11 Oct 2001 18:21:36 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Oct 2001 18:21:01 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VBQJ1>; Thu, 11 Oct 2001 18:21:01 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA5C@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: susana@ua.pt Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DIAMETER functions Date: Thu, 11 Oct 2001 18:20:57 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Susana, This draft was sent to SIPPING WG. Further comments/questions should be sent to the SIPPING mailinglist. I noticed that most of your questions are regarding the actual design of the Diameter application. However, the draft is only describing the requirements. The design comes later when the requirements are clear. Best Regards, Jaakko > -----Original Message----- > From: ext Susana Sargento [mailto:susana@ua.pt] > Sent: 09 October, 2001 12:43 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: DIAMETER functions > > > Hi, > I would like some help on DIAMETER. > > In the Internet Draft: AAA Requirements for IP > Telephony/Multimedia, it is > explained how SIP interacts with the AAA (DIAMETER). In the > Register phase > how is the AAA message from the proxy server to the DIAMETER? > Is the SIP > message included as an AVP? In the INVITE phase, the SIP > server sends an > authorization request to the DIAMETER which may include > policy decisions. Is > there any document where I can find more detail about this? > Because it is > said in general, but it is not specified exactly how it is done. > Is there any implementation of DIAMETER with SIP and QoS policy > authentication? > > Also in this draft it is said that there are some policy > functions that > should be included in DIAMETER, like performing > authentication taking into > account the time of day, etc. Is there any document that specifies the > messages that are sent to and from the DIAMETER server which > include those > policy decisions? Also, how to authenticate with DIAMETER taking into > account the bandwidth required for the session as well as the QoS > requirements? > > Thanks for your attention, > Susana > From owner-aaa-wg@merit.edu Thu Oct 11 11:59:58 2001 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 LAA18544 for ; Thu, 11 Oct 2001 11:59:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB2D491240; Thu, 11 Oct 2001 11:59:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F09591243; Thu, 11 Oct 2001 11:59: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 4C4C691240 for ; Thu, 11 Oct 2001 11:59:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 272275DDD1; Thu, 11 Oct 2001 11:59:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 3B5C15DDC8 for ; Thu, 11 Oct 2001 11:59:43 -0400 (EDT) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA11171; Thu, 11 Oct 2001 17:59:53 +0200 From: "Fredrik Johansson" To: "Thomas Panagiotis-PTHOMAS1" , "AAA Listan" Subject: RE: [AAA-WG]: Possible to do handover with HA in foreign network and multiple AAAH in realm? Date: Thu, 11 Oct 2001 18:00:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >> Is this problem even solvable? If the HA were in a home network you >> could potentially use configured knowledge to map from ip to uri. If not >> the only reasonable response seems to be to reject the authentication >> due to lack of information. > >or forward the AMR to an AAAH in your domain that may know something. >Multiple AAAHs in home domain must somehow be able to share information. >Protocol itself will not do much without proper configuration. Well, we designed the protocol to handle multiple AAAh and so a request could come in on any of them. If no session exist on the AAAh it would then create a session towards the HA and the HA should sort out wether it's a new registration or a contunuation of a old session. This was decided so no session state should be shared between multiple AAAh servers. And probably work fine as long as the HA is in the home network because you MAY expect the AAAh to be configured with the HA URI. However, with HA's allocated in a foreign network it means that every AAAh needs to be able to map between HA IP address and the HA URI for every possible HA in every possible foreign network that its clients can be visiting. The HA address is available in the registration request and sent in the Home Agent Address AVP in the AMR. However the URI of an HA in a foreign network is not known in any other AAAh server than the one that received the first request for registration. And we agreed previously that session state shouln't have to be shared between multiple AAAh. /Fredrik > >-Panos > >-----Original Message----- >From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] >Sent: Monday, October 08, 2001 7:41 AM >To: AAA Listan >Subject: [AAA-WG]: Possible to do handover with HA in foreign network >and multiple AAAH in realm? > > > > >The scenario is as follows: > >The mobile node authenticates with AAAH1 via FA1 and is allocated a home >agent in the foreign network. The MN then moves to FA2 and passes it the >HA-address. FA2 sends an AMR that is handled by AAAH2 serving the same >realm as AAAH1. Neither FA2 nor AAAH2 has any knowledge of the existing >session beyond that of the MIP-Mobile-Home-Agent avp. > >Note that this is the ip address of the interface that the home agent >uses to tunnel Mobile Ip traffic. There is no reason to expect this to >be the same interface used for diameter traffic, in fact this is even >unlikely. Since the mobile node has no knowledge of anything but Mobile >Ip it cannot be expected to pass the diameter uri of the HA. > >Is this problem even solvable? If the HA were in a home network you >could potentially use configured knowledge to map from ip to uri. If not >the only reasonable response seems to be to reject the authentication >due to lack of information. > >j From owner-aaa-wg@merit.edu Thu Oct 11 12:24:03 2001 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 MAA19046 for ; Thu, 11 Oct 2001 12:24:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DE1591245; Thu, 11 Oct 2001 12:23:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5796091246; Thu, 11 Oct 2001 12:23: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 2AEBC91245 for ; Thu, 11 Oct 2001 12:23:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 04EE25DDBD; Thu, 11 Oct 2001 12:23:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B7DA85DDAA for ; Thu, 11 Oct 2001 12:23:46 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B976674 for ; Thu, 11 Oct 2001 12:23:51 -0400 (EDT) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: MN migration to new realm / draft-mobileip-08-alpha01 Date: Thu, 11 Oct 2001 12:21:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, Section 1.4 of draft-ietf-aaa-diameter-mobileip-08-alpha01 describes how the AAAH handles the case where the MN has migrated to a new foreign network and wants to keep the HA which has been allocated in the previous foreign network. What follows is the section I'm referring to: | 1.4 Allocation of Home Agent in Foreign Network | | [...] | | Figure 7 shows the message flows for a Mobile Node requesting to keep | the Home Agent assigned in Foreign network 1 when it moves to foreign | network 2. Upon reception of the AMR in Foreign network 2, the AAAF | follows the procedures described earlier and forwards AMR to the | Mobile Node's home network, i.e. its AAAH. If the Mobile Node was | successfully authenticated the AAAH checks for the Origin-Host and | the value of the Origin-Host of the previous request. If a AAAH | deduces that the Mobile Node has moved to a new realm, it must check | whether the Mobile can still use the previously assigned Home Agent. | | +---------------+ +---------------+ +-------------+ | |Foreign net 2 | |Foreign net 1 | |Home network | | | | | | | | | Mobile Node | FA AAAF | | HA AAAF | | AAAH | | ----------- | ---- ---- | | ---- ------ | | ------ | | +---------------+ +---------------+ +-------------+ | | <----Challenge---- | Reg-Req (Response)-> | ---AMR---> | ----------------AMR---------------> | <-----HAR----- | <---HAR---- | ----HAA---> | ------HAA----> | <---------------AMA---------------- | <--AMA---- | <----Reg-Reply----- | Figure 7: Request to access Home Agent from new Foreign Network | | If the Mobile Node is allowed to keep the Home Agent the AAAH then | sends a HAR, which contains the Mobile IP Registration Request | message data encapsulated in the MIP-Reg-Request AVP and the MIP- | Home-Agent-Address AVP with Home Agent address, as well as any | optional KDC session keys, to the AAAF in foreign network 1. Upon | reception the AAAF in foreign network 1 will forward the HAR to the | Home Agent if its local policy allows such service. If the AAAF does | not permit such service, it MUST return a | DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. My question is with the sentence "If a AAAH deduces that the Mobile Node has moved to a new realm, it must check whether the Mobile can still use the previously assigned Home Agent." The previous sentence says "the AAAH checks for the Origin-Host and the value of the Origin-Host of the previous request". But this proposal implies that the AAAH maintains session-state and has remembered the previous request. From what I've been reading in the mailing list, the AAAH isn't required to maintain session state. Question: How does an AAAH that doesn't maintain session state make this "MN has moved to a new realm" deduction? Question: If the session-stateless AAAH could make such a deduction, it would seem that the AAAH could not allow the MN to keep the old HA, as the AAAH would be unable to route the HAR to the old foreign network where the HA lives. True? Question: If the session-stateless AAAH cannot make such a deduction, does that mean that the MN, if allowed to have a foreign HA, would lose his connection if he migrated to a new foreign network? Question: If the current request went to a different AAAH than the previous request, then even a session-stateful AAAH could not allow the MN to keep the old HA, as the AAAH would be unable to route the HAR to the old foreign network where the HA lives. True? Thanks, Bob K. From owner-aaa-wg@merit.edu Thu Oct 11 12:39:58 2001 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 MAA19406 for ; Thu, 11 Oct 2001 12:39:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D132991233; Thu, 11 Oct 2001 12:39:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D18A91235; Thu, 11 Oct 2001 12:39:41 -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 90C8C91233 for ; Thu, 11 Oct 2001 12:39:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F9C25DDBD; Thu, 11 Oct 2001 12:39:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 296445DDAA for ; Thu, 11 Oct 2001 12:39:39 -0400 (EDT) Received: (qmail 6898 invoked by uid 500); 11 Oct 2001 16:22:05 -0000 Date: Thu, 11 Oct 2001 09:22:05 -0700 From: Pat Calhoun To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: MN migration to new realm / draft-mobileip-08-alpha01 Message-ID: <20011011092205.E6038@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , aaa-wg References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Thu, Oct 11, 2001 at 12:21:29PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 11, 2001 at 12:21:29PM -0400, Bob Kopacz wrote: > Hi Pat, > > Section 1.4 of draft-ietf-aaa-diameter-mobileip-08-alpha01 describes > how the AAAH handles the case where the MN has migrated to a new > foreign network and wants to keep the HA which has been allocated in > the previous foreign network. What follows is the section I'm > referring to: > > | 1.4 Allocation of Home Agent in Foreign Network > | > | [...] > | > | Figure 7 shows the message flows for a Mobile Node requesting to keep > | the Home Agent assigned in Foreign network 1 when it moves to foreign > | network 2. Upon reception of the AMR in Foreign network 2, the AAAF > | follows the procedures described earlier and forwards AMR to the > | Mobile Node's home network, i.e. its AAAH. If the Mobile Node was > | successfully authenticated the AAAH checks for the Origin-Host and > | the value of the Origin-Host of the previous request. If a AAAH > | deduces that the Mobile Node has moved to a new realm, it must check > | whether the Mobile can still use the previously assigned Home Agent. > | > | +---------------+ +---------------+ +-------------+ > | |Foreign net 2 | |Foreign net 1 | |Home network | > | | | | | | | > | Mobile Node | FA AAAF | | HA AAAF | | AAAH | > | ----------- | ---- ---- | | ---- ------ | | ------ | > | +---------------+ +---------------+ +-------------+ > | > | <----Challenge---- > | Reg-Req (Response)-> > | ---AMR---> > | ----------------AMR---------------> > | <-----HAR----- > | <---HAR---- > | ----HAA---> > | ------HAA----> > | <---------------AMA---------------- > | <--AMA---- > | <----Reg-Reply----- > | Figure 7: Request to access Home Agent from new Foreign Network > | > | If the Mobile Node is allowed to keep the Home Agent the AAAH then > | sends a HAR, which contains the Mobile IP Registration Request > | message data encapsulated in the MIP-Reg-Request AVP and the MIP- > | Home-Agent-Address AVP with Home Agent address, as well as any > | optional KDC session keys, to the AAAF in foreign network 1. Upon > | reception the AAAF in foreign network 1 will forward the HAR to the > | Home Agent if its local policy allows such service. If the AAAF does > | not permit such service, it MUST return a > | DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > My question is with the sentence "If a AAAH deduces that the Mobile > Node has moved to a new realm, it must check whether the Mobile can > still use the previously assigned Home Agent." > > The previous sentence says "the AAAH checks for the Origin-Host and > the value of the Origin-Host of the previous request". But this > proposal implies that the AAAH maintains session-state and has > remembered the previous request. From what I've been reading in the > mailing list, the AAAH isn't required to maintain session state. > > Question: How does an AAAH that doesn't maintain session state make > this "MN has moved to a new realm" deduction? Mobile IP has a previous Foreign Agent extension, and combined with the Home Agent field of the registration requestion, this can be deduced. > Question: If the session-stateless AAAH could make such a deduction, > it would seem that the AAAH could not allow the MN to keep the old HA, > as the AAAH would be unable to route the HAR to the old foreign > network where the HA lives. True? no, the HA is in the registration request. > Question: If the session-stateless AAAH cannot make such a deduction, > does that mean that the MN, if allowed to have a foreign HA, would > lose his connection if he migrated to a new foreign network? only if the local policy states this needs to happen. > Question: If the current request went to a different AAAH than the > previous request, then even a session-stateful AAAH could not allow > the MN to keep the old HA, as the AAAH would be unable to route the > HAR to the old foreign network where the HA lives. True? see above. PatC From owner-aaa-wg@merit.edu Thu Oct 11 17:48:08 2001 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 RAA26338 for ; Thu, 11 Oct 2001 17:48:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8D1891242; Thu, 11 Oct 2001 17:47:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78AD691245; Thu, 11 Oct 2001 17:47:59 -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 6320291242 for ; Thu, 11 Oct 2001 17:47:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4D6A5DDAC; Thu, 11 Oct 2001 17:47:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by segue.merit.edu (Postfix) with ESMTP id ADC1C5DDA3 for ; Thu, 11 Oct 2001 17:47:56 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id BCBF1F44; Thu, 11 Oct 2001 14:47:53 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id OAA13770; Thu, 11 Oct 2001 14:49:24 -0700 (PDT) Date: Thu, 11 Oct 2001 14:49:24 -0700 (PDT) From: Joe Lau Message-Id: <200110112149.OAA13770@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [AAA-WG]: MN migration to new realm / draft-mobileip-08-alpha01 Cc: BKopacz@InterlinkNetworks.com, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit PatC wrote: > > Question: How does an AAAH that doesn't maintain session state make > > this "MN has moved to a new realm" deduction? > > Mobile IP has a previous Foreign Agent extension, and combined with the > Home Agent field of the registration requestion, this can be deduced. I am aware of the Previous Foreign Agent Notification Extension defined in the Route Optimiation draft. But I don't recall there is such an extension on the RFC 2002. Can you clarify where is the "previous Foreign Agent extension" is defined? At at any rate, this deduction process will require the AAAH to understand Mobile IP protocol. Doesn't it? Joe Lau From owner-aaa-wg@merit.edu Fri Oct 12 09:59:07 2001 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 JAA27989 for ; Fri, 12 Oct 2001 09:59:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 513ED9124E; Fri, 12 Oct 2001 09:58:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18FE99124F; Fri, 12 Oct 2001 09:58: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 EA8E69124E for ; Fri, 12 Oct 2001 09:58:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6A555DDAA; Fri, 12 Oct 2001 09:58:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A9B5D5DD9B for ; Fri, 12 Oct 2001 09:58:45 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 964C474; Fri, 12 Oct 2001 09:58:50 -0400 (EDT) From: "Bob Kopacz" To: "Tony Johansson" , "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: Bakeoff Test Suite Date: Fri, 12 Oct 2001 09:56:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony and/or Pat, The Test Suite at the bakeoff website indicates the interoperability tests will be based on draft-08, which isn't out yet. Is the plan then, that the bakeoff tests are based on draft-08-alpha01? And, for example, the MIP-XX-to-YY-Key AVPs are as described in draft-08-alpha01, and not per subsequent mailing list discussions? Thanks, Bob K. From owner-aaa-wg@merit.edu Fri Oct 12 10:02:06 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28126 for ; Fri, 12 Oct 2001 10:02:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2705191250; Fri, 12 Oct 2001 10:00:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECFBB91253; Fri, 12 Oct 2001 10:00:39 -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 D6A5391250 for ; Fri, 12 Oct 2001 10:00:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1B6C5DDAA; Fri, 12 Oct 2001 10:00:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2208D5DD9B for ; Fri, 12 Oct 2001 10:00:38 -0400 (EDT) Received: (qmail 11022 invoked by uid 500); 12 Oct 2001 13:45:46 -0000 Date: Fri, 12 Oct 2001 06:45:46 -0700 From: Pat Calhoun To: Bob Kopacz Cc: Tony Johansson , Pat Calhoun , aaa-wg Subject: [AAA-WG]: Re: Bakeoff Test Suite Message-ID: <20011012064546.D10950@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , Tony Johansson , Pat Calhoun , aaa-wg References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Fri, Oct 12, 2001 at 09:56:27AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk I am not involved in the bakeoff. I will let Tony respond as he is taking care of this event. PatC On Fri, Oct 12, 2001 at 09:56:27AM -0400, Bob Kopacz wrote: > Hi Tony and/or Pat, > > The Test Suite at the bakeoff website indicates the interoperability > tests will be based on draft-08, which isn't out yet. > > Is the plan then, that the bakeoff tests are based on draft-08-alpha01? > > And, for example, the MIP-XX-to-YY-Key AVPs are as described in > draft-08-alpha01, and not per subsequent mailing list discussions? > > Thanks, > Bob K. > From owner-aaa-wg@merit.edu Fri Oct 12 10:20:58 2001 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 KAA29083 for ; Fri, 12 Oct 2001 10:20:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F0C691253; Fri, 12 Oct 2001 10:20:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2FC991254; Fri, 12 Oct 2001 10:20: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 E6CDF91253 for ; Fri, 12 Oct 2001 10:20:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C98CE5DDAA; Fri, 12 Oct 2001 10:20:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B0E705DD9B for ; Fri, 12 Oct 2001 10:20:44 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id AF57B74; Fri, 12 Oct 2001 10:20:49 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: Order of Members of MIP-XX-to-YY-Key AVPs Date: Fri, 12 Oct 2001 10:18:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, In earlier drafts of Diameter, the Grouped AVPs had fixed member AVPs in a fixed order. Now the Grouped AVPs have a more flexible "header [ *fixed] [ *required] [ *optional] [ *fixed]" format. Question: At the time this change was made, did you intend the existing grouped AVPs, such as MIP-MN-AAA-Auth AVP and the MIP-XX-to-YY-Key AVPs, to retain the fixed order of their members, or did you intend the order of the required members to be arbitrary? e.g. if the fixed order was to be retained, should the MIP-MN-AAA-Auth AVP description have had the editing change from: MIP-MN-AAA-Auth ::= < AVP Header: 322 > { MIP-MN-AAA-SPI } { MIP-Auth-Input-Data-Length } { MIP-Authenticator-Length } { MIP-Authenticator-Offset } * [ AVP ] to: MIP-MN-AAA-Auth ::= < AVP Header: 322 > < MIP-MN-AAA-SPI > < MIP-Auth-Input-Data-Length > < MIP-Authenticator-Length > < MIP-Authenticator-Offset > * [ AVP ] Bob K. From owner-aaa-wg@merit.edu Fri Oct 12 10:42:55 2001 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 KAA00008 for ; Fri, 12 Oct 2001 10:42:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 04AF39124E; Fri, 12 Oct 2001 10:42:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8ACD91250; Fri, 12 Oct 2001 10:42: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 B87799124E for ; Fri, 12 Oct 2001 10:42:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AD225DDAA; Fri, 12 Oct 2001 10:42:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3AABD5DD9B for ; Fri, 12 Oct 2001 10:42:35 -0400 (EDT) Received: (qmail 11284 invoked by uid 500); 12 Oct 2001 14:27:44 -0000 Date: Fri, 12 Oct 2001 07:27:44 -0700 From: Pat Calhoun To: Bob Kopacz Cc: Pat Calhoun , aaa-wg Subject: [AAA-WG]: Re: Order of Members of MIP-XX-to-YY-Key AVPs Message-ID: <20011012072744.H10950@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , Pat Calhoun , aaa-wg References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Fri, Oct 12, 2001 at 10:18:27AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Bob, I don't see why ordering is required for this AVP. Did you have any specific concerns that would require ordering? PatC On Fri, Oct 12, 2001 at 10:18:27AM -0400, Bob Kopacz wrote: > Hi Pat, > > In earlier drafts of Diameter, the Grouped AVPs had fixed member AVPs > in a fixed order. > > Now the Grouped AVPs have a more flexible > > "header [ *fixed] [ *required] [ *optional] [ *fixed]" format. > > Question: At the time this change was made, did you intend the > existing grouped AVPs, such as MIP-MN-AAA-Auth AVP and the > MIP-XX-to-YY-Key AVPs, to retain the fixed order of their members, or > did you intend the order of the required members to be arbitrary? > > e.g. if the fixed order was to be retained, should the MIP-MN-AAA-Auth > AVP description have had the editing change > > from: > > MIP-MN-AAA-Auth ::= < AVP Header: 322 > > { MIP-MN-AAA-SPI } > { MIP-Auth-Input-Data-Length } > { MIP-Authenticator-Length } > { MIP-Authenticator-Offset } > * [ AVP ] > > to: > > MIP-MN-AAA-Auth ::= < AVP Header: 322 > > < MIP-MN-AAA-SPI > > < MIP-Auth-Input-Data-Length > > < MIP-Authenticator-Length > > < MIP-Authenticator-Offset > > * [ AVP ] > > Bob K. > From owner-aaa-wg@merit.edu Fri Oct 12 10:47:36 2001 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 KAA00132 for ; Fri, 12 Oct 2001 10:47:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9CAC91250; Fri, 12 Oct 2001 10:47:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C541891255; Fri, 12 Oct 2001 10:47: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 2F51091250 for ; Fri, 12 Oct 2001 10:47:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0AB815DDB3; Fri, 12 Oct 2001 10:47:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E65555DDAA for ; Fri, 12 Oct 2001 10:47:12 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id E52B074; Fri, 12 Oct 2001 10:47:17 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: RE: Order of Members of MIP-XX-to-YY-Key AVPs Date: Fri, 12 Oct 2001 10:44:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20011012072744.H10950@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, > -----Original Message----- > From: pcalhoun@charizard.diameter.org > [mailto:pcalhoun@charizard.diameter.org]On Behalf Of Pat Calhoun > Sent: Friday, October 12, 2001 10:28 AM > To: Bob Kopacz > Cc: Pat Calhoun; aaa-wg > Subject: Re: Order of Members of MIP-XX-to-YY-Key AVPs > > > Bob, > > I don't see why ordering is required for this AVP. Did you have any > specific concerns that would require ordering? No. I was just wondering if removing the ordering requirement was intended or an editing oversight. Thanks, Bob K. > PatC > On Fri, Oct 12, 2001 at 10:18:27AM -0400, Bob Kopacz wrote: > > Hi Pat, > > > > In earlier drafts of Diameter, the Grouped AVPs had fixed member AVPs > > in a fixed order. > > > > Now the Grouped AVPs have a more flexible > > > > "header [ *fixed] [ *required] [ *optional] [ *fixed]" format. > > > > Question: At the time this change was made, did you intend the > > existing grouped AVPs, such as MIP-MN-AAA-Auth AVP and the > > MIP-XX-to-YY-Key AVPs, to retain the fixed order of their members, or > > did you intend the order of the required members to be arbitrary? > > > > e.g. if the fixed order was to be retained, should the MIP-MN-AAA-Auth > > AVP description have had the editing change > > > > from: > > > > MIP-MN-AAA-Auth ::= < AVP Header: 322 > > > { MIP-MN-AAA-SPI } > > { MIP-Auth-Input-Data-Length } > > { MIP-Authenticator-Length } > > { MIP-Authenticator-Offset } > > * [ AVP ] > > > > to: > > > > MIP-MN-AAA-Auth ::= < AVP Header: 322 > > > < MIP-MN-AAA-SPI > > > < MIP-Auth-Input-Data-Length > > > < MIP-Authenticator-Length > > > < MIP-Authenticator-Offset > > > * [ AVP ] > > > > Bob K. > > > From owner-aaa-wg@merit.edu Fri Oct 12 14:01:19 2001 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 OAA05202 for ; Fri, 12 Oct 2001 14:01:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 447AD91250; Fri, 12 Oct 2001 14:00:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 123F291257; Fri, 12 Oct 2001 14:00: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 B2A8A91250 for ; Fri, 12 Oct 2001 14:00:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B63F5DD93; Fri, 12 Oct 2001 14:00:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E9FCD5DD92 for ; Fri, 12 Oct 2001 14:00:11 -0400 (EDT) Received: (qmail 11660 invoked by uid 500); 12 Oct 2001 17:45:19 -0000 Date: Fri, 12 Oct 2001 10:45:19 -0700 From: Pat Calhoun To: Bob Kopacz Cc: Pat Calhoun , aaa-wg Subject: [AAA-WG]: Re: Order of Members of MIP-XX-to-YY-Key AVPs Message-ID: <20011012104519.A11650@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , Pat Calhoun , aaa-wg References: <20011012072744.H10950@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Fri, Oct 12, 2001 at 10:44:55AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk not sure I understand the question, but if I do, my answer would be that I intentionally removed ordering. PatC On Fri, Oct 12, 2001 at 10:44:55AM -0400, Bob Kopacz wrote: > Hi Pat, > > > -----Original Message----- > > From: pcalhoun@charizard.diameter.org > > [mailto:pcalhoun@charizard.diameter.org]On Behalf Of Pat Calhoun > > Sent: Friday, October 12, 2001 10:28 AM > > To: Bob Kopacz > > Cc: Pat Calhoun; aaa-wg > > Subject: Re: Order of Members of MIP-XX-to-YY-Key AVPs > > > > > > Bob, > > > > I don't see why ordering is required for this AVP. Did you have any > > specific concerns that would require ordering? > > No. I was just wondering if removing the ordering requirement was > intended or an editing oversight. > > Thanks, > Bob K. > > > PatC > > On Fri, Oct 12, 2001 at 10:18:27AM -0400, Bob Kopacz wrote: > > > Hi Pat, > > > > > > In earlier drafts of Diameter, the Grouped AVPs had fixed member AVPs > > > in a fixed order. > > > > > > Now the Grouped AVPs have a more flexible > > > > > > "header [ *fixed] [ *required] [ *optional] [ *fixed]" format. > > > > > > Question: At the time this change was made, did you intend the > > > existing grouped AVPs, such as MIP-MN-AAA-Auth AVP and the > > > MIP-XX-to-YY-Key AVPs, to retain the fixed order of their members, or > > > did you intend the order of the required members to be arbitrary? > > > > > > e.g. if the fixed order was to be retained, should the MIP-MN-AAA-Auth > > > AVP description have had the editing change > > > > > > from: > > > > > > MIP-MN-AAA-Auth ::= < AVP Header: 322 > > > > { MIP-MN-AAA-SPI } > > > { MIP-Auth-Input-Data-Length } > > > { MIP-Authenticator-Length } > > > { MIP-Authenticator-Offset } > > > * [ AVP ] > > > > > > to: > > > > > > MIP-MN-AAA-Auth ::= < AVP Header: 322 > > > > < MIP-MN-AAA-SPI > > > > < MIP-Auth-Input-Data-Length > > > > < MIP-Authenticator-Length > > > > < MIP-Authenticator-Offset > > > > * [ AVP ] > > > > > > Bob K. > > > > > From owner-aaa-wg@merit.edu Fri Oct 12 15:45:13 2001 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 PAA08118 for ; Fri, 12 Oct 2001 15:45:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D667C91212; Fri, 12 Oct 2001 15:44:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A655B91225; Fri, 12 Oct 2001 15:44: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 8DDD691212 for ; Fri, 12 Oct 2001 15:44:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B7105DD9E; Fri, 12 Oct 2001 15:44:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 282905DD8E for ; Fri, 12 Oct 2001 15:44:45 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 0018F74; Fri, 12 Oct 2001 15:44:49 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier Date: Fri, 12 Oct 2001 15:42:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20010710105840.P10676@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I'm sorry to dredge this up, but I think there is a flaw here, so would like to re-open issue#93 and propose a solution. Base-Draft-08-alpha01 says: End-to-End Identifier The End-to-End Identifier is used to detect duplicate messages. Upon reboot, the high order 12 bits are initiated to contain the low order 12 bits of current time, while the low order 20 bits is set to a random value. Senders of request or answer messages MUST insert a unique identifier on each message, by incrementing the identifier by one (1). I'm thinking that, if the goal of the 12 time bits is to guarantee unique identifiers across reboots, then the end-to-end identifier's high-order 12-bits would need to be set to the current time's low order 12 bits every time an end-to-end identifier is generated, not just upon reboot. Then you would be guaranteed to produce unique identifiers across reboots provided that you meet the following criteria (which I lifted from earlier emails discussing this issue): 1. the device takes longer than a second to reboot 2. no transaction is kicking around for longer than an hour or so (2 ^ 12 seconds) 3. the transaction rate (the rate at which the identifier is incremented) is no greater than a million per second (2 ^ 20). The flaw: If the end-to-end identifier's 12 high-order bits are initialized only upon reboot, then there is no guarantee that upon reboot, a node wouldn't be sending the same end-to-end identifiers he was sending just a few seconds before the reboot. For example, suppose a node initializes his end-to-end identifier's 12 high-order bits only upon reboot. Suppose this node is booted at time T, stays up for 4095 (=2^12-1) seconds, and is rebooted at time T+4096. Then in each of these incarnations, the node would be using the same value for the 12 high-order bits of the end-to-end identifier. And the end-to-end identifiers used in the last few seconds of its previous life might be reused in the early transactions of its new life. Of course, if the end-to-end identifier's 12 high-order bits are updated every second, then the end-to-end identifier jumps by about 2^20 every second. I don't think there are any time bits that will help if you only want to init the high-order End-to-End Identifier bits upon reboot, so either go with updating the high-order bits every second, or get rid of it altogether and just init the End-to-End Identifier to a 32-bit random number upon reboot. The other comment I have to make is about the sentence "Senders of request messages MUST ... increment ... the identifier by one (1)". The "increment by 1" requirement seems to be an over-specification which imposes restrictions on the message originator's implementation, is undetectable by the message's recipient, and doesn't benefit the message's recipient. The previous thread concluded that a receiver could not make use of the "increment by 1". Chiefly, a recipient may receive an unordered and vanishingly small percentage of a client's Diameter messages. An end-to-end identifier which jumps by about 2^20 every second makes the unuseful "increment by 1" even less useful, so I propose getting rid of it altogether. Revise the End-to-End Identifier specification as follows: End-to-End Identifier The End-to-End Identifier is used to detect duplicate messages. Whenever an End-to-End Identifier is generated, the high order 12 bits are set to contain the low order 12 bits of current time, while the low order 20 bits are set to a value that ensures a unique identifier on each message. Bob K. From owner-aaa-wg@merit.edu Fri Oct 12 16:14:07 2001 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 QAA08741 for ; Fri, 12 Oct 2001 16:14:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70CF691253; Fri, 12 Oct 2001 16:13:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C86591258; Fri, 12 Oct 2001 16:13:54 -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 EBA9E91253 for ; Fri, 12 Oct 2001 16:13:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFA575DD9E; Fri, 12 Oct 2001 16:13:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 64B3C5DD8E for ; Fri, 12 Oct 2001 16:13:52 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9CKDJ027747; Fri, 12 Oct 2001 15:13:19 -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 f9CKDJk02678; Fri, 12 Oct 2001 15:13:19 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA13499; Fri, 12 Oct 2001 15:13:18 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id PAA18988; Fri, 12 Oct 2001 15:13:13 -0500 (CDT) Message-ID: <005301c1535a$54bd51e0$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Bob Kopacz" , "aaa-wg" Cc: "Tony Johansson" , "Pat Calhoun" References: Subject: Re: [AAA-WG]: Bakeoff Test Suite Date: Fri, 12 Oct 2001 13:13:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, Since Tony's on vacation, I'll go ahead and answer... To be honest, we underestimated the number of issues that would be raised, and subsequently anticipated that we would have had the -08 drafts out by now. While we are completely in favor of finalizing the protocol by raising and addressing issues and taking the amount of time necessary to do it correctly, we must now address the testing situation for the interop. As we all know, there have been a substantial amount of changes, both editorial and technical since the -07 drafts. The current -08 drafts which are now available, albeit in alpha status, better reflect a more stable and mature protocol, and it's safe to say we would much rather test using the alpha specs than their previous -07 counterparts. -Kevin ----- Original Message ----- From: "Bob Kopacz" To: "Tony Johansson" ; "Pat Calhoun" Cc: "aaa-wg" Sent: Friday, October 12, 2001 6:56 AM Subject: [AAA-WG]: Bakeoff Test Suite > Hi Tony and/or Pat, > > The Test Suite at the bakeoff website indicates the interoperability > tests will be based on draft-08, which isn't out yet. > > Is the plan then, that the bakeoff tests are based on draft-08-alpha01? > > And, for example, the MIP-XX-to-YY-Key AVPs are as described in > draft-08-alpha01, and not per subsequent mailing list discussions? > > Thanks, > Bob K. > From owner-aaa-wg@merit.edu Fri Oct 12 16:39:37 2001 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 QAA09064 for ; Fri, 12 Oct 2001 16:39:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B4A3A91258; Fri, 12 Oct 2001 16:39:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8060F91259; Fri, 12 Oct 2001 16:39:17 -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 722BD91258 for ; Fri, 12 Oct 2001 16:39:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55DDF5DD9E; Fri, 12 Oct 2001 16:39:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 3CC0D5DD8E for ; Fri, 12 Oct 2001 16:39:16 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 066F379; Fri, 12 Oct 2001 16:39:20 -0400 (EDT) From: "Bob Kopacz" To: "Kevin Purser" , "aaa-wg" Cc: "Tony Johansson" , "Pat Calhoun" Subject: RE: [AAA-WG]: Bakeoff Test Suite Date: Fri, 12 Oct 2001 16:36:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <005301c1535a$54bd51e0$869f558a@ew.us.am.ericsson.se> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kevin, > -----Original Message----- > From: Kevin Purser [mailto:kevin.purser@ericsson.com] > Sent: Friday, October 12, 2001 4:13 PM > To: Bob Kopacz; aaa-wg > Cc: Tony Johansson; Pat Calhoun > Subject: Re: [AAA-WG]: Bakeoff Test Suite > > > Hi Bob, > > Since Tony's on vacation, I'll go ahead and answer... > > To be honest, we underestimated the number of issues that would be raised, > and subsequently anticipated that we would have had the -08 drafts out by > now. While we are completely in favor of finalizing the protocol by raising > and addressing issues and taking the amount of time necessary to do it > correctly, we must now address the testing situation for the interop. > > As we all know, there have been a substantial amount of changes, both > editorial and technical since the -07 drafts. The current -08 drafts which > are now available, albeit in alpha status, better reflect a more stable and > mature protocol, and it's safe to say we would much rather test using the > alpha specs than their previous -07 counterparts. Thanks for the reply. I'm certainly in favor of 08-alpha over 07, and we have already modified our code to that spec. Bob K. > -Kevin > > > ----- Original Message ----- > From: "Bob Kopacz" > To: "Tony Johansson" ; "Pat Calhoun" > > Cc: "aaa-wg" > Sent: Friday, October 12, 2001 6:56 AM > Subject: [AAA-WG]: Bakeoff Test Suite > > > > Hi Tony and/or Pat, > > > > The Test Suite at the bakeoff website indicates the interoperability > > tests will be based on draft-08, which isn't out yet. > > > > Is the plan then, that the bakeoff tests are based on draft-08-alpha01? > > > > And, for example, the MIP-XX-to-YY-Key AVPs are as described in > > draft-08-alpha01, and not per subsequent mailing list discussions? > > > > Thanks, > > Bob K. > > > > From owner-aaa-wg@merit.edu Fri Oct 12 16:50:25 2001 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 QAA09270 for ; Fri, 12 Oct 2001 16:50:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8147891259; Fri, 12 Oct 2001 16:50:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F0B69125B; Fri, 12 Oct 2001 16:50:17 -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 44E4691259 for ; Fri, 12 Oct 2001 16:50:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A7995DD9E; Fri, 12 Oct 2001 16:50:16 -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 560A95DD8E for ; Fri, 12 Oct 2001 16:50:15 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA01721; Fri, 12 Oct 2001 16:49:54 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id QAA18834; Fri, 12 Oct 2001 16:50:41 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15303.22433.429099.131094@gargle.gargle.HOWL> Date: Fri, 12 Oct 2001 16:50:41 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: MIP-FA-to-MN-SPI and co-located servers X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Mark Eklund Submitter email address: meklund@diameter.org Date first submitted: 12-Oct-01 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html Document: mobileip Comment type: T Priority: 1 Section: 6.0 Rationale/Explanation of issue: This is a sub-issue of the issue, "Issue: Required AVPs in grouped key AVPs" submitted earlier by me that requests changing to use the Key ABNA as listed in the reference above. The value for the MIP-FA-to-MN-SPI key is contained in the registration request sent by the MN (and placed in the MIP-Reg-Request by the FA). The HA normally extracts this and sends it back to the AAAH as the MIP-FA-to-MN-SPI. The AAAH can then place that in the MIP-FA-to-MN-Key and sent back to the FA. A problem happens with a co-located server. When the AAAF gets an AMR and the MN-to-FA key was requested, it sends an AMA back to the FA that contains the MIP-FA-to-MN-Key and the MIP-MN-to-FA-Key. The problem is that the AAAF doesn't speak mobileip and can't extract the MIP-FA-to-MN-SPI from the registration request. Requested change: The currently suggested ABNF for the MIP-FA-to-MN-Key and the MIP-MN-to-FA-Key is MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-FA-to-MN-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } { MIP-Key-Lifetime } * [ AVP ] MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Key-Material } { MIP-Key-Lifetime } { AAA-SPI } * [ AVP ] Either make the MIP-FA-to-MN-SPI in the MIP-FA-to-MN-Key optional or only require that the MIP-MN-to-FA-Key be sent back when the server is co-located and add the MIP-Session-Key as an optional AVP. I.E. MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Key-Material } { MIP-Key-Lifetime } { AAA-SPI } [ MIP-Session-Key ] * [ AVP ] From owner-aaa-wg@merit.edu Sat Oct 13 07:55:30 2001 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 HAA02939 for ; Sat, 13 Oct 2001 07:55:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 228349125C; Sat, 13 Oct 2001 07:55:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C523791262; Sat, 13 Oct 2001 07:55: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 947629125C for ; Sat, 13 Oct 2001 07:55:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B69C5DDE9; Sat, 13 Oct 2001 07:55:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 226025DDE7 for ; Sat, 13 Oct 2001 07:55:15 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 104EA74; Sat, 13 Oct 2001 07:55:20 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: RE: [AAA-WG]: MN migration to new realm / draft-mobileip-08-alpha01 Date: Sat, 13 Oct 2001 07:52:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20011011092205.E6038@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Pat Calhoun > Sent: Thursday, October 11, 2001 12:22 PM > To: Bob Kopacz > Cc: aaa-wg > Subject: Re: [AAA-WG]: MN migration to new realm / > draft-mobileip-08-alpha01 > > > On Thu, Oct 11, 2001 at 12:21:29PM -0400, Bob Kopacz wrote: > > Hi Pat, > > > > Section 1.4 of draft-ietf-aaa-diameter-mobileip-08-alpha01 describes > > how the AAAH handles the case where the MN has migrated to a new > > foreign network and wants to keep the HA which has been allocated in > > the previous foreign network. What follows is the section I'm > > referring to: > > > > | 1.4 Allocation of Home Agent in Foreign Network > > | > > | [...] > > | > > | Figure 7 shows the message flows for a Mobile Node requesting to keep > > | the Home Agent assigned in Foreign network 1 when it moves to foreign > > | network 2. Upon reception of the AMR in Foreign network 2, the AAAF > > | follows the procedures described earlier and forwards AMR to the > > | Mobile Node's home network, i.e. its AAAH. If the Mobile Node was > > | successfully authenticated the AAAH checks for the Origin-Host and > > | the value of the Origin-Host of the previous request. If a AAAH > > | deduces that the Mobile Node has moved to a new realm, it must check > > | whether the Mobile can still use the previously assigned Home Agent. > > | > > | +---------------+ +---------------+ +-------------+ > > | |Foreign net 2 | |Foreign net 1 | |Home network | > > | | | | | | | > > | Mobile Node | FA AAAF | | HA AAAF | | AAAH | > > | ----------- | ---- ---- | | ---- ------ | | ------ | > > | +---------------+ +---------------+ +-------------+ > > | > > | <----Challenge---- > > | Reg-Req (Response)-> > > | ---AMR---> > > | ----------------AMR---------------> > > | <-----HAR----- > > | <---HAR---- > > | ----HAA---> > > | ------HAA----> > > | <---------------AMA---------------- > > | <--AMA---- > > | <----Reg-Reply----- > > | Figure 7: Request to access Home Agent from new Foreign Network > > | > > | If the Mobile Node is allowed to keep the Home Agent the AAAH then > > | sends a HAR, which contains the Mobile IP Registration Request > > | message data encapsulated in the MIP-Reg-Request AVP and the MIP- > > | Home-Agent-Address AVP with Home Agent address, as well as any > > | optional KDC session keys, to the AAAF in foreign network 1. Upon > > | reception the AAAF in foreign network 1 will forward the HAR to the > > | Home Agent if its local policy allows such service. If the AAAF does > > | not permit such service, it MUST return a > > | DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > > > My question is with the sentence "If a AAAH deduces that the Mobile > > Node has moved to a new realm, it must check whether the Mobile can > > still use the previously assigned Home Agent." > > > > The previous sentence says "the AAAH checks for the Origin-Host and > > the value of the Origin-Host of the previous request". But this > > proposal implies that the AAAH maintains session-state and has > > remembered the previous request. From what I've been reading in the > > mailing list, the AAAH isn't required to maintain session state. > > > > Question: How does an AAAH that doesn't maintain session state make > > this "MN has moved to a new realm" deduction? > > Mobile IP has a previous Foreign Agent extension, and combined with the > Home Agent field of the registration requestion, this can be deduced. I'll have to bone up on what is in a Mobile-IP Registration Request. But if I understand correctly, your thinking is that: 1. A stateless AAAH should parse the MIP-Reg-Request AVP to determine if the MN has moved to a new domain, and 2. The MIP-Reg-Request contains sufficient information to make this determination, and 3. The MIP-Reg-Request contains sufficient information for the AAAH to construct the Destination-Host (which contains a Diameter Identity) and Destination-Realm, for the HAR which is to be sent to the old foreign network where the HA lives. Up to this point, the AAA server has been able to treat the MIP-Reg-Request as opaque data; the FA extracted the goodies from the Reg-Req and presented them as Diameter AVPs. Would it be reasonable for the FA to extract this further information so the AAAH wouldn't have to parse the MIP-Reg-Request? > > Question: If the session-stateless AAAH could make such a deduction, > > it would seem that the AAAH could not allow the MN to keep the old HA, > > as the AAAH would be unable to route the HAR to the old foreign > > network where the HA lives. True? > > no, the HA is in the registration request. > > > Question: If the session-stateless AAAH cannot make such a deduction, > > does that mean that the MN, if allowed to have a foreign HA, would > > lose his connection if he migrated to a new foreign network? > > only if the local policy states this needs to happen. > > > Question: If the current request went to a different AAAH than the > > previous request, then even a session-stateful AAAH could not allow > > the MN to keep the old HA, as the AAAH would be unable to route the > > HAR to the old foreign network where the HA lives. True? > > see above. > > PatC > From owner-aaa-wg@merit.edu Sun Oct 14 06:38:03 2001 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 GAA28133 for ; Sun, 14 Oct 2001 06:38:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8892191212; Sun, 14 Oct 2001 06:37:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CBC791228; Sun, 14 Oct 2001 06:37:50 -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 2DBBE91212 for ; Sun, 14 Oct 2001 06:37:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0434D5DDD2; Sun, 14 Oct 2001 06:37:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 2FC355DD8E for ; Sun, 14 Oct 2001 06:37:48 -0400 (EDT) Received: from fredrikj (c14.local.ipunplugged.com [192.168.4.213]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA22673; Sun, 14 Oct 2001 12:37:44 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , "Bob Kopacz" Cc: "aaa-wg" Subject: RE: [AAA-WG]: MN migration to new realm / draft-mobileip-08-alpha01 Date: Sun, 14 Oct 2001 12:38:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011011092205.E6038@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I'm not sure this will work, please see comments inline /Fredrik > >On Thu, Oct 11, 2001 at 12:21:29PM -0400, Bob Kopacz wrote: >> Hi Pat, >> >> Section 1.4 of draft-ietf-aaa-diameter-mobileip-08-alpha01 describes >> how the AAAH handles the case where the MN has migrated to a new >> foreign network and wants to keep the HA which has been allocated in >> the previous foreign network. What follows is the section I'm >> referring to: >> >> | 1.4 Allocation of Home Agent in Foreign Network >> | >> | [...] >> | >> | Figure 7 shows the message flows for a Mobile Node requesting to keep >> | the Home Agent assigned in Foreign network 1 when it moves to foreign >> | network 2. Upon reception of the AMR in Foreign network 2, the AAAF >> | follows the procedures described earlier and forwards AMR to the >> | Mobile Node's home network, i.e. its AAAH. If the Mobile Node was >> | successfully authenticated the AAAH checks for the Origin-Host and >> | the value of the Origin-Host of the previous request. If a AAAH >> | deduces that the Mobile Node has moved to a new realm, it must check >> | whether the Mobile can still use the previously assigned Home Agent. >> | >> | +---------------+ +---------------+ +-------------+ >> | |Foreign net 2 | |Foreign net 1 | |Home network | >> | | | | | | | >> | Mobile Node | FA AAAF | | HA AAAF | | AAAH | >> | ----------- | ---- ---- | | ---- ------ | | ------ | >> | +---------------+ +---------------+ +-------------+ >> | >> | <----Challenge---- >> | Reg-Req (Response)-> >> | ---AMR---> >> | ----------------AMR---------------> >> | <-----HAR----- >> | <---HAR---- >> | ----HAA---> >> | ------HAA----> >> | <---------------AMA---------------- >> | <--AMA---- >> | <----Reg-Reply----- >> | Figure 7: Request to access Home Agent from new Foreign Network >> | >> | If the Mobile Node is allowed to keep the Home Agent the AAAH then >> | sends a HAR, which contains the Mobile IP Registration Request >> | message data encapsulated in the MIP-Reg-Request AVP and the MIP- >> | Home-Agent-Address AVP with Home Agent address, as well as any >> | optional KDC session keys, to the AAAF in foreign network 1. Upon >> | reception the AAAF in foreign network 1 will forward the HAR to the >> | Home Agent if its local policy allows such service. If the AAAF does >> | not permit such service, it MUST return a >> | DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. >> >> My question is with the sentence "If a AAAH deduces that the Mobile >> Node has moved to a new realm, it must check whether the Mobile can >> still use the previously assigned Home Agent." >> >> The previous sentence says "the AAAH checks for the Origin-Host and >> the value of the Origin-Host of the previous request". But this >> proposal implies that the AAAH maintains session-state and has >> remembered the previous request. From what I've been reading in the >> mailing list, the AAAH isn't required to maintain session state. >> >> Question: How does an AAAH that doesn't maintain session state make >> this "MN has moved to a new realm" deduction? > >Mobile IP has a previous Foreign Agent extension, and combined with the >Home Agent field of the registration requestion, this can be deduced. The MIP-Previous-FA AVP was taken out of the draft when we removed the optimization that you could get session keys from AAAf. Of course it can be added again, so no major problem here. > >> Question: If the session-stateless AAAH could make such a deduction, >> it would seem that the AAAH could not allow the MN to keep the old HA, >> as the AAAH would be unable to route the HAR to the old foreign >> network where the HA lives. True? > >no, the HA is in the registration request. Yes, the HA address is in the registration request, but the HA URI that is to be put in the Destination-Host AVP is not and the AAAh has no way of mapping from HA address to HA URI for every possible HA in foreign networks. It just doesn't scale. > >> Question: If the session-stateless AAAH cannot make such a deduction, >> does that mean that the MN, if allowed to have a foreign HA, would >> lose his connection if he migrated to a new foreign network? > >only if the local policy states this needs to happen. > >> Question: If the current request went to a different AAAH than the >> previous request, then even a session-stateful AAAH could not allow >> the MN to keep the old HA, as the AAAH would be unable to route the >> HAR to the old foreign network where the HA lives. True? > >see above. dito /Fredrik > >PatC From owner-aaa-wg@merit.edu Sun Oct 14 10:06:35 2001 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 KAA29321 for ; Sun, 14 Oct 2001 10:06:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2EA1F9122D; Sun, 14 Oct 2001 10:06:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA5F891250; Sun, 14 Oct 2001 10:06:22 -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 A571B9122D for ; Sun, 14 Oct 2001 10:06:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 822045DD91; Sun, 14 Oct 2001 10:06:21 -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 AD9F75DD8C for ; Sun, 14 Oct 2001 10:06:20 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA10907; Sun, 14 Oct 2001 10:05:25 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA19787; Sun, 14 Oct 2001 10:06:13 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15305.39893.580634.438676@gargle.gargle.HOWL> Date: Sun, 14 Oct 2001 10:06:13 -0400 To: "Bob Kopacz" Cc: "Pat Calhoun" , "aaa-wg" Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier In-Reply-To: References: <20010710105840.P10676@charizard.diameter.org> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, Bob Kopacz writes: > Hi Pat, > > I'm sorry to dredge this up, but I think there is a flaw here, so would > like to re-open issue#93 and propose a solution. > > Base-Draft-08-alpha01 says: > > End-to-End Identifier > The End-to-End Identifier is used to detect duplicate messages. > Upon reboot, the high order 12 bits are initiated to contain the > low order 12 bits of current time, while the low order 20 bits is > set to a random value. Senders of request or answer messages MUST > insert a unique identifier on each message, by incrementing the > identifier by one (1). > > I'm thinking that, if the goal of the 12 time bits is to guarantee > unique identifiers across reboots, then the end-to-end identifier's > high-order 12-bits would need to be set to the current time's low order > 12 bits every time an end-to-end identifier is generated, not just upon > reboot. > > Then you would be guaranteed to produce unique identifiers across > reboots provided that you meet the following criteria (which I lifted > from earlier emails discussing this issue): > > 1. the device takes longer than a second to reboot > > 2. no transaction is kicking around for longer than an hour or so > (2 ^ 12 seconds) > > 3. the transaction rate (the rate at which the identifier is incremented) > is no greater than a million per second (2 ^ 20). > > The flaw: If the end-to-end identifier's 12 high-order bits are > initialized only upon reboot, then there is no guarantee that upon > reboot, a node wouldn't be sending the same end-to-end identifiers he > was sending just a few seconds before the reboot. For example, suppose > a node initializes his end-to-end identifier's 12 high-order bits only > upon reboot. Suppose this node is booted at time T, stays up for 4095 > (=2^12-1) seconds, and is rebooted at time T+4096. Then in each of > these incarnations, the node would be using the same value for the 12 > high-order bits of the end-to-end identifier. And the end-to-end > identifiers used in the last few seconds of its previous life might be > reused in the early transactions of its new life. > > Of course, if the end-to-end identifier's 12 high-order bits are updated > every second, then the end-to-end identifier jumps by about 2^20 every > second. > > I don't think there are any time bits that will help if you only want to > init the high-order End-to-End Identifier bits upon reboot, so either go > with updating the high-order bits every second, or get rid of it > altogether and just init the End-to-End Identifier to a 32-bit random > number upon reboot. > > > The other comment I have to make is about the sentence "Senders of > request messages MUST ... increment ... the identifier by one (1)". The > "increment by 1" requirement seems to be an over-specification which > imposes restrictions on the message originator's implementation, is > undetectable by the message's recipient, and doesn't benefit the > message's recipient. The previous thread concluded that a receiver > could not make use of the "increment by 1". Chiefly, a recipient may > receive an unordered and vanishingly small percentage of a client's > Diameter messages. > > An end-to-end identifier which jumps by about 2^20 every second makes > the unuseful "increment by 1" even less useful, so I propose getting rid > of it altogether. > > Revise the End-to-End Identifier specification as follows: > > End-to-End Identifier > > The End-to-End Identifier is used to detect duplicate messages. > Whenever an End-to-End Identifier is generated, the high order > 12 bits are set to contain the low order 12 bits of current > time, while the low order 20 bits are set to a value that ensures > a unique identifier on each message. I agree the current implementation doesn't work, but wouldn't your suggestion limit Diameter to around a million calls per second? I'd prefer something like End-to-End Identifier The End-to-End Identifier is used to detect duplicate messages. Upon reboot, the End-to-End Identifier SHOULD be initialized to a number that would come after the last End-To-End identifier before reboot. Note that since wraparound is possible, if the last End-To-End identifier is 0xffffffff, 0 would be a valid initializer after reboot. If it is not possible to maintain identifier state between reboots, the identifier SHOULD be initialized to a random value. If there is some way to combine sentence two and three using some magic term that means after, but allowing wraparound, please suggest it. Also note that my wording doesn't require the new End-To-End identifier to be exactly one greater than the last End-To-End identifier before reboot. This allows you to checkpoint once every million times I.E. main() { int e2e; int e2echeckpoint; e2e = read_checkpoint(); e2echeckpoint += 1000000; write_checkpoint(e2echeckpoint); while (true) { /* packet create code */ if (++e2e == e2echeckpoint) { e2echeckpoint += 1000000; write_checkpoint(e2echeckpoint) } /* other code */ } } -mark > > Bob K. From owner-aaa-wg@merit.edu Sun Oct 14 10:58:21 2001 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 KAA29706 for ; Sun, 14 Oct 2001 10:58:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 583569120F; Sun, 14 Oct 2001 10:58:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2213591250; Sun, 14 Oct 2001 10:58: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 D92F39120F for ; Sun, 14 Oct 2001 10:57:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B01B25DDC8; Sun, 14 Oct 2001 10:57:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 38C755DD8C for ; Sun, 14 Oct 2001 10:57:59 -0400 (EDT) Received: (qmail 21860 invoked by uid 500); 14 Oct 2001 14:43:01 -0000 Date: Sun, 14 Oct 2001 07:43:01 -0700 From: Pat Calhoun To: Mark Jones , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation Message-ID: <20011014074301.A21749@charizard.diameter.org> Mail-Followup-To: Mark Jones , Pat Calhoun , aaa-wg@merit.edu References: <20011010072334.A26284@charizard.diameter.org> <20011010093432.A27333@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011010093432.A27333@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, Oct 10, 2001 at 09:34:32AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, After having read the draft some more, I do agree with some of Mark's comments, in that it isn't entirely clear in the draft how some keys are sent to some entities. So I have reworked section 5.0 into two sections, and would solicit comments. Text below. Thanks, PatC ---- 5.0 Key Distribution Center The mobile node and mobility agents use session keys to compute authentication extensions applied to registration messages, as defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If session keys are requested the AAA server(s) MUST return the key material after the Mobile Node is successfully authenticated and authorized. If the AAAH does not communicate directly with the foreign agent, and it does not wish for intermediate proxies to have access to the session keys, they SHOULD be protected using the CMS security application [9]. The MIP-Key-Lifetime AVP contains the number of seconds before session keys destined for the Home Agent and/or Foreign Agent expire. A value of zero indicates infinity (no timeout). The SPI values are used as key identifiers, meaning that each session key has its own SPI value; nodes that share a key also share an SPI. The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home authentication extensions, via the Mobile IP AAA Key Request extensions [15], while the Home Agent allocates the Mobile- Foreign, Mobile-Home and Foreign-Home SPIs. Once the session keys have been distributed, subsequent Mobile IP registrations need not invoke the AAA infrastructure until the keys expire. These registrations MUST include the Mobile-Home authentication extension. In addition, subsequent registrations MUST also include Mobile-Foreign authentication extension if the Mobile- Foreign key was generated and distributed by AAA; similarly for subsequent use of the Foreign-Home authentication extensions. 5.1 Key Material vs. Session Key Each session key that is generated by the AAAH will generally be distributed to two parties; for instance, a Mobile-Foreign is sent to both the mobile node and the foreign agent. The key sent to the mobile node is always in the form of key material, which the AAAH does by generating a random [18] value of at least 64 bits. The random value is used by the mobile node to create the actual session key. The following is an example of a session creation procedure, using MD5 as the hashing algorithm. Additional algorithms are supported, and listed in [15]. MD5(AAA-Key | key material | node-address | AAA-Key) Where: - AAA-Key is the long term secret shared between the mobile node and the AAAH. - Key material is a random [18] value of at least 64 bits. - node-address is the mobile node's identity. This is the contents of the MIP-Mobile-Node-Address AVP, unless the value of the AVP is all zero or ones, in which case of value of the User-Name AVP is used instead. The AAAH then generates the session key which is destined for the mobility agent, in this case the foreign agent, by following the above procedures. It is important that the hashing algorithm used by the mobile node is the same as the one used by the AAAH in the session key generation procedure. Therefore, the AAAH MUST know a priori the transform used, which is typically contained in the mobile node's configuration profile. The session keys destined for mobility agents are encoded using the security association available between the AAA server and the agents (e.g. IPSec, TLS, CMS). See sections 6.0 for details about the format of the AVPs used to transport the session keys. From owner-aaa-wg@merit.edu Sun Oct 14 11:05:14 2001 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 LAA29799 for ; Sun, 14 Oct 2001 11:05:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A03A91250; Sun, 14 Oct 2001 11:04:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47C8091253; Sun, 14 Oct 2001 11:04:54 -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 1710791250 for ; Sun, 14 Oct 2001 11:04:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC29D5DDA1; Sun, 14 Oct 2001 11:04:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3A4685DD8C for ; Sun, 14 Oct 2001 11:04:52 -0400 (EDT) Received: (qmail 21881 invoked by uid 500); 14 Oct 2001 14:49:54 -0000 Date: Sun, 14 Oct 2001 07:49:54 -0700 From: Pat Calhoun To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: MIP-FA-to-MN-SPI and co-located servers Message-ID: <20011014074954.B21749@charizard.diameter.org> Mail-Followup-To: Mark Eklund , aaa-wg@merit.edu References: <15303.22433.429099.131094@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15303.22433.429099.131094@gargle.gargle.HOWL>; from meklund@cisco.com on Fri, Oct 12, 2001 at 04:50:41PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Mark, You've lost me here. You state that a co-located server (whatever that happens to be) doesn't speak mobile ip, and therefore cannot extract the MIP-FA-to-MN-SPI AVP from the registration request. Why is the Diameter AVP in the Mobile IP message? I suspect that I'm misunderstanding your issue :( PatC On Fri, Oct 12, 2001 at 04:50:41PM -0400, Mark Eklund wrote: > Submitter name: Mark Eklund > Submitter email address: meklund@diameter.org > Date first submitted: 12-Oct-01 > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html > Document: mobileip > Comment type: T > Priority: 1 > Section: 6.0 > Rationale/Explanation of issue: > > This is a sub-issue of the issue, "Issue: Required AVPs in grouped > key AVPs" submitted earlier by me that requests changing to use the > Key ABNA as listed in the reference above. > > The value for the MIP-FA-to-MN-SPI key is contained in the > registration request sent by the MN (and placed in the > MIP-Reg-Request by the FA). The HA normally extracts this and sends > it back to the AAAH as the MIP-FA-to-MN-SPI. The AAAH can then > place that in the MIP-FA-to-MN-Key and sent back to the FA. > > A problem happens with a co-located server. When the AAAF gets an > AMR and the MN-to-FA key was requested, it sends an AMA back to the > FA that contains the MIP-FA-to-MN-Key and the MIP-MN-to-FA-Key. The > problem is that the AAAF doesn't speak mobileip and can't > extract the MIP-FA-to-MN-SPI from the registration request. > > Requested change: > The currently suggested ABNF for the MIP-FA-to-MN-Key and the > MIP-MN-to-FA-Key is > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > { MIP-Key-Lifetime } > * [ AVP ] > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > { MIP-Algorithm-Type } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } > * [ AVP ] > > Either make the MIP-FA-to-MN-SPI in the MIP-FA-to-MN-Key optional or > only require that the MIP-MN-to-FA-Key be sent back when the server > is co-located and add the MIP-Session-Key as an optional AVP. I.E. > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > { MIP-Algorithm-Type } > { MIP-Key-Material } > { MIP-Key-Lifetime } > { AAA-SPI } > [ MIP-Session-Key ] > * [ AVP ] From owner-aaa-wg@merit.edu Sun Oct 14 11:21:10 2001 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 LAA00078 for ; Sun, 14 Oct 2001 11:21:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FFD79123A; Sun, 14 Oct 2001 11:20:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E425191253; Sun, 14 Oct 2001 11:20:49 -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 CB9139123A for ; Sun, 14 Oct 2001 11:20:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A37C15DDA1; Sun, 14 Oct 2001 11:20:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 122965DD8C for ; Sun, 14 Oct 2001 11:20:48 -0400 (EDT) Received: (qmail 21959 invoked by uid 500); 14 Oct 2001 15:05:50 -0000 Date: Sun, 14 Oct 2001 08:05:50 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011014080550.D21749@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Following the recommendation to add this to the URI, here is the proposed text. I do, however, have some objections to the proposal that was made in the issue submission. Basically, the issue proposed two new URI fields, where TLS could be independently set for either transport protocols (e.g. TCP, SCTP). This would allow for a secure communication over one medium, and unsecure over the other. Of course, a malicious node would use the unsecure one. So, here is my proposed addition to the URI: security = ( "none" | "TLS" ) ; Specifies whether TLS is to be used ; when communicating with the peer. The ; default value is none. PatC From owner-aaa-wg@merit.edu Sun Oct 14 19:48:28 2001 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 TAA02221 for ; Sun, 14 Oct 2001 19:48:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACD3F91206; Sun, 14 Oct 2001 19:48:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ED9091208; Sun, 14 Oct 2001 19:48:09 -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 49D8491206 for ; Sun, 14 Oct 2001 19:48:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 02DBF5DDAB; Sun, 14 Oct 2001 19:48:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B43F85DD95 for ; Sun, 14 Oct 2001 19:48:06 -0400 (EDT) Received: (qmail 22506 invoked by uid 500); 14 Oct 2001 23:33:07 -0000 Date: Sun, 14 Oct 2001 16:33:07 -0700 From: Pat Calhoun To: Mark Eklund Cc: Bob Kopacz , Pat Calhoun , aaa-wg Subject: Re: [AAA-WG]: Issue 93: End-to-End Identifier Message-ID: <20011014163307.B22485@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Bob Kopacz , Pat Calhoun , aaa-wg References: <20010710105840.P10676@charizard.diameter.org> <15305.39893.580634.438676@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15305.39893.580634.438676@gargle.gargle.HOWL>; from meklund@cisco.com on Sun, Oct 14, 2001 at 10:06:13AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk hmmm... I'm torn. I think that Bob's suggestion solves the problem, but Mark's seems to be on a completely different track. What does the WG think is best? PatC On Sun, Oct 14, 2001 at 10:06:13AM -0400, Mark Eklund wrote: > Bob, > > Bob Kopacz writes: > > Hi Pat, > > > > I'm sorry to dredge this up, but I think there is a flaw here, so would > > like to re-open issue#93 and propose a solution. > > > > Base-Draft-08-alpha01 says: > > > > End-to-End Identifier > > The End-to-End Identifier is used to detect duplicate messages. > > Upon reboot, the high order 12 bits are initiated to contain the > > low order 12 bits of current time, while the low order 20 bits is > > set to a random value. Senders of request or answer messages MUST > > insert a unique identifier on each message, by incrementing the > > identifier by one (1). > > > > I'm thinking that, if the goal of the 12 time bits is to guarantee > > unique identifiers across reboots, then the end-to-end identifier's > > high-order 12-bits would need to be set to the current time's low order > > 12 bits every time an end-to-end identifier is generated, not just upon > > reboot. > > > > Then you would be guaranteed to produce unique identifiers across > > reboots provided that you meet the following criteria (which I lifted > > from earlier emails discussing this issue): > > > > 1. the device takes longer than a second to reboot > > > > 2. no transaction is kicking around for longer than an hour or so > > (2 ^ 12 seconds) > > > > 3. the transaction rate (the rate at which the identifier is incremented) > > is no greater than a million per second (2 ^ 20). > > > > The flaw: If the end-to-end identifier's 12 high-order bits are > > initialized only upon reboot, then there is no guarantee that upon > > reboot, a node wouldn't be sending the same end-to-end identifiers he > > was sending just a few seconds before the reboot. For example, suppose > > a node initializes his end-to-end identifier's 12 high-order bits only > > upon reboot. Suppose this node is booted at time T, stays up for 4095 > > (=2^12-1) seconds, and is rebooted at time T+4096. Then in each of > > these incarnations, the node would be using the same value for the 12 > > high-order bits of the end-to-end identifier. And the end-to-end > > identifiers used in the last few seconds of its previous life might be > > reused in the early transactions of its new life. > > > > Of course, if the end-to-end identifier's 12 high-order bits are updated > > every second, then the end-to-end identifier jumps by about 2^20 every > > second. > > > > I don't think there are any time bits that will help if you only want to > > init the high-order End-to-End Identifier bits upon reboot, so either go > > with updating the high-order bits every second, or get rid of it > > altogether and just init the End-to-End Identifier to a 32-bit random > > number upon reboot. > > > > > > The other comment I have to make is about the sentence "Senders of > > request messages MUST ... increment ... the identifier by one (1)". The > > "increment by 1" requirement seems to be an over-specification which > > imposes restrictions on the message originator's implementation, is > > undetectable by the message's recipient, and doesn't benefit the > > message's recipient. The previous thread concluded that a receiver > > could not make use of the "increment by 1". Chiefly, a recipient may > > receive an unordered and vanishingly small percentage of a client's > > Diameter messages. > > > > An end-to-end identifier which jumps by about 2^20 every second makes > > the unuseful "increment by 1" even less useful, so I propose getting rid > > of it altogether. > > > > Revise the End-to-End Identifier specification as follows: > > > > End-to-End Identifier > > > > The End-to-End Identifier is used to detect duplicate messages. > > Whenever an End-to-End Identifier is generated, the high order > > 12 bits are set to contain the low order 12 bits of current > > time, while the low order 20 bits are set to a value that ensures > > a unique identifier on each message. > > I agree the current implementation doesn't work, but wouldn't your > suggestion limit Diameter to around a million calls per second? I'd > prefer something like > > End-to-End Identifier > > The End-to-End Identifier is used to detect duplicate messages. > Upon reboot, the End-to-End Identifier SHOULD be initialized to > a number that would come after the last End-To-End identifier > before reboot. Note that since wraparound is possible, if the > last End-To-End identifier is 0xffffffff, 0 would be a valid > initializer after reboot. If it is not possible to maintain > identifier state between reboots, the identifier SHOULD be > initialized to a random value. > > If there is some way to combine sentence two and three using some magic > term that means after, but allowing wraparound, please suggest it. > > Also note that my wording doesn't require the new End-To-End > identifier to be exactly one greater than the last End-To-End > identifier before reboot. This allows you to checkpoint once every > million times I.E. > > main() > { > int e2e; > int e2echeckpoint; > > e2e = read_checkpoint(); > e2echeckpoint += 1000000; > write_checkpoint(e2echeckpoint); > > while (true) { > /* packet create code */ > if (++e2e == e2echeckpoint) { > e2echeckpoint += 1000000; > write_checkpoint(e2echeckpoint) > } > /* other code */ > } > } > > -mark > > > > > Bob K. From owner-aaa-wg@merit.edu Sun Oct 14 19:53:39 2001 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 TAA02244 for ; Sun, 14 Oct 2001 19:53:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 48CF091216; Sun, 14 Oct 2001 19:53:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1ED4F9120F; Sun, 14 Oct 2001 19:53: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 E625D9121A for ; Sun, 14 Oct 2001 19:53:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF5BF5DDB1; Sun, 14 Oct 2001 19:52:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 88F1D5DD95 for ; Sun, 14 Oct 2001 19:52:59 -0400 (EDT) Received: (qmail 22528 invoked by uid 500); 14 Oct 2001 23:37:45 -0000 Date: Sun, 14 Oct 2001 16:37:45 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP Message-ID: <20011014163745.C22485@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA3B@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA3B@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Tue, Oct 09, 2001 at 08:41:18PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk ok, having looked at the document further, you are correct that there were some inconsistencies. I've added the User-Name to the ASR/ASA, and fixed the table in section 10.2. Thanks, PatC On Tue, Oct 09, 2001 at 08:41:18PM +0300, jaakko.rajaniemi@nokia.com wrote: > Hi, > > Right, however I was mainly thinking of the base protocol commands which are > part of the user session like Session-Termination, Abort-Session and > Re-auth. Those are defined differently with regard to User-Name AVP. > > Best Regards, Jaakko > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: 08 October, 2001 0:54 > > To: Rajaniemi Jaakko (NET/Espoo) > > Cc: pcalhoun@diameter.org; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Abort-Session-Request and User-Name AVP > > > > > > > After this long talk my question here is that, is there a > > specific reason > > > why the User-Name AVP is included into some of the base > > protocol commands as > > > a mandatory AVP and some of them don't have it? > > > > because some messages have nothing to do with specific users > > (e.g. watchdog > > messages). > > > > PatC > > From owner-aaa-wg@merit.edu Sun Oct 14 19:55:58 2001 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 TAA02262 for ; Sun, 14 Oct 2001 19:55:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B303291208; Sun, 14 Oct 2001 19:55:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B17B9120F; Sun, 14 Oct 2001 19:55: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 6C82191208 for ; Sun, 14 Oct 2001 19:55:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45D035DDAD; Sun, 14 Oct 2001 19:55:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DE3055DD95 for ; Sun, 14 Oct 2001 19:55:36 -0400 (EDT) Received: (qmail 22546 invoked by uid 500); 14 Oct 2001 23:40:38 -0000 Date: Sun, 14 Oct 2001 16:40:37 -0700 From: Pat Calhoun To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: CMS Security for Mobile-IP Session Keys Message-ID: <20011014164037.D22485@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , aaa-wg References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Mon, Oct 08, 2001 at 06:08:19PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Q1: Suppose the AAAH receives an AMR from some FA, and the AAAH wants to > hide the session keys being returned in the AMA, but the FA has not > previously set up a DSA with the AAAH. Does the AAAH then reject the AMR > with a Result-Code of DIAMETER_NO_DSA_ESTABLISHED? Or is it the FA that > dictates whether CMS will be used, i.e. if no DSA has been set up by the FA, > then the AAAH can't hide his AMA's session keys? It's a policy decision on both ends. If the FA's policy was to establish a DSA then it would. If the AAAH will only accept requests with a DSA in place, then it would reply with the error code you mentioned. > Q2: Suppose a Diameter Mobile-IP AAA Home server receives an AMR in which > the AAAF has offered to allocate the HA in the visited network. Suppose the > AAAH wants to accept the offer, and the AAAH wants to use CMS to hide the > session keys he will be sending to the foreign HA via the HAR. Before > sending the HAR, the AAAH will want to first set up a DSA with the HA by > sending a DSAR. But the AAAH doesn't yet know who the HA is. The best he > can do is to send the DSAR with the Destination-Realm set to the AMR's > Origin-Realm, and with no Destination-Host. In this case, it seems the DSAR > would be consumed by some AAA server in the foreign network, so the AAAH > would end up with a DSA with some AAAF, rather than with the HA. hmmm... interesting scenario. I believe that the AAAH would send the HAR, which would be rejected by the HA with the error code you mentioned above, and then the DSA could be established. I'll admit this isn't the most efficient approach, but it is rather difficult to setup a DSA with an unknown host. PatC From owner-aaa-wg@merit.edu Mon Oct 15 00:59:30 2001 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 AAA06284 for ; Mon, 15 Oct 2001 00:59:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C39359120E; Mon, 15 Oct 2001 00:59:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 918289120F; Mon, 15 Oct 2001 00:59: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 7F1919120E for ; Mon, 15 Oct 2001 00:59:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 556725DDDF; Mon, 15 Oct 2001 00:59:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id BF8DA5DD95 for ; Mon, 15 Oct 2001 00:59:03 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9F4x3m08569 for aaa-wg@merit.edu; Mon, 15 Oct 2001 00:59:03 -0400 (EDT) (envelope-from barney) Date: Mon, 15 Oct 2001 00:59:03 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 93: End-to-End Identifier Message-ID: <20011015005903.A8407@tp.databus.com> References: <20010710105840.P10676@charizard.diameter.org> <15305.39893.580634.438676@gargle.gargle.HOWL> <20011014163307.B22485@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011014163307.B22485@charizard.diameter.org>; from pcalhoun@diameter.org on Sun, Oct 14, 2001 at 04:33:07PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Making the identifier start random on reboot is no better and no worse than making the hi-order 12 bits depend on time and the rest random, as the reboot interval is itself random. Making the id depend on the time of the request depends on ensuring that time can never go backward or noticing when it does and adjusting the remaining bits to compensate. Yes, I have seen NTP go backward, when network paths or queues make forward and reverse one-way delays significantly different for a while. If one is going to require no duplicates within an hour at a request rate of a million per second then a 32-bit id is just barely adequate even with perfect state memory across reboots, so any algorithm that does not assume state memory will necessarily fail. The only solution I see is to make the id longer. A 64-bit id started at a random value on reboot would give a negligible probability of duplication. The point of incrementing by 1 each time is to avoid exhausting the id space faster than necessary. Obviously it does not have to be done perfectly, but I cannot imagine an implementation deliberately choosing a larger increment. Barney Wolff On Sun, Oct 14, 2001 at 04:33:07PM -0700, Pat Calhoun wrote: > hmmm... I'm torn. I think that Bob's suggestion solves the problem, but > Mark's seems to be on a completely different track. What does the WG > think is best? From owner-aaa-wg@merit.edu Mon Oct 15 01:05:16 2001 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 BAA06357 for ; Mon, 15 Oct 2001 01:05:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3612C9120F; Mon, 15 Oct 2001 01:04:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A1F291212; Mon, 15 Oct 2001 01:04:50 -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 E7B8C9120F for ; Mon, 15 Oct 2001 01:04:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6AA25DD95; Mon, 15 Oct 2001 01:04:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 3B5895DDE7 for ; Mon, 15 Oct 2001 01:04:48 -0400 (EDT) Received: by CMS3 with Internet Mail Service (5.5.2653.19) id <47HK66R1>; Mon, 15 Oct 2001 14:02:30 +0900 Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E7FC@CMS3> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [RE] Re: [AAA-WG]: CMS Security for Mobile-IP Session Keys Date: Mon, 15 Oct 2001 14:02:29 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15536.97380370" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15536.97380370 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable I thought i can use CMS Security only between FA and AAAF... for strong authentication of registration keys. But, because of below emails. i think i need change my thought. =20 Final Question is :=20 Regardless of HA's location(home or foreign domain),=20 is it recommended that the CMS security application be used between 'HA' and AAAH as well as between 'FA' and AAAH? =20 please make things clear!! =20 =20 =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: Pat Calhoun[pcalhoun@diameter.org] =B9=DE=B4=C2=BB=E7=B6=F7: Bob Kopacz =C2=FC=C1=B6:aaa-wg =C1=A6=B8=F1: Re: [AAA-WG]: CMS Security for Mobile-IP Session Keys =B9=DE=C0=BA=B3=AF=C2=A5: 2001/10/15 =BF=F9 08:40 > Q1: Suppose the AAAH receives an AMR from some FA, and the AAAH wants = to=20 > hide the session keys being returned in the AMA, but the FA has not=20 > previously set up a DSA with the AAAH. Does the AAAH then reject the = AMR=20 > with a Result-Code of DIAMETER_NO_DSA_ESTABLISHED? Or is it the FA = that=20 > dictates whether CMS will be used, i.e. if no DSA has been set up by = the FA,=20 > then the AAAH can't hide his AMA's session keys? It's a policy decision on both ends. If the FA's policy was to = establish a DSA=20 then it would. If the AAAH will only accept requests with a DSA in = place, then=20 it would reply with the error code you mentioned. > Q2: Suppose a Diameter Mobile-IP AAA Home server receives an AMR in = which=20 > the AAAF has offered to allocate the HA in the visited network. = Suppose the=20 > AAAH wants to accept the offer, and the AAAH wants to use CMS to hide = the=20 > session keys he will be sending to the foreign HA via the HAR. = Before=20 > sending the HAR, the AAAH will want to first set up a DSA with the HA = by=20 > sending a DSAR. But the AAAH doesn't yet know who the HA is. The = best he=20 > can do is to send the DSAR with the Destination-Realm set to the = AMR's=20 > Origin-Realm, and with no Destination-Host. In this case, it seems = the DSAR=20 > would be consumed by some AAA server in the foreign network, so the = AAAH=20 > would end up with a DSA with some AAAF, rather than with the HA. hmmm... interesting scenario. I believe that the AAAH would send the = HAR,=20 which would be rejected by the HA with the error code you mentioned = above,=20 and then the DSA could be established. I'll admit this isn't the most efficient approach, but it is rather difficult=20 to setup a DSA with an unknown host. PatC ------_=_NextPart_001_01C15536.97380370 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [RE] Re: [AAA-WG]: CMS Security for Mobile-IP Session = Keys

I thought i can use CMS Security only between FA and = AAAF... for strong authentication of registration keys.
But, because of below emails. i think i need change = my thought.
 
Final Question is :
           Regardless of HA's location(home or foreign = domain),
           is it recommended that the CMS security = application be used
           between 'HA' and AAAH as well as between 'FA' and = AAAH?
 
please make things clear!!
 
 

=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Pat = Calhoun[pcalhoun@diameter.org]
=B9=DE=B4=C2=BB=E7=B6=F7: Bob Kopacz
=C2=FC=C1=B6:aaa-wg
=C1=A6=B8=F1: Re: [AAA-WG]: CMS Security for = Mobile-IP Session Keys
=B9=DE=C0=BA=B3=AF=C2=A5: 2001/10/15 =BF=F9 = 08:40


> Q1: Suppose the AAAH receives an AMR from some = FA, and the AAAH wants to
> hide the session keys being returned in the = AMA, but the FA has not
> previously set up a DSA with the AAAH.  = Does the AAAH then reject the AMR
> with a Result-Code of = DIAMETER_NO_DSA_ESTABLISHED?  Or is it the FA that
> dictates whether CMS will be used, i.e. if no = DSA has been set up by the FA,
> then the AAAH can't hide his AMA's session = keys?
It's a policy decision on both ends. If the FA's = policy was to establish a DSA
then it would. If the AAAH will only accept requests = with a DSA in place, then
it would reply with the error code you = mentioned.
> Q2: Suppose a Diameter Mobile-IP AAA Home = server receives an AMR in which
> the AAAF has offered to allocate the HA in the = visited network.  Suppose the
> AAAH wants to accept the offer, and the AAAH = wants to use CMS to hide the
> session keys he will be sending to the foreign = HA via the HAR.  Before
> sending the HAR, the AAAH will want to first = set up a DSA with the HA by
> sending a DSAR.  But the AAAH doesn't yet = know who the HA is.  The best he
> can do is to send the DSAR with the = Destination-Realm set to the AMR's
> Origin-Realm, and with no = Destination-Host.  In this case, it seems the DSAR
> would be consumed by some AAA server in the = foreign network, so the AAAH
> would end up with a DSA with some AAAF, rather = than with the HA.
hmmm... interesting scenario. I believe that the = AAAH would send the HAR,
which would be rejected by the HA with the error = code you mentioned above,
and then the DSA could be established.
I'll admit this isn't the most efficient approach, = but it is rather difficult
to setup a DSA with an unknown host.
PatC

------_=_NextPart_001_01C15536.97380370-- From owner-aaa-wg@merit.edu Mon Oct 15 02:07:36 2001 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 CAA17689 for ; Mon, 15 Oct 2001 02:07:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82FC891213; Mon, 15 Oct 2001 02:07:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52FA391214; Mon, 15 Oct 2001 02:07: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 2010491213 for ; Mon, 15 Oct 2001 02:07:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7B515DDE7; Mon, 15 Oct 2001 02:07:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by segue.merit.edu (Postfix) with ESMTP id 1AF995DD95 for ; Mon, 15 Oct 2001 02:07:11 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA18962; Mon, 15 Oct 2001 08:07:03 +0200 (MET DST) Received: from mchh159e.mch.pn.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA08862; Mon, 15 Oct 2001 08:07:03 +0200 (MET DST) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Oct 2001 08:07:05 +0200 Message-ID: <5B4D0C5BA65ECA46969C1419122317E60957E5@mchh161e> From: Daser Martin ICM N MC MI E4 To: "'Kevin Purser'" , aaa-wg Subject: [AAA-WG]: Where to get Diameter 08 alpha Date: Mon, 15 Oct 2001 08:06:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, people keep mentioning the 08-alpha01 draft for Diameter. I cannot find this version of the draft. Where can I get it? Thanks, Martin Daser From owner-aaa-wg@merit.edu Mon Oct 15 09:36:31 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28136 for ; Mon, 15 Oct 2001 09:36:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EFCD91213; Mon, 15 Oct 2001 09:35:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10F9D9122B; Mon, 15 Oct 2001 09:35:32 -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 86B2591213 for ; Mon, 15 Oct 2001 09:35:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E3F15DDC1; Mon, 15 Oct 2001 09:35:28 -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 C8DCE5DDA7 for ; Mon, 15 Oct 2001 09:35:27 -0400 (EDT) Received: (qmail 24702 invoked by uid 500); 15 Oct 2001 13:50:28 -0000 Date: Mon, 15 Oct 2001 08:50:28 -0500 From: David Frascone To: Daser Martin ICM N MC MI E4 Cc: "'Kevin Purser'" , aaa-wg Subject: Re: [AAA-WG]: Where to get Diameter 08 alpha Message-ID: <20011015085028.K18406@newman.frascone.com> Mail-Followup-To: Daser Martin ICM N MC MI E4 , 'Kevin Purser' , aaa-wg References: <5B4D0C5BA65ECA46969C1419122317E60957E5@mchh161e> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E60957E5@mchh161e>; from Martin.Daser@icn.siemens.de on Mon, Oct 15, 2001 at 08:06:57AM +0200 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk http://www.diameter.org/alpha/ On Mon, Oct 15, 2001 at 08:06:57AM +0200, Daser Martin ICM N MC MI E4 wrote: > Hello, > people keep mentioning the 08-alpha01 draft for Diameter. > I cannot find this version of the draft. Where can I get it? > > Thanks, > Martin Daser > From owner-aaa-wg@merit.edu Mon Oct 15 09:42:20 2001 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 JAA28347 for ; Mon, 15 Oct 2001 09:42:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A345091216; Mon, 15 Oct 2001 09:42:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D2409121A; Mon, 15 Oct 2001 09:42:06 -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 5091891216 for ; Mon, 15 Oct 2001 09:42:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 363495DDC1; Mon, 15 Oct 2001 09:42:05 -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 660FB5DDA7 for ; Mon, 15 Oct 2001 09:42:04 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA03696; Mon, 15 Oct 2001 09:41:40 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id JAA20202; Mon, 15 Oct 2001 09:42:30 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15306.59334.293703.83745@gargle.gargle.HOWL> Date: Mon, 15 Oct 2001 09:42:30 -0400 To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 93: End-to-End Identifier In-Reply-To: <20011015005903.A8407@tp.databus.com> References: <20010710105840.P10676@charizard.diameter.org> <15305.39893.580634.438676@gargle.gargle.HOWL> <20011014163307.B22485@charizard.diameter.org> <20011015005903.A8407@tp.databus.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barney Wolff writes: > Making the identifier start random on reboot is no better and no worse > than making the hi-order 12 bits depend on time and the rest random, as > the reboot interval is itself random. > > Making the id depend on the time of the request depends on ensuring > that time can never go backward or noticing when it does and adjusting > the remaining bits to compensate. Yes, I have seen NTP go backward, > when network paths or queues make forward and reverse one-way delays > significantly different for a while. > > If one is going to require no duplicates within an hour at a > request rate of a million per second then a 32-bit id is just > barely adequate even with perfect state memory across reboots, so any > algorithm that does not assume state memory will necessarily fail. > > The only solution I see is to make the id longer. A 64-bit id started > at a random value on reboot would give a negligible probability of > duplication. > > The point of incrementing by 1 each time is to avoid exhausting the > id space faster than necessary. Obviously it does not have to be > done perfectly, but I cannot imagine an implementation deliberately > choosing a larger increment. > > Barney Wolff > > On Sun, Oct 14, 2001 at 04:33:07PM -0700, Pat Calhoun wrote: > > hmmm... I'm torn. I think that Bob's suggestion solves the problem, but > > Mark's seems to be on a completely different track. What does the WG > > think is best? From owner-aaa-wg@merit.edu Mon Oct 15 10:27:42 2001 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 KAA00317 for ; Mon, 15 Oct 2001 10:27:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 910819120A; Mon, 15 Oct 2001 10:27:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52C8A91217; Mon, 15 Oct 2001 10:27: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 406079120A for ; Mon, 15 Oct 2001 10:27:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 167EA5DDC1; Mon, 15 Oct 2001 10:27:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F2A425DD8C for ; Mon, 15 Oct 2001 10:27:27 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id EDF757A; Mon, 15 Oct 2001 10:27:32 -0400 (EDT) From: "Bob Kopacz" To: "Barney Wolff" , Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier Date: Mon, 15 Oct 2001 10:25:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20011015005903.A8407@tp.databus.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > The point of incrementing by 1 each time is to avoid exhausting the > id space faster than necessary. Obviously it does not have to be > done perfectly, but I cannot imagine an implementation deliberately > choosing a larger increment. I was thinking that the "increment by 1" might cause complications for multi-process Diameter implementations. For example, imagine a Diameter server implemented as three communicating processes: The NASREQ application is one process. The Mobile-IP application is a second process. And there is a third lower-level process which handles the Diameter base protocol and the TCP/SCTP connections. When the NASREQ application or Mobile-IP application originate a message, they pass it to the lower-level process for transmission. If there is an "increment by 1" rule, then the applications would need to access some common "end-to-end-identifier allocator". Or the applications would have to let the lower-level process assign the end-to-end-identifier and return it to the application process. If there wasn't an "increment by 1" rule, than each application could manage its own end-to-end-identifier allocation, as long as it didn't clash with the end-to-end-identifiers allocated by other processes. To ensure a non-clash in this example, the NASREQ application could assign even-numbered end-to-end-identifiers, while the Mobile-IP application could assign odd-numbered end-to-end-identifiers. In this case, then, each application would be incrementing by two rather than one. Bob K. From owner-aaa-wg@merit.edu Mon Oct 15 10:40:01 2001 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 KAA00824 for ; Mon, 15 Oct 2001 10:40:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC5A49121D; Mon, 15 Oct 2001 10:39:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C3E191220; Mon, 15 Oct 2001 10:39: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 7BAF09121D for ; Mon, 15 Oct 2001 10:39:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FD1D5DD8C; Mon, 15 Oct 2001 10:39:35 -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 6B5815DE0F for ; Mon, 15 Oct 2001 10:39:34 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA04946; Mon, 15 Oct 2001 10:39:10 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA20215; Mon, 15 Oct 2001 10:39:59 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15306.62783.586551.803047@gargle.gargle.HOWL> Date: Mon, 15 Oct 2001 10:39:59 -0400 To: Pat Calhoun Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: MIP-FA-to-MN-SPI and co-located servers In-Reply-To: <20011014074954.B21749@charizard.diameter.org> References: <15303.22433.429099.131094@gargle.gargle.HOWL> <20011014074954.B21749@charizard.diameter.org> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let me state my (mis)understanding of this situation. First the non-co-located situation: 1. A MIP-FA-to-MN-Key contains a MIP-Peer-SPI. 2. This MIP-Peer-SPI is normally sent from the HA to the AAAH in the form of a MIP-FA-to-MN-SPI. 3. The HA created the MIP-FA-to-MN-SPI somehow. I'm a little fuzzy on this part. Either it 1. extracted it from the Mobile Node SPI in the Generalized MN-FA Key Request extension or 2. Generated it in some other manner. In the co-located situation, we have three players, the mobile node (MN), the co-located Agent that acts as both the foreign and home agent (agent), and the aaa server that answers the requests (server). If the MN requests a FA-to-MN key, the server will 1. Have to return both a MIP-FA-to-MN-Key and a MIP-MN-to-FA-Key. 2. Have to return something for the MIP-Peer-SPI in the MIP-FA-to-MN-Key 3. If the MIP-Peer-SPI is the same as the Mobile Node SPI in the Generalized MN-FA Key Request extension, it will have to speak Mobile-IP. Even if 3 is not true, I would think that the agent would be responsible for generating the MIP-Peer-SPI. -mark Pat Calhoun writes: > Mark, > > You've lost me here. You state that a co-located server (whatever that > happens to be) doesn't speak mobile ip, and therefore cannot extract the > MIP-FA-to-MN-SPI AVP from the registration request. Why is the Diameter > AVP in the Mobile IP message? > > I suspect that I'm misunderstanding your issue :( > > PatC > On Fri, Oct 12, 2001 at 04:50:41PM -0400, Mark Eklund wrote: > > Submitter name: Mark Eklund > > Submitter email address: meklund@diameter.org > > Date first submitted: 12-Oct-01 > > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html > > Document: mobileip > > Comment type: T > > Priority: 1 > > Section: 6.0 > > Rationale/Explanation of issue: > > > > This is a sub-issue of the issue, "Issue: Required AVPs in grouped > > key AVPs" submitted earlier by me that requests changing to use the > > Key ABNA as listed in the reference above. > > > > The value for the MIP-FA-to-MN-SPI key is contained in the > > registration request sent by the MN (and placed in the > > MIP-Reg-Request by the FA). The HA normally extracts this and sends > > it back to the AAAH as the MIP-FA-to-MN-SPI. The AAAH can then > > place that in the MIP-FA-to-MN-Key and sent back to the FA. > > > > A problem happens with a co-located server. When the AAAF gets an > > AMR and the MN-to-FA key was requested, it sends an AMA back to the > > FA that contains the MIP-FA-to-MN-Key and the MIP-MN-to-FA-Key. The > > problem is that the AAAF doesn't speak mobileip and can't > > extract the MIP-FA-to-MN-SPI from the registration request. > > > > Requested change: > > The currently suggested ABNF for the MIP-FA-to-MN-Key and the > > MIP-MN-to-FA-Key is > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > { MIP-FA-to-MN-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > { MIP-Key-Lifetime } > > * [ AVP ] > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > { MIP-Algorithm-Type } > > { MIP-Key-Material } > > { MIP-Key-Lifetime } > > { AAA-SPI } > > * [ AVP ] > > > > Either make the MIP-FA-to-MN-SPI in the MIP-FA-to-MN-Key optional or > > only require that the MIP-MN-to-FA-Key be sent back when the server > > is co-located and add the MIP-Session-Key as an optional AVP. I.E. > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > { MIP-Algorithm-Type } > > { MIP-Key-Material } > > { MIP-Key-Lifetime } > > { AAA-SPI } > > [ MIP-Session-Key ] > > * [ AVP ] From owner-aaa-wg@merit.edu Mon Oct 15 11:01:23 2001 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 LAA01629 for ; Mon, 15 Oct 2001 11:01:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85BAB9121F; Mon, 15 Oct 2001 11:00:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BC8E91221; Mon, 15 Oct 2001 11:00: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 4965B9121F for ; Mon, 15 Oct 2001 11:00:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CA5A5DDC1; Mon, 15 Oct 2001 11:00:44 -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 58B765DD8C for ; Mon, 15 Oct 2001 11:00:43 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA05391; Mon, 15 Oct 2001 10:59:59 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id LAA20226; Mon, 15 Oct 2001 11:00:50 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15306.64034.655148.524728@gargle.gargle.HOWL> Date: Mon, 15 Oct 2001 11:00:50 -0400 To: Pat Calhoun Cc: Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation In-Reply-To: <20011014074301.A21749@charizard.diameter.org> References: <20011010072334.A26284@charizard.diameter.org> <20011010093432.A27333@charizard.diameter.org> <20011014074301.A21749@charizard.diameter.org> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, This clears up a lot for me, but I have a question. Pat Calhoun writes: > All, > > After having read the draft some more, I do agree with some of Mark's > comments, in that it isn't entirely clear in the draft how some keys are > sent to some entities. So I have reworked section 5.0 into two sections, > and would solicit comments. > > Text below. > > Thanks, > > PatC > ---- > > 5.0 Key Distribution Center > > The mobile node and mobility agents use session keys to compute > authentication extensions applied to registration messages, as > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > session keys are requested the AAA server(s) MUST return the key > material after the Mobile Node is successfully authenticated and > authorized. > > If the AAAH does not communicate directly with the foreign agent, and > it does not wish for intermediate proxies to have access to the > session keys, they SHOULD be protected using the CMS security > application [9]. > > The MIP-Key-Lifetime AVP contains the number of seconds before > session keys destined for the Home Agent and/or Foreign Agent expire. > A value of zero indicates infinity (no timeout). > > The SPI values are used as key identifiers, meaning that each session > key has its own SPI value; nodes that share a key also share an SPI. > The Mobile Node proposes SPIs for use in computing the Mobile-Foreign > and Mobile-Home authentication extensions, via the Mobile IP AAA Key Does this mean that the AAAH needs to speak mobile ip to extract this SPI or will there be a new AVPs sent in the AMR for that? Note that you need to have two different AVPs since the Generalized MN-FA Key Request Extension and the Generalized MN-HA Key Request Extension could contain two different SPIs. -mark > Request extensions [15], while the Home Agent allocates the Mobile- > Foreign, Mobile-Home and Foreign-Home SPIs. > > Once the session keys have been distributed, subsequent Mobile IP > registrations need not invoke the AAA infrastructure until the keys > expire. These registrations MUST include the Mobile-Home > authentication extension. In addition, subsequent registrations MUST > also include Mobile-Foreign authentication extension if the Mobile- > Foreign key was generated and distributed by AAA; similarly for > subsequent use of the Foreign-Home authentication extensions. > > > 5.1 Key Material vs. Session Key > > Each session key that is generated by the AAAH will generally be > distributed to two parties; for instance, a Mobile-Foreign is sent to > both the mobile node and the foreign agent. > > The key sent to the mobile node is always in the form of key > material, which the AAAH does by generating a random [18] value of at > least 64 bits. The random value is used by the mobile node to create > the actual session key. The following is an example of a session > creation procedure, using MD5 as the hashing algorithm. Additional > algorithms are supported, and listed in [15]. > > MD5(AAA-Key | key material | node-address | AAA-Key) > > Where: > > - AAA-Key is the long term secret shared between the mobile > node and the AAAH. > - Key material is a random [18] value of at least 64 bits. > - node-address is the mobile node's identity. This is the > contents of the MIP-Mobile-Node-Address AVP, unless the value > of the AVP is all zero or ones, in which case of value of the > User-Name AVP is used instead. > > The AAAH then generates the session key which is destined for the > mobility agent, in this case the foreign agent, by following the > above procedures. It is important that the hashing algorithm used by > the mobile node is the same as the one used by the AAAH in the > session key generation procedure. Therefore, the AAAH MUST know a > priori the transform used, which is typically contained in the mobile > node's configuration profile. The session keys destined for mobility > agents are encoded using the security association available between > the AAA server and the agents (e.g. IPSec, TLS, CMS). > > See sections 6.0 for details about the format of the AVPs used to > transport the session keys. From owner-aaa-wg@merit.edu Mon Oct 15 11:03:03 2001 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 LAA01722 for ; Mon, 15 Oct 2001 11:03:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECBA09120A; Mon, 15 Oct 2001 11:02:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6AEF91216; Mon, 15 Oct 2001 11:02:44 -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 C5AA19120A for ; Mon, 15 Oct 2001 11:02:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A11185DDC1; Mon, 15 Oct 2001 11:02:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 47DB45DD8C for ; Mon, 15 Oct 2001 11:02:40 -0400 (EDT) Received: (qmail 23812 invoked by uid 500); 15 Oct 2001 14:47:39 -0000 Date: Mon, 15 Oct 2001 07:47:39 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation Message-ID: <20011015074738.A23784@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , Mark Jones , aaa-wg@merit.edu References: <20011010072334.A26284@charizard.diameter.org> <20011010093432.A27333@charizard.diameter.org> <20011014074301.A21749@charizard.diameter.org> <15306.64034.655148.524728@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15306.64034.655148.524728@gargle.gargle.HOWL>; from meklund@cisco.com on Mon, Oct 15, 2001 at 11:00:50AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > This clears up a lot for me, but I have a question. good... progress. > > > > 5.0 Key Distribution Center > > > > The mobile node and mobility agents use session keys to compute > > authentication extensions applied to registration messages, as > > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > > session keys are requested the AAA server(s) MUST return the key > > material after the Mobile Node is successfully authenticated and > > authorized. > > > > If the AAAH does not communicate directly with the foreign agent, and > > it does not wish for intermediate proxies to have access to the > > session keys, they SHOULD be protected using the CMS security > > application [9]. > > > > The MIP-Key-Lifetime AVP contains the number of seconds before > > session keys destined for the Home Agent and/or Foreign Agent expire. > > A value of zero indicates infinity (no timeout). > > > > The SPI values are used as key identifiers, meaning that each session > > key has its own SPI value; nodes that share a key also share an SPI. > > The Mobile Node proposes SPIs for use in computing the Mobile-Foreign > > and Mobile-Home authentication extensions, via the Mobile IP AAA Key > > Does this mean that the AAAH needs to speak mobile ip to extract this > SPI or will there be a new AVPs sent in the AMR for that? Note that > you need to have two different AVPs since the Generalized MN-FA Key > Request Extension and the Generalized MN-HA Key Request Extension > could contain two different SPIs. no, the AAAH MUST NOT need to know how to parse Mobile IP registration messages. PatC From owner-aaa-wg@merit.edu Mon Oct 15 11:18:14 2001 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 LAA02298 for ; Mon, 15 Oct 2001 11:18:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5546691216; Mon, 15 Oct 2001 11:17:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D51A91221; Mon, 15 Oct 2001 11:17: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 E271091216 for ; Mon, 15 Oct 2001 11:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B81735DD8C; Mon, 15 Oct 2001 11:17:55 -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 E56495DDC2 for ; Mon, 15 Oct 2001 11:17:54 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA05731; Mon, 15 Oct 2001 11:17:31 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id LAA20252; Mon, 15 Oct 2001 11:18:22 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15306.65086.85828.967010@gargle.gargle.HOWL> Date: Mon, 15 Oct 2001 11:18:22 -0400 To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 93: End-to-End Identifier In-Reply-To: <20011015005903.A8407@tp.databus.com> References: <20010710105840.P10676@charizard.diameter.org> <15305.39893.580634.438676@gargle.gargle.HOWL> <20011014163307.B22485@charizard.diameter.org> <20011015005903.A8407@tp.databus.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barney, Barney Wolff writes: > Making the identifier start random on reboot is no better and no worse > than making the hi-order 12 bits depend on time and the rest random, as > the reboot interval is itself random. Agreed. > > Making the id depend on the time of the request depends on ensuring > that time can never go backward or noticing when it does and adjusting > the remaining bits to compensate. Yes, I have seen NTP go backward, > when network paths or queues make forward and reverse one-way delays > significantly different for a while. Good point. > > If one is going to require no duplicates within an hour at a > request rate of a million per second then a 32-bit id is just > barely adequate even with perfect state memory across reboots, so any > algorithm that does not assume state memory will necessarily fail. Is this a reasonable requirement? Should we expect that when we are processing a million of packets a second that there will be an one hour network latency? > > The only solution I see is to make the id longer. A 64-bit id started > at a random value on reboot would give a negligible probability of > duplication. > Can we assume that at whatever rate we send requests, the round trip time will never be so long that you will have 2^32 outstanding packets? If this is not true, we MUST use your suggested method. The other solution (if the answer to the above is yes) is to checkpoint the generated identifiers between reboots. If a server is capable of handling millions of packets a second, I would assume it could also checkpoint where it is. For slower servers, a random number should be sufficient. For example, a server that only generates one thousand of packets a second and a network latency of 60 seconds would have a 1/35791 chance of repeating the same numbers when using a random 32 bit initializer. (60 * 1000) / 0xffffffff = 1/35791 -mark > The point of incrementing by 1 each time is to avoid exhausting the > id space faster than necessary. Obviously it does not have to be > done perfectly, but I cannot imagine an implementation deliberately > choosing a larger increment. > > Barney Wolff > > On Sun, Oct 14, 2001 at 04:33:07PM -0700, Pat Calhoun wrote: > > hmmm... I'm torn. I think that Bob's suggestion solves the problem, but > > Mark's seems to be on a completely different track. What does the WG > > think is best? From owner-aaa-wg@merit.edu Mon Oct 15 11:19:37 2001 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 LAA02339 for ; Mon, 15 Oct 2001 11:19:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A49B9120A; Mon, 15 Oct 2001 11:19:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4630991221; Mon, 15 Oct 2001 11:19: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 31BCF9120A for ; Mon, 15 Oct 2001 11:19:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17C2B5DDC2; Mon, 15 Oct 2001 11:19:19 -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 461AC5DD8C for ; Mon, 15 Oct 2001 11:19:18 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA05771; Mon, 15 Oct 2001 11:18:44 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id LAA20255; Mon, 15 Oct 2001 11:19:35 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15306.65158.956904.50885@gargle.gargle.HOWL> Date: Mon, 15 Oct 2001 11:19:34 -0400 To: "Bob Kopacz" Cc: "Barney Wolff" , Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier In-Reply-To: References: <20011015005903.A8407@tp.databus.com> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz writes: > Hi, > > > The point of incrementing by 1 each time is to avoid exhausting the > > id space faster than necessary. Obviously it does not have to be > > done perfectly, but I cannot imagine an implementation deliberately > > choosing a larger increment. > > I was thinking that the "increment by 1" might cause complications > for multi-process Diameter implementations. > > For example, imagine a Diameter server implemented as three > communicating processes: The NASREQ application is one process. The > Mobile-IP application is a second process. And there is a third > lower-level process which handles the Diameter base protocol and the > TCP/SCTP connections. When the NASREQ application or Mobile-IP > application originate a message, they pass it to the lower-level > process for transmission. > > If there is an "increment by 1" rule, then the applications would > need to access some common "end-to-end-identifier allocator". Or > the applications would have to let the lower-level process assign > the end-to-end-identifier and return it to the application process. > > If there wasn't an "increment by 1" rule, than each application > could manage its own end-to-end-identifier allocation, as long as it > didn't clash with the end-to-end-identifiers allocated by other > processes. To ensure a non-clash in this example, the NASREQ > application could assign even-numbered end-to-end-identifiers, while > the Mobile-IP application could assign odd-numbered > end-to-end-identifiers. In this case, then, each application would > be incrementing by two rather than one. > > Bob K. From owner-aaa-wg@merit.edu Mon Oct 15 13:48:18 2001 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 NAA07424 for ; Mon, 15 Oct 2001 13:48:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B209E91224; Mon, 15 Oct 2001 13:47:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79E0F9122B; Mon, 15 Oct 2001 13:47: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 635F791224 for ; Mon, 15 Oct 2001 13:47:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C1705DE10; Mon, 15 Oct 2001 13:47:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 803565DD8C for ; Mon, 15 Oct 2001 13:47:51 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9FHlfH11891 for aaa-wg@merit.edu; Mon, 15 Oct 2001 13:47:41 -0400 (EDT) (envelope-from barney) Date: Mon, 15 Oct 2001 13:47:36 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 93: End-to-End Identifier Message-ID: <20011015134736.A11394@tp.databus.com> References: <20010710105840.P10676@charizard.diameter.org> <15305.39893.580634.438676@gargle.gargle.HOWL> <20011014163307.B22485@charizard.diameter.org> <20011015005903.A8407@tp.databus.com> <15306.65086.85828.967010@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15306.65086.85828.967010@gargle.gargle.HOWL>; from meklund@cisco.com on Mon, Oct 15, 2001 at 11:18:22AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Oct 15, 2001 at 11:18:22AM -0400, Mark Eklund wrote: > > > > If one is going to require no duplicates within an hour at a > > request rate of a million per second then a 32-bit id is just > > barely adequate even with perfect state memory across reboots, so any > > algorithm that does not assume state memory will necessarily fail. > > Is this a reasonable requirement? Should we expect that when we are > processing a million of packets a second that there will be an one > hour network latency? Well, it didn't come from me. :) The catch is that reasonable numbers leave a significant chance of duplication with a 32-bit id, if there is no non-volitile storage. Not significant for a single client, but in a large network over time it would surely happen. > > The only solution I see is to make the id longer. A 64-bit id started > > at a random value on reboot would give a negligible probability of > > duplication. > > > > Can we assume that at whatever rate we send requests, the round trip > time will never be so long that you will have 2^32 outstanding > packets? If this is not true, we MUST use your suggested method. The problem is not RTT, but MSL - how long something can be stuck somewhere in the chain of things between client and server. With random ids, you don't need 2^32 to start to have a risk of a false duplicate. I'm not pushing strongly for a 64-bit id, because I don't think missing a duplicate is such a catastrophic event as to require it. But if people are going to put extreme requirements on Diameter, that's the only solution in the absence of NV storage. (Of course it's the client, not the server, that is likely to be lacking such.) Barney Wolff From owner-aaa-wg@merit.edu Mon Oct 15 16:54:29 2001 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 QAA11468 for ; Mon, 15 Oct 2001 16:54:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29B509122E; Mon, 15 Oct 2001 16:54:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9BF39122F; Mon, 15 Oct 2001 16:54: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 CD2D69122E for ; Mon, 15 Oct 2001 16:54:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 860C05DD8F; Mon, 15 Oct 2001 16:54:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 6E9B75DD9E for ; Mon, 15 Oct 2001 16:54:07 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 2FB0C79; Mon, 15 Oct 2001 16:53:57 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: Handling of Duplicate Requests Date: Mon, 15 Oct 2001 16:51:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, The Diameter base draft mentions a few things about how the AAA home server handles duplicate request messages, but leaves much to the implementer's imagination. Maybe this is by design, but maybe the AAAH's actions should be specified a little more. Here's the kinds of things I've been thinking about: Suppose a home server receives a duplicate request, i.e. a request whose Origin-Host and End-to-End-Identifier match a recent previously-received request. There's a couple cases here: 1. The previously-received request has already been replied to. or 2. The previously-received request hasn't yet been replied to. The server is waiting for something, e.g. the original request is an AMR, the server has sent an HAR to the Home Agent, but hasn't gotten the HAA back yet. And for each of these two cases, there are a couple of cases: a. The duplicate request is really a duplicate. b. The duplicate request is not really a duplicate: -- Even though the Origin-Host and End-to-End-Identifiers match, the "duplicate" differs in some essential way, e.g. the Session-Id or User-Name differs from the previously-received request. -- Or maybe the duplicate differs in some minor but legitimate way. (Maybe the following aren't real-world examples, but here goes...) Example#1: An FA is connected to two AAAFs. The FA sends his AMR to AAAF1, then fails over and resends his request to AAAF2. AAAF1 and AAAF2 twiddle the MIP-Feature-Vector bits differently, and forward the AMR to the AAAH. Example#2: A NAS is connected to two local proxies. The NAS sends his request to AAAP1, then fails over and resends this request to AAAP2. AAAP1 and AAAP2 modify the request message differently because of slightly different policy. Does the following make sense for the AAA Home Server?: Case 1a: is easy, just send back pretty much the same answer. Case 1b: Send negative reply for duplicate, Result-Code=[TBD]. Send an Abort-Session-Request for the original (iff original answer was a SUCCESS). Case 2a: Is the expectation here that when the server can finally respond to the original request, that it responds to the duplicate at the same time? Case 2b: Send a negative reply for both the original request and the duplicate, Result-Code=[TBD]. Bob K. From owner-aaa-wg@merit.edu Mon Oct 15 16:59:24 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11612 for ; Mon, 15 Oct 2001 16:59:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3FAE9122F; Mon, 15 Oct 2001 16:58:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DD2391230; Mon, 15 Oct 2001 16:58: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 5F7A39122F for ; Mon, 15 Oct 2001 16:58:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 463465DD8F; Mon, 15 Oct 2001 16:58:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 2E12A5DD8C for ; Mon, 15 Oct 2001 16:58:45 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 2680679; Mon, 15 Oct 2001 16:58:50 -0400 (EDT) From: "Bob Kopacz" To: "Mark Eklund" Cc: "Pat Calhoun" , "aaa-wg" Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier Date: Mon, 15 Oct 2001 16:56:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <15305.39893.580634.438676@gargle.gargle.HOWL> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, > -----Original Message----- > From: Mark Eklund [mailto:meklund@cisco.com] > Sent: Sunday, October 14, 2001 10:06 AM > To: Bob Kopacz > Cc: Pat Calhoun; aaa-wg > Subject: RE: [AAA-WG]: Issue 93: End-to-End Identifier > > > Bob, > > Bob Kopacz writes: > > Hi Pat, > > > > [... blah blah blah] > > > > Revise the End-to-End Identifier specification as follows: > > > > End-to-End Identifier > > > > The End-to-End Identifier is used to detect duplicate messages. > > Whenever an End-to-End Identifier is generated, the high order > > 12 bits are set to contain the low order 12 bits of current > > time, while the low order 20 bits are set to a value that ensures > > a unique identifier on each message. > > I agree the current implementation doesn't work, but wouldn't your > suggestion limit Diameter to around a million calls per second? I'd > prefer something like This didn't occur to me. So your idea is probably better. > End-to-End Identifier > > The End-to-End Identifier is used to detect duplicate messages. > Upon reboot, the End-to-End Identifier SHOULD be initialized to > a number that would come after the last End-To-End identifier > before reboot. Note that since wraparound is possible, if the > last End-To-End identifier is 0xffffffff, 0 would be a valid > initializer after reboot. If it is not possible to maintain > identifier state between reboots, the identifier SHOULD be > initialized to a random value. > > > -mark > From owner-aaa-wg@merit.edu Mon Oct 15 18:30:07 2001 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 SAA14468 for ; Mon, 15 Oct 2001 18:30:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AF029122F; Mon, 15 Oct 2001 18:29:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CED491237; Mon, 15 Oct 2001 18:29:44 -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 325F69122F for ; Mon, 15 Oct 2001 18:29:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12FA75DD8D; Mon, 15 Oct 2001 18:29:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 8721A5DD8C for ; Mon, 15 Oct 2001 18:29:42 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9FMU8Q29472 for ; Mon, 15 Oct 2001 17:30:08 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Oct 2001 17:29:40 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Oct 2001 17:29:40 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: RE: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt) Date: Mon, 15 Oct 2001 17:29:40 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811378268@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] NAIs for HA and FA (draft-ietf-mobileip-gnaie-05.txt) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcFVvT2Fg/S67sGvEdWBTQBQi2X+DwAC0F8Q From: "Le Franck (NRC/Dallas)" To: Cc: "aaa-wg" X-OriginalArrivalTime: 15 Oct 2001 22:29:40.0250 (UTC) FILETIME=[E12987A0:01C155C8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA14468 There is a discussion on the AAA mailing list "MN migration to new realm / draft-mobileip-08-alpha01": a Mobile node may be moving from Foreign domain 1, where it has been assigned a dynamic HA, to Foreign Domain 2; and the MN wants to keep its HA. The MN's AAAh needs to be informed of the Home agent address to know where to send the HAR. The HA NAI can probably be used in this case . Franck > -----Original Message----- > From: ext Patil Basavaraj (NET/Dallas) > Sent: 15 October, 2001 4:05 PM > To: 'Mobile IP' > Subject: [mobile-ip] NAIs for HA and FA > (draft-ietf-mobileip-gnaie-05.txt) > > > Hello, > > I-D draft-ietf-mobileip-gnaie-05.txt specifies an NAI for the Foreign > Agent and Home Agent. These NAIs are carried in the Reg_Req and > Reg_Resp messages of Mobile IPv4. The draft does not specify the > applicability of these NAIs. What do you believe will be the need and > the use for NAIs asociated with Foreign agents and Home Agents? > Is there a real need for HA/FA NAIs? Comments, opinions... > > -Basavaraj > From owner-aaa-wg@merit.edu Mon Oct 15 18:41:16 2001 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 SAA14717 for ; Mon, 15 Oct 2001 18:41:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DA7291237; Mon, 15 Oct 2001 18:41:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00B839123A; Mon, 15 Oct 2001 18:41: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 EC95891237 for ; Mon, 15 Oct 2001 18:41:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD73B5DD9E; Mon, 15 Oct 2001 18:41:00 -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 0A7805DD8C for ; Mon, 15 Oct 2001 18:41:00 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA15019; Mon, 15 Oct 2001 18:40:33 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id SAA21497; Mon, 15 Oct 2001 18:41:22 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15307.26130.501476.105437@gargle.gargle.HOWL> Date: Mon, 15 Oct 2001 18:41:22 -0400 To: Pat Calhoun Cc: Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > > This clears up a lot for me, but I have a question. > > good... progress. > Thanks, I still either don't quite understand or have drug up a new issue. > > > > > > 5.0 Key Distribution Center > > > > > > The mobile node and mobility agents use session keys to compute > > > authentication extensions applied to registration messages, as > > > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > > > session keys are requested the AAA server(s) MUST return the key > > > material after the Mobile Node is successfully authenticated and > > > authorized. > > > > > > If the AAAH does not communicate directly with the foreign agent, and > > > it does not wish for intermediate proxies to have access to the > > > session keys, they SHOULD be protected using the CMS security > > > application [9]. > > > > > > The MIP-Key-Lifetime AVP contains the number of seconds before > > > session keys destined for the Home Agent and/or Foreign Agent expire. > > > A value of zero indicates infinity (no timeout). > > > > > > The SPI values are used as key identifiers, meaning that each session > > > key has its own SPI value; nodes that share a key also share an SPI. > > > The Mobile Node proposes SPIs for use in computing the Mobile-Foreign > > > and Mobile-Home authentication extensions, via the Mobile IP AAA Key > > > > Does this mean that the AAAH needs to speak mobile ip to extract this > > SPI or will there be a new AVPs sent in the AMR for that? Note that > > you need to have two different AVPs since the Generalized MN-FA Key > > Request Extension and the Generalized MN-HA Key Request Extension > > could contain two different SPIs. > > no, the AAAH MUST NOT need to know how to parse Mobile IP registration messages. O.K. Tell me where I go wrong here. 1. The Mobile Node SPI in the Generalized MN-FA Key Request extension is the suggested SPI from the MN to be used by the AAAH to encrypt the key and send it to the HA. 2. The AAAH doesn't have to use this, but it is preferred. 3. The FA does not extract this SPI and put it in any AVP. 4. The AAAH then must extract this SPI. 5. This is a violation of the "AAAH MUST NOT need to know how to parse the Mobile IP registration messages". -mark > > PatC > From owner-aaa-wg@merit.edu Mon Oct 15 22:40:53 2001 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 WAA19357 for ; Mon, 15 Oct 2001 22:40:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD4B69123C; Mon, 15 Oct 2001 22:40:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B36849123E; Mon, 15 Oct 2001 22:40: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 90B3A9123C for ; Mon, 15 Oct 2001 22:40:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 789785DD9E; Mon, 15 Oct 2001 22:40:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D55DD5DD8D for ; Mon, 15 Oct 2001 22:40:33 -0400 (EDT) Received: (qmail 25059 invoked by uid 500); 16 Oct 2001 02:25:31 -0000 Date: Mon, 15 Oct 2001 19:25:30 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation Message-ID: <20011015192530.A25050@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , Mark Jones , aaa-wg@merit.edu References: <15307.26130.501476.105437@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15307.26130.501476.105437@gargle.gargle.HOWL>; from meklund@cisco.com on Mon, Oct 15, 2001 at 06:41:22PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Oct 15, 2001 at 06:41:22PM -0400, Mark Eklund wrote: > Pat, > > > > This clears up a lot for me, but I have a question. > > > > good... progress. > > > > Thanks, I still either don't quite understand or have drug up a new > issue. > > > > > > > > > 5.0 Key Distribution Center > > > > > > > > The mobile node and mobility agents use session keys to compute > > > > authentication extensions applied to registration messages, as > > > > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > > > > session keys are requested the AAA server(s) MUST return the key > > > > material after the Mobile Node is successfully authenticated and > > > > authorized. > > > > > > > > If the AAAH does not communicate directly with the foreign agent, and > > > > it does not wish for intermediate proxies to have access to the > > > > session keys, they SHOULD be protected using the CMS security > > > > application [9]. > > > > > > > > The MIP-Key-Lifetime AVP contains the number of seconds before > > > > session keys destined for the Home Agent and/or Foreign Agent expire. > > > > A value of zero indicates infinity (no timeout). > > > > > > > > The SPI values are used as key identifiers, meaning that each session > > > > key has its own SPI value; nodes that share a key also share an SPI. > > > > The Mobile Node proposes SPIs for use in computing the Mobile-Foreign > > > > and Mobile-Home authentication extensions, via the Mobile IP AAA Key > > > > > > Does this mean that the AAAH needs to speak mobile ip to extract this > > > SPI or will there be a new AVPs sent in the AMR for that? Note that > > > you need to have two different AVPs since the Generalized MN-FA Key > > > Request Extension and the Generalized MN-HA Key Request Extension > > > could contain two different SPIs. > > > > no, the AAAH MUST NOT need to know how to parse Mobile IP registration messages. > > O.K. Tell me where I go wrong here. > > 1. The Mobile Node SPI in the Generalized MN-FA Key Request extension > is the suggested SPI from the MN to be used by the AAAH to encrypt > the key and send it to the HA. > > 2. The AAAH doesn't have to use this, but it is preferred. > > 3. The FA does not extract this SPI and put it in any AVP. > > 4. The AAAH then must extract this SPI. > > 5. This is a violation of the "AAAH MUST NOT need to know how to parse > the Mobile IP registration messages". The only SPI AAAH needs is the MN-AAA SPI, and this can be found in the MIP-MN-AAA-SPI AVP. Not sure why you state that the AAAH needs the MN-FA SPI. PatC From owner-aaa-wg@merit.edu Tue Oct 16 11:33:59 2001 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 LAA03087 for ; Tue, 16 Oct 2001 11:33:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 242AC91267; Tue, 16 Oct 2001 11:33:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7DC491268; Tue, 16 Oct 2001 11:33:41 -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 BF83991267 for ; Tue, 16 Oct 2001 11:33:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 95D2E5DDBA; Tue, 16 Oct 2001 11:33:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 108815DDA8 for ; Tue, 16 Oct 2001 11:33:40 -0400 (EDT) Received: (qmail 27434 invoked by uid 500); 16 Oct 2001 15:18:35 -0000 Date: Tue, 16 Oct 2001 08:18:35 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 195: Clarifications on key generation (mobileip-08) Message-ID: <20011016081835.A27419@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I've just talked to Mark, and finally understand his concern. Basically, when a key is shared between two mobility agents (meaning the mobile node is not involved), there is no key creation because there is no long term MN shared secret involved. Therefore, the keying material, which is random, is used as the session key. So, I'd like to propose the following language to be added at the end of section 5.1: " For keys to be shared between two mobility agents (e.g. foreign and home agents), the aaah would generate the key material. Since the key is not destined for the mobile node, there is no need to follow the session key generation procedures detailed above. Therefore, the keying material (random value) is considered the session key." Thoughts? PatC From owner-aaa-wg@merit.edu Tue Oct 16 12:52:16 2001 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 MAA10245 for ; Tue, 16 Oct 2001 12:52:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45BDE91243; Tue, 16 Oct 2001 12:51:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BA0291269; Tue, 16 Oct 2001 12:51:50 -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 D4CE591243 for ; Tue, 16 Oct 2001 12:51:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 92F1F5DDBA; Tue, 16 Oct 2001 12:51:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 3318C5DDA8 for ; Tue, 16 Oct 2001 12:51:48 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9GGpl007317; Tue, 16 Oct 2001 11:51:47 -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 f9GGpls28502; Tue, 16 Oct 2001 11:51:47 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA14273; Tue, 16 Oct 2001 11:51:46 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id LAA16090; Tue, 16 Oct 2001 11:51:43 -0500 (CDT) Message-ID: <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Pat Calhoun" , References: <20011014080550.D21749@charizard.diameter.org> Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Date: Tue, 16 Oct 2001 09:51:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hey Pat, Just a nit, but since the URI will also identify access devices, we should probably add "IPSec" to the option list. -Kev ----- Original Message ----- From: "Pat Calhoun" To: Sent: Sunday, October 14, 2001 8:05 AM Subject: [AAA-WG]: Issue 191: How to know when to use TLS > Following the recommendation to add this to the URI, here is the > proposed text. I do, however, have some objections to the proposal > that was made in the issue submission. Basically, the issue proposed > two new URI fields, where TLS could be independently set for either > transport protocols (e.g. TCP, SCTP). This would allow for a secure > communication over one medium, and unsecure over the other. Of course, > a malicious node would use the unsecure one. > > So, here is my proposed addition to the URI: > > security = ( "none" | "TLS" ) > ; Specifies whether TLS is to be used > ; when communicating with the peer. The > ; default value is none. > > PatC > From owner-aaa-wg@merit.edu Tue Oct 16 13:46:40 2001 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 NAA12393 for ; Tue, 16 Oct 2001 13:46:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E0B49126B; Tue, 16 Oct 2001 13:46:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 516819126E; Tue, 16 Oct 2001 13:46:10 -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 DA39D9126B for ; Tue, 16 Oct 2001 13:46:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0BE35DDBD; Tue, 16 Oct 2001 13:46:08 -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 D7C9B5DDA2 for ; Tue, 16 Oct 2001 13:46:07 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA05637; Tue, 16 Oct 2001 13:45:40 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id NAA24017; Tue, 16 Oct 2001 13:46:31 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15308.29303.76083.931957@gargle.gargle.HOWL> Date: Tue, 16 Oct 2001 13:46:31 -0400 To: Pat Calhoun Cc: Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation In-Reply-To: <20011015192530.A25050@charizard.diameter.org> References: <15307.26130.501476.105437@gargle.gargle.HOWL> <20011015192530.A25050@charizard.diameter.org> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I think the gist of my confusion is how the AAAH chooses the AAA-SPI for encryption and how the HA chooses the FA SPI and the HA SPI. I didn't find any guidance in draft-ietf-mobileip-aaa-key-08.txt or draft-ietf-aaa-diameter-mobileip-08-alpha01.txt, but did find some in your proposed text where you said, "The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home authentication extensions, via the Mobile IP AAA Key Request extensions [15], while the Home Agent allocates the Mobile- Foreign, Mobile-Home and Foreign-Home SPIs. If following statements are correct, I am no longer confused (at not least about this part :). 1. The AAAH MAY use the value of the MIP-MN-AAA-SPI when generating the MIP-Session-Key in the MIP-HA-to-MN-Key and generating the MIP-Session-Key in the MIP-FA-to-MN-Key, or it MAY generate one according to local policy. 2. As of 8-alpha01 there is no way of conveying the above AAA SPI to the HA. To fix this problem, the issue was proposed in http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00136.html to add an AAA-SPI to the MIP-MN-to-FA-Key and the MIP-MN-to-HA-Key. 3. The HA MAY use the Mobile Node SPI from the MN-FA-Key Request extension in the MIP-Reg-Request as the FA SPI, or it MA generate one according to local policy. 4. The HA MAY use the Mobile Node SPI from the MN-HA-Key Request extension in the MIP-Reg-Request as the HA SPI, or it MAY generate one according to local policy. -mark Pat Calhoun writes: > On Mon, Oct 15, 2001 at 06:41:22PM -0400, Mark Eklund wrote: > > Pat, > > > > > > This clears up a lot for me, but I have a question. > > > > > > good... progress. > > > > > > > Thanks, I still either don't quite understand or have drug up a new > > issue. > > > > > > > > > > > > 5.0 Key Distribution Center > > > > > > > > > > The mobile node and mobility agents use session keys to compute > > > > > authentication extensions applied to registration messages, as > > > > > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > > > > > session keys are requested the AAA server(s) MUST return the key > > > > > material after the Mobile Node is successfully authenticated and > > > > > authorized. > > > > > > > > > > If the AAAH does not communicate directly with the foreign agent, and > > > > > it does not wish for intermediate proxies to have access to the > > > > > session keys, they SHOULD be protected using the CMS security > > > > > application [9]. > > > > > > > > > > The MIP-Key-Lifetime AVP contains the number of seconds before > > > > > session keys destined for the Home Agent and/or Foreign Agent expire. > > > > > A value of zero indicates infinity (no timeout). > > > > > > > > > > The SPI values are used as key identifiers, meaning that each session > > > > > key has its own SPI value; nodes that share a key also share an SPI. > > > > > The Mobile Node proposes SPIs for use in computing the Mobile-Foreign > > > > > and Mobile-Home authentication extensions, via the Mobile IP AAA Key > > > > > > > > Does this mean that the AAAH needs to speak mobile ip to extract this > > > > SPI or will there be a new AVPs sent in the AMR for that? Note that > > > > you need to have two different AVPs since the Generalized MN-FA Key > > > > Request Extension and the Generalized MN-HA Key Request Extension > > > > could contain two different SPIs. > > > > > > no, the AAAH MUST NOT need to know how to parse Mobile IP registration messages. > > > > O.K. Tell me where I go wrong here. > > > > 1. The Mobile Node SPI in the Generalized MN-FA Key Request extension > > is the suggested SPI from the MN to be used by the AAAH to encrypt > > the key and send it to the HA. > > > > 2. The AAAH doesn't have to use this, but it is preferred. > > > > 3. The FA does not extract this SPI and put it in any AVP. > > > > 4. The AAAH then must extract this SPI. > > > > 5. This is a violation of the "AAAH MUST NOT need to know how to parse > > the Mobile IP registration messages". > > The only SPI AAAH needs is the MN-AAA SPI, and this can be found in the > MIP-MN-AAA-SPI AVP. > > Not sure why you state that the AAAH needs the MN-FA SPI. > > PatC From owner-aaa-wg@merit.edu Tue Oct 16 13:48:18 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12449 for ; Tue, 16 Oct 2001 13:48:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6FE29126C; Tue, 16 Oct 2001 13:47:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AE819126D; Tue, 16 Oct 2001 13:47: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 8078C9126C for ; Tue, 16 Oct 2001 13:47:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6310A5DDA8; Tue, 16 Oct 2001 13:47:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id E8A3D5DDA2 for ; Tue, 16 Oct 2001 13:47:43 -0400 (EDT) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id NAA10841; Tue, 16 Oct 2001 13:41:27 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA16929; Tue, 16 Oct 2001 13:49:09 -0400 (EDT) From: "Mark Jones" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 195: Clarifications on key generation (mobileip-08) Date: Tue, 16 Oct 2001 13:49:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20011016081835.A27419@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I'd prefer we stay clear of even mentioning key material in this context (especially since the result is put in a MIP-Session-Key AVP). " The Foreign-Home session key is shared between two mobility agents: the FA and HA. Since this key is not destined for the mobile node, there is no need to follow the session key generation procedures detailed above. Instead, the AAAH generates a random [18] value of at least 64 bits for use as the Foreign-Home session key." Comments? Regards, Mark > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Pat Calhoun > Sent: October 16, 2001 11:19 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 195: Clarifications on key generation > (mobileip-08) > > > All, > > I've just talked to Mark, and finally understand his concern. > Basically, when a > key is shared between two mobility agents (meaning the mobile > node is not involved), > there is no key creation because there is no long term MN shared > secret involved. > Therefore, the keying material, which is random, is used as the > session key. > > So, I'd like to propose the following language to be added at the > end of section > 5.1: > > " For keys to be shared between two mobility agents (e.g. > foreign and home > agents), the aaah would generate the key material. Since the key is not > destined for the mobile node, there is no need to follow the > session key > generation procedures detailed above. Therefore, the keying > material (random > value) is considered the session key." > > Thoughts? > > PatC > From owner-aaa-wg@merit.edu Tue Oct 16 14:23:07 2001 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 OAA14031 for ; Tue, 16 Oct 2001 14:23:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EF2B9126D; Tue, 16 Oct 2001 14:22:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E7889126E; Tue, 16 Oct 2001 14: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 15AB29126D for ; Tue, 16 Oct 2001 14:22:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE3E55DDBE; Tue, 16 Oct 2001 14:22:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 679F15DDBD for ; Tue, 16 Oct 2001 14:22:53 -0400 (EDT) Received: (qmail 28418 invoked by uid 500); 16 Oct 2001 18:07:48 -0000 Date: Tue, 16 Oct 2001 11:07:48 -0700 From: Pat Calhoun To: Kevin Purser Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011016110748.A28410@charizard.diameter.org> Mail-Followup-To: Kevin Purser , Pat Calhoun , aaa-wg@merit.edu References: <20011014080550.D21749@charizard.diameter.org> <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Tue, Oct 16, 2001 at 09:51:38AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Just a nit, but since the URI will also identify access devices, we should > probably add "IPSec" to the option list. But this implies that there is an interface to the local policy manager from the Diameter process, which I doubt exists. So, how would the Diameter react if IPSec was on or off? I think that IPSec is a different beast. PatC From owner-aaa-wg@merit.edu Tue Oct 16 14:24:04 2001 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 OAA14067 for ; Tue, 16 Oct 2001 14:24:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C90C9126E; Tue, 16 Oct 2001 14:23:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA7959126F; Tue, 16 Oct 2001 14:23: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 B21089126E for ; Tue, 16 Oct 2001 14:23:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9835C5DDBE; Tue, 16 Oct 2001 14:23:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3D6A55DDBD for ; Tue, 16 Oct 2001 14:23:51 -0400 (EDT) Received: (qmail 28434 invoked by uid 500); 16 Oct 2001 18:08:46 -0000 Date: Tue, 16 Oct 2001 11:08:46 -0700 From: Pat Calhoun To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 195: Clarifications on key generation (mobileip-08) Message-ID: <20011016110846.B28410@charizard.diameter.org> Mail-Followup-To: Mark Jones , Pat Calhoun , aaa-wg@merit.edu References: <20011016081835.A27419@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjones@bridgewatersystems.com on Tue, Oct 16, 2001 at 01:49:03PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk works for me. PatC On Tue, Oct 16, 2001 at 01:49:03PM -0400, Mark Jones wrote: > Pat, > > I'd prefer we stay clear of even mentioning key material in this context > (especially since the result is put in a MIP-Session-Key AVP). > > " The Foreign-Home session key is shared between two mobility agents: > the FA and HA. Since this key is not destined for the mobile node, > there is no need to follow the session key generation procedures > detailed above. Instead, the AAAH generates a random [18] value of > at least 64 bits for use as the Foreign-Home session key." > > Comments? > > Regards, > Mark > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Pat Calhoun > > Sent: October 16, 2001 11:19 AM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Issue 195: Clarifications on key generation > > (mobileip-08) > > > > > > All, > > > > I've just talked to Mark, and finally understand his concern. > > Basically, when a > > key is shared between two mobility agents (meaning the mobile > > node is not involved), > > there is no key creation because there is no long term MN shared > > secret involved. > > Therefore, the keying material, which is random, is used as the > > session key. > > > > So, I'd like to propose the following language to be added at the > > end of section > > 5.1: > > > > " For keys to be shared between two mobility agents (e.g. > > foreign and home > > agents), the aaah would generate the key material. Since the key is not > > destined for the mobile node, there is no need to follow the > > session key > > generation procedures detailed above. Therefore, the keying > > material (random > > value) is considered the session key." > > > > > > > > > Thoughts? > > > > PatC > > > From owner-aaa-wg@merit.edu Tue Oct 16 14:49:28 2001 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 OAA15123 for ; Tue, 16 Oct 2001 14:49:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3725591235; Tue, 16 Oct 2001 14:49:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F127991271; Tue, 16 Oct 2001 14:49: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 C652591235 for ; Tue, 16 Oct 2001 14:49:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A20385DDBE; Tue, 16 Oct 2001 14:49:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id B04065DDBD for ; Tue, 16 Oct 2001 14:49:09 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9GIn9028246; Tue, 16 Oct 2001 13:49:09 -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 f9GIn8G22584; Tue, 16 Oct 2001 13:49:09 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA21451; Tue, 16 Oct 2001 13:49:08 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id NAA18389; Tue, 16 Oct 2001 13:49:04 -0500 (CDT) Message-ID: <006101c15673$3c3923d0$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Pat Calhoun" , References: <20011014080550.D21749@charizard.diameter.org> <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> <20011016110748.A28410@charizard.diameter.org> Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Date: Tue, 16 Oct 2001 11:49:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Just a nit, but since the URI will also identify access devices, we should > > probably add "IPSec" to the option list. > > But this implies that there is an interface to the local policy manager from the > Diameter process, which I doubt exists. So, how would the Diameter react if IPSec > was on or off? I think that IPSec is a different beast. > I see your point... I was just thinking in terms of being explicit in describing the connection properties in the URI. In other words, it just seems a little counterintuitive to me when a diameter server is communicating with an access device through IPSec, and the corresponding URI for the access device says "security = none". -Kev From owner-aaa-wg@merit.edu Tue Oct 16 15:04:18 2001 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 PAA15849 for ; Tue, 16 Oct 2001 15:04:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F29791271; Tue, 16 Oct 2001 15:04:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0307A91272; Tue, 16 Oct 2001 15:04:02 -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 DED0491271 for ; Tue, 16 Oct 2001 15:04:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB4C35DDBD; Tue, 16 Oct 2001 15:04:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1B0A25DDBE for ; Tue, 16 Oct 2001 15:04:01 -0400 (EDT) Received: (qmail 29187 invoked by uid 500); 16 Oct 2001 18:48:56 -0000 Date: Tue, 16 Oct 2001 11:48:55 -0700 From: Pat Calhoun To: Kevin Purser Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011016114855.A29165@charizard.diameter.org> Mail-Followup-To: Kevin Purser , Pat Calhoun , aaa-wg@merit.edu References: <20011014080550.D21749@charizard.diameter.org> <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> <20011016110748.A28410@charizard.diameter.org> <006101c15673$3c3923d0$869f558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <006101c15673$3c3923d0$869f558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Tue, Oct 16, 2001 at 11:49:03AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 16, 2001 at 11:49:03AM -0700, Kevin Purser wrote: > > > Just a nit, but since the URI will also identify access devices, we > should > > > probably add "IPSec" to the option list. > > > > But this implies that there is an interface to the local policy manager > from the > > Diameter process, which I doubt exists. So, how would the Diameter react > if IPSec > > was on or off? I think that IPSec is a different beast. > > > > I see your point... I was just thinking in terms of being explicit in > describing the connection properties in the URI. In other words, it just > seems a little counterintuitive to me when a diameter server is > communicating with an access device through IPSec, and the corresponding URI > for the access device says "security = none". right I hear you, but having "security = ipsec" does nothing to the implementation. Further, as far as Diameter is concerned, when IPSec is used, there is NO app level security. In fact, Diameter has no way of knowing whether there is a local policy to protect Diameter traffic. PatC From owner-aaa-wg@merit.edu Tue Oct 16 15:12:55 2001 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 PAA16264 for ; Tue, 16 Oct 2001 15:12:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE33D91275; Tue, 16 Oct 2001 15:12:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5EAD91273; Tue, 16 Oct 2001 15:12:40 -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 C5F2291278 for ; Tue, 16 Oct 2001 15:12:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABC0C5DDBE; Tue, 16 Oct 2001 15:12:36 -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 D4B925DDBD for ; Tue, 16 Oct 2001 15:12:35 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07304; Tue, 16 Oct 2001 15:11:27 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id PAA24771; Tue, 16 Oct 2001 15:12:19 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15308.34451.377162.39099@gargle.gargle.HOWL> Date: Tue, 16 Oct 2001 15:12:19 -0400 To: Mark Eklund Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: MIP-FA-to-MN-SPI and co-located servers In-Reply-To: <15306.62783.586551.803047@gargle.gargle.HOWL> References: <15303.22433.429099.131094@gargle.gargle.HOWL> <20011014074954.B21749@charizard.diameter.org> <15306.62783.586551.803047@gargle.gargle.HOWL> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, Please reject this issue, I now understand from this excerpt section 3.0 that when there is a co-located situation, the only key needed is the MN-HA key. The MIP-MN-to-HA-Key and MIP-HA-to-MN-Key AVPs MUST be present if the session keys were requested in the AMR, and the Co-Located-Mobile-Node bit was set in the MIP-Feature-Vector AVP. -mark Mark Eklund writes: > Let me state my (mis)understanding of this situation. First the > non-co-located situation: > > 1. A MIP-FA-to-MN-Key contains a MIP-Peer-SPI. > > 2. This MIP-Peer-SPI is normally sent from the HA to the AAAH in the > form of a MIP-FA-to-MN-SPI. > > 3. The HA created the MIP-FA-to-MN-SPI somehow. I'm a little fuzzy on > this part. Either it > 1. extracted it from the Mobile Node SPI in the Generalized MN-FA > Key Request extension or > 2. Generated it in some other manner. > > In the co-located situation, we have three players, the mobile node > (MN), the co-located Agent that acts as both the foreign and home > agent (agent), and the aaa server that answers the requests (server). > If the MN requests a FA-to-MN key, the server will > > 1. Have to return both a MIP-FA-to-MN-Key and a MIP-MN-to-FA-Key. > > 2. Have to return something for the MIP-Peer-SPI in the MIP-FA-to-MN-Key > > 3. If the MIP-Peer-SPI is the same as the Mobile Node SPI in the > Generalized MN-FA Key Request extension, it will have to speak > Mobile-IP. > > Even if 3 is not true, I would think that the agent would be > responsible for generating the MIP-Peer-SPI. > > -mark > > Pat Calhoun writes: > > Mark, > > > > You've lost me here. You state that a co-located server (whatever that > > happens to be) doesn't speak mobile ip, and therefore cannot extract the > > MIP-FA-to-MN-SPI AVP from the registration request. Why is the Diameter > > AVP in the Mobile IP message? > > > > I suspect that I'm misunderstanding your issue :( > > > > PatC > > On Fri, Oct 12, 2001 at 04:50:41PM -0400, Mark Eklund wrote: > > > Submitter name: Mark Eklund > > > Submitter email address: meklund@diameter.org > > > Date first submitted: 12-Oct-01 > > > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html > > > Document: mobileip > > > Comment type: T > > > Priority: 1 > > > Section: 6.0 > > > Rationale/Explanation of issue: > > > > > > This is a sub-issue of the issue, "Issue: Required AVPs in grouped > > > key AVPs" submitted earlier by me that requests changing to use the > > > Key ABNA as listed in the reference above. > > > > > > The value for the MIP-FA-to-MN-SPI key is contained in the > > > registration request sent by the MN (and placed in the > > > MIP-Reg-Request by the FA). The HA normally extracts this and sends > > > it back to the AAAH as the MIP-FA-to-MN-SPI. The AAAH can then > > > place that in the MIP-FA-to-MN-Key and sent back to the FA. > > > > > > A problem happens with a co-located server. When the AAAF gets an > > > AMR and the MN-to-FA key was requested, it sends an AMA back to the > > > FA that contains the MIP-FA-to-MN-Key and the MIP-MN-to-FA-Key. The > > > problem is that the AAAF doesn't speak mobileip and can't > > > extract the MIP-FA-to-MN-SPI from the registration request. > > > > > > Requested change: > > > The currently suggested ABNF for the MIP-FA-to-MN-Key and the > > > MIP-MN-to-FA-Key is > > > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > { MIP-FA-to-MN-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > { MIP-Key-Lifetime } > > > * [ AVP ] > > > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > > { MIP-Algorithm-Type } > > > { MIP-Key-Material } > > > { MIP-Key-Lifetime } > > > { AAA-SPI } > > > * [ AVP ] > > > > > > Either make the MIP-FA-to-MN-SPI in the MIP-FA-to-MN-Key optional or > > > only require that the MIP-MN-to-FA-Key be sent back when the server > > > is co-located and add the MIP-Session-Key as an optional AVP. I.E. > > > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > > { MIP-Algorithm-Type } > > > { MIP-Key-Material } > > > { MIP-Key-Lifetime } > > > { AAA-SPI } > > > [ MIP-Session-Key ] > > > * [ AVP ] From owner-aaa-wg@merit.edu Tue Oct 16 16:43:57 2001 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 QAA20293 for ; Tue, 16 Oct 2001 16:43:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0A4691238; Tue, 16 Oct 2001 16:43:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A83991274; Tue, 16 Oct 2001 16:43:44 -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 4595F91238 for ; Tue, 16 Oct 2001 16:43:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E0A75DDBE; Tue, 16 Oct 2001 16:43:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id AB5EE5DDBC for ; Tue, 16 Oct 2001 16:43:42 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9GKhg026104; Tue, 16 Oct 2001 15:43:42 -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 f9GKhf108151; Tue, 16 Oct 2001 15:43:41 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA01544; Tue, 16 Oct 2001 15:43:40 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id PAA20519; Tue, 16 Oct 2001 15:43:36 -0500 (CDT) Message-ID: <009101c15683$3c4e1820$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Pat Calhoun" , References: <20011014080550.D21749@charizard.diameter.org> <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> <20011016110748.A28410@charizard.diameter.org> <006101c15673$3c3923d0$869f558a@ew.us.am.ericsson.se> <20011016114855.A29165@charizard.diameter.org> Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Date: Tue, 16 Oct 2001 13:43:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > On Tue, Oct 16, 2001 at 11:49:03AM -0700, Kevin Purser wrote: > > > > Just a nit, but since the URI will also identify access devices, we > > should > > > > probably add "IPSec" to the option list. > > > > > > But this implies that there is an interface to the local policy manager > > from the > > > Diameter process, which I doubt exists. So, how would the Diameter react > > if IPSec > > > was on or off? I think that IPSec is a different beast. > > > > > > > I see your point... I was just thinking in terms of being explicit in > > describing the connection properties in the URI. In other words, it just > > seems a little counterintuitive to me when a diameter server is > > communicating with an access device through IPSec, and the corresponding URI > > for the access device says "security = none". > > right I hear you, but having "security = ipsec" does nothing to the implementation. > Further, as far as Diameter is concerned, when IPSec is used, there is NO app > level security. In fact, Diameter has no way of knowing whether there is a local > policy to protect Diameter traffic. > After re-reading the original issue, my comment becomes more of an editorial one- why not use something like: tls = ( "no" | "yes" ) ; Specifies whether TLS is to be used ; when communicating with the peer. The ; default value is no. which is really what the original issue was trying to accomplish, right? Or better yet, to leave future transport layer mechanisms available: transport-security = ( "none" | "TLS" | ...) ; Specifies whether TLS [or other eventual transport layer mechanisms] is to be used ; when communicating with the peer. The ; default value is none. Simply put, if this option in the URI is only intended to describe transport layer mechanisms, why not make that obvious in the URI option name, rather than using a term as broad as "security". -Kev From owner-aaa-wg@merit.edu Tue Oct 16 17:49:58 2001 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 RAA21439 for ; Tue, 16 Oct 2001 17:49:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4F5491230; Tue, 16 Oct 2001 17:49:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74EBC91240; Tue, 16 Oct 2001 17:49: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 F32A991230 for ; Tue, 16 Oct 2001 17:49:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D33195DDBD; Tue, 16 Oct 2001 17:49:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BE6F05DDBC for ; Tue, 16 Oct 2001 17:49:45 -0400 (EDT) Received: from interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5D56E7E for ; Tue, 16 Oct 2001 17:49:45 -0400 (EDT) Message-ID: <3BCCABB5.98812917@interlinknetworks.com> Date: Tue, 16 Oct 2001 17:50:45 -0400 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: End-to-End Security Proposal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Help! I'm finding it difficult to use my S/MIME toolkit to implement the proposed CMS Security Application. I think the CMS Security Application provides more sophistication and complexity than is necessary. Am I alone here? Part of it may simply be that I am a newcomer to CMS and S/MIME and part of it may be that my S/MIME toolkit does not implement the latest CMS standard. Could we consider an End-to-End security scheme that does not require CMS? I think it may be possible to achieve the desired security goals without using CMS or S/MIME and to simplify Diameter End-to-End security at the same time. I propose changing the Diameter End-to-End security scheme as follows: - Eliminate the Local-CA-info and CA-Chain AVPs. Certificate Authority databases must be maintained at Diameter nodes. (A Certificate Authority database must already be maintained by Diameter Servers to support TLS, and the database must now also include all CAs required for End-to-End security.) - Replace AAA-Server-Certs and CMS-Cert AVPs with the Origin-Certificate AVP. The Origin-Certificate subjectAltName field contains a dNSName that is set to either the FQDN or the realm of a Diameter host. Setting the dNSName to a realm name allows a set of Diameter Servers to use the same certificate. - Eliminate OCSP-Request-Flags, OCSP-Nonce, and OCSP-Responses AVPs. It is up to the diameter peers to validate certificates during the establishment of the security association as is done during a TLS handshake. Endpoints share each other's certificates and may terminate security associations if notified outside of the Diameter protocol that a certificate has been revoked. - Eliminate DSA-TTL AVP. The proposed scheme requires endpoints to exchange certificates. The certificate expiration time may be used to determine when a DSA must expire. - Eliminate Expected-Signed-AVP and Expected-Encrypted-AVP AVPs. The proposed scheme requires that Diameter protocol specifications must indicate which AVPs must be signed and encrypted when a DSA has been established. The proposal also allows optional AVPs to be signed and/or encrypted if desired. - Replace CMS-Encrypted-Data AVP with Encrypted-Data AVP - Replace CMS-Signed-Data AVP with Signed-Data AVP. This proposal requires that each Diameter host participating in a security association have a certificate and an associated private key. A certificate and private key may be installed on and used by a particular host, or it may be installed on and used by all Diameter Servers in a realm. Proposed Diameter-Security-Association-Request Message Format :: < Diameter-Header: 304, REQ, PXY > { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } { Origin-Certificate } [ Destination-Host ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] Proposed Diameter-Security-Association-Answer Message Format :: < Diameter-Header: 304, PXY > { Result-Code } { Origin-Host } { Auth-Application-Id } { Origin-Realm } { Destination-Realm } [ Origin-Certificate ] [ Destination-Host ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] Definitions of New AVPs ----------------------- Origin-Certificate AVP Origin-Certificate AVP is of type OctetString, and contains the certificate for the origin realm or origin host. The certificate is encoded using DER. The certificate subjectAltName field contains a dNSName that is set to either the FQDN or the realm of the origin host. Setting the dNSName to a realm name allows a set of Diameter Servers to use the same certificate. Encrypted-Data AVP Encrypted-Data AVP is of type Group. It has the following message format: Encrypted-Data ::= < AVP Header: ??? > { Destination Realm } { ED-Origin-Session-Key-Number } { ED-Origin-Session-Key } { Encrypted-Data-Value } [ Destination Host ] The ED-Origin-Session-Key-Number is of type Unsigned32. It identifies the origin session key that is used to encrypt data for the Encrypted-Data-Value AVP. The same origin session key may be used for a number of messages. Each time a new origin session key is created the origin session key number is incremented. A receiving host can decrypt the ED-Origin-Session-Key using the receiving hosts private key; this asymmetric decryption is slow and to be avoided when possible. A receiving host can remember the decrypted origin session key and the ED-Origin-Session-Key-Number so that if another Encrypted-Data AVP is later received with the same ED-Origin-Session-Key-Number the ED-Origin-Session-Key does not have to be decrypted again. It is helpful to always include the ED-Origin-Session-Key-Number and ED-Origin-Session-Key because it allows the Encrypted-Data-Value AVP to be decrypted by any Diameter Server in a realm that has the required private key. It also allows for a new origin session key to be generated by the origin host whenever it deems it appropriate to do so. The ED-Origin-Session-Key is of type OctetString and contains a session key randomly generated by the message originator. The session key is encrypted using the public key of the Destination so that only the Destination can decrypt it. The origin session key is used to encrypt data for the Encrypted-Data-Value AVP. The Encrypted-Data-Value AVP is formed by concatenating all AVPs in a message that require encryption and encrypting them with 3DES using the origin session key. (The origin session key is used to decrypt this AVP.) Signed-Data AVP Signed-Data AVP is of type Group. It has the following message format: Signed-Data ::= < AVP Header: ??? > 1* { AVP } { Signature } [ Origin-Host ] Any AVP requiring a signature must be included in this group; if any encrypted AVP must be signed, the Encrypted-Data AVP must be put into this group. The Signature AVP contains an RSA digital signature for the list of AVPs requiring a signature. Countersigning is not supported. If a proxy wishes to add a signature to AVP data, it must create a new Signed-Data AVP that includes the AVPs requiring its signature. I'm very interested in hearing if any others would like to see similar changes. Thanks for taking the time to read this. With kind regards, Don Zick Interlink Networks, Inc. From owner-aaa-wg@merit.edu Tue Oct 16 23:19:35 2001 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 XAA26880 for ; Tue, 16 Oct 2001 23:19:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B512991227; Tue, 16 Oct 2001 23:19:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8511A91230; Tue, 16 Oct 2001 23:19: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 728E391227 for ; Tue, 16 Oct 2001 23:19:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D58A5DD98; Tue, 16 Oct 2001 23:19:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 033215DD94 for ; Tue, 16 Oct 2001 23:19:13 -0400 (EDT) Received: (qmail 30065 invoked by uid 500); 17 Oct 2001 03:04:07 -0000 Date: Tue, 16 Oct 2001 20:04:07 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: MIP-FA-to-MN-SPI and co-located servers Message-ID: <20011016200407.A30056@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , aaa-wg@merit.edu References: <15303.22433.429099.131094@gargle.gargle.HOWL> <20011014074954.B21749@charizard.diameter.org> <15306.62783.586551.803047@gargle.gargle.HOWL> <15308.34451.377162.39099@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15308.34451.377162.39099@gargle.gargle.HOWL>; from meklund@cisco.com on Tue, Oct 16, 2001 at 03:12:19PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Please reject this issue... I will gladly do so :) PatC From owner-aaa-wg@merit.edu Tue Oct 16 23:20:11 2001 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 XAA26924 for ; Tue, 16 Oct 2001 23:20:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3FFA91230; Tue, 16 Oct 2001 23:19:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C403891235; Tue, 16 Oct 2001 23:19: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 B186D91230 for ; Tue, 16 Oct 2001 23:19:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 984715DD98; Tue, 16 Oct 2001 23:19:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1A5945DD94 for ; Tue, 16 Oct 2001 23:19:52 -0400 (EDT) Received: (qmail 30081 invoked by uid 500); 17 Oct 2001 03:04:46 -0000 Date: Tue, 16 Oct 2001 20:04:46 -0700 From: Pat Calhoun To: Kevin Purser Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Message-ID: <20011016200446.B30056@charizard.diameter.org> Mail-Followup-To: Kevin Purser , Pat Calhoun , aaa-wg@merit.edu References: <20011014080550.D21749@charizard.diameter.org> <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> <20011016110748.A28410@charizard.diameter.org> <006101c15673$3c3923d0$869f558a@ew.us.am.ericsson.se> <20011016114855.A29165@charizard.diameter.org> <009101c15683$3c4e1820$869f558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009101c15683$3c4e1820$869f558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Tue, Oct 16, 2001 at 01:43:34PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > After re-reading the original issue, my comment becomes more of an editorial > one- why not use something like: > > tls = ( "no" | "yes" ) > ; Specifies whether TLS is to be used > ; when communicating with the peer. The > ; default value is no. > > which is really what the original issue was trying to accomplish, right? Or > better yet, to leave future transport layer mechanisms available: > > transport-security = ( "none" | "TLS" | ...) > ; Specifies whether TLS [or other eventual > transport layer mechanisms] is to be used > ; when communicating with the peer. The > ; default value is none. > > Simply put, if this option in the URI is only intended to describe transport > layer mechanisms, why not make that obvious in the URI option name, rather > than using a term as broad as "security". I agree. PatC From owner-aaa-wg@merit.edu Wed Oct 17 01:12:18 2001 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 BAA00098 for ; Wed, 17 Oct 2001 01:12:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3BD991243; Wed, 17 Oct 2001 01:12:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D6B491267; Wed, 17 Oct 2001 01:12: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 8721C91243 for ; Wed, 17 Oct 2001 01:12:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 659F45DDC5; Wed, 17 Oct 2001 01:12:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 7E8155DDC1 for ; Wed, 17 Oct 2001 01:12:02 -0400 (EDT) Received: from jariws1 ([62.248.238.92]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011017051201.ICRZ27233.fep02-app.kolumbus.fi@jariws1>; Wed, 17 Oct 2001 08:12:01 +0300 Message-ID: <00aa01c156ca$44f25800$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , "Kevin Purser" Cc: "Pat Calhoun" , References: <20011014080550.D21749@charizard.diameter.org> <001d01c15662$d702c030$869f558a@ew.us.am.ericsson.se> <20011016110748.A28410@charizard.diameter.org> <006101c15673$3c3923d0$869f558a@ew.us.am.ericsson.se> <20011016114855.A29165@charizard.diameter.org> <009101c15683$3c4e1820$869f558a@ew.us.am.ericsson.se> <20011016200446.B30056@charizard.diameter.org> Subject: Re: [AAA-WG]: Issue 191: How to know when to use TLS Date: Wed, 17 Oct 2001 08:12:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > After re-reading the original issue, my comment becomes more of an editorial > > one- why not use something like: > > > > tls = ( "no" | "yes" ) > > ; Specifies whether TLS is to be used > > ; when communicating with the peer. The > > ; default value is no. > > > > which is really what the original issue was trying to accomplish, right? Or > > better yet, to leave future transport layer mechanisms available: > > > > transport-security = ( "none" | "TLS" | ...) > > ; Specifies whether TLS [or other eventual > > transport layer mechanisms] is to be used > > ; when communicating with the peer. The > > ; default value is none. > > > > Simply put, if this option in the URI is only intended to describe transport > > layer mechanisms, why not make that obvious in the URI option name, rather > > than using a term as broad as "security". > > I agree. Looks good from my point of view as well. Jari From owner-aaa-wg@merit.edu Wed Oct 17 07:04:20 2001 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 HAA17696 for ; Wed, 17 Oct 2001 07:04:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 450EE91267; Wed, 17 Oct 2001 07:04:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0293A9126B; Wed, 17 Oct 2001 07:04:06 -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 BC99591267 for ; Wed, 17 Oct 2001 07:04:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86A055DDAF; Wed, 17 Oct 2001 07:04:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id A7BD95DD9D for ; Wed, 17 Oct 2001 07:04:04 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id MAA04631 for ; Wed, 17 Oct 2001 12:04:04 +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, 17 Oct 2001 12:00:42 +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 MAA25782; Wed, 17 Oct 2001 12:05:56 +0100 Message-ID: <3BCD65A7.12C42CE@baltimore.ie> Date: Wed, 17 Oct 2001 12:04:07 +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: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: End-to-End Security Proposal References: <3BCCABB5.98812917@interlinknetworks.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 Don, It would be a *bad* idea for this group to start inventing key management schemes - using CMS means we use the work already done over the last 5 or so years by a large bunch of cryptographers and security protocol folks. Throwing that away doesn't sound at all sensible to me. I think that's the main issue, but have responded to in more detail below. Stephen. Don Zick wrote: > > Help! I'm finding it difficult to use my S/MIME toolkit to implement > the proposed CMS Security Application. I think the CMS Security Application > provides more sophistication and complexity than is necessary. Am I > alone here? Part of it may simply be that I am a newcomer to CMS and S/MIME > and part of it may be that my S/MIME toolkit does not implement the latest > CMS standard. I'd be surprised if the latter was the case, since our use of CMS should allow an S/MIME v2 toolkit to be used. What difficulties have you actually found? > Could we consider an End-to-End security scheme that does not require > CMS? It would be a major piece of work to start defining how to do signing/encryption/key exchange etc. without using CMS (and this just isn't the right venue for such work in any case). > I think it may be possible to achieve the desired security goals without > using CMS or S/MIME and to simplify Diameter End-to-End security at the > same time. You seem to be proposing two types of changes, with different impacts: - changes to how we're using PKI - changes to how we do signing/encryption etc. Overall, I'd argue that the PKI changes would make the Diameter spec look simpler but just push (actually hide) the complexity back down into the generic PKI code and thereby likely reduce interop. For the second case, I basically think it'd be very unwise for this group to start defining e.g. key exchange mechanisms. Take a peek at the smime or tls wg's archives to see how hard some of these things get! In any case, responding to the details... > I propose changing the Diameter End-to-End security scheme as follows: > > - Eliminate the Local-CA-info and CA-Chain AVPs. Certificate Authority > databases must be maintained at Diameter nodes. (A Certificate Authority > database must already be maintained by Diameter Servers to support TLS, > and the database must now also include all CAs required for End-to-End > security.) Local-CA-info is how one node tells another which CAs it trusts. Without this, you're basically reduced to there being a few global public CAs that everyone trusts (as happens now with browsers). I don't think that that's what's required. Note also that this is more or less the same trick as used in TLS handshakes. The CA-Chain AVP basically makes it easier for nodes by getting rid of some of the potential flexibility that general handling of certificate chains involves (we're insisting that all AAA nodes in a given realm use the same CA). Without this, nodes would have to be able to process more complex certificate chains (e.g. where two AAA servers in the same realm are certified by different CAs). Basically, while removing these AVPs might make the Diameter CMS specification look simpler, it'd reduce the chances of successfully establishing a DSA with a node somewhere on the Internet. > - Replace AAA-Server-Certs and CMS-Cert AVPs with the Origin-Certificate > AVP. The Origin-Certificate subjectAltName field contains a dNSName that > is set to either the FQDN or the realm of a Diameter host. Setting the dNSName > to a realm name allows a set of Diameter Servers to use the same certificate. I don't follow you here - other than suggesting changing the name of the AAA-Server-Certs AVP what's the difference? > - Eliminate OCSP-Request-Flags, OCSP-Nonce, and OCSP-Responses AVPs. > It is up to the diameter peers to validate certificates during the establishment > of the security association as is done during a TLS handshake. Endpoints > share each other's certificates and may terminate security associations if > notified outside of the Diameter protocol that a certificate has been revoked. The OCSP stuff is optional. The reason for including it is that I expect there'll be cases where nodes cannot reasonably be expected to be able to get certificate status information except via Diameter. I'd say that experience (of using PKIs) has shown that this is worthwhile. > - Eliminate DSA-TTL AVP. The proposed scheme requires endpoints to > exchange certificates. The certificate expiration time may be used to > determine when a DSA must expire. While this is possible, I don't think its reasonable - do you think a DSA expiry averaging 6 months is reasonable? That could be a lot of NV storage! > - Eliminate Expected-Signed-AVP and Expected-Encrypted-AVP AVPs. The > proposed scheme requires that Diameter protocol specifications must > indicate which AVPs must be signed and encrypted when a DSA has been > established. The proposal also allows optional AVPs to be signed and/or > encrypted if desired. Without these, how can nodes find out what security other nodes expect to be applied? > - Replace CMS-Encrypted-Data AVP with Encrypted-Data AVP > - Replace CMS-Signed-Data AVP with Signed-Data AVP. EEK! Really, take a peek at the smime wg archives to see what a hornet's nest your suggesting we open up. [...] > Encrypted-Data AVP > Encrypted-Data AVP is of type Group. It has the following message > format: > > Encrypted-Data ::= < AVP Header: ??? > > { Destination Realm } > { ED-Origin-Session-Key-Number } > { ED-Origin-Session-Key } > { Encrypted-Data-Value } > [ Destination Host ] [...] > Signed-Data ::= < AVP Header: ??? > > 1* { AVP } > { Signature } > [ Origin-Host ] Ok, questions: - How can I ever use DSA, ECC or D-H with these? Even if RSA is mandatory, fixing that in the protocol is unwise. - How to I indicate the algorithm for the session key? Fixing 3-DES in the protocol is unwise. - Where do I put IVs? - Where do I put algorithm parameters? - How is the session key wrapped (which key bits are where, say for RC4-export or AES?) [Note: this can be a *hard* problem!!!] - How do I setup a session key with >1 recipient? - How is the data transformed before encrypting/signing (padding, use of OAEP etc). - How do I tell someone they can forget a session key? - If a session key is reused, does repeated encryption expose anything about the cleartext? (say where an attacker forces encryption of a known plaintext-block-1 by connecting to a NAS and then watches until someone else's connection results in the same ciphertext) - Given some (key or data) wrapping, how do we know its not vulnerable to some crypto attacks? (E.g. something like the million message attack on pkcs#1?) Do we really want to go there? I think not. (In fact, I hope you don't try to answer those questions:-) -- ____________________________________________________________ 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 Oct 17 08:13:58 2001 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 IAA19861 for ; Wed, 17 Oct 2001 08:13:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2E1B91242; Wed, 17 Oct 2001 08:13:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C8FE91246; Wed, 17 Oct 2001 08:13: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 5609091242 for ; Wed, 17 Oct 2001 08:13:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F1345DDC6; Wed, 17 Oct 2001 08:13:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A8F4E5DD9D for ; Wed, 17 Oct 2001 08:13:43 -0400 (EDT) Received: (qmail 30982 invoked by uid 500); 17 Oct 2001 11:58:36 -0000 Date: Wed, 17 Oct 2001 04:58:36 -0700 From: Pat Calhoun To: Bob Kopacz Cc: Pat Calhoun , aaa-wg Subject: [AAA-WG]: Re: Handling of Duplicate Requests Message-ID: <20011017045836.B30911@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , Pat Calhoun , aaa-wg References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Mon, Oct 15, 2001 at 04:51:33PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk well, unlike RADIUS, identifiers aren't changed just because a bit is twiddled in the packet. That's a fundamental difference since it makes it much easier to interpret duplicates. The down side (as you state above) is that a future request could have a different set of AVPs. However, I would claim that once you've asked for a set of features, I don't understand why you'd want to change your mind mid-course. Given the above, is your concern answered? PatC On Mon, Oct 15, 2001 at 04:51:33PM -0400, Bob Kopacz wrote: > Hi Pat, > > The Diameter base draft mentions a few things about how the AAA home > server handles duplicate request messages, but leaves much to the > implementer's imagination. Maybe this is by design, but maybe the > AAAH's actions should be specified a little more. > > Here's the kinds of things I've been thinking about: > > Suppose a home server receives a duplicate request, i.e. a request > whose Origin-Host and End-to-End-Identifier match a recent > previously-received request. > > There's a couple cases here: > > 1. The previously-received request has already been replied to. > > or > > 2. The previously-received request hasn't yet been replied to. The > server is waiting for something, e.g. the original request is an AMR, > the server has sent an HAR to the Home Agent, but hasn't gotten the > HAA back yet. > > > And for each of these two cases, there are a couple of cases: > > a. The duplicate request is really a duplicate. > > b. The duplicate request is not really a duplicate: > -- Even though the Origin-Host and End-to-End-Identifiers match, the > "duplicate" differs in some essential way, e.g. the Session-Id or > User-Name differs from the previously-received request. > -- Or maybe the duplicate differs in some minor but legitimate way. > (Maybe the following aren't real-world examples, but here goes...) > Example#1: An FA is connected to two AAAFs. The FA sends his AMR to > AAAF1, then fails over and resends his request to AAAF2. AAAF1 and > AAAF2 twiddle the MIP-Feature-Vector bits differently, and forward the > AMR to the AAAH. > Example#2: A NAS is connected to two local proxies. The NAS sends his > request to AAAP1, then fails over and resends this request to AAAP2. > AAAP1 and AAAP2 modify the request message differently because of > slightly different policy. > > > Does the following make sense for the AAA Home Server?: > > Case 1a: is easy, just send back pretty much the same answer. > > Case 1b: Send negative reply for duplicate, Result-Code=[TBD]. Send > an Abort-Session-Request for the original (iff original answer was a > SUCCESS). > > Case 2a: Is the expectation here that when the server can finally > respond to the original request, that it responds to the duplicate at > the same time? > > Case 2b: Send a negative reply for both the original request and the > duplicate, Result-Code=[TBD]. > > Bob K. > From owner-aaa-wg@merit.edu Wed Oct 17 09:52:07 2001 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 JAA24696 for ; Wed, 17 Oct 2001 09:52:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1857291246; Wed, 17 Oct 2001 09:51:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE57991249; Wed, 17 Oct 2001 09:51:54 -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 ADA2391246 for ; Wed, 17 Oct 2001 09:51:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D6CE5DDD0; Wed, 17 Oct 2001 09:51:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (unknown [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 6C1915DD9D for ; Wed, 17 Oct 2001 09:51:53 -0400 (EDT) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id f9HDqr401395 for ; Wed, 17 Oct 2001 09:52:53 -0400 Message-ID: <3BCD8D33.429F98FA@interlinknetworks.com> Date: Wed, 17 Oct 2001 09:52:52 -0400 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: End-to-End Security Proposal References: <3BCCABB5.98812917@interlinknetworks.com> <3BCD65A7.12C42CE@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stephen, Thank you for your reply. You raise some excellent points and have enlightened me on a number of issues. It just seems to this newcomer that CMS may be overkill for what we need to do. I would have hoped that based on what has been learned over the years in the CMS debates that we could have come up with a reasonable set of AVPs to support End-to-End security without requiring an S/MIME toolkit, which for me is proving to be painful. I am continuing to learn and understand about CMS and I appreciate your explanations. I have been doing some testing with OpenSSL. This toolkit has support for PKCS #7 (CMS Version 1.5). Will that work for the Diameter CMS Security Application? If not, do you recommend any toolkits in particular? I have some questions about the Diameter CMS Security Application draft 3 alpha 1. 1. The end of section 6 states that all MIME encoded data in this specification MUST use the "application/pkcs7-mime" MIME type. OpenSSL supports the "application/x-pkcs7-mime". Will the OpenSSL format work? 2. From section 6.1, BER encoding is used. OpenSSL only supports DER, which is more restrictive. Is this a problem? 3. From section 6.3, MIME(x) represents the MIME encoding of x. Will my mime encoded buffer look like this? MIME-Version: 1.0 Content-Type: base64 {Base 64 encoded AVP List} 4. From section 6.3, EnvelopedData-fnc(x,y) and SignedData(y) routines are described. I'm still trying to figure out if/how OpenSSL can perform these functions. Will PKCS #7 routines be appropriate to use here? 5. OpenSSL does not easily support counter-signatures. How important are these? Thanks again for your reply, Don Zick Interlink Networks, Inc. Stephen Farrell wrote: > Hi Don, > > It would be a *bad* idea for this group to start inventing key > management schemes - using CMS means we use the work already > done over the last 5 or so years by a large bunch of cryptographers > and security protocol folks. Throwing that away doesn't sound > at all sensible to me. > > I think that's the main issue, but have responded to in > more detail below. > > Stephen. > > Don Zick wrote: > > > > Help! I'm finding it difficult to use my S/MIME toolkit to implement > > the proposed CMS Security Application. I think the CMS Security Application > > provides more sophistication and complexity than is necessary. Am I > > alone here? Part of it may simply be that I am a newcomer to CMS and S/MIME > > and part of it may be that my S/MIME toolkit does not implement the latest > > CMS standard. > > I'd be surprised if the latter was the case, since our use of CMS should > allow an S/MIME v2 toolkit to be used. What difficulties have you > actually found? > > > Could we consider an End-to-End security scheme that does not require > > CMS? > > It would be a major piece of work to start defining how to do > signing/encryption/key exchange etc. without using CMS (and this > just isn't the right venue for such work in any case). > > > I think it may be possible to achieve the desired security goals without > > using CMS or S/MIME and to simplify Diameter End-to-End security at the > > same time. > > You seem to be proposing two types of changes, with different impacts: > > - changes to how we're using PKI > - changes to how we do signing/encryption etc. > > Overall, I'd argue that the PKI changes would make the Diameter spec > look simpler but just push (actually hide) the complexity back down > into the generic PKI code and thereby likely reduce interop. > > For the second case, I basically think it'd be very unwise for this > group to start defining e.g. key exchange mechanisms. Take a peek at > the smime or tls wg's archives to see how hard some of these things > get! > > In any case, responding to the details... > > > I propose changing the Diameter End-to-End security scheme as follows: > > > > - Eliminate the Local-CA-info and CA-Chain AVPs. Certificate Authority > > databases must be maintained at Diameter nodes. (A Certificate Authority > > database must already be maintained by Diameter Servers to support TLS, > > and the database must now also include all CAs required for End-to-End > > security.) > > Local-CA-info is how one node tells another which CAs it trusts. Without > this, you're basically reduced to there being a few global public CAs > that everyone trusts (as happens now with browsers). I don't think that > that's what's required. Note also that this is more or less the same > trick as used in TLS handshakes. > > The CA-Chain AVP basically makes it easier for nodes by getting rid > of some of the potential flexibility that general handling of > certificate chains involves (we're insisting that all AAA nodes in a > given realm use the same CA). Without this, nodes would have to be > able to process more complex certificate chains (e.g. where two AAA > servers in the same realm are certified by different CAs). > > Basically, while removing these AVPs might make the Diameter CMS > specification look simpler, it'd reduce the chances of successfully > establishing a DSA with a node somewhere on the Internet. > > > - Replace AAA-Server-Certs and CMS-Cert AVPs with the Origin-Certificate > > AVP. The Origin-Certificate subjectAltName field contains a dNSName that > > is set to either the FQDN or the realm of a Diameter host. Setting the dNSName > > to a realm name allows a set of Diameter Servers to use the same certificate. > > I don't follow you here - other than suggesting changing the name of > the AAA-Server-Certs AVP what's the difference? > > > - Eliminate OCSP-Request-Flags, OCSP-Nonce, and OCSP-Responses AVPs. > > It is up to the diameter peers to validate certificates during the establishment > > of the security association as is done during a TLS handshake. Endpoints > > share each other's certificates and may terminate security associations if > > notified outside of the Diameter protocol that a certificate has been revoked. > > The OCSP stuff is optional. The reason for including it is that I expect > there'll be cases where nodes cannot reasonably be expected to be able to > get certificate status information except via Diameter. I'd say that experience > (of using PKIs) has shown that this is worthwhile. > > > - Eliminate DSA-TTL AVP. The proposed scheme requires endpoints to > > exchange certificates. The certificate expiration time may be used to > > determine when a DSA must expire. > > While this is possible, I don't think its reasonable - do you think a > DSA expiry averaging 6 months is reasonable? That could be a lot of > NV storage! > > > - Eliminate Expected-Signed-AVP and Expected-Encrypted-AVP AVPs. The > > proposed scheme requires that Diameter protocol specifications must > > indicate which AVPs must be signed and encrypted when a DSA has been > > established. The proposal also allows optional AVPs to be signed and/or > > encrypted if desired. > > Without these, how can nodes find out what security other nodes expect > to be applied? > > > - Replace CMS-Encrypted-Data AVP with Encrypted-Data AVP > > - Replace CMS-Signed-Data AVP with Signed-Data AVP. > > EEK! Really, take a peek at the smime wg archives to see what a > hornet's nest your suggesting we open up. > > [...] > > > Encrypted-Data AVP > > Encrypted-Data AVP is of type Group. It has the following message > > format: > > > > Encrypted-Data ::= < AVP Header: ??? > > > { Destination Realm } > > { ED-Origin-Session-Key-Number } > > { ED-Origin-Session-Key } > > { Encrypted-Data-Value } > > [ Destination Host ] > [...] > > Signed-Data ::= < AVP Header: ??? > > > 1* { AVP } > > { Signature } > > [ Origin-Host ] > > Ok, questions: > > - How can I ever use DSA, ECC or D-H with these? Even if RSA is > mandatory, fixing that in the protocol is unwise. > - How to I indicate the algorithm for the session key? Fixing 3-DES > in the protocol is unwise. > - Where do I put IVs? > - Where do I put algorithm parameters? > - How is the session key wrapped (which key bits are where, say for > RC4-export or AES?) [Note: this can be a *hard* problem!!!] > - How do I setup a session key with >1 recipient? > - How is the data transformed before encrypting/signing (padding, use > of OAEP etc). > - How do I tell someone they can forget a session key? > - If a session key is reused, does repeated encryption expose anything > about the cleartext? (say where an attacker forces encryption of > a known plaintext-block-1 by connecting to a NAS and then watches > until someone else's connection results in the same ciphertext) > - Given some (key or data) wrapping, how do we know its not vulnerable > to some crypto attacks? (E.g. something like the million message > attack on pkcs#1?) > > Do we really want to go there? I think not. (In fact, I hope you > don't try to answer those questions:-) > > -- > ____________________________________________________________ > 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 Oct 17 10:38:59 2001 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 KAA26202 for ; Wed, 17 Oct 2001 10:38:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1C9291239; Wed, 17 Oct 2001 10:38:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B99A19124C; Wed, 17 Oct 2001 10:38: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 B56C791239 for ; Wed, 17 Oct 2001 10:38:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 918DB5DDCD; Wed, 17 Oct 2001 10:38:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id EACCC5DD9D for ; Wed, 17 Oct 2001 10:38:34 -0400 (EDT) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id UAA04627; Wed, 17 Oct 2001 20:07:12 +0530 (IST) From: Kaushik Narayan Message-Id: <200110171437.UAA04627@cisco.com> Subject: Re: [AAA-WG]: End-to-End Security Proposal To: dzick@interlinknetworks.com (Don Zick) Date: Wed, 17 Oct 2001 20:07:12 +0530 (IST) Cc: aaa-wg@merit.edu In-Reply-To: <3BCCABB5.98812917@interlinknetworks.com> from "Don Zick" at Oct 16, 2001 05:50:45 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.2197.1003329432--%" Sender: owner-aaa-wg@merit.edu Precedence: bulk --%--multipart-mixed-boundary-1.2197.1003329432--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit don, hi! I have been working on GSSAPI for Diameter End-to-End security. This is an experimental piece of work which I have been working on some time now. You can find the latest version of the draft draft-kaushik-diameter-strong-sec-03.txt. I need to update the draft based on some recent changes. I am attaching the latest version of the draft along with this email since I have recently updated the IETF drafts directory and I can't see the latest version out there. regards, kaushik! > > > Help! I'm finding it difficult to use my S/MIME toolkit to implement > the > proposed CMS Security Application. I think the CMS Security Application > > provides more sophistication and complexity than is necessary. Am I > alone > here? Part of it may simply be that I am a newcomer to CMS and S/MIME > and > part of it may be that my S/MIME toolkit does not implement the latest > CMS > standard. > > Could we consider an End-to-End security scheme that does not require > CMS? > I think it may be possible to achieve the desired security goals without > > using CMS or S/MIME and to simplify Diameter End-to-End security at the > same time. > > I propose changing the Diameter End-to-End security scheme as follows: > > - Eliminate the Local-CA-info and CA-Chain AVPs. Certificate Authority > databases must be maintained at Diameter nodes. (A Certificate > Authority > database must already be maintained by Diameter Servers to support > TLS, > and the database must now also include all CAs required for End-to-End > > security.) > - Replace AAA-Server-Certs and CMS-Cert AVPs with the Origin-Certificate > > AVP. The Origin-Certificate subjectAltName field contains a dNSName > that > is set to either the FQDN or the realm of a Diameter host. Setting > the dNSName > to a realm name allows a set of Diameter Servers to use the same > certificate. > - Eliminate OCSP-Request-Flags, OCSP-Nonce, and OCSP-Responses AVPs. > It is up to the diameter peers to validate certificates during the > establishment > of the security association as is done during a TLS handshake. > Endpoints > share each other's certificates and may terminate security > associations if > notified outside of the Diameter protocol that a certificate has been > revoked. > - Eliminate DSA-TTL AVP. The proposed scheme requires endpoints to > exchange > certificates. The certificate expiration time may be used to > determine when a DSA > must expire. > - Eliminate Expected-Signed-AVP and Expected-Encrypted-AVP AVPs. The > proposed scheme requires that Diameter protocol specifications must > indicate > which AVPs must be signed and encrypted when a DSA has been > established. > The proposal also allows optional AVPs to be signed and/or encrypted > if > desired. > - Replace CMS-Encrypted-Data AVP with Encrypted-Data AVP > - Replace CMS-Signed-Data AVP with Signed-Data AVP. > > > This proposal requires that each Diameter host participating in a > security > association have a certificate and an associated private key. A > certificate > and private key may be installed on and used by a particular host, or it > may > be installed on and used by all Diameter Servers in a realm. > > Proposed Diameter-Security-Association-Request > > Message Format > :: < Diameter-Header: 304, REQ, PXY > > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Auth-Application-Id } > { Origin-Certificate } > [ Destination-Host ] > [ Origin-State-Id ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > Proposed Diameter-Security-Association-Answer > > Message Format > :: < Diameter-Header: 304, PXY > > { Result-Code } > { Origin-Host } > { Auth-Application-Id } > { Origin-Realm } > { Destination-Realm } > [ Origin-Certificate ] > [ Destination-Host ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > Definitions of New AVPs > ----------------------- > > Origin-Certificate AVP > Origin-Certificate AVP is of type OctetString, and contains the > certificate for the origin realm or origin host. The certificate is > encoded > using DER. The certificate subjectAltName field contains a dNSName that > is > set to either the FQDN or the realm of the origin host. Setting the > dNSName > to a realm name allows a set of Diameter Servers to use the same > certificate. > > > Encrypted-Data AVP > Encrypted-Data AVP is of type Group. It has the following message > format: > > Encrypted-Data ::= < AVP Header: ??? > > { Destination Realm } > { ED-Origin-Session-Key-Number } > { ED-Origin-Session-Key } > { Encrypted-Data-Value } > [ Destination Host ] > > The ED-Origin-Session-Key-Number is of type Unsigned32. It > identifies the origin session key that is used to encrypt > data for the Encrypted-Data-Value AVP. The same origin session > key may be used for a number of messages. Each > time a new origin session key is created the origin session > key number is incremented. A receiving host can decrypt > the ED-Origin-Session-Key using the receiving hosts private key; this > asymmetric decryption is slow and to be avoided when possible. > A receiving host can remember the decrypted origin session key > and the ED-Origin-Session-Key-Number so that if another > Encrypted-Data AVP is later received with the same > ED-Origin-Session-Key-Number > the ED-Origin-Session-Key does not have to be decrypted again. > It is helpful to always include the ED-Origin-Session-Key-Number > and ED-Origin-Session-Key because it allows the Encrypted-Data-Value > AVP to be decrypted by any Diameter Server in a realm that has > the required private key. It also allows for a new origin session > key to be generated by the origin host whenever it deems it appropriate > to do so. > > The ED-Origin-Session-Key is of type OctetString and contains a > session key randomly generated by the message originator. The > session key is encrypted using the public key of the Destination > so that only the Destination can decrypt it. The origin session > key is used to encrypt data for the Encrypted-Data-Value AVP. > > The Encrypted-Data-Value AVP is formed by concatenating all > AVPs in a message that require encryption and encrypting them > with 3DES using the origin session key. (The origin session > key is used to decrypt this AVP.) > > > Signed-Data AVP > Signed-Data AVP is of type Group. It has the following message format: > > Signed-Data ::= < AVP Header: ??? > > 1* { AVP } > { Signature } > [ Origin-Host ] > > Any AVP requiring a signature must be included in this group; if any > encrypted AVP must be signed, the Encrypted-Data AVP must be put into > this group. > > The Signature AVP contains an RSA digital signature for the list of > AVPs requiring a signature. > > Countersigning is not supported. If a proxy wishes to add a signature > to AVP data, it must create a new Signed-Data AVP that includes the > AVPs requiring its signature. > > > I'm very interested in hearing if any others would like to see similar > changes. > > Thanks for taking the time to read this. > > With kind regards, > Don Zick > Interlink Networks, Inc. > > > --%--multipart-mixed-boundary-1.2197.1003329432--% Content-Type: text/plain Content-Description: ascii text Content-Disposition: attachment; filename="draft-kaushik-diameter-strong-sec-03.txt" Content-Transfer-Encoding: 7bit Individual Contribution Kaushik Narayan Internet-Draft HCL-Cisco Category :Standards Track October 2001 Diameter Strong Security Extension using GSSAPI v2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires April 2002. Please send comments to the author (kaushik@cisco.com). Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The Diameter base protocol defines message integrity and AVP encryption using static symmetric transforms to secure the communication between two Diameter nodes. The base protocol also defines a Diameter proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. Kaushik expires April 2002 [Page 1] Internet-Draft March 2001 The ROAMOPS Working Group has defined a requirement that needs the Diameter servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify, and/or be able to view sensitive information, within the message. The Mobile-IP and NASREQ Working Groups have stated that strong authentication is a requirement for AAA data, such as accounting records. This Diameter extension specifies how strong AVP authentication, integrity and encryption can be done using by keys negotiated using Kerberos v5. Table of Contents 1.0 Introduction 2.0 GSSAPI Overview 3.0 GSS Algorithm 4.0 Command-Codes Values 4.1 E2E-GSS-SA-Setup-Request (EGSSR) Command 4.2 E2E-GSS-SA-Setup-Answer (EGSSA) Command 5.0 Usage Scenario with Kerberos v5 GSSAPI mechanism 6.0 Deployment Issues 7.0 Strong Security AVPs 7.1 GSS-Data AVP 7.2 GSS-Token AVP 8.0 Result Code AVP Values 9.0 IANA Considerations 10.0 Security Considerations 11.0 References 12.0 Authors' Addresses 1.0 Introduction The Diameter base protocol [1] defines message integrity and AVP encryption using symmetric transforms to secure the communication between two Diameter nodes. The base protocol also defines a Diameter proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. The ROAMOPS Working Group has defined a requirement in [10] that allows for the Diameter servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify and see sensitive information within the message. The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that non-repudiation is a requirement for AAA data, such as accounting records. Kaushik expires April 2002 [Page 2] Internet-Draft March 2001 When a chain of proxies use hop-by-hop security, each node in the proxy chain MUST recompute the Integrity-Value-Check (ICV) [1], making it easy for a malicious proxy to modify information in a Diameter message. It is virtually impossible for the rest of the nodes in the proxy chain to know that the message was modified in mid-stream. Figure 1 shows an example of such a network, where DIA3 modifies the contents of "foo" in both the request and the response. (Request) (Request) (Request) [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (Answer) (Answer) (Answer) [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] Figure 1: Proxy Chain This document describes how strong authentication and encryption can be provided in the Diameter protocol, by employing security services provided by GSSAPI. GSSAPI would be use for key negotiation between Diameter peers. In the example provided in Figure 1, the originator of the request and response adds a digital signature that covers a set of AVPs within the message. The protected AVPs MUST NOT be changed by an intermediate proxy server (DIA2, DIA3), since the signature validation performed by the end server would fail. The Extension number for this draft is two (2). This value is used in the Extension-Id AVP as defined in [1]. This specification makes use of the 'P' bit in the AVP Header, which is defined in [2]. 2.0 GSSAPI Overview In GSS, client and server interact to create a "security context". Creating a security context involves a negotiation between client and server. Once a context has been established, it has a finite lifetime for which it can be used to secure messages. Client and server MUST be locally authenticated and have acquired default credentials before using this protocol as specified in Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. Kaushik expires April 2002 [Page 3] Internet-Draft March 2001 In GSS, establishing a security context involves the passing of opaque tokens between the client and the server. The client generates the initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens depends on the underlying security mechanism A completed negotiation results in a context handle. A unique context is required for each server to which the client sends secure messages. A context is identified by a context handle. A client maintains a mapping of servers to handles, (target_name, key_name, context_handle) The value key_name also identifies a context handle. The context_handle WOULD be used to provide protection for Diameter AVPs. The GSS Security Context is synonomous to the Security Assocation (SA) for the purpose of this discussion. 3.0 GSS Algorithm When a Diameter node is about to send a messsage which MAY use strong security, it must determine whether to use the strong security service or not. The Diameter node WOULD first check whether a context handle has been cached for the given destination realm. The cached context handle would be used for strong security in case it has not expired. In the present discussion we assume that the Diameter node does not have cached any information. This draft makes use of the Diameter E2E-GSS-SA-Setup-Request (EGSSR) and E2E-GSS-SA-Setup-Answer (EGSSA) messages defined in section 4 to establish whether strong security is required and if so, for which AVPs. Kaushik expires April 2002 [Page 4] Internet-Draft March 2001 Step 1: The originating node sends the EGSSR message to the destination node (a server in the destination realm). The originating node calls GSS_Init_sec_context, using the most recent reply token received from desitination node during this exchange, if any. It MUST set the integ_req_flag to "true" to request that per-message integrity protection be supported for this context. and it MUST pass the TTL for this SA in lifetime_req parameter. The orginating node would generate an error in the following cases * If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available. * If the call does not produce a GSS token of non-zero length. In case of an error, the originating node cannot obtain end-to-end strong security. The originating node sends the EGSSA message with a valid GSS token to the destination node in the following cases * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, The destination node will reply back with a new token to be provided to GSS_Init_sec_context. * If GSS_Init_sec_context returns a GSS_S_COMPLETE. In this case the security context has been succesfully established at the orginating node and the processing on the destination node continues with Step 3. This EGSSR message WOULD contain - the token returned from the GSS_Init_sec_context call. - a list of AVPs that expected to be protected (and how) for this realm Kaushik expires April 2002 [Page 5] Internet-Draft March 2001 Step 2: The destination node calls GSS_Accept_sec_context, using the token received in the EGSSR message from originating node. The destination node WOULD reply back with an EGSSA message containing the GSS token in the following cases * If the resulting major_status code is GSS_S_COMPLETE, the security context has been established succesfully on the destination node and processing continues with Step 3. * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the processing will continue with Steps 1 and 2 until GSS_S_COMPLETE. In case the GSS_Acccept_Sec_Context does not produce a GSS token of non-zero length, the destination node would send an error message in the EGSSA message. This EGSSA message WOULD contain - the token returned from the GSS_Accept_sec_context call. - a list of AVPs that expected to be protected (and how) for this realm Step 3: The security context has been succesfully established at the Diameter node. The Diameter node can now obtain security services using the context handle, the GSS_Wrap method would be used for confidentiality protection and GSS_GetMIC would be used for integrity protection. The context handle would be valid until TTL set by the destination node expires. Callers would be returned GSS_S_CONTEXT_EXPIRED in case they call GSS_Wrap or GSS_GetMIC after TTL expiration. The list of AVPs to be protected would be carried in the Expected-Signed-AVP and Expected-Encrypted-AVP AVPs defined in [2]. 4.0 Command-Codes Values This section defines new Command-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. The following Command Codes are currently defined in this document: Command-Name Abbrev. Code Reference ------------------------------------------------------------ E2E-GSS-SA-Setup-Request EGSSR 320 4.1 E2E-GSS-SA-Setup-Answer EGSSA 320 4.2 Kaushik expires April 2002 [Page 6] Internet-Draft March 2001 4.1 E2E-GSS-SA-Setup-Request (EGSSR) Command The E2E-SA-Setup-Request command, indicated by the Command-Code field set to 320 and the 'R' bit set in the message flags field, is sent by a Diameter node to establish a Diameter GSS based End-to-End Security Association. ::= < Diameter-Header: 320, R > * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] [ GSS-Token ] 4.2 E2E-GSS-SA-Setup-Answer (EGSSA) Command The E2E-SA-Setup-Answer command, indicated by the Command-Code field set to 304 and the 'A' bit set in the message flags field, is sent by a Diameter node in response to an EGSSR message. ::= < Diameter-Header: 320, A > * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] [ GSS-Token ] 5.0 Usage Scenario with Kerberos v5 GSSAPI mechanism. The Kerberos v5 GSSAPI mechanism SHOULD be used in the is used with mutual authentication. The originating Diameter node SHOULD possess a valid cross realm TGT which forms the default credentials. Acquisition of cross realm TGTs and models for cross realm trust are discussed in section 5.0. The Kerberos v5 service principal would be of the form diameter@homeserver.HOMEREALM.COM. The GSS_Init_Sec_Context would acquire the service principal ticket from the KDC in case there isn't a valid ticket present in the credentials cache. In routing the Diameter Request to the destination Diameter node, the NAI is typically used, as described in RFC 2486. The originating Diameter node (NAS) would also need the hostname of the destination Diameter node (homeserver) to construct the End-to-End service principal. The hostname and port of a destination Diameter node (homeserver) WOULD be determined by quering DNS, using either an address record approach, or an SRV record approach. Remote realm Kerberos Key Distribution Centres(KDC) can either be statically configured or can be discovered dynamically. The internet draft "draft-ietf-cat-krb-dns-locate-02.txt" suggests a method of dynamic discovery of the KDC for a remote realm. Kaushik expires April 2002 [Page 7] Internet-Draft March 2001 The key exchange of the Kerberos GSS mechanism would happen as follows. originating node (NAS) destination node (homeserver) ---------------------- ----------------------------- GSS_Init_sec_context(TTL,integ_req_flag) returns GSS_S_CONTINUE_NEEDED, output_token EGSSR --------> Expected-Signed-AVP Expected-Encrypted-AVP GSS-Token (output_token) GSS_Accept_sec_context(input_token) returns GSS_S_COMPLETE, output_token <-------- EGSSA Expected-Signed-AVP Expected-Encrypted-AVP GSS-Token (output_token). GSS_Init_sec_context(input_token) returns GSS_S_SUCCESS. At the end of the above exchange, the homeserver and NAS would have mutually authenticated each other and both the Diameter nodes would have a context handle which would provide the security services to both Diameter nodes. The key exchange of the Kerberos GSS mechanism and the SA creation WOULD take one round trip. 6.0 Deployment Issues A valid cross-realm TGT should be present on the originating Diameter node (NAS) to create a security associations with destination Diameter nodes (homeserver) in that realm. The initial TGT can be obtained manually during bootup of the originating node (NAS). Alternatively PKINIT can be employed wherein the homeserver's public key certificate WOULD be used in the initial authentication exchange with the local KDC. Cross realm trust in Kerberos can be established in multiple ways. The simplest way is to maintain separate keys for every realm which wishes to exchange authentication information with another realm (which implies n(n-1) keys). Kerberos v5 support transitive trust which allows hierarchichal arrangement of realms for better scalability. Kaushik expires April 2002 [Page 8] Internet-Draft March 2001 Another option available is PKCROSS which utilizes a public key infrastructure (PKI) [X509] to simplify the administrative burden of maintaining cross-realm keys. PKCROSS take advantage of the distributed trust management capabilities of public key cryptography for establishing cross realm trust. The model proposed in this draft has the NAS as the GSS client and the Diameter homeserver as the GSS server. 7.0 Strong Security AVPs This section contains AVPs that are used to establish a Diameter End-to-End Security Association. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| GSS-Data 310 6.1 Grouped | M | P | | V | N | GSS-Token 348 6.2 OctetString| M | P | | V | N | E2ESecureList 349 6.3 OctetString| M | P | | V | Y | 7.1 GSS-Data AVP The GSS-Data AVP (AVP Code 350) is of type Grouped and contains the AVPs which are required for End to End security. The grammar for the grouped Data field is defined is: GSS-Data = Digest ptextlen Encrypted-Data Digest = ; the output token of GSS_GetMIC call which provides e2e integrity protection and data origin authentication for Diameter AVPs. ptextlen = ; Plaintext-Data-Length. Encrypted-Data = ; the output token of the GSS_Wrap call which provides confidentiality for Diameter AVPs. +---------------------------------------------------------------+ | AVP Header (AVP Code = 320) | +---------------------------------------------------------------+ | Digest AVP | +---------------------------------------------------------------+ | Plaintext-Data-Length AVP | +---------------------------------------------------------------+ | Encrypted-Data AVP | +---------------------------------------------------------------+ Kaushik expires April 2002 [Page 9] Internet-Draft March 2001 7.2 GSS-Token AVP The GSS-Token AVP (AVP Code = 351) is of type OctetString. This AVP carries the GSS token exchanged during context initialization. 8.0 Result-Code AVP Values This section defines new Result-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. 9.0 IANA Considerations The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the Diameter name spaces. 10.0 Security Considerations This draft determines whether to use Kerberos purely on the basis of the existence or non-existence of a Kerberos service principal. This presents an opportunity for a downgrade attack wherein because an attacker can spoof an error message from the KDC and make the Diameter client not use end to end security which would compromise end to end security. Implementations should provide users with a policy knob which allow Diameter clients to throw an error in case they encounter an error while acquiring the service principal ticket from the KDC. 11.0 References [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, September 2000. [2] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security Extension", draft-calhoun-diameter-strong-crypto-07.txt (work in progress), March 2001. Kaushik expires April 2002 [Page 10] Internet-Draft March 2001 [3] J. Linn, "Generic Security Service Application Program Interface", Version 2, Update 1, RFC 2743, January 2000 [4] Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep- tember 2000. [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", draft-ietf- mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000. [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [11] P. Calhoun, W. Bulley, "Diameter NASREQ Extension", draft- calhoun-diameter-nasreq-05.txt, IETF work in progress, September 2000. [12] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- tember 2000. [13] Arkko, Calhoun, Patel, Zorn, "Diameter Accounting Extension", draft-calhoun-diameter-accounting-08.txt, IETF work in progress, 12.0 Author's Address Kaushik Narayan HCL-Cisco Offshore Development Centre, 158, NSK Salai, Vadapalani Chennai, Tamilnadu 600 026, India EMail: kaushik@cisco.com Phone: +091-44-3741939 Kaushik expires April 2002 [Page 11] Internet-Draft March 2001 13.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Kaushik expires April 2002 [Page 12] --%--multipart-mixed-boundary-1.2197.1003329432--%-- From owner-aaa-wg@merit.edu Wed Oct 17 13:14:19 2001 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 NAA00527 for ; Wed, 17 Oct 2001 13:14:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF0599126D; Wed, 17 Oct 2001 13:14:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96AC89126E; Wed, 17 Oct 2001 13:14:06 -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 806619126D for ; Wed, 17 Oct 2001 13:14:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 620DF5DDB3; Wed, 17 Oct 2001 13:14:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id BA6165DD9B for ; Wed, 17 Oct 2001 13:14:04 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA09101 for ; Wed, 17 Oct 2001 18:14:04 +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, 17 Oct 2001 18:10:42 +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 SAA31733; Wed, 17 Oct 2001 18:15:56 +0100 Message-ID: <3BCDBC56.CB8993EF@baltimore.ie> Date: Wed, 17 Oct 2001 18:13:58 +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: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: End-to-End Security Proposal References: <3BCCABB5.98812917@interlinknetworks.com> <3BCD65A7.12C42CE@baltimore.ie> <3BCD8D33.429F98FA@interlinknetworks.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 Don, > I have been doing some testing with OpenSSL. This toolkit has support for PKCS #7 (CMS > Version 1.5). Will that work for the Diameter CMS Security Application? That should be fine for everything except the re-use of content encryption keys (which is a new spec. & is optional for Diameter in any case). > If not, do > you recommend any toolkits in particular? Ahem. Commercials are probably not a good idea:-) You could look at www.imc.org - I think there's information about various s/mime implementations there. > 1. The end of section 6 states that all MIME encoded data in this specification MUST > use the "application/pkcs7-mime" MIME type. OpenSSL supports the > "application/x-pkcs7-mime". Will the OpenSSL format work? Hmm. Should be fine for CMS-Encrypted-Data (you can just change it). I need to check the spec about signed (I'm out of the office now.) If there are any problems we should allow either (x-pkcs7-mime used to be pretty widely supported), on receipt probably. > 2. From section 6.1, BER encoding is used. OpenSSL only supports DER, which is more > restrictive. Is this a problem? DER is a subset of BER, so emitting DER is fine. If your version of openssl doesn't support decoding BER (I'd be surprised about that) then that could be a problem (OTOH, we could maybe get away with ruling out indefinite length encoding - I originally changed to BER 'cause a colleague who was coding up an early version found that easier.) > 3. From section 6.3, MIME(x) represents the MIME encoding of x. Will my mime encoded > buffer look like this? > > MIME-Version: 1.0 > Content-Type: base64 > > {Base 64 encoded AVP List} Not-in-office excuse again I'm afraid, get back to you tomorrow. > > 4. From section 6.3, EnvelopedData-fnc(x,y) and SignedData(y) routines are described. > I'm still trying to figure out if/how OpenSSL can perform these functions. Will PKCS > #7 routines be appropriate to use here? Yes. > 5. OpenSSL does not easily support counter-signatures. How important are these? Personally, I'm not that sure. I seem to recall some people wanting them for accounting purposes - I'd be surprised if there were a real "in-line" need to counter-signing. 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 Thu Oct 18 09:34:27 2001 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 JAA09191 for ; Thu, 18 Oct 2001 09:34:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 594889127D; Thu, 18 Oct 2001 09:34:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 270CE9127E; Thu, 18 Oct 2001 09:34:09 -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 3342B9127D for ; Thu, 18 Oct 2001 09:34:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0805D5DD9A; Thu, 18 Oct 2001 09:34:08 -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 514CE5DD93 for ; Thu, 18 Oct 2001 09:34:07 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9IDYdf16396 for ; Thu, 18 Oct 2001 16:34:39 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 18 Oct 2001 16:34:02 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VH2P8>; Thu, 18 Oct 2001 16:34:02 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B0@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF specification Date: Thu, 18 Oct 2001 16:33:55 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jaakko Rajaniemi Submitter email address: jaakko.rajaniemi@nokia.com Date first submitted: 2001-10-18 Document: base Comment type: T Priority: 1 Section: 3.2 Rationale/Explanation of issue: The section 3.2 "Command Code ABNF specification" contains the ABNF specification which must be followed when contructing Diameter Command Codes. It does not contain a possibility to use the alternatives (see RFC2243, section 3.2) when defining the AVPs included into the commands. This is very restrictive and does not allow enough flexibility when defining command codes and therefore it is proposed that the alternatives is included. Requested change: Include following description to the avp-spec in the section 3.2: avp-spec = diameter-name *("/" diameter-name) ; The avp-spec has to be an AVP Name, ; defined in the base or extended Diameter ; specifications. The avp-spec may contain AVP Names ; which are alternatives, see RFC 2234 section 3.2. From owner-aaa-wg@merit.edu Thu Oct 18 10:49:36 2001 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 KAA11713 for ; Thu, 18 Oct 2001 10:49:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 303E991282; Thu, 18 Oct 2001 10:49:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F201891283; Thu, 18 Oct 2001 10:49: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 DBDD091282 for ; Thu, 18 Oct 2001 10:49:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B31925DDA6; Thu, 18 Oct 2001 10:49:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5469C5DDAF for ; Thu, 18 Oct 2001 10:49:25 -0400 (EDT) Received: (qmail 12557 invoked by uid 500); 18 Oct 2001 14:32:28 -0000 Date: Thu, 18 Oct 2001 07:32:28 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF specification Message-ID: <20011018073228.C12320@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B0@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B0@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Thu, Oct 18, 2001 at 04:33:55PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk May I ask why you've used 200? There is already one. Is this a new issue that requires a new issue number? PatC On Thu, Oct 18, 2001 at 04:33:55PM +0300, jaakko.rajaniemi@nokia.com wrote: > > Submitter name: Jaakko Rajaniemi > Submitter email address: jaakko.rajaniemi@nokia.com > Date first submitted: 2001-10-18 > Document: base > Comment type: T > Priority: 1 > Section: 3.2 > Rationale/Explanation of issue: > > The section 3.2 "Command Code ABNF specification" contains the ABNF > specification which must be followed when contructing Diameter Command > Codes. It does not contain a possibility to use the alternatives (see > RFC2243, section 3.2) when defining the AVPs included into the commands. > This is very restrictive and does not allow enough flexibility when defining > command codes and therefore it is proposed that the alternatives is > included. > > > Requested change: > > Include following description to the avp-spec in the section 3.2: > > avp-spec = diameter-name *("/" diameter-name) > ; The avp-spec has to be an AVP Name, > ; defined in the base or extended Diameter > ; specifications. The avp-spec may contain AVP Names > ; which are alternatives, see RFC 2234 section 3.2. From owner-aaa-wg@merit.edu Thu Oct 18 11:39:12 2001 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 LAA13082 for ; Thu, 18 Oct 2001 11:39:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F069291285; Thu, 18 Oct 2001 11:39:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7E9191286; Thu, 18 Oct 2001 11:39:02 -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 C240691285 for ; Thu, 18 Oct 2001 11:39:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B27E5DDA2; Thu, 18 Oct 2001 11:39:01 -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 B51E15DD93 for ; Thu, 18 Oct 2001 11:39:00 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9IFdaf01625 for ; Thu, 18 Oct 2001 18:39:36 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Oct 2001 18:38:59 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M6VHL72>; Thu, 18 Oct 2001 18:38:59 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B1@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Thu, 18 Oct 2001 18:38:47 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I took the number from the diameter.org but now I noticed that this is already used. Sorry for this confusion. This is a new issue and requires a new number. Best Regards, Jaakko > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 18 October, 2001 17:32 > To: Rajaniemi Jaakko (NET/Espoo) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command > Code ABNF > specification > > > May I ask why you've used 200? There is already one. Is this > a new issue that > requires a new issue number? > > PatC > On Thu, Oct 18, 2001 at 04:33:55PM +0300, > jaakko.rajaniemi@nokia.com wrote: > > > > Submitter name: Jaakko Rajaniemi > > Submitter email address: jaakko.rajaniemi@nokia.com > > Date first submitted: 2001-10-18 > > Document: base > > Comment type: T > > Priority: 1 > > Section: 3.2 > > Rationale/Explanation of issue: > > > > The section 3.2 "Command Code ABNF specification" contains the ABNF > > specification which must be followed when contructing > Diameter Command > > Codes. It does not contain a possibility to use the > alternatives (see > > RFC2243, section 3.2) when defining the AVPs included into > the commands. > > This is very restrictive and does not allow enough > flexibility when defining > > command codes and therefore it is proposed that the alternatives is > > included. > > > > > > Requested change: > > > > Include following description to the avp-spec in the section 3.2: > > > > avp-spec = diameter-name *("/" diameter-name) > > ; The avp-spec has to be an AVP Name, > > ; defined in the base or extended Diameter > > ; specifications. The avp-spec may > contain AVP Names > > ; which are alternatives, see RFC 2234 > section 3.2. > From owner-aaa-wg@merit.edu Thu Oct 18 15:05:13 2001 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 PAA18122 for ; Thu, 18 Oct 2001 15:05:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF83B91293; Thu, 18 Oct 2001 15:04:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B12991294; Thu, 18 Oct 2001 15:04: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 364B291293 for ; Thu, 18 Oct 2001 15:04:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A1F95DDAD; Thu, 18 Oct 2001 15:04:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (unknown [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 9A3395DD93 for ; Thu, 18 Oct 2001 15:04:50 -0400 (EDT) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id f9IJ5nF10042 for ; Thu, 18 Oct 2001 15:05:49 -0400 Message-ID: <3BCF280B.FFFBBBF8@interlinknetworks.com> Date: Thu, 18 Oct 2001 15:05:47 -0400 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: MIME encoding with CMS Security Application Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stephen and all, >Re: [AAA-WG}: Issue 150: S/MIME precisions > >From: Stephen Farrell >Date: Tue Sep 18 14:23:26 2001 > >If we don't want to do the MIME encoding then we can omit >it, but someone someday might build using a toolkit that >forces the MIME en/decoding and we'll have more interop >problems than otherwise. (I personally don't mind whether >we omit the MIME encoding or not.) How about we eliminate the MIME en/decoding? I think the following is true. Please correct me where I'm wrong. - it requires additional processing - The CMS-Signed-Data AVP contains a signature for MIME encoded data, but not the MIME encoded data itself. This means that the receiver of a CMS-Signed-Data AVP must be able to generate the MIME encoded data in the exact same manner as the sender. It might be difficult for all implementations to perform the MIME encoding exactly the same. Identical MIME headers must always be used with the exact same fields, spacing, carriage returns, and line feeds. This may be a problem if a toolkit adds header information automatically. - I don't think my toolkit requires it ;-) Does anyone out there require that the MIME en/decoding be performed? Thanks for considering this, Don From owner-aaa-wg@merit.edu Thu Oct 18 15:40:19 2001 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 PAA18588 for ; Thu, 18 Oct 2001 15:40:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70F7C91295; Thu, 18 Oct 2001 15:40:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40A6191296; Thu, 18 Oct 2001 15:40:10 -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 4AEC391295 for ; Thu, 18 Oct 2001 15:40:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E5FF5DDAE; Thu, 18 Oct 2001 15:40:09 -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 8858F5DDA2 for ; Thu, 18 Oct 2001 15:40:08 -0400 (EDT) Received: (qmail 10527 invoked by uid 500); 18 Oct 2001 19:56:03 -0000 Date: Thu, 18 Oct 2001 14:56:03 -0500 From: David Frascone To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: MIME encoding with CMS Security Application Message-ID: <20011018145603.I5680@newman.frascone.com> Mail-Followup-To: Don Zick , aaa-wg@merit.edu References: <3BCF280B.FFFBBBF8@interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BCF280B.FFFBBBF8@interlinknetworks.com>; from dzick@interlinknetworks.com on Thu, Oct 18, 2001 at 03:05:47PM -0400 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I see absolutely no reason to convert to 7 bit data in a binary stream. So, vote is *against* mime encoding. -Dave On Thu, Oct 18, 2001 at 03:05:47PM -0400, Don Zick wrote: > Hi Stephen and all, > > >Re: [AAA-WG}: Issue 150: S/MIME precisions > > > >From: Stephen Farrell > >Date: Tue Sep 18 14:23:26 2001 > > > >If we don't want to do the MIME encoding then we can omit > >it, but someone someday might build using a toolkit that > >forces the MIME en/decoding and we'll have more interop > >problems than otherwise. (I personally don't mind whether > >we omit the MIME encoding or not.) > > How about we eliminate the MIME en/decoding? I think the following is > true. Please correct me where I'm wrong. > > - it requires additional processing > - The CMS-Signed-Data AVP contains a signature for MIME encoded data, > but not the MIME encoded data itself. This means that the receiver of a > CMS-Signed-Data AVP must be able to generate the MIME encoded data in > the exact same manner as the sender. It might be difficult for all > implementations to perform the MIME encoding exactly the same. > Identical MIME headers must always be used with the exact same fields, > spacing, carriage returns, and line feeds. This may be a problem if a > toolkit adds header information automatically. > - I don't think my toolkit requires it ;-) > > Does anyone out there require that the MIME en/decoding be performed? > > Thanks for considering this, > Don > > > > > From owner-aaa-wg@merit.edu Thu Oct 18 21:16:55 2001 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 VAA22172 for ; Thu, 18 Oct 2001 21:16:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C040991296; Thu, 18 Oct 2001 21:16:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7996591297; Thu, 18 Oct 2001 21:16: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 4906391296 for ; Thu, 18 Oct 2001 21:16:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 307ED5DDB2; Thu, 18 Oct 2001 21:16:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id E81F95DDAD for ; Thu, 18 Oct 2001 21:16:25 -0400 (EDT) Received: by CMS3 with Internet Mail Service (5.5.2653.19) id <47HK7A8G>; Fri, 19 Oct 2001 10:14:05 +0900 Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80C@CMS3> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: Which case AAA server provide Only Accounting Service to MN? Date: Fri, 19 Oct 2001 10:14:05 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1583B.58427670" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1583B.58427670 Content-Type: text/plain; charset="euc-kr" I have tried to think the following case : If MN shares statically the pre-established Security Association with FA and HA, AAA server provides only an Accounting Service to MN. Is that possible scenario? Final question : at MIP network, I want to know which case AAA server provide Only Accounting Service ? Mobile Node Foreign Agent AAAF AAAH Home Agent ------------------ --------------------- ------------- ---------- ---------- Advertisement & <--------- Challenge Reg-Req --------> Reg-Req ---------- --------------------------------------> <----------- ------------------------------------------ Reg-Reply <---------- Reg-Reply ACR -------------- --> (Session-Id = foo) ACR -----------------> (Session-Id = foo) <------------------- ACA (Session-Id = foo) <---------------- -- ACA (Session-Id = foo) ------_=_NextPart_001_01C1583B.58427670 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Which case AAA server provide Only Accounting Service to = MN?

I have tried to think the following case :
 
If MN shares statically the pre-established Security = Association with FA and HA,
AAA server provides only an Accounting Service to = MN.
 
Is that possible scenario?
 
Final question :
         at = MIP network, I want to know which case AAA server provide Only = Accounting Service ?
 
   Mobile Node   Foreign = Agent    AAAF  =          AAAH    Home = Agent
   ------------------   = ---------------------   -------------     ---------- =      ----------
        =         =         =          = Advertisement &
        =         <--------- = Challenge
 
        =          = Reg-Req  -------->
        =         =         =         =         =         =          = Reg-Req  = ------------------------------------------------>
        =         =         =         =         =         =         =         <----------------------------------------------------- = Reg-Reply

        =           = <---------- Reg-Reply
 
 
        =         =         =         =         =         =           ACR = ---------------->
        =         =         =         =           = (Session-Id =3D foo)
        =         =         =         =         =         =         =         =         =         =         =         =         ACR = ----------------->

        =         =         =         =         =         =         =         =         =         =         (Session-Id = =3D foo)
        =         =         =         =         =         =         =         =         =         =         =            = <------------------- ACA

        =         =         =         =         =         =         =         =         =         =         =         =         =         =         =         (Session-Id = =3D foo)

 
        =         =         =         =         =         =            = <------------------ ACA
        =         =         =         =         =         =         =         =         =         =         (Session-Id = =3D foo)
 
 
 
 

------_=_NextPart_001_01C1583B.58427670-- From owner-aaa-wg@merit.edu Fri Oct 19 06:10:00 2001 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 GAA13377 for ; Fri, 19 Oct 2001 06:10:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE3F6912A5; Fri, 19 Oct 2001 06:09:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7C6E912A6; Fri, 19 Oct 2001 06:09: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 873E5912A5 for ; Fri, 19 Oct 2001 06:09:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E6555DDC0; Fri, 19 Oct 2001 06:09:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 7A47F5DD97 for ; Fri, 19 Oct 2001 06:09:46 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id LAA26849 for ; Fri, 19 Oct 2001 11:09:45 +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 ; Fri, 19 Oct 2001 11:06:23 +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 LAA29305; Fri, 19 Oct 2001 11:11:49 +0100 Message-ID: <3BCFFBF0.784FDD4A@baltimore.ie> Date: Fri, 19 Oct 2001 11:09:52 +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: David Frascone Cc: Don Zick , aaa-wg@merit.edu Subject: Re: [AAA-WG]: MIME encoding with CMS Security Application References: <3BCF280B.FFFBBBF8@interlinknetworks.com> <20011018145603.I5680@newman.frascone.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Frascone wrote: > > I see absolutely no reason to convert to 7 bit data in a binary stream. > I'm starting to agree. The only reason to include it is if there are CMS toolkits out there that insist on the MIME encoding. I checked with a bunch of our folks a while back and though they couldn't identify such a toolkit, everyone thought they remembered that there is one such, so I left it in. If no-one interested in Diameter has a problem though, then it can be removed easily enough (assuming that no Diameter porxy/agent/server is liable to start converting EOLs, upper-> lower or other signature-breaking things). Stephen. > So, vote is *against* mime encoding. > > -Dave > > On Thu, Oct 18, 2001 at 03:05:47PM -0400, Don Zick wrote: > > Hi Stephen and all, > > > > >Re: [AAA-WG}: Issue 150: S/MIME precisions > > > > > >From: Stephen Farrell > > >Date: Tue Sep 18 14:23:26 2001 > > > > > >If we don't want to do the MIME encoding then we can omit > > >it, but someone someday might build using a toolkit that > > >forces the MIME en/decoding and we'll have more interop > > >problems than otherwise. (I personally don't mind whether > > >we omit the MIME encoding or not.) > > > > How about we eliminate the MIME en/decoding? I think the following is > > true. Please correct me where I'm wrong. > > > > - it requires additional processing > > - The CMS-Signed-Data AVP contains a signature for MIME encoded data, > > but not the MIME encoded data itself. This means that the receiver of a > > CMS-Signed-Data AVP must be able to generate the MIME encoded data in > > the exact same manner as the sender. It might be difficult for all > > implementations to perform the MIME encoding exactly the same. > > Identical MIME headers must always be used with the exact same fields, > > spacing, carriage returns, and line feeds. This may be a problem if a > > toolkit adds header information automatically. > > - I don't think my toolkit requires it ;-) > > > > Does anyone out there require that the MIME en/decoding be performed? > > > > Thanks for considering this, > > Don > > > > > > > > > > -- ____________________________________________________________ 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 Fri Oct 19 13:38:47 2001 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 NAA25561 for ; Fri, 19 Oct 2001 13:38:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27400912BC; Fri, 19 Oct 2001 13:38:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4EBA912BE; Fri, 19 Oct 2001 13:38: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 B66A9912BC for ; Fri, 19 Oct 2001 13:38:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8ED295DDC8; Fri, 19 Oct 2001 13:38:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 314455DD97 for ; Fri, 19 Oct 2001 13:38:24 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9JHcN002333 for ; Fri, 19 Oct 2001 12:38:23 -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 f9JHcMF26331 for ; Fri, 19 Oct 2001 12:38:23 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA09723 for ; Fri, 19 Oct 2001 12:38:22 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id MAA14780 for ; Fri, 19 Oct 2001 12:38:18 -0500 (CDT) Message-ID: <001a01c158c4$d8379480$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: References: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80C@CMS3> Subject: [AAA-WG]: Addendum to test specification Date: Fri, 19 Oct 2001 10:37:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, We have added a small section at the end of the test specification for the upcoming bakeoff. This addendum serves to identify additional parameters or modifications that have been discussed to consensus on the AAA WG mailing list subsequent to the release of the alpha versions of the drafts. This section is intended solely to facilitate better interoperability during this event, and in no way constitutes formal modifications to the alpha drafts. Please feel free to email us with any additional items which may have been omitted. -Kev From owner-aaa-wg@merit.edu Fri Oct 19 14:13:59 2001 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 OAA26547 for ; Fri, 19 Oct 2001 14:13:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24151912B0; Fri, 19 Oct 2001 14:13:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7DF9912C0; Fri, 19 Oct 2001 14:13: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 C583B912B0 for ; Fri, 19 Oct 2001 14:13:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F3105DDAD; Fri, 19 Oct 2001 14:13:44 -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 1ED355DD97 for ; Fri, 19 Oct 2001 14:13:44 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9JIDhY00155; Fri, 19 Oct 2001 13:13:43 -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 f9JIDhX12976; Fri, 19 Oct 2001 13:13:43 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA12137; Fri, 19 Oct 2001 13:13:42 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id NAA15426; Fri, 19 Oct 2001 13:13:38 -0500 (CDT) Message-ID: <002501c158c9$c85a33b0$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "David Frascone" , References: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80C@CMS3> <001a01c158c4$d8379480$869f558a@ew.us.am.ericsson.se> <20011019132128.C18649@newman.frascone.com> Subject: Re: [AAA-WG]: Addendum to test specification Date: Fri, 19 Oct 2001 11:13:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The link to the test spec is: http://standards.ericsson.net/diameter-bake-off/diameter_testspec.html ----- Original Message ----- From: "David Frascone" To: "Kevin Purser" Sent: Friday, October 19, 2001 11:21 AM Subject: Re: [AAA-WG]: Addendum to test specification > A link would be nice :) > > On Fri, Oct 19, 2001 at 10:37:59AM -0700, Kevin Purser wrote: > > All, > > > > We have added a small section at the end of the test specification for the > > upcoming bakeoff. This addendum serves to identify additional parameters or > > modifications that have been discussed to consensus on the AAA WG mailing > > list subsequent to the release of the alpha versions of the drafts. This > > section is intended solely to facilitate better interoperability during this > > event, and in no way constitutes formal modifications to the alpha drafts. > > Please feel free to email us with any additional items which may have been > > omitted. > > > > -Kev > > > > > From owner-aaa-wg@merit.edu Sat Oct 20 16:57:52 2001 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 QAA19055 for ; Sat, 20 Oct 2001 16:57:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD39391206; Sat, 20 Oct 2001 16:57:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF2EF9120A; Sat, 20 Oct 2001 16:57: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 9ECF891206 for ; Sat, 20 Oct 2001 16:57:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C9225DDCB; Sat, 20 Oct 2001 16:57:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E667F5DD92 for ; Sat, 20 Oct 2001 16:57:34 -0400 (EDT) Received: (qmail 11722 invoked by uid 500); 20 Oct 2001 20:42:13 -0000 Date: Sat, 20 Oct 2001 13:42:12 -0700 From: Pat Calhoun To: haenamu@etri.re.kr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Which case AAA server provide Only Accounting Service to MN? Message-ID: <20011020134212.G11651@charizard.diameter.org> Mail-Followup-To: haenamu@etri.re.kr, aaa-wg@merit.edu References: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80C@CMS3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80C@CMS3>; from haenamu@etri.re.kr on Fri, Oct 19, 2001 at 10:14:05AM +0900 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I have tried to think the following case : > > If MN shares statically the pre-established Security Association with FA > and HA, > AAA server provides only an Accounting Service to MN. > > Is that possible scenario? sure is. The MN doesn't include the MN-AAA auth ext, but the HA is configured to send accounting messages. > Final question : > at MIP network, I want to know which case AAA server provide Only > Accounting Service ? sorry, don't understand the question enough to provide an answer :( PatC From owner-aaa-wg@merit.edu Sun Oct 21 13:10:04 2001 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 NAA15256 for ; Sun, 21 Oct 2001 13:10:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46B9991210; Sun, 21 Oct 2001 13:09:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16AC691213; Sun, 21 Oct 2001 13:09:50 -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 D1D1F91210 for ; Sun, 21 Oct 2001 13:09:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A90E85DDD6; Sun, 21 Oct 2001 13:09:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7E9D25DDD2 for ; Sun, 21 Oct 2001 13:09:48 -0400 (EDT) Received: from phoenix (pm552-05.dialip.mich.net [198.110.22.159]) by aaa.interlinknetworks.com (Postfix) with SMTP id A2DAE74; Sun, 21 Oct 2001 13:09:46 -0400 (EDT) From: "Bob Kopacz" To: "Kevin Purser" , Subject: RE: [AAA-WG]: Addendum to test specification Date: Sun, 21 Oct 2001 13:07:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001a01c158c4$d8379480$869f558a@ew.us.am.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kevin, A couple minor questions: 1. At the bakeoff, for the values of the MIP-Replay-Mode AVP, should we be using the incorrect 0/1/2 values (0=None, 1=Timestamps, 2=Nonces) from draft-ietf-aaa-diameter-mobileip-08-alpha01, or the correct 1/2/3 (1=None, 2=Timestamps, 3=Nonces) values from the upcoming draft-ietf-aaa-diameter-mobileip-08? 2. At the bakeoff, should the Accounting messages be carrying Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets, and Acct-Output-Packets as 32-bit integers or 64-bit integers? Thanks, Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf > Of Kevin Purser > Sent: Friday, October 19, 2001 1:38 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Addendum to test specification > > > All, > > We have added a small section at the end of the test specification for the > upcoming bakeoff. This addendum serves to identify additional parameters or > modifications that have been discussed to consensus on the AAA WG mailing > list subsequent to the release of the alpha versions of the drafts. This > section is intended solely to facilitate better interoperability during this > event, and in no way constitutes formal modifications to the alpha drafts. > Please feel free to email us with any additional items which may have been > omitted. > > -Kev From owner-aaa-wg@merit.edu Sun Oct 21 13:46:34 2001 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 NAA15623 for ; Sun, 21 Oct 2001 13:46:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B46991213; Sun, 21 Oct 2001 13:45:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F44491224; Sun, 21 Oct 2001 13:45:33 -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 0A8FF91213 for ; Sun, 21 Oct 2001 13:45:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEAD05DDD2; Sun, 21 Oct 2001 13:45:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 8B3BB5DDBA for ; Sun, 21 Oct 2001 13:45:31 -0400 (EDT) Received: from phoenix (pm552-09.dialip.mich.net [198.110.22.163]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6473774; Sun, 21 Oct 2001 13:45:29 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: Handling of Duplicate Requests Date: Sun, 21 Oct 2001 13:43:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <20011017045836.B30911@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Pat Calhoun > Sent: Wednesday, October 17, 2001 7:59 AM > To: Bob Kopacz > Cc: Pat Calhoun; aaa-wg > Subject: [AAA-WG]: Re: Handling of Duplicate Requests > > well, unlike RADIUS, identifiers aren't changed just because a bit is > twiddled in the packet. That's a fundamental difference since it makes it > much easier to interpret duplicates. > > The down side (as you state above) is that a future request could have a > different set of AVPs. However, I would claim that once you've asked for a > set of features, I don't understand why you'd want to change your mind > mid-course. > > Given the above, is your concern answered? I think, yes. I was blathering on a bit, sorry. What I was trying to ask, and what I am no longer asking, was: 1. When a home server receives a duplicate request, i.e. a request whose Origin-Host and End-to-End-Identifier match a recent previously-received request, should it examine the AVPs from the duplicate request to confirm it is really a duplicate? [Answer:no]. 2. If the AAAH detected a duplicate is not really a duplicate, how should it handle this error? [Answer: not a question anymore, since the AAAH doesn't make this check]. 3. A theoretical question: Is it possible for a duplicate to not really be a duplicate for legitimate reasons, such as one proxy modifying the original request in one way, and a second proxy modifying the retransmission in a different way? [Answer: even if yes, any changes are inconsequential]. 4. Should duplicate checking be done only by home servers, or should proxies also check their pending transaction queue for duplicates? [Answer: only home servers]. 5. If a home server recieves a duplicate, while the original is still pending, then should it send an answer for both the original and the duplicate? [Answer: yes] Thanks, Bob K. > PatC > On Mon, Oct 15, 2001 at 04:51:33PM -0400, Bob Kopacz wrote: > > Hi Pat, > > > > The Diameter base draft mentions a few things about how the AAA home > > server handles duplicate request messages, but leaves much to the > > implementer's imagination. Maybe this is by design, but maybe the > > AAAH's actions should be specified a little more. > > > > Here's the kinds of things I've been thinking about: > > > > Suppose a home server receives a duplicate request, i.e. a request > > whose Origin-Host and End-to-End-Identifier match a recent > > previously-received request. > > > > There's a couple cases here: > > > > 1. The previously-received request has already been replied to. > > > > or > > > > 2. The previously-received request hasn't yet been replied to. The > > server is waiting for something, e.g. the original request is an AMR, > > the server has sent an HAR to the Home Agent, but hasn't gotten the > > HAA back yet. > > > > > > And for each of these two cases, there are a couple of cases: > > > > a. The duplicate request is really a duplicate. > > > > b. The duplicate request is not really a duplicate: > > -- Even though the Origin-Host and End-to-End-Identifiers match, the > > "duplicate" differs in some essential way, e.g. the Session-Id or > > User-Name differs from the previously-received request. > > -- Or maybe the duplicate differs in some minor but legitimate way. > > (Maybe the following aren't real-world examples, but here goes...) > > Example#1: An FA is connected to two AAAFs. The FA sends his AMR to > > AAAF1, then fails over and resends his request to AAAF2. AAAF1 and > > AAAF2 twiddle the MIP-Feature-Vector bits differently, and forward the > > AMR to the AAAH. > > Example#2: A NAS is connected to two local proxies. The NAS sends his > > request to AAAP1, then fails over and resends this request to AAAP2. > > AAAP1 and AAAP2 modify the request message differently because of > > slightly different policy. > > > > > > Does the following make sense for the AAA Home Server?: > > > > Case 1a: is easy, just send back pretty much the same answer. > > > > Case 1b: Send negative reply for duplicate, Result-Code=[TBD]. Send > > an Abort-Session-Request for the original (iff original answer was a > > SUCCESS). > > > > Case 2a: Is the expectation here that when the server can finally > > respond to the original request, that it responds to the duplicate at > > the same time? > > > > Case 2b: Send a negative reply for both the original request and the > > duplicate, Result-Code=[TBD]. > > > > Bob K. > > > From owner-aaa-wg@merit.edu Sun Oct 21 15:46:26 2001 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 PAA16267 for ; Sun, 21 Oct 2001 15:46:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3686991226; Sun, 21 Oct 2001 15:45:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0893491229; Sun, 21 Oct 2001 15:45: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 DE0A791226 for ; Sun, 21 Oct 2001 15:45:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3C575DDD4; Sun, 21 Oct 2001 15:45:47 -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 24FF35DDA8 for ; Sun, 21 Oct 2001 15:45:47 -0400 (EDT) Received: (qmail 21299 invoked by uid 500); 21 Oct 2001 20:02:43 -0000 Date: Sun, 21 Oct 2001 15:02:43 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: TCP streaming problem Message-ID: <20011021150243.C21177@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I have an issue with how reserved bits and invalid attribute lengths are handled. In the spec (08-alpha1), a server is supposed to return a protocol error if it receives a packet that is malformed. But, I do not think that simply returning an error is a good idea (Or, it's not a good idea when TCP is the transport . . . see below) Let's suppose the following situation: As a result of either buggy code, or in an attempt to be malicious, I send some random bytes to a diameter server. Of course, when the errors are detected (via reserved bits set, or invalid avp lengths), the message (up to that point?) is returned with an error. But then what? How would the server find the start of the next (hopefully valid) diameter message? With SCTP (or the old UDP), this problem was moot, since the messages were guaranteed to arrive in one packet all together. But TCP is a stream, and finding the next start of message would be close to impossible. So, I prepose, in the event of a protocol error that might be caused by a malicious or broken server, the connection be immediately dropped. (An error packet could be sent first, I guess). I think this should be a MUST for TCP, SCTP would be up to the wg. Comments? From owner-aaa-wg@merit.edu Sun Oct 21 17:41:55 2001 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 RAA17430 for ; Sun, 21 Oct 2001 17:41:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2909891229; Sun, 21 Oct 2001 17:41:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB1B89122A; Sun, 21 Oct 2001 17:41:33 -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 B212091229 for ; Sun, 21 Oct 2001 17:41:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 857815DDAC; Sun, 21 Oct 2001 17:41:32 -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 10C595DD8D for ; Sun, 21 Oct 2001 17:41:32 -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 f9LLfVY20275; Sun, 21 Oct 2001 16:41:31 -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 f9LLfV607760; Sun, 21 Oct 2001 16:41:31 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA04954; Sun, 21 Oct 2001 16:41:30 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id QAA09834; Sun, 21 Oct 2001 16:41:26 -0500 (CDT) Message-ID: <001f01c15a79$249f0af0$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Bob Kopacz" , References: Subject: Re: [AAA-WG]: Addendum to test specification Date: Sun, 21 Oct 2001 14:41:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, > > 1. At the bakeoff, for the values of the MIP-Replay-Mode AVP, should > we be using the incorrect 0/1/2 values (0=None, 1=Timestamps, > 2=Nonces) from draft-ietf-aaa-diameter-mobileip-08-alpha01, or the > correct 1/2/3 (1=None, 2=Timestamps, 3=Nonces) values from the > upcoming draft-ietf-aaa-diameter-mobileip-08? > I remember this one being discussed and agreed that it should be 1/2/3, so I'll go ahead and add this one to the test spec. > 2. At the bakeoff, should the Accounting messages be carrying > Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets, and > Acct-Output-Packets as 32-bit integers or 64-bit integers? > Did we ever reach a concensus on this one? -Kev > Thanks, > Bob K. > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf > > Of Kevin Purser > > Sent: Friday, October 19, 2001 1:38 PM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Addendum to test specification > > > > > > All, > > > > We have added a small section at the end of the test specification for the > > upcoming bakeoff. This addendum serves to identify additional parameters or > > modifications that have been discussed to consensus on the AAA WG mailing > > list subsequent to the release of the alpha versions of the drafts. This > > section is intended solely to facilitate better interoperability during this > > event, and in no way constitutes formal modifications to the alpha drafts. > > Please feel free to email us with any additional items which may have been > > omitted. > > > > -Kev > From owner-aaa-wg@merit.edu Sun Oct 21 21:32:03 2001 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 VAA19224 for ; Sun, 21 Oct 2001 21:32:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 74AB991216; Sun, 21 Oct 2001 21:31:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A7299122D; Sun, 21 Oct 2001 21:31: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 0BA1791216 for ; Sun, 21 Oct 2001 21:31:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E69505DDD7; Sun, 21 Oct 2001 21:31:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 6F7B35DDBE for ; Sun, 21 Oct 2001 21:31:39 -0400 (EDT) Received: by CMS3 with Internet Mail Service (5.5.2653.19) id <47HK7DBT>; Mon, 22 Oct 2001 10:29:18 +0900 Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80F@CMS3> From: haenamu@etri.re.kr To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: [RE] Re: [AAA-WG]: Which case AAA server provide Only Accounting Service to MN? Date: Mon, 22 Oct 2001 10:29:16 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15A98.F6C21D50" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15A98.F6C21D50 Content-Type: text/plain; charset="euc-kr" >> I have tried to think the following case : >> >> If MN shares statically the pre-established Security Association with FA >> and HA, >> AAA server provides only an Accounting Service to MN. >> >> Is that possible scenario? >sure is. The MN doesn't include the MN-AAA auth ext, but the HA is configured to send accounting messages. you said HA send accounting message. Does HA need to send Accounting Message? I think FA can know accounting-output-packets and -input-packets but, HA can calculate only accounting-input-packets. If Both of FA and HA sends Accounting message to AAAH, AAAH can't compare input-accounting information from HA with input- accounting information from FA. And because of network delay and topology, output-accounting information from both sides(FA, HA) may be different. I think that AAAH can't provide settlement services properly, owing to the above reasons. What do you think about only FA send accounting message? Is that enough? >> Final question : >> at MIP network, I want to know which case AAA server provide Only >> Accounting Service ? >sorry, don't understand the question enough to provide an answer :( >PatC My original intend is the same. Two questions are the same things never mind the second question. ------_=_NextPart_001_01C15A98.F6C21D50 Content-Type: text/html; charset="euc-kr" [RE] Re: [AAA-WG]: Which case AAA server provide Only Accounting Service to MN?

>> I have tried to think the following case :
>>  
>> If MN shares statically the pre-established Security Association with FA
>> and HA,
>> AAA server provides only an Accounting Service to MN.
>>  
>> Is that possible scenario?

>sure is. The MN doesn't include the MN-AAA auth ext, but the HA is configured
to send accounting messages.

you said HA send accounting message.
Does HA need to send Accounting Message?

I think
     FA can know accounting-output-packets and -input-packets
     but, HA can calculate only accounting-input-packets.

If Both of FA and HA sends Accounting message to AAAH,
AAAH can't compare input-accounting information from HA with input-accounting information from FA.
And because of network delay and topology,
output-accounting information from both sides(FA, HA) may be different.

I think that AAAH can't provide settlement services properly, owing to the above reasons.

What do you think about only FA send accounting message? Is that enough?


>> Final question :
>>         at MIP network, I want to know which case AAA server provide Only
>> Accounting Service ?

>sorry, don't understand the question enough to provide an answer :(
>PatC


My original intend is the same. Two questions are the same things
never mind the second question.






    



------_=_NextPart_001_01C15A98.F6C21D50-- From owner-aaa-wg@merit.edu Mon Oct 22 10:15:04 2001 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 KAA17595 for ; Mon, 22 Oct 2001 10:15:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C11BC91235; Mon, 22 Oct 2001 10:14:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9315491236; Mon, 22 Oct 2001 10:14: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 0F80291235 for ; Mon, 22 Oct 2001 10:14:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBD825DDF6; Mon, 22 Oct 2001 10:14:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id AB0815DDD1 for ; Mon, 22 Oct 2001 10:14:28 -0400 (EDT) Received: from phoenix (pm552-18.dialip.mich.net [198.110.22.172]) by aaa.interlinknetworks.com (Postfix) with SMTP id E7B2674; Mon, 22 Oct 2001 10:14:26 -0400 (EDT) From: "Bob Kopacz" To: "Kevin Purser" , Subject: RE: [AAA-WG]: Addendum to test specification Date: Mon, 22 Oct 2001 10:12:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001f01c15a79$249f0af0$869f558a@ew.us.am.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kevin, > -----Original Message----- > From: Kevin Purser [mailto:kevin.purser@ericsson.com] > Sent: Sunday, October 21, 2001 5:41 PM > To: Bob Kopacz; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Addendum to test specification > > Bob, > > > 1. At the bakeoff, for the values of the MIP-Replay-Mode AVP, should > > we be using the incorrect 0/1/2 values (0=None, 1=Timestamps, > > 2=Nonces) from draft-ietf-aaa-diameter-mobileip-08-alpha01, or the > > correct 1/2/3 (1=None, 2=Timestamps, 3=Nonces) values from the > > upcoming draft-ietf-aaa-diameter-mobileip-08? > > > > I remember this one being discussed and agreed that it should be 1/2/3, so > I'll go ahead and add this one to the test spec. > > > 2. At the bakeoff, should the Accounting messages be carrying > > Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets, and > > Acct-Output-Packets as 32-bit integers or 64-bit integers? > > Did we ever reach a concensus on this one? I don't know. An issue (#182) was posted to make these attributes 32-bits, as they are existing RADIUS attributes. The issue hasn't been discussed or rejected. The issue is posted, though, in the "resolved" section rather than the "open issues" section, so I took that to mean that it has either been quietly accepted or is leaning that way. Given that, I'd guess we'll be seeing these attributes as 64-bits at the bakeoff, per the draft-08-alpha01's. I just want to set up my dictionary correctly for the bakeoff; that's why I asked the question. Bob K. > -Kev > > > Thanks, > > Bob K. > > From owner-aaa-wg@merit.edu Mon Oct 22 11:21:56 2001 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 LAA19740 for ; Mon, 22 Oct 2001 11:21:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EA929123B; Mon, 22 Oct 2001 11:21:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5058E9123C; Mon, 22 Oct 2001 11:21:40 -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 5CFC79123B for ; Mon, 22 Oct 2001 11:21:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4026A5DDF8; Mon, 22 Oct 2001 11:21:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E6D025DDF7 for ; Mon, 22 Oct 2001 11:21:37 -0400 (EDT) Received: (qmail 26113 invoked by uid 500); 22 Oct 2001 15:06:14 -0000 Date: Mon, 22 Oct 2001 08:06:14 -0700 From: Pat Calhoun To: haenamu@etri.re.kr Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [RE] Re: [AAA-WG]: Which case AAA server provide Only Accounting Service to MN? Message-ID: <20011022080614.B26094@charizard.diameter.org> Mail-Followup-To: haenamu@etri.re.kr, pcalhoun@diameter.org, aaa-wg@merit.edu References: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80F@CMS3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E80F@CMS3>; from haenamu@etri.re.kr on Mon, Oct 22, 2001 at 10:29:16AM +0900 Sender: owner-aaa-wg@merit.edu Precedence: bulk > >sure is. The MN doesn't include the MN-AAA auth ext, but the HA is > configured > to send accounting messages. > > you said HA send accounting message. > Does HA need to send Accounting Message? if that's what it is configured to do, then yes. > I think > FA can know accounting-output-packets and -input-packets > but, HA can calculate only accounting-input-packets. correct, unless reverse tunneling is enabled. > If Both of FA and HA sends Accounting message to AAAH, > AAAH can't compare input-accounting information from HA with input- > accounting information from FA. > And because of network delay and topology, > output-accounting information from both sides(FA, HA) may be different. correct. > I think that AAAH can't provide settlement services properly, owing to the > above reasons. > > What do you think about only FA send accounting message? Is that enough? it's a business decision, and not a technical one, IMHO. PatC From owner-aaa-wg@merit.edu Mon Oct 22 11:25:13 2001 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 LAA19850 for ; Mon, 22 Oct 2001 11:25:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7396F9123C; Mon, 22 Oct 2001 11:24:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 459CB9123D; Mon, 22 Oct 2001 11:24:54 -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 0682F9123C for ; Mon, 22 Oct 2001 11:24:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D98B95DDFA; Mon, 22 Oct 2001 11:24:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4F0BE5DDF7 for ; Mon, 22 Oct 2001 11:24:52 -0400 (EDT) Received: (qmail 26136 invoked by uid 500); 22 Oct 2001 15:09:28 -0000 Date: Mon, 22 Oct 2001 08:09:28 -0700 From: Pat Calhoun To: Bob Kopacz Cc: Kevin Purser , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Addendum to test specification Message-ID: <20011022080928.D26094@charizard.diameter.org> Mail-Followup-To: Bob Kopacz , Kevin Purser , aaa-wg@merit.edu References: <001f01c15a79$249f0af0$869f558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BKopacz@InterlinkNetworks.com on Mon, Oct 22, 2001 at 10:12:06AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I don't know. An issue (#182) was posted to make these attributes 32-bits, > as they are existing RADIUS attributes. The issue hasn't been discussed > or rejected. The issue is posted, though, in the "resolved" section > rather than the "open issues" section, so I took that to mean that > it has either been quietly accepted or is leaning that way. the fix was obvious, so I just cleaned up the document. If you believe that the fix is not correct, please let me know. PatC From owner-aaa-wg@merit.edu Mon Oct 22 11:32:39 2001 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 LAA20043 for ; Mon, 22 Oct 2001 11:32:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3CB791220; Mon, 22 Oct 2001 11:32:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DA299123D; Mon, 22 Oct 2001 11:32:09 -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 893D091220 for ; Mon, 22 Oct 2001 11:32:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6811C5DDF6; Mon, 22 Oct 2001 11:32:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0E7D55DDCC for ; Mon, 22 Oct 2001 11:32:08 -0400 (EDT) Received: (qmail 26167 invoked by uid 500); 22 Oct 2001 15:16:44 -0000 Date: Mon, 22 Oct 2001 08:16:44 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF specification Message-ID: <20011022081644.E26094@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B0@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B0@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Thu, Oct 18, 2001 at 04:33:55PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 18, 2001 at 04:33:55PM +0300, jaakko.rajaniemi@nokia.com wrote: > > Submitter name: Jaakko Rajaniemi > Submitter email address: jaakko.rajaniemi@nokia.com > Date first submitted: 2001-10-18 > Document: base > Comment type: T > Priority: 1 > Section: 3.2 > Rationale/Explanation of issue: > > The section 3.2 "Command Code ABNF specification" contains the ABNF > specification which must be followed when contructing Diameter Command > Codes. It does not contain a possibility to use the alternatives (see > RFC2243, section 3.2) when defining the AVPs included into the commands. > This is very restrictive and does not allow enough flexibility when defining > command codes and therefore it is proposed that the alternatives is > included. > Requested change: > > Include following description to the avp-spec in the section 3.2: > > avp-spec = diameter-name *("/" diameter-name) > ; The avp-spec has to be an AVP Name, > ; defined in the base or extended Diameter > ; specifications. The avp-spec may contain AVP Names > ; which are alternatives, see RFC 2234 section 3.2. What this section proposes is that each AVP name have an alternate name, increasing the confusion in the protocol. Why does the Diameter protocol require alternate names for AVPs? PatC From owner-aaa-wg@merit.edu Mon Oct 22 11:35:02 2001 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 LAA20100 for ; Mon, 22 Oct 2001 11:35:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6776B9123D; Mon, 22 Oct 2001 11:34:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 355DF9123E; Mon, 22 Oct 2001 11:34: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 067F19123D for ; Mon, 22 Oct 2001 11:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E11235DDF6; Mon, 22 Oct 2001 11:34:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9DD785DDCC for ; Mon, 22 Oct 2001 11:34:43 -0400 (EDT) Received: (qmail 26208 invoked by uid 500); 22 Oct 2001 15:19:20 -0000 Date: Mon, 22 Oct 2001 08:19:20 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 188: NAS-Key-Binding and Ciphersuite Negotiation Message-ID: <20011022081919.A26194@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, This issue proposes that the NAS-Key-Binding be optional. Below is the new ABNF for the NAS-Session-Key AVP: NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key } { NAS-Key-Data } [ NAS-Key-Binding ] [ NAS-Key-Lifetime ] [ NAS-IV ] * [ AVP ] Thanks, PatC From owner-aaa-wg@merit.edu Mon Oct 22 11:36:42 2001 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 LAA20166 for ; Mon, 22 Oct 2001 11:36:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A40D09123E; Mon, 22 Oct 2001 11:36:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05B6D9123F; Mon, 22 Oct 2001 11:36: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 018209123E for ; Mon, 22 Oct 2001 11:36:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC91E5DDF6; Mon, 22 Oct 2001 11:36:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 51EC85DDCC for ; Mon, 22 Oct 2001 11:36:25 -0400 (EDT) Received: (qmail 26223 invoked by uid 500); 22 Oct 2001 15:21:01 -0000 Date: Mon, 22 Oct 2001 08:21:01 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 190: NAS-Session-Key and Session Master Keys Message-ID: <20011022082101.B26194@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk This issue requests new keying types. Below is the proposed text for this issue. The NAS-Key-Type AVP (AVP Code 407) is of type Enumerated, and specifies how the key is to be used. The following values are supported: CIPHER_KEY 1 The key is used to encrypt data INTEGRITY_KEY 2 The key is used to authenticate the data MASTER_CIPHER_KEY 3 The master cipher is used to derive further cipher keys MASTER_INTEGRITY_KEY 4 The master integrity is used to derive further integrity keys MASTER_KEY 5 The master can be used to derive any type of keys, but is not guaranteed to be useful for any particular crypto system. Additional processing will be required, and is not specified in this document. Comments welcomed, PatC From owner-aaa-wg@merit.edu Mon Oct 22 12:26:56 2001 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 MAA22023 for ; Mon, 22 Oct 2001 12:26:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51FA291242; Mon, 22 Oct 2001 12:23:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34CCD91244; Mon, 22 Oct 2001 12:23: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 51CBB91243 for ; Mon, 22 Oct 2001 12:23:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 380C35DDAA; Mon, 22 Oct 2001 12:23:25 -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 7F4E75DD9D for ; Mon, 22 Oct 2001 12:23:24 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9MGO1f17863 for ; Mon, 22 Oct 2001 19:24:01 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Oct 2001 19:23:23 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 22 Oct 2001 19:23:23 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA66@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Mon, 22 Oct 2001 19:23:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, > What this section proposes is that each AVP name have an > alternate name, > increasing the confusion in the protocol. > > Why does the Diameter protocol require alternate names for AVPs? The proposal allows to contruct commands where it is required (or fixed or optional) to include one of the alternatives in the ABNF definition. This is not like allowing to have alternate names for AVPs for no reason at all. For example, in the following command definition: Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > { User-Name } { Origin-Host } { example1_AVP / example2_AVP } * [ AVP ] The Example-Request command MUST have either example1_AVP or example2_AVP. These type of definitions are quite common but they are not possible with the current command code ABNF specification. Or as in the following example below, the Example-Request command can optionally have either example1_AVP or example2_AVP and nothing else. Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > { User-Name } { Origin-Host } [ example1_AVP / example2_AVP ] > > PatC Best Regards, Jaakko > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 22 October, 2001 18:17 > To: Rajaniemi Jaakko (NET/Espoo) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command > Code ABNF > specification > > > On Thu, Oct 18, 2001 at 04:33:55PM +0300, > jaakko.rajaniemi@nokia.com wrote: > > > > Submitter name: Jaakko Rajaniemi > > Submitter email address: jaakko.rajaniemi@nokia.com > > Date first submitted: 2001-10-18 > > Document: base > > Comment type: T > > Priority: 1 > > Section: 3.2 > > Rationale/Explanation of issue: > > > > The section 3.2 "Command Code ABNF specification" contains the ABNF > > specification which must be followed when contructing > Diameter Command > > Codes. It does not contain a possibility to use the > alternatives (see > > RFC2243, section 3.2) when defining the AVPs included into > the commands. > > This is very restrictive and does not allow enough > flexibility when defining > > command codes and therefore it is proposed that the alternatives is > > included. > > Requested change: > > > > Include following description to the avp-spec in the section 3.2: > > > > avp-spec = diameter-name *("/" diameter-name) > > ; The avp-spec has to be an AVP Name, > > ; defined in the base or extended Diameter > > ; specifications. The avp-spec may > contain AVP Names > > ; which are alternatives, see RFC 2234 > section 3.2. > > What this section proposes is that each AVP name have an > alternate name, > increasing the confusion in the protocol. > > Why does the Diameter protocol require alternate names for AVPs? > > PatC > From owner-aaa-wg@merit.edu Mon Oct 22 16:02:22 2001 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 QAA28609 for ; Mon, 22 Oct 2001 16:02:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8FAD691254; Mon, 22 Oct 2001 16:01:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B3EC91256; Mon, 22 Oct 2001 16:01:37 -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 E3F5F91254 for ; Mon, 22 Oct 2001 16:01:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C42605DDD0; Mon, 22 Oct 2001 16:01:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 62CAE5DD9B for ; Mon, 22 Oct 2001 16:01:35 -0400 (EDT) Received: (qmail 26853 invoked by uid 500); 22 Oct 2001 19:46:11 -0000 Date: Mon, 22 Oct 2001 12:46:11 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Message-ID: <20011022124611.B26838@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu References: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA66@esebe013.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA66@esebe013.NOE.Nokia.com>; from jaakko.rajaniemi@nokia.com on Mon, Oct 22, 2001 at 07:23:16PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Ah, I like it. Others? PatC On Mon, Oct 22, 2001 at 07:23:16PM +0300, jaakko.rajaniemi@nokia.com wrote: > Hi, > > > What this section proposes is that each AVP name have an > > alternate name, > > increasing the confusion in the protocol. > > > > Why does the Diameter protocol require alternate names for AVPs? > > The proposal allows to contruct commands where it is required (or fixed or > optional) to include one of the alternatives in the ABNF definition. This is > not like allowing to have alternate names for AVPs for no reason at all. For > example, in the following command definition: > > Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > > { User-Name } > { Origin-Host } > { example1_AVP / example2_AVP } > * [ AVP ] > > The Example-Request command MUST have either example1_AVP or example2_AVP. > These type of definitions are quite common but they are not possible with > the current command code ABNF specification. > > Or as in the following example below, the Example-Request command can > optionally have either example1_AVP or example2_AVP and nothing else. > > Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > > { User-Name } > { Origin-Host } > [ example1_AVP / example2_AVP ] > > > > > PatC > > Best Regards, Jaakko > > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: 22 October, 2001 18:17 > > To: Rajaniemi Jaakko (NET/Espoo) > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command > > Code ABNF > > specification > > > > > > On Thu, Oct 18, 2001 at 04:33:55PM +0300, > > jaakko.rajaniemi@nokia.com wrote: > > > > > > Submitter name: Jaakko Rajaniemi > > > Submitter email address: jaakko.rajaniemi@nokia.com > > > Date first submitted: 2001-10-18 > > > Document: base > > > Comment type: T > > > Priority: 1 > > > Section: 3.2 > > > Rationale/Explanation of issue: > > > > > > The section 3.2 "Command Code ABNF specification" contains the ABNF > > > specification which must be followed when contructing > > Diameter Command > > > Codes. It does not contain a possibility to use the > > alternatives (see > > > RFC2243, section 3.2) when defining the AVPs included into > > the commands. > > > This is very restrictive and does not allow enough > > flexibility when defining > > > command codes and therefore it is proposed that the alternatives is > > > included. > > > Requested change: > > > > > > Include following description to the avp-spec in the section 3.2: > > > > > > avp-spec = diameter-name *("/" diameter-name) > > > ; The avp-spec has to be an AVP Name, > > > ; defined in the base or extended Diameter > > > ; specifications. The avp-spec may > > contain AVP Names > > > ; which are alternatives, see RFC 2234 > > section 3.2. > > > > What this section proposes is that each AVP name have an > > alternate name, > > increasing the confusion in the protocol. > > > > Why does the Diameter protocol require alternate names for AVPs? > > > > PatC > > From owner-aaa-wg@merit.edu Tue Oct 23 09:41:30 2001 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 JAA01805 for ; Tue, 23 Oct 2001 09:41:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3ADFA91268; Tue, 23 Oct 2001 09:41:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AAB99126A; Tue, 23 Oct 2001 09:41: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 EC8A691268 for ; Tue, 23 Oct 2001 09:41:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C387E5DDB4; Tue, 23 Oct 2001 09:41: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 D85EB5DDB1 for ; Tue, 23 Oct 2001 09:41:17 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9NDfsf11970 for ; Tue, 23 Oct 2001 16:41:54 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Oct 2001 16:41:15 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 23 Oct 2001 16:41:06 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA68@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Tue, 23 Oct 2001 16:40:56 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, The same change would be nice to have in the Grouped AVP definition also. This would mean that in the section 4.5 "Grouped AVP Values" and the avp-spec definition in there is modified in the same way: avp-spec = name-fmt *("/" name-fmt) ; The avp-spec has to be an AVP Name, defined ; in the base or extended Diameter ; specifications. The avp-spec may contain AVP Names ; which are alternatives, see RFC 2234 section 3.2 This would allow the same type of ABNF grammar to be used with the Command codes and the Grouped AVPs. Best Regards, Jaakko > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 22 October, 2001 22:46 > To: Rajaniemi Jaakko (NET/Espoo) > Cc: pcalhoun@diameter.org; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command > Code ABNF > sp ecification > > > Ah, I like it. > > Others? > > PatC > On Mon, Oct 22, 2001 at 07:23:16PM +0300, > jaakko.rajaniemi@nokia.com wrote: > > Hi, > > > > > What this section proposes is that each AVP name have an > > > alternate name, > > > increasing the confusion in the protocol. > > > > > > Why does the Diameter protocol require alternate names for AVPs? > > > > The proposal allows to contruct commands where it is > required (or fixed or > > optional) to include one of the alternatives in the ABNF > definition. This is > > not like allowing to have alternate names for AVPs for no > reason at all. For > > example, in the following command definition: > > > > Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > > > { User-Name } > > { Origin-Host } > > { example1_AVP / example2_AVP } > > * [ AVP ] > > > > The Example-Request command MUST have either example1_AVP > or example2_AVP. > > These type of definitions are quite common but they are not > possible with > > the current command code ABNF specification. > > > > Or as in the following example below, the Example-Request > command can > > optionally have either example1_AVP or example2_AVP and > nothing else. > > > > Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > > > { User-Name } > > { Origin-Host } > > [ example1_AVP / example2_AVP ] > > > > > > > > PatC > > > > Best Regards, Jaakko > > > > > -----Original Message----- > > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: 22 October, 2001 18:17 > > > To: Rajaniemi Jaakko (NET/Espoo) > > > Cc: aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command > > > Code ABNF > > > specification > > > > > > > > > On Thu, Oct 18, 2001 at 04:33:55PM +0300, > > > jaakko.rajaniemi@nokia.com wrote: > > > > > > > > Submitter name: Jaakko Rajaniemi > > > > Submitter email address: jaakko.rajaniemi@nokia.com > > > > Date first submitted: 2001-10-18 > > > > Document: base > > > > Comment type: T > > > > Priority: 1 > > > > Section: 3.2 > > > > Rationale/Explanation of issue: > > > > > > > > The section 3.2 "Command Code ABNF specification" > contains the ABNF > > > > specification which must be followed when contructing > > > Diameter Command > > > > Codes. It does not contain a possibility to use the > > > alternatives (see > > > > RFC2243, section 3.2) when defining the AVPs included into > > > the commands. > > > > This is very restrictive and does not allow enough > > > flexibility when defining > > > > command codes and therefore it is proposed that the > alternatives is > > > > included. > > > > Requested change: > > > > > > > > Include following description to the avp-spec in the > section 3.2: > > > > > > > > avp-spec = diameter-name *("/" diameter-name) > > > > ; The avp-spec has to be an AVP Name, > > > > ; defined in the base or > extended Diameter > > > > ; specifications. The avp-spec may > > > contain AVP Names > > > > ; which are alternatives, see RFC 2234 > > > section 3.2. > > > > > > What this section proposes is that each AVP name have an > > > alternate name, > > > increasing the confusion in the protocol. > > > > > > Why does the Diameter protocol require alternate names for AVPs? > > > > > > PatC > > > > From owner-aaa-wg@merit.edu Wed Oct 24 04:08:00 2001 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 EAA18911 for ; Wed, 24 Oct 2001 04:08:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE92A91205; Wed, 24 Oct 2001 04:07:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B92891276; Wed, 24 Oct 2001 04:07: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 3BA0391205 for ; Wed, 24 Oct 2001 04:07:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 096FA5DE09; Wed, 24 Oct 2001 04:07:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 6BAAE5DDB1 for ; Wed, 24 Oct 2001 04:07:45 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22342; Wed, 24 Oct 2001 02:07:44 -0600 (MDT) Received: from vayne (muc-isdn-5 [129.157.164.105]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id KAA14796; Wed, 24 Oct 2001 10:07:42 +0200 (MET DST) Date: Wed, 24 Oct 2001 10:20:22 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF specification To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <84230E60BFCF6B4FB0360BAE4C9B3EB562A7B0@esebe013.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Jaakko, > The section 3.2 "Command Code ABNF specification" contains the ABNF > specification which must be followed when contructing Diameter Command > Codes. This is intentional. Command codes are terminals in Diameter messages. I can't say an AVP is either this or that. > This is very restrictive and does not allow enough flexibility when > defining command codes and therefore it is proposed that the > alternatives is included. Restrictiveness in a type system is good. It makes it clear what you require. Let's say we get things wrong and have to revise a particular diameter application. We just create new AVPs and commands as necessary. Backwards compatibility is assured precisely **because** we have been very strict and very clear about what AVPs mean. First version Revised version ------------- --------------- Application A Application B Command A1 Command A1 Avp A11, A12, A13 Avp A11, A12, B13, B14 Command A2 Command B2 Avp A21, A22 Avp B22 etc. etc. Note the revised version - has a new application id - will reuse command IDs, if possible, but may replace them (A2->B2) - will reuse AVP ids if possible, but may replace them (A13->B13), remove them (A21-> not supported) or invent new ones (A1 uses B14). The result of your change would be much more complicated rules to determine if an AVP was supported for any given application. These rules would get ever more complex as we revised the application. Consider if each AVP in the 'first version' referred to possibly many variants. This aliasing complicates revision, interpretation and reasoning about the specification. I say KISS ('Keep It Simple Standards-cowboys!') > It does not contain a possibility to use the alternatives (see > RFC2243, section 3.2) when defining the AVPs included into the commands. The section you refer to describes how to list alternatives among non-terminals. AVP names are currently terminals and I argue they should stay that way. Erik From owner-aaa-wg@merit.edu Wed Oct 24 13:58:07 2001 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 NAA09244 for ; Wed, 24 Oct 2001 13:58:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F9219127E; Wed, 24 Oct 2001 13:57:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D56F9127F; Wed, 24 Oct 2001 13:57:54 -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 0AD219127E for ; Wed, 24 Oct 2001 13:57:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4F985DDA2; Wed, 24 Oct 2001 13:57:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 44FCC5DD9C for ; Wed, 24 Oct 2001 13:57:52 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA09611 for ; Wed, 24 Oct 2001 18:57:51 +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, 24 Oct 2001 18:54:25 +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 TAA15853; Wed, 24 Oct 2001 19:00:23 +0100 Message-ID: <3BD70129.25E290F8@baltimore.ie> Date: Wed, 24 Oct 2001 18:58:01 +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: aaa-wg@merit.edu Cc: Pat Calhoun , "Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente" Subject: [AAA-WG]: issue 185: CMS-protected AVPs outside a DSA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat's hassling me to help tidy up some issues that are stragglers:-) The text for #185 is below for reference. I think we can close this if we add the following clarification at the end of either section 1.2 or 1.5: "This specification does NOT REQUIRE that a DSA be established before the CMS AVPs are used. For example, a Diameter agent could sign or countersign certain messages as they pass by, or a node might add an additional recipient to a CMS-Encrypted-Data for archival purposes." Regards, Stephen. Issue 185: CMS-protected AVPs outside a DSA Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-24 Reference: Document: CMS-02 Comment type: T Priority: 1 Section: Rationale/Explanation of issue: The CMS application comprises two main "features" (as described in section 2.0): the security feature, which comprises the messages necessary for establishing security associations and the AVPs needed to protect other AVPs; and the proxy feature, made up of the messages that are used to ask a proxy to establish a security association. On the other hand, the CMS draft begins by describing how a security association can be established (sections 1.1 and 1.2). It might looks like as if the CMS draft states that a security association is needed to exchange protected AVPs. But it doesn't actually say it. Another points: - The definition of CMS-Signed-Data AVP (section 6.1) introduces the concept of countersignatures. This attribute allows any Diameter peer to add its own digital signature to an existing CMS-Signed-Data AVPs (but always on the same set of AVPs, the ones with its protection bit set). As far as I understand, this situation could happen when a broker signs AVPs in given Diameter messages that traverse through it. Section 1.3 also describes a "business model" in which two Diameter nodes signs "in parallel" accounting AVPs. It is supposed that those both parties are the participants of a DSA (according to figure 4). The base specification also talks about AVPs being signed by two parties (sections 9.5 and 9.7.1) usually to be forwarded to a third party with settlement purposes (however, it isn't said whether those AVPs would be forwarded using new Diameter messsages). Discussion on issue #150 emphasizes that a digital signature has no actual receiver (that is, a Diameter node can sign anything withour a explicit request within the framework of an established DSA) - The definition of CMS-Encrypted-Data AVP (section 6.2) reviews the concept of RecipientInfo, an attribute of the CMS structure EnvelopedData that allows to encrypt a given set of AVPs for different receivers using an only CMS-Encrypted-Data AVP. Discussion on issue #150 also introduces an example in which a Diameter node has to encrypt some (different) AVPs to two different receivers. Section 6.2 (proposed) says that: If the recipient is not specified in a RecipientInfo, it MAY choose to process the message or return an answer with the Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT" that is, a node can receive a CMS-Encrypted-Data AVP with a receiver different from itself. - As a result of "Questions about AVPs ocurrence" series, it was stated that "The DSAR message MUST NOT be used simply as a convenient certificate distribution protocol without establishing a DSA" (section 4.1). What might imply that a DSA is necessary to include a CMS-Cert AVP. However, section 6.1.7 in base protocol states that: Redirector agents MAY also include the certificate of the servers in the Redirect-Host AVP(s). These certificates are encapsulated in a CMS-Cert AVP [11]. and the same in section 1.3 of CMS: the redirect agent to retrieve the necessary information for it to communicate directly with the home server, which MAY include the home server's certificates. Requested change: a) Clarifying whether CMS-* (that is, CMS-Signed-Data, CMS-Encrypted-Data and CMS-Cert) may be exchanged without an established DSA between the peers. If so, introducing a brief description of scenarios in which no previous DSA is needed (that is, that a node can sign of encrypt AVPs according only to its local policy and not to an explicit DSA) b) Whenever CMS is used in the base draft, describing that functionality in the CMS draft. -- ____________________________________________________________ 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 Oct 24 14:00:25 2001 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 OAA09397 for ; Wed, 24 Oct 2001 14:00:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 694C19127F; Wed, 24 Oct 2001 14:00:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B30691280; Wed, 24 Oct 2001 14: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 1EB7D9127F for ; Wed, 24 Oct 2001 13:59:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 020B95DDA2; Wed, 24 Oct 2001 13:59:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 57B455DD9C for ; Wed, 24 Oct 2001 13:59:58 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA09630 for ; Wed, 24 Oct 2001 18:59:57 +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, 24 Oct 2001 18:56:31 +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 TAA15877; Wed, 24 Oct 2001 19:02:30 +0100 Message-ID: <3BD701A7.5FC93675@baltimore.ie> Date: Wed, 24 Oct 2001 19:00:07 +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: aaa-wg@merit.edu Cc: Pat Calhoun , "Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente" Subject: [AAA-WG]: Issue 180: AAA-Server-Certs Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit And the one other outstanding one: I'd argue that this is a "reject" given my suggested resolution of #185. Stephen. Issue 180: AAA-Server-Certs Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-14 Reference: Document: CMS-02 Comment type: T Priority: 2 Section: 6.6 Rationale/Explanation of issue: It remains unclear for me the meaning of AAA-Server-Certs. As far as I understand, a DSA is established between two Diameter agents (not between an agent and a realm) so that no CMS-protected AVP can come from a node "outside" the DSA. If this supposition is right, including certificates of other home nodes is useless, since the initiator of the DSA wouldn't accept CMS AVPs from a different node although belonging also to the home realm. Requested change: Add clarifying text. -- ____________________________________________________________ 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 Oct 24 14:06:56 2001 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 OAA09695 for ; Wed, 24 Oct 2001 14:06:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DB0191280; Wed, 24 Oct 2001 14:06:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D581991281; Wed, 24 Oct 2001 14:06:44 -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 A0E5091280 for ; Wed, 24 Oct 2001 14:06:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81B345DDA2; Wed, 24 Oct 2001 14:06:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 5A1675DD9C for ; Wed, 24 Oct 2001 14:06:42 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9OI6cC00722; Wed, 24 Oct 2001 20:06:38 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id UAA13520; Wed, 24 Oct 2001 20:06:32 +0200 (MET DST) Message-ID: <3BD7033B.293CD4B6@rioja.ericsson.se> Date: Wed, 24 Oct 2001 20:06:51 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Stephen Farrell wrote: > > And the one other outstanding one: > > I'd argue that this is a "reject" given my suggested > resolution of #185. I've got currently a close deadline. Could you keep this issue as open until Friday? Regards // M.A. From owner-aaa-wg@merit.edu Wed Oct 24 14:24:42 2001 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 OAA10397 for ; Wed, 24 Oct 2001 14:24:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A9A791282; Wed, 24 Oct 2001 14:24:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A48291283; Wed, 24 Oct 2001 14:24:30 -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 3DBAA91282 for ; Wed, 24 Oct 2001 14:24:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 222535DDA2; Wed, 24 Oct 2001 14:24:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 482485DD9C for ; Wed, 24 Oct 2001 14:24:28 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id TAA09801 for ; Wed, 24 Oct 2001 19:24:27 +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, 24 Oct 2001 19:21:01 +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 TAA16151; Wed, 24 Oct 2001 19:26:59 +0100 Message-ID: <3BD70764.11FFA489@baltimore.ie> Date: Wed, 24 Oct 2001 19:24:36 +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: aaa-wg@merit.edu Cc: Pat Calhoun Subject: [AAA-WG]: non-issue issue: MIME encoding in CMS Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, It doesn't have an issue number, but the suggestion to drop the MIME encoding step was raised on the list, was supported and wasn't opposed. (see: http://www.merit.edu/mail.archives/aaa-wg/msg02431.html) I think the changes listed below would be what needs to be done (based on draft-ietf-aaa-diameter-cms-03.alpha01.txt). I'm for making this change - I haven't found a toolkit for which it causes a problem. (OTOH, I'm also ok with not making the change if it causes someone a problem.) Stephen. 1. Replace this bit at the end of 6.0: "All MIME encoded data in this specification MUST use the "application/pkcs7-mime" MIME type." with: "No MIME encoding of binary data is required for this specification. This is different from the use of CMS in S/MIME but is ok since Diameter is a binary protocol and investigation has not shown this to causes problems when using existing CMS & S/MIME toolkits." 2. Delete this bit from the start of 6.1: "...and MUST then be encoded according to MIME encoding rules specified in [16,17]." 3. Delete this line from top of page 24 (section 6.2): " - MIME encoded (according to the rules specified in [16,17])," 4. Replace this bit from 6.3: " - MIME(x) represents the MIME encoding of x" with " - The "|" character represents catenation" 5. Replace this bit of 6.3 (MIME->"|" and formating) "The resulting message will look like: AVP1='P is set', EnvelopedData-fnc(MIME(s,t,e),P) AVP2='P is set', EnvelopedData-fnc(MIME(s,e,p,h),A) AVP3='P is set', e' AVP4='P is clear', n AVP5='P is clear', SignedData(T)" with: "The resulting message will look like: AVP1='P is set', EnvelopedData-fnc(s|t|e,P) AVP2='P is set', EnvelopedData-fnc(s|e|p|h,A) AVP3='P is set', e' AVP4='P is clear', n AVP5='P is clear', SignedData(T)" 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 Oct 24 14:25:46 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10459 for ; Wed, 24 Oct 2001 14:25:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75A8191283; Wed, 24 Oct 2001 14:25:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 497CC91284; Wed, 24 Oct 2001 14:25: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 18CE791283 for ; Wed, 24 Oct 2001 14:25:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBE825DDA2; Wed, 24 Oct 2001 14:25:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 004D95DD9C for ; Wed, 24 Oct 2001 14:25:11 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9OIP8C02279; Wed, 24 Oct 2001 20:25:08 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id UAA14369; Wed, 24 Oct 2001 20:25:02 +0200 (MET DST) Message-ID: <3BD70791.85D04185@rioja.ericsson.se> Date: Wed, 24 Oct 2001 20:25:21 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Farrell wrote: > > And the one other outstanding one: > > I'd argue that this is a "reject" given my suggested > resolution of #185. After some convincing arguments by Stephen, I'll try to show my point of view. My main concern is the following: I understand that, given that it isn't necessary to establish a previous DSA to send CMS-enabled AVPs (#185), any of the AAA Servers of the realm can answer a client that has established a DSA with an only server (let's call it the front-end server). That's the light side and looks fine. My concern is the back-end processing. I mean, how do the rest of the servers of the realms know about parameters such as the TTL of the Expected-*-AVPs of the existing DSA. AFAIK this communication isn't covered by the protocol. If that's true, it has no sense to add this AVP (AAA-Server-Certs) since there isn't a Diameter way to send this parameters. Or maybe I'm wrong and there's a way. Please, need an explanation :-)) Regards // M.A. From owner-aaa-wg@merit.edu Wed Oct 24 14:27:40 2001 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 OAA10540 for ; Wed, 24 Oct 2001 14:27:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B07B191284; Wed, 24 Oct 2001 14:27:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C09491285; Wed, 24 Oct 2001 14:27: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 4975091284 for ; Wed, 24 Oct 2001 14:27:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C5E95DD9C; Wed, 24 Oct 2001 14:27:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 3729B5DDA2 for ; Wed, 24 Oct 2001 14:27:26 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9OIRLj05898; Wed, 24 Oct 2001 20:27:21 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id UAA14536; Wed, 24 Oct 2001 20:27:16 +0200 (MET DST) Message-ID: <3BD70817.737C6D5F@rioja.ericsson.se> Date: Wed, 24 Oct 2001 20:27:35 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: stephen.farrell@baltimore.ie, aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> <3BD70791.85D04185@rioja.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Miguel Ángel Monjas Llorente wrote: > > Stephen Farrell wrote: > > > > And the one other outstanding one: > > > > I'd argue that this is a "reject" given my suggested > > resolution of #185. > > After some convincing arguments by Stephen, I'll try to show my point > of view. > > My main concern is the following: I understand that, given that it > isn't necessary to establish a previous DSA to send CMS-enabled AVPs > (#185), any of the AAA Servers of the realm can answer a client that > has established a DSA with an only server (let's call it the front-end > server). That's the light side and looks fine. > > My concern is the back-end processing. I mean, how do the rest of the > servers of the realms know about parameters such as the TTL of the ^^ or > Expected-*-AVPs of the existing DSA. AFAIK this communication isn't > covered by the protocol. If that's true, it has no sense to add this > AVP (AAA-Server-Certs) since there isn't a Diameter way to send this > parameters. Or maybe I'm wrong and there's a way. Please, need an > explanation :-)) From owner-aaa-wg@merit.edu Wed Oct 24 14:33:41 2001 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 OAA10740 for ; Wed, 24 Oct 2001 14:33:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4317C91285; Wed, 24 Oct 2001 14:33:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10ADB91286; Wed, 24 Oct 2001 14:33: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 E68A891285 for ; Wed, 24 Oct 2001 14:33:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC1425DDA2; Wed, 24 Oct 2001 14:33:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id F15E25DD9C for ; Wed, 24 Oct 2001 14:33:22 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id TAA09955 for ; Wed, 24 Oct 2001 19:33:22 +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, 24 Oct 2001 19:29:55 +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 TAA16268; Wed, 24 Oct 2001 19:35:54 +0100 Message-ID: <3BD7097B.DC21EE40@baltimore.ie> Date: Wed, 24 Oct 2001 19:33:31 +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: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> <3BD70791.85D04185@rioja.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id TAA16268 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10740 Hi Miguel, I had assumed that all of the servers concerned would have the same expected-* and ttl configuration settings. But, you're right that that wasn't stated (good catch). So, how about adding: "All of the AAA nodes for which certificates are present in the AAA-Server-Certs AVP MUST have the same DSA-related configuration settings, that is: they MUST emit the same Expected-* AVPs and have the same limits imposted on DSA TTLs." I'd put this into 4.2 or 3.2 (end of page 13) or even 6.7. I prefer 3.2 myself. Does that close it out? Stephen. Miguel Ángel Monjas Llorente wrote: > > Stephen Farrell wrote: > > > > And the one other outstanding one: > > > > I'd argue that this is a "reject" given my suggested > > resolution of #185. > > After some convincing arguments by Stephen, I'll try to show my point > of view. > > My main concern is the following: I understand that, given that it > isn't necessary to establish a previous DSA to send CMS-enabled AVPs > (#185), any of the AAA Servers of the realm can answer a client that > has established a DSA with an only server (let's call it the front-end > server). That's the light side and looks fine. > > My concern is the back-end processing. I mean, how do the rest of the > servers of the realms know about parameters such as the TTL of the > Expected-*-AVPs of the existing DSA. AFAIK this communication isn't > covered by the protocol. If that's true, it has no sense to add this > AVP (AAA-Server-Certs) since there isn't a Diameter way to send this > parameters. Or maybe I'm wrong and there's a way. Please, need an > explanation :-)) > > Regards > > // M.A. -- ____________________________________________________________ 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 Oct 24 15:53:30 2001 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 PAA12892 for ; Wed, 24 Oct 2001 15:53:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3E8091288; Wed, 24 Oct 2001 15:53:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9795F91289; Wed, 24 Oct 2001 15:53:18 -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 54BE391288 for ; Wed, 24 Oct 2001 15:53:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3D085DE07; Wed, 24 Oct 2001 15:52:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id ED1DA5DDCA for ; Wed, 24 Oct 2001 15:52:55 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9OJqbj20029; Wed, 24 Oct 2001 21:52:37 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id VAA18444; Wed, 24 Oct 2001 21:52:29 +0200 (MET DST) Message-ID: <3BD71BD3.FF935111@rioja.ericsson.se> Date: Wed, 24 Oct 2001 21:51:47 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson Spain X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> <3BD70791.85D04185@rioja.ericsson.se> <3BD7097B.DC21EE40@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Farrell wrote: > > Hi Miguel, > > I had assumed that all of the servers concerned would have the > same expected-* and ttl configuration settings. But, you're > right that that wasn't stated (good catch). > > So, how about adding: > > "All of the AAA nodes for which certificates are present in the > AAA-Server-Certs AVP MUST have the same DSA-related configuration > settings, that is: they MUST emit the same Expected-* AVPs and > have the same limits imposted on DSA TTLs." > > I'd put this into 4.2 or 3.2 (end of page 13) or even 6.7. I > prefer 3.2 myself. > > Does that close it out? I prefer you decide it :-)) My last and only concern is the following: You're thinking about server->client communication. Let's imagine a client and two servers (A and B) in the realm R. The client has been instructed to establish a DSA with the realm R and to ask that AVP1 and AVP2 will be signed when receiving them from the realm. The DSA is actually established by server A. How does server B finds out that AVP1 and AVP2 were agreed as signed by server A? Do you see my point? Regards // M.A. From owner-aaa-wg@merit.edu Wed Oct 24 19:57:12 2001 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 TAA17416 for ; Wed, 24 Oct 2001 19:57:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F178391291; Wed, 24 Oct 2001 19:56:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B69D5912A4; Wed, 24 Oct 2001 19:56: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 88FF091291 for ; Wed, 24 Oct 2001 19:55:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 633775DE04; Wed, 24 Oct 2001 19:55:54 -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 1149F5DDFD for ; Wed, 24 Oct 2001 19:55:54 -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 f9ONtrY13512 for ; Wed, 24 Oct 2001 18:55:53 -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 f9ONtrd21416 for ; Wed, 24 Oct 2001 18:55:53 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA02596 for ; Wed, 24 Oct 2001 18:55:52 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id SAA10717 for ; Wed, 24 Oct 2001 18:55:48 -0500 (CDT) Message-ID: <000b01c15ce7$696ac410$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: Subject: Fw: [AAA-WG]: Addendum to test specification Date: Wed, 24 Oct 2001 16:55:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Forwarding to the list... ----- Original Message ----- From: "Pat Calhoun" To: "Bob Kopacz" Cc: "Pat Calhoun" ; "Kevin Purser" Sent: Monday, October 22, 2001 5:03 PM Subject: Re: [AAA-WG]: Addendum to test specification > > In case Kevin wants to do #3, do you have suggested > > names and AVP code#'s for the four new 64-bit > > AVPs? For our dictionaries. > > hmmm... I thought this had made it in the Alpha draft, and I see it hadn't > (hence your confusion). > > Here they are (I appologize for the formatting... I don't have nroff where > I am at the moment) > > 8.0 Accounting AVPs > > .in 3 > This section contains a description of the AVPs defined in this document > that are to be included in Diameter accounting messages [2]. > > > .in 0 > 8.1 Accounting-Input-Extended-Octets AVP > > .in 3 > The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type > Unsigned64, and contains the number of octets in IP packets received by the > user. > > > .in 0 > 8.2 Accounting-Output-Extended-Octets AVP > > .in 3 > The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type > Unsigned64, and contains the number of octets in IP packets sent to the user. > > > .in 0 > 8.3 Accounting-Session-Time AVP > > .in 3 > The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, and > indicates the length of the current session in seconds. > > > .in 0 > 8.4 Accounting-Input-Extended-Packets AVP > > .in 3 > The Accounting-Input-Extended-Packets (AVP Code 365) is of type Unsigned64, and > contains the number of IP packets received by the user. > > > .in 0 > 8.5 Accounting-Output-Extended-Packets AVP > > .in 3 > The Accounting-Output-Extended-Packets (AVP Code 366) is of type Unsigned64, > and contains the number of IP packets sent to the user. > From owner-aaa-wg@merit.edu Thu Oct 25 00:11:08 2001 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 AAA23926 for ; Thu, 25 Oct 2001 00:11:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8BE2791294; Thu, 25 Oct 2001 00:10:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B78E91298; Thu, 25 Oct 2001 00:10: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 3724091294 for ; Thu, 25 Oct 2001 00:10:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DD415DD96; Thu, 25 Oct 2001 00:10:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 3CDE45DD93 for ; Thu, 25 Oct 2001 00:10:55 -0400 (EDT) Received: from jariws1 ([62.248.238.80]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011025041053.EKQ13228.fep01-app.kolumbus.fi@jariws1>; Thu, 25 Oct 2001 07:10:53 +0300 Message-ID: <00f301c15d0b$10aed040$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: "Pat Calhoun" References: <3BD70764.11FFA489@baltimore.ie> Subject: Re: [AAA-WG]: non-issue issue: MIME encoding in CMS Date: Thu, 25 Oct 2001 07:11:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > It doesn't have an issue number, but the suggestion to drop > the MIME encoding step was raised on the list, was supported > and wasn't opposed. > (see: http://www.merit.edu/mail.archives/aaa-wg/msg02431.html) > > I think the changes listed below would be what needs to be > done (based on draft-ietf-aaa-diameter-cms-03.alpha01.txt). > > I'm for making this change - I haven't found a toolkit > for which it causes a problem. (OTOH, I'm also ok with > not making the change if it causes someone a problem.) I support making this change. Jari From owner-aaa-wg@merit.edu Thu Oct 25 00:51:14 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24401 for ; Thu, 25 Oct 2001 00:51:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E9AD91297; Thu, 25 Oct 2001 00:50:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E41791299; Thu, 25 Oct 2001 00:50: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 33C7991297 for ; Thu, 25 Oct 2001 00:50:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 067915DD96; Thu, 25 Oct 2001 00:50:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E18F15DD93 for ; Thu, 25 Oct 2001 00:50:36 -0400 (EDT) Received: from phoenix (pm552-11.dialip.mich.net [198.110.22.165]) by aaa.interlinknetworks.com (Postfix) with SMTP id F11FD79; Thu, 25 Oct 2001 00:50:34 -0400 (EDT) From: "Bob Kopacz" To: "Mark Eklund" Cc: "aaa-wg" Subject: RE: [AAA-WG]: FA-HA Key Generation in the foreign domain Date: Thu, 25 Oct 2001 00:48:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <15290.6612.8463.125082@gargle.gargle.HOWL> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Mark Eklund > Sent: Tuesday, October 02, 2001 3:48 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: FA-HA Key Generation in the foreign domain > > All, > > I need to clarify what happens when the AAAF generates the FA-HA key > when the HA is in the foreign domain. What this concerns is how the > MIP-FA-to-HA-Key gets added to the AMA. > > When the AAAF gets an HAR with the FA-HA-Key-Request set in the > MIP-Feature-Vector AVP, it generates the FA-HA Key. Is the MIP-Feature-Vector AVP in the HAR? The draft-08-alpha01 is inconsistent; the HAR ABNF shows it as optional, and the occurrence rules table shows it as disallowed. But it seems it better be there, otherwise how would the AAAF know whether it should generate FA-HA keys or not? > It then includes > it in the MIP-HA-to-FA-Key that it sends to the HA. When it gets back > the HAA, it remembers the MIP-FA-to-HA-SPI, its own generated key, and > the Accounting-Multi-Session-Id AVP from the HA. It then forwards the > HAA on to the AAAH. > > When the AAAH sends the AMA to the AAAF, the AAAF will have to add the > MIP-FA-to-HA-Key AVP. It will do this by matching the > Accounting-Multi-Session-Id in the AMA to the one saved when the HAA > was received. The Accounting-Multi-Session-Id is the only thing that > is common between the HAA and the AMA. > > Is this the only way the current specification will allow this? > > Is there any merit to changing the specification so that if a > FA-HA-Key is generated in the foreign domain, the AAAF MUST add the > FA-to-HA-Key to the HAR and the AAAH MUST move it from the HAR to the ^^^ ^^^ HAA HAA > AMA? This would prevent the AAAF from having to keep a lookup table > and do garbage collection on that table if the AMA is never received. I think your idea would make life easier for the AAAF. I'm with you on this one. > If so, I'll raise the issue. > > -mark Bob K. From owner-aaa-wg@merit.edu Thu Oct 25 04:24:24 2001 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 EAA11564 for ; Thu, 25 Oct 2001 04:24:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B14E991214; Thu, 25 Oct 2001 04:24:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CFE49129A; Thu, 25 Oct 2001 04:24:03 -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 360AD91214 for ; Thu, 25 Oct 2001 04:24:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14E415DDCE; Thu, 25 Oct 2001 04:24:02 -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 41EBB5DDC4 for ; Thu, 25 Oct 2001 04:24:01 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9P8ObA14716 for ; Thu, 25 Oct 2001 11:24:37 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 11:23:59 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 25 Oct 2001 11:23:59 +0300 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA70@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: Erik.Guttman@Sun.COM Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Thu, 25 Oct 2001 11:23:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Erik, > Let's say we get things wrong and have to revise a particular diameter > application. We just create new AVPs and commands as necessary. > Backwards compatibility is assured precisely **because** we have been > very strict and very clear about what AVPs mean. > > First version Revised version > ------------- --------------- > Application A Application B > Command A1 Command A1 > Avp A11, A12, A13 Avp A11, A12, B13, B14 > Command A2 Command B2 > Avp A21, A22 Avp B22 > etc. etc. > > Note the revised version > - has a new application id > - will reuse command IDs, if possible, but may replace them (A2->B2) > - will reuse AVP ids if possible, but may replace them (A13->B13), > remove them (A21-> not supported) or invent new ones (A1 uses B14). > > The result of your change would be much more complicated rules to > determine if an AVP was supported for any given application. These > rules would get ever more complex as we revised the application. > Consider if each AVP in the 'first version' referred to possibly many > variants. This aliasing complicates revision, interpretation and > reasoning about the specification. I can't see how my proposal complicates rules to determine if an AVP is supported by an application at all, because alternatives means that the actual AVP included into the command can be one of the alternatives represented in the definition and therefore all alternatives must be supported by the application. The proposal only improves the representational power of the Diameter command code definition. > > It does not contain a possibility to use the alternatives (see > > RFC2243, section 3.2) when defining the AVPs included into > the commands. > > The section you refer to describes how to list alternatives among > non-terminals. AVP names are currently terminals and I argue they > should stay that way. I think that you mean that the diameter-name is terminal and my proposal does not change that. Best Regards, Jaakko PS. As you may have noticed the reference to RFC2243 is wrong. It should be RFC2234 (ABNF specification). > -----Original Message----- > From: ext Erik Guttman [mailto:Erik.Guttman@Sun.COM] > Sent: 24 October, 2001 11:20 > To: Rajaniemi Jaakko (NET/Espoo) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command > Code ABNF > specification > > > > Jaakko, > > > The section 3.2 "Command Code ABNF specification" contains the ABNF > > specification which must be followed when contructing > Diameter Command > > Codes. > > This is intentional. Command codes are terminals in Diameter > messages. > I can't say an AVP is either this or that. > > > This is very restrictive and does not allow enough flexibility when > > defining command codes and therefore it is proposed that the > > alternatives is included. > > Restrictiveness in a type system is good. It makes it clear what you > require. > > Let's say we get things wrong and have to revise a particular diameter > application. We just create new AVPs and commands as necessary. > Backwards compatibility is assured precisely **because** we have been > very strict and very clear about what AVPs mean. > > First version Revised version > ------------- --------------- > Application A Application B > Command A1 Command A1 > Avp A11, A12, A13 Avp A11, A12, B13, B14 > Command A2 Command B2 > Avp A21, A22 Avp B22 > etc. etc. > > Note the revised version > - has a new application id > - will reuse command IDs, if possible, but may replace them (A2->B2) > - will reuse AVP ids if possible, but may replace them (A13->B13), > remove them (A21-> not supported) or invent new ones (A1 uses B14). > > The result of your change would be much more complicated rules to > determine if an AVP was supported for any given application. These > rules would get ever more complex as we revised the application. > Consider if each AVP in the 'first version' referred to possibly many > variants. This aliasing complicates revision, interpretation and > reasoning about the specification. > > I say KISS ('Keep It Simple Standards-cowboys!') > > > It does not contain a possibility to use the alternatives (see > > RFC2243, section 3.2) when defining the AVPs included into > the commands. > > The section you refer to describes how to list alternatives among > non-terminals. AVP names are currently terminals and I argue they > should stay that way. > > Erik > From owner-aaa-wg@merit.edu Thu Oct 25 04:26:25 2001 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 EAA11590 for ; Thu, 25 Oct 2001 04:26:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC6859129A; Thu, 25 Oct 2001 04:26:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93F189129B; Thu, 25 Oct 2001 04:26: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 490009129A for ; Thu, 25 Oct 2001 04:26:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EBC95DDCE; Thu, 25 Oct 2001 04:26:04 -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 4608A5DDC4 for ; Thu, 25 Oct 2001 04:26:03 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9P8QaA16537 for ; Thu, 25 Oct 2001 11:26:36 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 11:25:58 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 25 Oct 2001 11:25:58 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719804A@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: Erik.Guttman@Sun.COM, jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Thu, 25 Oct 2001 11:25:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Erik, I feel you have misunderstood what is being proposed by Jaakko. The proposal is NOT to touch the terminals (AVP definitions) at all, but to allow *command definitions* where _either_ AVP1 _or_ AVP2 is required. AVP1 and AVP2 being defined elsewhere. Maybe the source of the confusion is the location of the "/" delimiter in Jaakko's proposal. In the RFC 2234 ABNF the "<>"'s around elements are not required. In the Diameter specs each AVP name is included in some kind of brackets separately. If this is to be continued, the alternative delimiter "/" should be outside of the brackets, but then additional parentheses may be needed, unless line breaks are made syntactically significant. Example (using the syntax proposed in issue 200): Session-Termination-Req ::= < Diameter Header: 275, REQ, PXY > < Session-Id / User-Name > ... This would allow Session Termination to be issued either based on the Session-Id AVP, or the User-Name AVP (Current definition requires both). Maybe a more proper syntax would be: Session-Termination-Req ::= < Diameter Header: 275, REQ, PXY > < Session-Id > / < User-Name > ... Here the line breaks are understood to limit the effect of the alternative delimiter. If this is not acceptable, then consider: Session-Termination-Req ::= < Diameter Header: 275, REQ, PXY > (< Session-Id >) / (< User-Name >) ... But this is kind of ugly... An alternative to the whole proposal is that two different commands are defined. Example: Session-Termination-1-Req ::= < Diameter Header: 275, REQ, PXY > < Session-Id > ... and Session-Termination-2-Req ::= < Diameter Header: 999, REQ, PXY > < User-Name > ... As the kind of brackets used denotes the "requiredness" of the AVP, maybe the simplest change to the command definition grammar adding alternatives would be to allow multiple AVPs to be included in one pair of brackets. Modified rules could be like this: fixed = [qual] "<" 1*avp-spec [ "/" 1*avp-spec ] ">" ; Defines the fixed position of an AVP sequence. ; Either the AVPs before OR after the "/" delimiter ; MUST be present at this position in the presented ; order required = [qual] "{" 1*avp-spec [ "/" 1*avp-spec ] "}" ; Either the AVPs before OR after the "/" delimiter ; MUST be present but can occur in any order optional = [qual] "[" 1*avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule without the ; alternative operator This allows the syntax Jaakko proposed, but does it in the proper level in the grammar, IMO. Also this grammar is backwards compatible with the existing command definitions. I don't see why allowing alternatives would make it harder to determine whether a Diameter application is supporting a given AVP or not. An AVP is supported if it is present anywhere in the command definition. The alternative places additional flexibility to when one of the alternative AVP (sequences) can be left out, though. Additionally, in the example above, if both Session-Id and User-Name are included, the receiver should pick one (maybe the one listed first in the command definition), and should consider the other as an optional AVP. With regards, Jarno Erik Guttman wrote: > Jaakko, > > > The section 3.2 "Command Code ABNF specification" contains the ABNF > > specification which must be followed when contructing > Diameter Command > > Codes. > > This is intentional. Command codes are terminals in Diameter > messages. > I can't say an AVP is either this or that. > > > This is very restrictive and does not allow enough flexibility when > > defining command codes and therefore it is proposed that the > > alternatives is included. > > Restrictiveness in a type system is good. It makes it clear what you > require. > > Let's say we get things wrong and have to revise a particular diameter > application. We just create new AVPs and commands as necessary. > Backwards compatibility is assured precisely **because** we have been > very strict and very clear about what AVPs mean. > > First version Revised version > ------------- --------------- > Application A Application B > Command A1 Command A1 > Avp A11, A12, A13 Avp A11, A12, B13, B14 > Command A2 Command B2 > Avp A21, A22 Avp B22 > etc. etc. > > Note the revised version > - has a new application id > - will reuse command IDs, if possible, but may replace them (A2->B2) > - will reuse AVP ids if possible, but may replace them (A13->B13), > remove them (A21-> not supported) or invent new ones (A1 uses B14). > > The result of your change would be much more complicated rules to > determine if an AVP was supported for any given application. These > rules would get ever more complex as we revised the application. > Consider if each AVP in the 'first version' referred to possibly many > variants. This aliasing complicates revision, interpretation and > reasoning about the specification. > > I say KISS ('Keep It Simple Standards-cowboys!') > > > It does not contain a possibility to use the alternatives (see > > RFC2243, section 3.2) when defining the AVPs included into > the commands. > > The section you refer to describes how to list alternatives among > non-terminals. AVP names are currently terminals and I argue they > should stay that way. > > Erik > From owner-aaa-wg@merit.edu Thu Oct 25 05:20:53 2001 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 FAA12189 for ; Thu, 25 Oct 2001 05:20:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65AC39129B; Thu, 25 Oct 2001 05:20:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D34D9129C; Thu, 25 Oct 2001 05:20: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 0ADDF9129B for ; Thu, 25 Oct 2001 05:20:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D306C5DDAB; Thu, 25 Oct 2001 05:20:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 39FF85DD9A for ; Thu, 25 Oct 2001 05:20:24 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00929; Thu, 25 Oct 2001 02:20:13 -0700 (PDT) Received: from vayne (remote-nl-46.Holland.Sun.COM [129.159.209.128]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA06446; Thu, 25 Oct 2001 11:20:11 +0200 (MET DST) Date: Thu, 25 Oct 2001 11:32:51 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification To: jarno.rajahalme@nokia.com Cc: Erik.Guttman@sun.com, jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F91175719804A@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 Jarno, > I feel you have misunderstood what is being proposed by Jaakko. The proposal > is NOT to touch the terminals (AVP definitions) at all, but to allow > *command definitions* where _either_ AVP1 _or_ AVP2 is required. AVP1 and > AVP2 being defined elsewhere. This does complicate things. A rule that says "AVP1 is required" is less complicated than a rule which says "'either AVP1 or AVP2' is required." > An alternative to the whole proposal is that two different commands are > defined. This is the best argument for this feature. Namely, if you have several options ( A / B), (C / D), you'd have to define 4 different commands for each combination and say any of them would do. That's ugly. For this reason, I reluctantly support the proposal. > As the kind of brackets used denotes the "requiredness" of the AVP, maybe > the simplest change to the command definition grammar adding alternatives > would be to allow multiple AVPs to be included in one pair of brackets. > Modified rules could be like this: This would require a rewrite of all Diameter specs. This is not only editorial work. It would require quite a bit of technical review to make sure it remained equivalent to the old representation. > Additionally, in the example above, if both Session-Id and User-Name are > included, the receiver should pick one (maybe the one listed first in the > command definition), and should consider the other as an optional AVP. No. A rule which requires a choice of A or B in a fixed position does not imply that the choice not taken is an optional AVP. This would require an additional rule. Erik From owner-aaa-wg@merit.edu Thu Oct 25 05:24:54 2001 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 FAA12233 for ; Thu, 25 Oct 2001 05:24:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 632A39129C; Thu, 25 Oct 2001 05:24:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28AB39129D; Thu, 25 Oct 2001 05:24: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 CBCAE9129C for ; Thu, 25 Oct 2001 05:24:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF23E5DDAB; Thu, 25 Oct 2001 05:24:33 -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 C55875DD9A for ; Thu, 25 Oct 2001 05:24:32 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9P9P5A11373 for ; Thu, 25 Oct 2001 12:25:05 +0300 (EET DST) Received: from esebh11nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 12:24:27 +0300 Received: by esebh11nok with Internet Mail Service (5.5.2652.78) id ; Thu, 25 Oct 2001 12:24:28 +0300 Message-ID: <4AE1AC3D692F55488F2D03518907B8AD063D01@beebe001.NOE.Nokia.com> From: Yanqun.Le@nokia.com To: pcalhoun@diameter.org, charliep@iprg.nokia.com Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: [AAA-WG]: about the password in Bake off test cases Date: Thu, 25 Oct 2001 12:21:53 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Looking through RFC2002, I can't find any text about password. And I wonder how can mobile node send password to Foreign Agent. Is password sent by Registration Request? Even if Foreign Agent received password, by which AVP does it deliver the password to AAA server? Thank you in advance. Le Yanqun From owner-aaa-wg@merit.edu Thu Oct 25 05:50:08 2001 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 FAA12502 for ; Thu, 25 Oct 2001 05:50:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A17479129E; Thu, 25 Oct 2001 05:49:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 711AE9129F; Thu, 25 Oct 2001 05:49: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 386CC9129E for ; Thu, 25 Oct 2001 05:49:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CC155DDAB; Thu, 25 Oct 2001 05:49:45 -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 618225DD9A for ; Thu, 25 Oct 2001 05:49:44 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9P9oKA05191 for ; Thu, 25 Oct 2001 12:50:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Oct 2001 12:49:42 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 25 Oct 2001 12:49:43 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D596@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: Erik.Guttman@sun.com Cc: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Thu, 25 Oct 2001 12:49:33 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Erik, You wrote: > > I feel you have misunderstood what is being proposed by > Jaakko. The proposal > > is NOT to touch the terminals (AVP definitions) at all, but to allow > > *command definitions* where _either_ AVP1 _or_ AVP2 is > required. AVP1 and > > AVP2 being defined elsewhere. > > This does complicate things. A rule that says "AVP1 is required" is > less complicated than a rule which says "'either AVP1 or > AVP2' is required." > I agree, on the level of a single rule it is more complicated... > > An alternative to the whole proposal is that two different > commands are > > defined. > > This is the best argument for this feature. Namely, if you > have several > options ( A / B), (C / D), you'd have to define 4 different commands > for each combination and say any of them would do. That's ugly. > ... but having a separate command for each combination will likely be more complex on the level of the Application specification. > For this reason, I reluctantly support the proposal. > Great. > > As the kind of brackets used denotes the "requiredness" of > the AVP, maybe > > the simplest change to the command definition grammar > adding alternatives > > would be to allow multiple AVPs to be included in one pair > of brackets. > > Modified rules could be like this: > > This would require a rewrite of all Diameter specs. This is not only > editorial work. It would require quite a bit of technical review to > make sure it remained equivalent to the old representation. > I though that the rules I presented were backwards compatible. The current way of placing each AVP in it's own brackets is still covered by the proposed new grammar rules. Hence the grammar rules in the Base Diameter is the only place that needs to be changed. > > Additionally, in the example above, if both Session-Id and > User-Name are > > included, the receiver should pick one (maybe the one > listed first in the > > command definition), and should consider the other as an > optional AVP. > > No. A rule which requires a choice of A or B in a fixed position > does not imply that the choice not taken is an optional AVP. This > would require an additional rule. > At the least the "optional" rule's comment should be modified to allow specifying an AVP both as an alternative and optional. Jarno From owner-aaa-wg@merit.edu Thu Oct 25 07:49:32 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14511 for ; Thu, 25 Oct 2001 07:49:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52910912A0; Thu, 25 Oct 2001 07:48:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14211912A1; Thu, 25 Oct 2001 07:48:59 -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 E9E3E912A0 for ; Thu, 25 Oct 2001 07:48:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFC685DD9A; Thu, 25 Oct 2001 07:48:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5EEE15DD95 for ; Thu, 25 Oct 2001 07:48:57 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16610; Thu, 25 Oct 2001 05:48:55 -0600 (MDT) Received: from vayne (remote-nl-19.Holland.Sun.COM [129.159.209.101]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id NAA10684; Thu, 25 Oct 2001 13:48:54 +0200 (MET DST) Date: Thu, 25 Oct 2001 14:01:33 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification To: jarno.rajahalme@nokia.com Cc: Erik.Guttman@sun.com, jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F91175715D596@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 Jarno, > > This does complicate things. A rule that says "AVP1 is required" is > > less complicated than a rule which says "'either AVP1 or > > AVP2' is required." > > > > I agree, on the level of a single rule it is more complicated... It gets worse the more options you have. If there are 3 rules which have 3 options each, there are 9 valid combinations. Are all valid? Things get ugly if the options aren't independent. Further, more options make interoperation harder to verify and protocol implementations more complex and less likely to be hardened. > ... but having a separate command for each combination will likely be more > complex on the level of the Application specification. Yes. But let's resist (wherever possible) the introduction of more than one way to do anything. > > This would require a rewrite of all Diameter specs. This is not only > > editorial work. It would require quite a bit of technical review to > > make sure it remained equivalent to the old representation. > > > > I though that the rules I presented were backwards compatible. The current > way of placing each AVP in it's own brackets is still covered by the > proposed new grammar rules. Hence the grammar rules in the Base Diameter is > the only place that needs to be changed. If so - why do you want to introduce this change?!? To ease the way for protocol complexity in the future? :/ Erik From owner-aaa-wg@merit.edu Thu Oct 25 10:39:32 2001 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 KAA20584 for ; Thu, 25 Oct 2001 10:39:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 832899120F; Thu, 25 Oct 2001 10:39:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F2D391218; Thu, 25 Oct 2001 10:39:18 -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 03B809120F for ; Thu, 25 Oct 2001 10:39:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D29875DE0F; Thu, 25 Oct 2001 10:39:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 83A3C5DDAB for ; Thu, 25 Oct 2001 10:39:16 -0400 (EDT) Received: (qmail 4913 invoked by uid 500); 25 Oct 2001 14:23:42 -0000 Date: Thu, 25 Oct 2001 07:23:42 -0700 From: Pat Calhoun To: Erik Guttman Cc: jarno.rajahalme@nokia.com, jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Message-ID: <20011025072342.A4902@charizard.diameter.org> Mail-Followup-To: Erik Guttman , jarno.rajahalme@nokia.com, jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: <009CA59D1752DD448E07F8EB2F91175715D596@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Erik.Guttman@sun.com on Thu, Oct 25, 2001 at 02:01:33PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk After following this thread, I tend to agree with Erik. Adding this feature has unknown ramifications in the drafts, will require more editorial work, and it is still unclear to me what applications would benefit from this feature. So, unless this is considered a bug, we had agreed not to add new features many moons ago. If there is a known bug that requires this feature, then please point it out. Thanks, PatC On Thu, Oct 25, 2001 at 02:01:33PM +0200, Erik Guttman wrote: > Jarno, > > > > This does complicate things. A rule that says "AVP1 is required" is > > > less complicated than a rule which says "'either AVP1 or > > > AVP2' is required." > > > > > > > I agree, on the level of a single rule it is more complicated... > > It gets worse the more options you have. If there are 3 rules > which have 3 options each, there are 9 valid combinations. Are > all valid? Things get ugly if the options aren't independent. > Further, more options make interoperation harder to verify and > protocol implementations more complex and less likely to be > hardened. > > > ... but having a separate command for each combination will likely be more > > complex on the level of the Application specification. > > Yes. But let's resist (wherever possible) the introduction of > more than one way to do anything. > > > > This would require a rewrite of all Diameter specs. This is not only > > > editorial work. It would require quite a bit of technical review to > > > make sure it remained equivalent to the old representation. > > > > > > > I though that the rules I presented were backwards compatible. The current > > way of placing each AVP in it's own brackets is still covered by the > > proposed new grammar rules. Hence the grammar rules in the Base Diameter is > > the only place that needs to be changed. > > If so - why do you want to introduce this change?!? To ease the way > for protocol complexity in the future? :/ > > > Erik > From owner-aaa-wg@merit.edu Thu Oct 25 10:41:12 2001 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 KAA20633 for ; Thu, 25 Oct 2001 10:41:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C152591218; Thu, 25 Oct 2001 10:40:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9777D9129F; Thu, 25 Oct 2001 10:40: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 5435091218 for ; Thu, 25 Oct 2001 10:40:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C0915DE0F; Thu, 25 Oct 2001 10:40:57 -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 462665DDAB for ; Thu, 25 Oct 2001 10:40:56 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA06621; Thu, 25 Oct 2001 10:40:18 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA27315; Thu, 25 Oct 2001 10:41:18 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15320.9358.167315.231184@gargle.gargle.HOWL> Date: Thu, 25 Oct 2001 10:41:18 -0400 To: "Bob Kopacz" Cc: "Mark Eklund" , "aaa-wg" Subject: RE: [AAA-WG]: FA-HA Key Generation in the foreign domain In-Reply-To: References: <15290.6612.8463.125082@gargle.gargle.HOWL> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, Bob Kopacz writes: > Hi Mark, > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Mark Eklund > > Sent: Tuesday, October 02, 2001 3:48 PM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: FA-HA Key Generation in the foreign domain > > > > All, > > > > I need to clarify what happens when the AAAF generates the FA-HA key > > when the HA is in the foreign domain. What this concerns is how the > > MIP-FA-to-HA-Key gets added to the AMA. > > > > When the AAAF gets an HAR with the FA-HA-Key-Request set in the > > MIP-Feature-Vector AVP, it generates the FA-HA Key. > > Is the MIP-Feature-Vector AVP in the HAR? The draft-08-alpha01 is > inconsistent; the HAR ABNF shows it as optional, and the occurrence > rules table shows it as disallowed. But it seems it better be > there, otherwise how would the AAAF know whether it should generate > FA-HA keys or not? My guess is that the table lags behind changes in the ABNF. I tend to trust the ABNF over the table. > > > It then includes > > it in the MIP-HA-to-FA-Key that it sends to the HA. When it gets back > > the HAA, it remembers the MIP-FA-to-HA-SPI, its own generated key, and > > the Accounting-Multi-Session-Id AVP from the HA. It then forwards the > > HAA on to the AAAH. > > > > When the AAAH sends the AMA to the AAAF, the AAAF will have to add the > > MIP-FA-to-HA-Key AVP. It will do this by matching the > > Accounting-Multi-Session-Id in the AMA to the one saved when the HAA > > was received. The Accounting-Multi-Session-Id is the only thing that > > is common between the HAA and the AMA. > > > > Is this the only way the current specification will allow this? > > > > Is there any merit to changing the specification so that if a > > FA-HA-Key is generated in the foreign domain, the AAAF MUST add the > > FA-to-HA-Key to the HAR and the AAAH MUST move it from the HAR to the > ^^^ ^^^ > HAA HAA > > AMA? This would prevent the AAAF from having to keep a lookup table > > and do garbage collection on that table if the AMA is never received. > > I think your idea would make life easier for the AAAF. I'm with you on > this one. > > > If so, I'll raise the issue. I'll raise an issue. -mark > > > > -mark > > Bob K. > From owner-aaa-wg@merit.edu Thu Oct 25 10:46:43 2001 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 KAA20754 for ; Thu, 25 Oct 2001 10:46:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 494259129F; Thu, 25 Oct 2001 10:46:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12F0A912A1; Thu, 25 Oct 2001 10: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 798FD9129F for ; Thu, 25 Oct 2001 10:46:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A91A5DDC4; Thu, 25 Oct 2001 10:46:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C63AD5DDAB for ; Thu, 25 Oct 2001 10:46:28 -0400 (EDT) Received: (qmail 4954 invoked by uid 500); 25 Oct 2001 14:30:55 -0000 Date: Thu, 25 Oct 2001 07:30:55 -0700 From: Pat Calhoun To: Yanqun.Le@nokia.com Cc: pcalhoun@diameter.org, charliep@iprg.nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: [AAA-WG]: Re: about the password in Bake off test cases Message-ID: <20011025073055.C4902@charizard.diameter.org> Mail-Followup-To: Yanqun.Le@nokia.com, pcalhoun@diameter.org, charliep@iprg.nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <4AE1AC3D692F55488F2D03518907B8AD063D01@beebe001.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4AE1AC3D692F55488F2D03518907B8AD063D01@beebe001.NOE.Nokia.com>; from Yanqun.Le@nokia.com on Thu, Oct 25, 2001 at 12:21:53PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Oct 25, 2001 at 12:21:53PM +0300, Yanqun.Le@nokia.com wrote: > Hi, > > Looking through RFC2002, I can't find any text about password. And I > wonder how can mobile node send password to Foreign Agent. Is password > sent by Registration Request? > > Even if Foreign Agent received password, by which AVP does it deliver > the password to AAA server? sorry, what is a password? PatC From owner-aaa-wg@merit.edu Thu Oct 25 12:22:17 2001 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 MAA22882 for ; Thu, 25 Oct 2001 12:22:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0C0991217; Thu, 25 Oct 2001 12:22:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84E56912A1; Thu, 25 Oct 2001 12:22: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 4ABA791217 for ; Thu, 25 Oct 2001 12:22:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D24F25DDD3; Thu, 25 Oct 2001 12:22:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 31E7A5DDC4 for ; Thu, 25 Oct 2001 12:22:06 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id RAA20627 for ; Thu, 25 Oct 2001 17:22:05 +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, 25 Oct 2001 17:18:38 +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 RAA05807; Thu, 25 Oct 2001 17:24:41 +0100 Message-ID: <3BD83C36.2FE8FF2C@baltimore.ie> Date: Thu, 25 Oct 2001 17:22:14 +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: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> <3BD70791.85D04185@rioja.ericsson.se> <3BD7097B.DC21EE40@baltimore.ie> <3BD71BD3.FF935111@rioja.ericsson.se> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Miguel, All, Well, this turned out not to be so easy to fix after all ;-( The problem with AAA-Server-Certs was (as Miguel pointed out) that we don't have a way to pass on DSA state (in particular the peer's Expected-Encrypted-AVP value being the nasty case) to support failover. I just chatted to Pat about this & we reckon that we should make the following changes: - AAA-Server-Certs -> AAA-Node-Cert now containing only one cert - We made the DSAR and DSAA pki stuff the same (i.e. each can now contain a Local-CA-Info, CA-Chain and AAA-Node-Cert). Basically, the argument is that's its better to remove the partial support for failover rather than having to rely on vendor-specific mechanisms being implemented on all servers within a realm. 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 Thu Oct 25 12:34:39 2001 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 MAA23169 for ; Thu, 25 Oct 2001 12:34:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55FA3912A1; Thu, 25 Oct 2001 12:34:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25A17912A2; Thu, 25 Oct 2001 12:34: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 DD106912A1 for ; Thu, 25 Oct 2001 12:34:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9A5A5DDC6; Thu, 25 Oct 2001 12:34:24 -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 BB6055DDC4 for ; Thu, 25 Oct 2001 12:34:23 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA09265; Thu, 25 Oct 2001 12:33:51 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id MAA27348; Thu, 25 Oct 2001 12:34:49 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15320.16169.573651.659223@gargle.gargle.HOWL> Date: Thu, 25 Oct 2001 12:34:49 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the AAAF X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 25-Oct-01 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html Document: mobileip Comment type: Technical Priority: 1 Section: 2.4, 5.3, 8.1 Rationale/Explanation of issue: When the HA is in the foreign network and a FA-HA key is requested, the AAAF generates the key. The AAAF is then responsible for adding the MIP-FA-to-HA Key to the AMA. This means that the AAAF must maintain a list containing all MIP-FA-to-HA Key AVPs and their matching Accounting-Multi-Session-Id AVPs. When each AMA is received, the AAAF must then consult the list and when it finds a matching Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA. Requested change: Instead of requiring the AAAF to add the MIP-FA-to-HA Key AVP to the AMA, send the MIP-FA-to-HA Key back in the HAA. The AAAH then can move the MIP-FA-to-HA Key from the HAA to the AMA. Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4. Change MIP-Feature-Vector column HAR = 0-1 to section 8.1 Change MIP-FA-to-HA-Key column HAA = 0-1 to section 8.1 Change the final paragraph of section 5.3 to Upon receipt of the HAA, the Diameter server responsible for key allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI. If the key is generated at the AAAF, it adds the MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH. Depending upon where the HA was located the AAAH either generates the MIP-FA-to-HA Key AVP itself or extracts the AVP from the HAA sent by the AAAF. The AAAH adds the MIP-FA-to-HA Key to the AMA. -mark From owner-aaa-wg@merit.edu Thu Oct 25 12:45:22 2001 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 MAA23484 for ; Thu, 25 Oct 2001 12:45:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8259912A2; Thu, 25 Oct 2001 12:45:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63451912A3; Thu, 25 Oct 2001 12:45: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 1DE33912A2 for ; Thu, 25 Oct 2001 12:45:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6599B5DDD3; Thu, 25 Oct 2001 12:45:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 320CD5DDC4 for ; Thu, 25 Oct 2001 12:45:00 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9PGiuC06485; Thu, 25 Oct 2001 18:44:56 +0200 (MEST) Received: from rioja.es.eu.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA05788; Thu, 25 Oct 2001 18:44:50 +0200 (MET DST) Message-ID: <3BD84183.8923DD6E@rioja.es.eu.ericsson.se> Date: Thu, 25 Oct 2001 18:44:51 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente , aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <3BD701A7.5FC93675@baltimore.ie> <3BD70791.85D04185@rioja.ericsson.se> <3BD7097B.DC21EE40@baltimore.ie> <3BD71BD3.FF935111@rioja.ericsson.se> <3BD83C36.2FE8FF2C@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Farrell wrote: > > Miguel, All, > > Well, this turned out not to be so easy to fix after all ;-( > > The problem with AAA-Server-Certs was (as Miguel pointed out) > that we don't have a way to pass on DSA state (in particular > the peer's Expected-Encrypted-AVP value being the nasty case) > to support failover. > > I just chatted to Pat about this & we reckon that we should > make the following changes: > > - AAA-Server-Certs -> AAA-Node-Cert now containing only one > cert > - We made the DSAR and DSAA pki stuff the same (i.e. each > can now contain a Local-CA-Info, CA-Chain and AAA-Node-Cert). > > Basically, the argument is that's its better to remove the > partial support for failover rather than having to rely on > vendor-specific mechanisms being implemented on all servers > within a realm. It's OK for me. Go ahead!! :-)) // M.A. From owner-aaa-wg@merit.edu Thu Oct 25 13:16:37 2001 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 NAA24367 for ; Thu, 25 Oct 2001 13:16:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9819912A3; Thu, 25 Oct 2001 13:16:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DAF5912A5; Thu, 25 Oct 2001 13:16:06 -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 BD5C0912A3 for ; Thu, 25 Oct 2001 13:16:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FF835DDC6; Thu, 25 Oct 2001 13:16:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from localhost.localdomain (unknown [208.224.156.67]) by segue.merit.edu (Postfix) with ESMTP id F1C4D5DDB0 for ; Thu, 25 Oct 2001 13:16:03 -0400 (EDT) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f9PHEm801365 for ; Thu, 25 Oct 2001 13:14:51 -0400 Message-ID: <3BD84887.224B37D3@interlinknetworks.com> Date: Thu, 25 Oct 2001 13:14:47 -0400 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue 185: CMS-protected AVPs outside a DSA References: <3BD70129.25E290F8@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stephen, Stephen Farrell wrote: > > "This specification does NOT REQUIRE that a DSA be established > before the CMS AVPs are used. For example, a Diameter agent > could sign or countersign certain messages as they pass by, or > a node might add an additional recipient to a CMS-Encrypted-Data > for archival purposes." > > Regards, > Stephen. > I don't follow why a node might add an additional recipient to a CMS-Encrypted-Data AVP. How can anyone but the originally intended recipient of a CMS-Encrypted-Data AVP have the necessary key information to interpret the AVP? Thanks, Don From owner-aaa-wg@merit.edu Thu Oct 25 13:20:03 2001 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 NAA24512 for ; Thu, 25 Oct 2001 13:20:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9BF1B912A4; Thu, 25 Oct 2001 13:19:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F9FD912A5; Thu, 25 Oct 2001 13:19: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 33C20912A4 for ; Thu, 25 Oct 2001 13:19:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E36635DDC6; Thu, 25 Oct 2001 13:19:51 -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 036C45DDB0 for ; Thu, 25 Oct 2001 13:19:51 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA10518; Thu, 25 Oct 2001 13:19:18 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id NAA27403; Thu, 25 Oct 2001 13:20:17 -0400 (EDT) Date: Thu, 25 Oct 2001 13:20:17 -0400 (EDT) Message-Id: <200110251720.NAA27403@knox6039.cisco.com> X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund To: aaa-wg@merit.edu Subject: [AAA-WG]: Why does AAAF generate keys when HA is in a foreign domain? Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I just sent out an issue, "ISSUE: MIP-FA-to-HA being added to the AMA by the AAAF" that deals with the fact that when the HA is in the foreign domain, the AAAF generates the FA-to-HA keys. I'm just curious what keeps us from being consistent and always having the AAAH generate the keys. Is there a problem with the AAAH knowing what the FA-to-HA key for that session will be? What kind of security issues would this create? -mark From owner-aaa-wg@merit.edu Thu Oct 25 13:30:34 2001 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 NAA24819 for ; Thu, 25 Oct 2001 13:30:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22C52912A5; Thu, 25 Oct 2001 13:30:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4252912A6; Thu, 25 Oct 2001 13:30: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 2D356912A5 for ; Thu, 25 Oct 2001 13:30:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 850505DDAD; Thu, 25 Oct 2001 13:30:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (unknown [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 8DCEF5DD9C for ; Thu, 25 Oct 2001 13:30:07 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA21331 for ; Thu, 25 Oct 2001 18:30:07 +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, 25 Oct 2001 18:26:39 +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 SAA07043; Thu, 25 Oct 2001 18:32:44 +0100 Message-ID: <3BD84C29.E21CB3C5@baltimore.ie> Date: Thu, 25 Oct 2001 18:30:17 +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: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue 185: CMS-protected AVPs outside a DSA References: <3BD70129.25E290F8@baltimore.ie> <3BD84887.224B37D3@interlinknetworks.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 Don, > I don't follow why a node might add an additional recipient to a > CMS-Encrypted-Data AVP. Why: E.g. say if *I* want someone to archive all the stuff *I* encrypt. Not a super example, though I agree. > How can anyone but the originally intended > recipient of a CMS-Encrypted-Data AVP have the necessary key information > to interpret the AVP? How: Of course not anyone can do this, only someone with access to the clear text, which basically means the originating node, in which case its easy (just add another RecipientInfo). Cheers, 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 Thu Oct 25 20:45:04 2001 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 UAA03405 for ; Thu, 25 Oct 2001 20:45:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 30815912B2; Thu, 25 Oct 2001 20:44:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E19FF912B1; Thu, 25 Oct 2001 20:44: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 CBEFD912B7 for ; Thu, 25 Oct 2001 20:44:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB00D5DDC6; Thu, 25 Oct 2001 20:44:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 61FD15DDBC for ; Thu, 25 Oct 2001 20:44:33 -0400 (EDT) Received: (qmail 6294 invoked by uid 500); 26 Oct 2001 00:28:58 -0000 Date: Thu, 25 Oct 2001 17:28:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 205: Should AVPs be ordered? Message-ID: <20011025172858.E5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 3 Section: 3.2 Rationale/Explanation of issue: The base protocol spec command code ABNF doesn't specify that mandatory AVPs don't necessarily need to appear before the optional ones. Add a sentence making this clearer. From owner-aaa-wg@merit.edu Thu Oct 25 20:45:10 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03417 for ; Thu, 25 Oct 2001 20:45:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49BA0912B0; Thu, 25 Oct 2001 20:44:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B126912B7; Thu, 25 Oct 2001 20:44: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 E2FC7912B0 for ; Thu, 25 Oct 2001 20:44:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C69B05DDC6; Thu, 25 Oct 2001 20:44:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 83C6A5DDBC for ; Thu, 25 Oct 2001 20:44:09 -0400 (EDT) Received: (qmail 6285 invoked by uid 500); 26 Oct 2001 00:28:34 -0000 Date: Thu, 25 Oct 2001 17:28:34 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 204: How to handle CER from unknown peer Message-ID: <20011025172834.D5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: 5.3, 7.1 Rationale/Explanation of issue: If a CER is received from an unknown peer, the draft doesn't really specify what should be done. A new Result-Code will handle this case (and the necessary text in 5.3. From owner-aaa-wg@merit.edu Thu Oct 25 20:45:32 2001 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 UAA03448 for ; Thu, 25 Oct 2001 20:45:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F2BB912BC; Thu, 25 Oct 2001 20:45:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2241912B1; Thu, 25 Oct 2001 20:45: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 BC829912BC for ; Thu, 25 Oct 2001 20:44:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68A305DDCB; Thu, 25 Oct 2001 20:44:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 24CF05DDBC for ; Thu, 25 Oct 2001 20:44:58 -0400 (EDT) Received: (qmail 6307 invoked by uid 500); 26 Oct 2001 00:29:23 -0000 Date: Thu, 25 Oct 2001 17:29:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 206: ABNF of non-proxiable commands incorrect Message-ID: <20011025172923.F5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: various Rationale/Explanation of issue: Some non-proxyable command code's ABNFs include the Destination-Host and Destination-Realm AVPs, which is invalid according to the definition of these AVPs. The ABNFs need to be cleaned up. From owner-aaa-wg@merit.edu Thu Oct 25 20:45:58 2001 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 UAA03467 for ; Thu, 25 Oct 2001 20:45:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93538912C4; Thu, 25 Oct 2001 20:45:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65162912C1; Thu, 25 Oct 2001 20:45: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 D01E2912B4 for ; Thu, 25 Oct 2001 20:45:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B348B5DDCB; Thu, 25 Oct 2001 20:45:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 665BA5DDBC for ; Thu, 25 Oct 2001 20:45:22 -0400 (EDT) Received: (qmail 6315 invoked by uid 500); 26 Oct 2001 00:29:47 -0000 Date: Thu, 25 Oct 2001 17:29:47 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 207: AAA URI inconsistent Message-ID: <20011025172947.G5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: various Rationale/Explanation of issue: Some examples of the URI in the spec does not include the aaa:// prefix. Add it to the examples. The ABNF definition doesn't include the scheme name (aaa://). Add that as well. From owner-aaa-wg@merit.edu Thu Oct 25 20:46:43 2001 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 UAA03489 for ; Thu, 25 Oct 2001 20:46:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B69DE912C7; Thu, 25 Oct 2001 20:45:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B961912B5; Thu, 25 Oct 2001 20:45: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 A916A912C7 for ; Thu, 25 Oct 2001 20:45:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CE055DDC6; Thu, 25 Oct 2001 20:45:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0719B5DDBC for ; Thu, 25 Oct 2001 20:45:46 -0400 (EDT) Received: (qmail 6332 invoked by uid 500); 26 Oct 2001 00:30:11 -0000 Date: Thu, 25 Oct 2001 17:30:11 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election Message-ID: <20011025173011.H5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: 5.6 Rationale/Explanation of issue: The last state machine statement is incorrect. Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open I-Rcv-DPR I-Snd-DPA, R-Open R-Snd-CEA I-Rcv-CEA R-Snd-DPR I-Open If a CEA is returned with the proper error code, there is no reason to send a DPR. Add the Result-Code value, and remove the DPR here. From owner-aaa-wg@merit.edu Thu Oct 25 20:47:14 2001 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 UAA03515 for ; Thu, 25 Oct 2001 20:47:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A445F912B5; Thu, 25 Oct 2001 20:46:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71EA2912CF; Thu, 25 Oct 2001 20:46:06 -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 3C4EE912B5 for ; Thu, 25 Oct 2001 20:46:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2146A5DDC6; Thu, 25 Oct 2001 20:46:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D28DE5DDBC for ; Thu, 25 Oct 2001 20:46:02 -0400 (EDT) Received: (qmail 6344 invoked by uid 500); 26 Oct 2001 00:30:28 -0000 Date: Thu, 25 Oct 2001 17:30:28 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 209: Authorization-Lifetime inconsistency Message-ID: <20011025173028.I5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base, MIP Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In the base draft, the Authorization-Lifetime set to 0 means immediate re-auth. In the MIP draft 0 means infinity. Fix the MIP draft to be consistent with the base draft. From owner-aaa-wg@merit.edu Thu Oct 25 20:47:55 2001 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 UAA03552 for ; Thu, 25 Oct 2001 20:47:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C4A40912DC; Thu, 25 Oct 2001 20:46:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6124D912D8; Thu, 25 Oct 2001 20:46:33 -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 5229B912D6 for ; Thu, 25 Oct 2001 20:46:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 328575DDC6; Thu, 25 Oct 2001 20:46:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E33C55DDBC for ; Thu, 25 Oct 2001 20:46:26 -0400 (EDT) Received: (qmail 6351 invoked by uid 500); 26 Oct 2001 00:30:52 -0000 Date: Thu, 25 Oct 2001 17:30:52 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 210: Session-Timeout ABNF/Table inconsistency Message-ID: <20011025173052.J5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base, MIP Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In the MIP draft, the use of the Session-Timeout in the command code ABNFs in inconsistent with the table. From owner-aaa-wg@merit.edu Thu Oct 25 20:48:37 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03571 for ; Thu, 25 Oct 2001 20:48:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D3F3912B6; Thu, 25 Oct 2001 20:46:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF0D5912E0; Thu, 25 Oct 2001 20:46:49 -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 70DE4912B6 for ; Thu, 25 Oct 2001 20:46:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 54F965DDCB; Thu, 25 Oct 2001 20:46:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0A2305DDBC for ; Thu, 25 Oct 2001 20:46:45 -0400 (EDT) Received: (qmail 6363 invoked by uid 500); 26 Oct 2001 00:31:10 -0000 Date: Thu, 25 Oct 2001 17:31:10 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 211: When should Destination-Host be present in HAR? Message-ID: <20011025173110.K5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: all Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In the MIP draft, it isn't really clear when the Destination-Host should be present in the HAR when the HA is assigned in a foreign domain. The text and figure need to be cleaned up. From owner-aaa-wg@merit.edu Thu Oct 25 20:48:47 2001 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 UAA03594 for ; Thu, 25 Oct 2001 20:48:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E929912E1; Thu, 25 Oct 2001 20:47:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED293912E9; Thu, 25 Oct 2001 20:47: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 03891912E1 for ; Thu, 25 Oct 2001 20:47:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD39A5DDC6; Thu, 25 Oct 2001 20:47:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2960E5DDCB for ; Thu, 25 Oct 2001 20:47:06 -0400 (EDT) Received: (qmail 6370 invoked by uid 500); 26 Oct 2001 00:31:31 -0000 Date: Thu, 25 Oct 2001 17:31:31 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Message-ID: <20011025173131.L5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: MIP Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Once a mobile has been assigned a home agent, if a subsequent HAR is to be sent, a new AAAH has no way to map the IP address in the registration request to a Destination-Host AVP of the Home Agent. Fix The GNAIE ID is being updated to reflect comments of the IESG. In this document we will specify that the HA may include its NAI in the Registration Reply, and if so, the mobile node must include the same extension in subsequent registration requests. This will require some Mobile IP WG involvement. From owner-aaa-wg@merit.edu Thu Oct 25 20:49:55 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03619 for ; Thu, 25 Oct 2001 20:49:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1523D912F1; Thu, 25 Oct 2001 20:47:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96B44912EB; Thu, 25 Oct 2001 20:47: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 87A65912E7 for ; Thu, 25 Oct 2001 20:47:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 644145DDC6; Thu, 25 Oct 2001 20:47:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 216AA5DDBC for ; Thu, 25 Oct 2001 20:47:30 -0400 (EDT) Received: (qmail 6382 invoked by uid 500); 26 Oct 2001 00:31:55 -0000 Date: Thu, 25 Oct 2001 17:31:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 213: MN-AAA SPI must be included in the HAR message Message-ID: <20011025173155.M5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: MIP Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: The Home Agent needs to have access to the MN-AAA SPI in order to create the Mobile AAA key extensions. This information is not sent by the AAAH to the home agent. Therefore the AAAH must include the MIP-MN-AAA-SPI AVP in the HAR to the HA. From owner-aaa-wg@merit.edu Thu Oct 25 20:53:11 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03676 for ; Thu, 25 Oct 2001 20:53:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E2B0A912B8; Thu, 25 Oct 2001 20:47:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC56C912F3; Thu, 25 Oct 2001 20:47: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 3E568912B8 for ; Thu, 25 Oct 2001 20:47:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20F285DDC6; Thu, 25 Oct 2001 20:47:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D1CC15DDBC for ; Thu, 25 Oct 2001 20:47:48 -0400 (EDT) Received: (qmail 6390 invoked by uid 500); 26 Oct 2001 00:32:14 -0000 Date: Thu, 25 Oct 2001 17:32:14 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 214: Unknown-User Result-Code provides too much info Message-ID: <20011025173214.N5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: 7.1 Rationale/Explanation of issue: Some text should be provided in the Result-Code value to state that an alternative is to use Authentication-Failure. It is felt that Unknown User provides too much info, and could lead to certain types of attacks. From owner-aaa-wg@merit.edu Thu Oct 25 20:53:26 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03692 for ; Thu, 25 Oct 2001 20:53:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A393291302; Thu, 25 Oct 2001 20:48:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65FAF91300; Thu, 25 Oct 2001 20:48:18 -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 B9753912FB for ; Thu, 25 Oct 2001 20:48:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C3065DDC6; Thu, 25 Oct 2001 20:48:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 454525DDBC for ; Thu, 25 Oct 2001 20:48:12 -0400 (EDT) Received: (qmail 6402 invoked by uid 500); 26 Oct 2001 00:32:37 -0000 Date: Thu, 25 Oct 2001 17:32:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 215: use of hmac-md5 is incorrect Message-ID: <20011025173237.O5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base, aaa-keys Comment type: Technical Priority: 1 Section: 7.1 Rationale/Explanation of issue: Need to make use that the use of md5 and hmac-md5 is consistent across both drafts. The latest aaa-keys uses hmac-md5, but uses the incorrect function prototype (it uses hmac-md5 with a prefix+suffix mode). From owner-aaa-wg@merit.edu Thu Oct 25 20:53:42 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03713 for ; Thu, 25 Oct 2001 20:53:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E471D912BA; Thu, 25 Oct 2001 20:48:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 486F391300; Thu, 25 Oct 2001 20:48:39 -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 C1A05912BA for ; Thu, 25 Oct 2001 20:48:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A932D5DDBC; Thu, 25 Oct 2001 20:48:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 633B35DDC6 for ; Thu, 25 Oct 2001 20:48:32 -0400 (EDT) Received: (qmail 6409 invoked by uid 500); 26 Oct 2001 00:32:57 -0000 Date: Thu, 25 Oct 2001 17:32:57 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 216: Home Agent MUST support home address allocation Message-ID: <20011025173257.P5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: MIP Comment type: Technical Priority: 1 Section: 1.2 Rationale/Explanation of issue: The draft doesn't actually state that the Home Agent MUST support home address allocation, but the draft does state that the AAAH MAY do it. The lack of a MUST can cause interoperability problems From owner-aaa-wg@merit.edu Thu Oct 25 20:53:49 2001 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 UAA03723 for ; Thu, 25 Oct 2001 20:53:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 432179130D; Thu, 25 Oct 2001 20:50:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 726AB9131B; Thu, 25 Oct 2001 20:50: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 C0A9D9130D for ; Thu, 25 Oct 2001 20:48:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A05E55DDC6; Thu, 25 Oct 2001 20:48:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5E0F45DDBC for ; Thu, 25 Oct 2001 20:48:52 -0400 (EDT) Received: (qmail 6421 invoked by uid 500); 26 Oct 2001 00:33:17 -0000 Date: Thu, 25 Oct 2001 17:33:17 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 217: typo in MIP section 3.2 Message-ID: <20011025173317.Q5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: MIP Comment type: Technical Priority: 4 Section: 3.2 Rationale/Explanation of issue: In section 3.2, the term foreign agent should read foreign domain. From owner-aaa-wg@merit.edu Thu Oct 25 20:53:50 2001 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 UAA03743 for ; Thu, 25 Oct 2001 20:53:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC22891312; Thu, 25 Oct 2001 20:50:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74D6291327; Thu, 25 Oct 2001 20:50:40 -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 793CE91312 for ; Thu, 25 Oct 2001 20:49:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5BCC55DDC6; Thu, 25 Oct 2001 20:49:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1A5F35DDBC for ; Thu, 25 Oct 2001 20:49:11 -0400 (EDT) Received: (qmail 6432 invoked by uid 500); 26 Oct 2001 00:33:36 -0000 Date: Thu, 25 Oct 2001 17:33:36 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 218: ABNF/Table inconsistencies Message-ID: <20011025173336.R5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: all Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In some drafts, there are inconsistencies between the ABNF and the command code tables at the end of the spec. From owner-aaa-wg@merit.edu Thu Oct 25 20:54:21 2001 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 UAA03768 for ; Thu, 25 Oct 2001 20:54:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5D499131E; Thu, 25 Oct 2001 20:51:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B66A91327; Thu, 25 Oct 2001 20:51: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 114B191300 for ; Thu, 25 Oct 2001 20:49:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 351E05DDC6; Thu, 25 Oct 2001 20:49:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E4B955DDBC for ; Thu, 25 Oct 2001 20:49:27 -0400 (EDT) Received: (qmail 6439 invoked by uid 500); 26 Oct 2001 00:33:53 -0000 Date: Thu, 25 Oct 2001 17:33:53 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 219: AMA AVP issue when failure occurs on AAAH Message-ID: <20011025173353.S5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: MIP Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: If the mobile is not authenticated successfully (or some other error occurs on AAAH), the ABNF requires some AVPs that may not be available. From owner-aaa-wg@merit.edu Thu Oct 25 20:54:30 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03783 for ; Thu, 25 Oct 2001 20:54:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 883E291329; Thu, 25 Oct 2001 20:51:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDD479132A; Thu, 25 Oct 2001 20:51: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 F1E5D91329 for ; Thu, 25 Oct 2001 20:50:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7A975DDC6; Thu, 25 Oct 2001 20:50:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 52D8B5DDBC for ; Thu, 25 Oct 2001 20:50:53 -0400 (EDT) Received: (qmail 6472 invoked by uid 500); 26 Oct 2001 00:35:18 -0000 Date: Thu, 25 Oct 2001 17:35:18 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 223: How does CMS work if the HA is unknown and in foreign network Message-ID: <20011025173518.W5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: MIP Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: The Mobile IP extension allows the foreign network to specify whether it is willing to provide a home agent. However, if the AAAH wants to setup a DSA with the Home Agent, how can it do that since it doesn't know the URI of the HA. Fix When the AAAF states it is willing to allocate an HA in its domain, it includes the URI in a new AVP, called Candidate-Home-Agent-Host. From owner-aaa-wg@merit.edu Thu Oct 25 20:55:07 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03811 for ; Thu, 25 Oct 2001 20:55:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0753491327; Thu, 25 Oct 2001 20:51:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 270B591300; Thu, 25 Oct 2001 20: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 04E0F9130C for ; Thu, 25 Oct 2001 20:50:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB8855DDC6; Thu, 25 Oct 2001 20:50:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 588855DDBC for ; Thu, 25 Oct 2001 20:50:33 -0400 (EDT) Received: (qmail 6465 invoked by uid 500); 26 Oct 2001 00:34:58 -0000 Date: Thu, 25 Oct 2001 17:34:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 222: Routing Within a Domain Message-ID: <20011025173458.V5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In a hierarchical network (meaning that there are agents between the access device and the destination) when all peers are in the same administrative domain, routing isn't guaranteed to work. Fix When a hierarchy exists, a sub-domain should be used (e.g. sub.domain.com). Just add text to make this clear in the routing section. With Longest-Match- From-Right (already in the spec), this feature works fine. From owner-aaa-wg@merit.edu Thu Oct 25 20:55:10 2001 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 UAA03822 for ; Thu, 25 Oct 2001 20:55:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C2429131B; Thu, 25 Oct 2001 20:51:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 272F191322; Thu, 25 Oct 2001 20:50:49 -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 38B339131A for ; Thu, 25 Oct 2001 20:49:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F029C5DDC6; Thu, 25 Oct 2001 20:49:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AE37D5DDBC for ; Thu, 25 Oct 2001 20:49:49 -0400 (EDT) Received: (qmail 6447 invoked by uid 500); 26 Oct 2001 00:34:15 -0000 Date: Thu, 25 Oct 2001 17:34:15 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 220: Not possible to dynamically update capabilities Message-ID: <20011025173415.T5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: base Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: The draft does not allow a peer to update its capabilities. Some folks believe this is problematic when the capabilities change over time. Currently, it would require that the transport be disconnected and re-established. Fix Allow a CER to be sent while in the open state. From owner-aaa-wg@merit.edu Thu Oct 25 20:55:38 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03847 for ; Thu, 25 Oct 2001 20:55:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D4C79130C; Thu, 25 Oct 2001 20:51:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98BB79131B; Thu, 25 Oct 2001 20:50: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 DFD119131E for ; Thu, 25 Oct 2001 20:50:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A32925DDBC; Thu, 25 Oct 2001 20:50:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5F22F5DDC6 for ; Thu, 25 Oct 2001 20:50:12 -0400 (EDT) Received: (qmail 6458 invoked by uid 500); 26 Oct 2001 00:34:37 -0000 Date: Thu, 25 Oct 2001 17:34:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 221: Why require CMS to send it's expected AVPs? Message-ID: <20011025173437.U5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 25-Oct-01 Reference: Document: cms Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Each Diameter application states which AVPs should be encrypted and which can be signed. Since this is possible, why bother requiring that the DSAR sender to include what AVPs it expects to have signed/encrypted? Isn't the AVP definition sufficient? From owner-aaa-wg@merit.edu Thu Oct 25 20:55:53 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03870 for ; Thu, 25 Oct 2001 20:55:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AD1C91338; Thu, 25 Oct 2001 20:54:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DF3C91337; Thu, 25 Oct 2001 20:54: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 4C9B291339 for ; Thu, 25 Oct 2001 20:54:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3F155DDDA; Thu, 25 Oct 2001 20:53:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5FA725DDEC for ; Thu, 25 Oct 2001 20:53:33 -0400 (EDT) Received: (qmail 6487 invoked by uid 500); 26 Oct 2001 00:37:43 -0000 Date: Thu, 25 Oct 2001 17:37:43 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: That's it folks Message-ID: <20011025173743.X5663@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, This week was the Diameter bake-off, and I met the folks there today. These are the issues that they found during test. Unfortunately, we had finally gotten down to zero, and just opened up another 20 or so. I will try to address these as quickly as possible to get the next version of the specs out. Many of these are fairly trivial, but a couple in there are a little more complex. Getting quick confirmation from folks on the list would be most helpful, and would help get to quick resolution. Thanks to all of the folks that were at the bakeoff and found these issues! PatC From owner-aaa-wg@merit.edu Thu Oct 25 22:42:55 2001 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 WAA06936 for ; Thu, 25 Oct 2001 22:42:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC792912BB; Thu, 25 Oct 2001 22:42:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C14B912BD; Thu, 25 Oct 2001 22:42: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 5C281912BB for ; Thu, 25 Oct 2001 22:41:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B5975DDC4; Thu, 25 Oct 2001 22:41:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A92E85DD8F for ; Thu, 25 Oct 2001 22:41:58 -0400 (EDT) Received: (qmail 6746 invoked by uid 500); 26 Oct 2001 02:26:23 -0000 Date: Thu, 25 Oct 2001 19:26:23 -0700 From: Pat Calhoun To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Why does AAAF generate keys when HA is in a foreign domain? Message-ID: <20011025192623.B5663@charizard.diameter.org> Mail-Followup-To: Mark Eklund , aaa-wg@merit.edu References: <200110251720.NAA27403@knox6039.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200110251720.NAA27403@knox6039.cisco.com>; from meklund@cisco.com on Thu, Oct 25, 2001 at 01:20:17PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Why should the AAAH be aware of keys between nodes in another network? Just so that it can hack them? I know for a fact that the security ADs would have serious security concerns about someone not involved in the transactions, and in another domain, be involved in key generation when it shouldn't. PatC On Thu, Oct 25, 2001 at 01:20:17PM -0400, Mark Eklund wrote: > All, > > I just sent out an issue, "ISSUE: MIP-FA-to-HA being added to the AMA > by the AAAF" that deals with the fact that when the HA is in the > foreign domain, the AAAF generates the FA-to-HA keys. I'm just > curious what keeps us from being consistent and always having the AAAH > generate the keys. > > Is there a problem with the AAAH knowing what the FA-to-HA key for > that session will be? What kind of security issues would this create? > > -mark > From owner-aaa-wg@merit.edu Thu Oct 25 23:34:05 2001 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 XAA07748 for ; Thu, 25 Oct 2001 23:34:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55CEF912C3; Thu, 25 Oct 2001 23:33:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 253D7912CD; Thu, 25 Oct 2001 23:33: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 E3D97912C3 for ; Thu, 25 Oct 2001 23:33:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C73955DDC4; Thu, 25 Oct 2001 23:33:17 -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 3F2A65DD8F for ; Thu, 25 Oct 2001 23:33:17 -0400 (EDT) Received: (qmail 23425 invoked by uid 500); 26 Oct 2001 03:51:31 -0000 Date: Thu, 25 Oct 2001 22:51:31 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 224: Handling errors in the TCP stream Message-ID: <20011025225130.B23269@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: David Frascone Submitter email address: dave@frascone.com Date first submitted: 25-Oct-01 Reference: Document: Base Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Since TCP is stream oriented, an error in the stream is completely un-recoverable. Therefore, when an error is detected in the stream, the connection must be closed. Errors can be detected by reserved bits being set, avp lengths being less than the size of an AVP header, or greater than the diameter message length. There was no input on whether or not to first send a response. Since an error can occur in a request or in an answer, I think closing the connection without sending a response is acceptable. From owner-aaa-wg@merit.edu Fri Oct 26 03:27:49 2001 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 DAA24977 for ; Fri, 26 Oct 2001 03:27:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C9D0912D6; Fri, 26 Oct 2001 03:25:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7017091300; Fri, 26 Oct 2001 03:25: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 A8BB7912D6 for ; Fri, 26 Oct 2001 03:25:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D4CC5DD99; Fri, 26 Oct 2001 03:25:00 -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 6DD415DD9E for ; Fri, 26 Oct 2001 03:24:59 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9Q7PYA19856 for ; Fri, 26 Oct 2001 10:25:35 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Oct 2001 10:24:57 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 26 Oct 2001 10:24:57 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719804D@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: Erik.Guttman@sun.com Cc: jaakko.rajaniemi@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Fri, 26 Oct 2001 10:24:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Erik, > It gets worse the more options you have. If there are 3 rules > which have 3 options each, there are 9 valid combinations. Are > all valid? Things get ugly if the options aren't independent. > Further, more options make interoperation harder to verify and > protocol implementations more complex and less likely to be > hardened. > If the command definition needs all those options they are going to be there in a form or another. With the current grammar some AVPs will be made mandatory (and they are included even if that would be unnecessary) and the rest optional. Natural language text in the command definition will then lay out the rules on the interrelationships of these AVPs, specifying when each optional AVP should be included, etc. The proposed change would enable making these rules more formally defined and easier to see from the command definition itself. It will increase the complexity of the ABNF format of the command definition, but will make the intended syntax of the command more explicit, and the command definition more understandable. The overall complexity of the command definition and it's implementation should not change. > > > This would require a rewrite of all Diameter specs. This > is not only > > > editorial work. It would require quite a bit of > technical review to > > > make sure it remained equivalent to the old representation. > > > > > > > I though that the rules I presented were backwards > compatible. The current > > way of placing each AVP in it's own brackets is still covered by the > > proposed new grammar rules. Hence the grammar rules in the > Base Diameter is > > the only place that needs to be changed. > > If so - why do you want to introduce this change?!? To ease the way > for protocol complexity in the future? :/ > To enable more explicit command definitions in the future, where more of the command syntax is being described by the ABNF rather than the English text accompanying it. But to respond to Pat's comment, I am not aware of an existing bug in the current Diameter specs that this would be a solution for. All the possible bugs can be fixed just as well by fine tuning the English describing the command :-) Jarno From owner-aaa-wg@merit.edu Fri Oct 26 10:08:50 2001 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 KAA04206 for ; Fri, 26 Oct 2001 10:08:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E46D39120C; Fri, 26 Oct 2001 10:08:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC50D912EF; Fri, 26 Oct 2001 10:08: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 2E3849120C for ; Fri, 26 Oct 2001 10:08:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 077785DDC5; Fri, 26 Oct 2001 10:08:26 -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 3751B5DDAD for ; Fri, 26 Oct 2001 10:08:25 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA10945; Fri, 26 Oct 2001 10:07:51 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id KAA10594; Fri, 26 Oct 2001 10:08:52 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15321.28276.586611.636534@gargle.gargle.HOWL> Date: Fri, 26 Oct 2001 10:08:52 -0400 To: Pat Calhoun Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Why does AAAF generate keys when HA is in a foreign domain? In-Reply-To: <20011025192623.B5663@charizard.diameter.org> References: <200110251720.NAA27403@knox6039.cisco.com> <20011025192623.B5663@charizard.diameter.org> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, Pat Calhoun writes: > Why should the AAAH be aware of keys between nodes in another network? Just I'm just trying to find a viable alternative to the AAAF having to cache the key it generated when it received a HAR until it receives an AMR. > so that it can hack them? I know for a fact that the security ADs would have The AAAH is already aware of the MN-FA key and the MN-HA key. I'm just trying to determine what security risk also knowing the FA-HA key would be. This key will only be associated with that one session associated with that mobile node. I guess if the AAAH has access to all the keys and can break into the foreign domain, and sniff the data transfer between the HA and the FA, it could then listen to everything said by the mobile node. So if listening in on the MN traffic when the MN is in the foreign domain is a worry, we definitely should not allow the AAAH to have access to the HA-FA key. Remember though that when the HA is in the foreign domain, the AAAF will have all keys, so it can listen in on the conversation. When the HA is in the home domain, the AAAH wil have access to all the keys and it can also listen in on the conversation. Is there something else that could be revealed in the HA-FA conversation that needs to be protected? -mark > serious security concerns about someone not involved in the transactions, > and in another domain, be involved in key generation when it shouldn't. > > PatC > On Thu, Oct 25, 2001 at 01:20:17PM -0400, Mark Eklund wrote: > > All, > > > > I just sent out an issue, "ISSUE: MIP-FA-to-HA being added to the AMA > > by the AAAF" that deals with the fact that when the HA is in the > > foreign domain, the AAAF generates the FA-to-HA keys. I'm just > > curious what keeps us from being consistent and always having the AAAH > > generate the keys. > > > > Is there a problem with the AAAH knowing what the FA-to-HA key for > > that session will be? What kind of security issues would this create? > > > > -mark > > From owner-aaa-wg@merit.edu Fri Oct 26 11:27:47 2001 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 LAA07088 for ; Fri, 26 Oct 2001 11:27:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E74912F9; Fri, 26 Oct 2001 11:27:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 503D5912FA; Fri, 26 Oct 2001 11:27:22 -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 13BA4912F9 for ; Fri, 26 Oct 2001 11:27:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE6FF5DDE3; Fri, 26 Oct 2001 11:27:20 -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 0F3D75DDDB for ; Fri, 26 Oct 2001 11:27:20 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id QAA24746 for ; Fri, 26 Oct 2001 16:27:17 +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 ; Fri, 26 Oct 2001 16:23:50 +0100 Received: from baltimore.ie (wks149-6.ie.baltimore.com [10.153.6.149]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA31007; Fri, 26 Oct 2001 16:29:58 +0100 Message-ID: <3BD980E0.2F6EF2FC@baltimore.ie> Date: Fri, 26 Oct 2001 16:27:28 +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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 221: Why require CMS to send it's expected AVPs? References: <20011025173437.U5663@charizard.diameter.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, Don't we support vendor-specific AVPs or any AVPs where encryption is optional? Similarly, won't requiring/not-requiring a signature over a given AVP be a matter of local policy? Any of the above makes the expected-* worthwhile IMHO. If none of the above apply, you're right, we could do without 'em. Stephen. Pat Calhoun wrote: > > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: cms > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > Each Diameter application states which AVPs should be encrypted and which > can be signed. Since this is possible, why bother requiring that the DSAR > sender to include what AVPs it expects to have signed/encrypted? Isn't > the AVP definition sufficient? -- ____________________________________________________________ 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 Fri Oct 26 12:54:36 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10818 for ; Fri, 26 Oct 2001 12:54:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 280EE9132D; Fri, 26 Oct 2001 12:52:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8ED0E91335; Fri, 26 Oct 2001 12:52: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 BE7B79133A for ; Fri, 26 Oct 2001 12:51:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F1B25DDC5; Fri, 26 Oct 2001 12:51:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 8B9CB5DDA7 for ; Fri, 26 Oct 2001 12:51:28 -0400 (EDT) Received: from phoenix (unknown [208.224.156.67]) by aaa.interlinknetworks.com (Postfix) with SMTP id CD4D882; Fri, 26 Oct 2001 12:51:27 -0400 (EDT) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: ISSUE: Specify Statefulness/Statelessness Requirements Date: Fri, 26 Oct 2001 12:49:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: October 26,2001 Reference: None Document: draft-ietf-aaa-diameter-mobileip-08-alpha01 Comment type: T Priority: 1 Section: 1, 1.2, 1.4 Rationale/Explanation of issue: The Mobile-IP Diameter draft is fuzzy regarding statefulness/statelessness requirements. Implementers are left to infer the requirements. Some people have inferred that an AAA home server must maintain session state, others have not made that inference. Requested change: Specify the statefulness/statelessness requirements. If it is true that maintaining session-state is not required, then amend the draft as follows: 1. Up front, somewhere in the "Introduction" section, add the following text: "A AAA home server which supports the Mobile-IP authentication application MAY maintain session-state or MAY be session-stateless. A AAA foreign server which supports the Mobile-IP authentication application MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST not maintain session-state. AAA home and foreign servers, as well as AAA proxies and relays, MUST maintain transaction state." 2. Section 1.2 "Inter-Domain Mobile IP", says: "During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see figure 2). Of course, the AAAH MUST use the same session identifier for all HARs initiated on behalf of a given mobile node's session." Remove the 2nd sentence, which begins "Of course ...". 3. Section 1.2 "Inter-Domain Mobile IP", also says: "For new sessions, the AAAH MUST create an accounting session identifier, which is added to the Accounting-Multi-Session-Id AVP in the HAR message sent to the home agent." Remove the phrase "For new sessions" from the first sentence, so that the text reads: "The AAAH MUST create an accounting session identifier, which is added to the Accounting-Multi-Session-Id AVP in the HAR message sent to the home agent." 4 Section 1.4 "Allocation of Home Agent in Foreign Network", says" "Figure 7 shows the message flows for a Mobile Node requesting to keep the Home Agent assigned in Foreign network 1 when it moves to foreign network 2. [...]. If the Mobile Node was successfully authenticated the AAAH checks for the Origin-Host and the value of the Origin-Host of the previous request. If a AAAH deduces that the Mobile Node has moved to a new realm, it must check whether the Mobile can still use the previously assigned Home Agent." Change the sentence "If the Mobile Node was successfully authenticated the AAAH checks for the Origin-Host and the value of the Origin-Host of the previous request." to "If the Mobile Node was successfully authenticated, a session-stateful AAAH checks for the Origin-Host and the value of the Origin-Host of the previous request." and add some text describing how a session-stateless AAAH server deduces that the Mobile Node has moved to a new foreign realm. From owner-aaa-wg@merit.edu Fri Oct 26 13:08:59 2001 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 NAA11312 for ; Fri, 26 Oct 2001 13:08:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AFE839136A; Fri, 26 Oct 2001 13:03:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73D0791354; Fri, 26 Oct 2001 12:57: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 B9F9F91344 for ; Fri, 26 Oct 2001 12:53:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E86265DDD5; Fri, 26 Oct 2001 12:53:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 8BFE15DDA7 for ; Fri, 26 Oct 2001 12:53:32 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9QGrJQ24207 for ; Fri, 26 Oct 2001 11:53:19 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 26 Oct 2001 11:53:15 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 26 Oct 2001 11:53:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Date: Fri, 26 Oct 2001 11:53:16 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF444CCF62@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Thread-Index: AcFdt/eZh7w07smoEdWBTgBQi2X+DwAhjuDQ From: "Patil Basavaraj (NET/Dallas)" To: "'ext Pat Calhoun'" , Cc: "'Mobile IP'" X-OriginalArrivalTime: 26 Oct 2001 16:53:15.0461 (UTC) FILETIME=[B4A26750:01C15E3E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA11312 Pat, The GNAIE I-D is in the process of being deprecated as a WG document. So refering to the GNAIE as a way to fix it may not be the solution. As I have pointed out to you and the other authors of the GNAIE I-D, the I-D that needs a specific NAI extension ought to define it rather than having a placeholder for extensions I-D which is reference by others. The FA-NAI specified in GNAIE should (or can) be specified in the reg-tun I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 I-D. So far the HA-NAI has not been really shown as a requirement by any other I-Ds in the Mobile IP WG. -Basavaraj > > > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: MIP > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > Once a mobile has been assigned a home agent, if a subsequent > HAR is to > be sent, a new AAAH has no way to map the IP address in the > registration > request to a Destination-Host AVP of the Home Agent. > > Fix > > The GNAIE ID is being updated to reflect comments of the IESG. In this > document we will specify that the HA may include its NAI in the > Registration Reply, and if so, the mobile node must include > the same extension > in subsequent registration requests. This will require some > Mobile IP WG > involvement. > From owner-aaa-wg@merit.edu Fri Oct 26 13:12:56 2001 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 NAA11445 for ; Fri, 26 Oct 2001 13:12:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A9D0A91380; Fri, 26 Oct 2001 13:12:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8E2F9137B; Fri, 26 Oct 2001 13:08: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 B5F1491380 for ; Fri, 26 Oct 2001 13:05:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A9885DDC5; Fri, 26 Oct 2001 13:05:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from h002.d148.aaa.com.148.168.192.in-addr.arpa (unknown [208.224.156.67]) by segue.merit.edu (Postfix) with ESMTP id 149555DDA7 for ; Fri, 26 Oct 2001 13:05:46 -0400 (EDT) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by h002.d148.aaa.com.148.168.192.in-addr.arpa (8.11.0/8.11.0) with ESMTP id f9QH4kw01221 for ; Fri, 26 Oct 2001 13:04:46 -0400 Message-ID: <3BD997AD.7AE6CF1C@interlinknetworks.com> Date: Fri, 26 Oct 2001 13:04:46 -0400 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 221: Why require CMS to send it's expected AVPs? References: <20011025173437.U5663@charizard.diameter.org> <3BD980E0.2F6EF2FC@baltimore.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Stephen, I see Pat hasn't responded yet so I thought I'd wiegh in with my 2 cents. >Don't we support vendor-specific AVPs or any AVPs where encryption >is optional? Vendor-specific AVPs should have AVP definitions just like standard AVPs. I don't know of any cases where encryption of an AVP should be optional when a DSA is in place. I am very interested in any examples where encryption of an AVP should be optional. Even if encryption is optional, why not leave it up to the sender's local policy. After all, the sender is the source of the sensitive data. The receiver will be able to decipher the AVP whether it is encrypted or not. >Similarly, won't requiring/not-requiring a signature over a given AVP be >a matter of local policy? It seems like a reasonable simplification to just always sign when a DSA is in place. A Diameter node can ignore signatures if it chooses. Thanks, Don Stephen Farrell wrote: > Pat, > > Don't we support vendor-specific AVPs or any AVPs where encryption > is optional? Similarly, won't requiring/not-requiring a signature > over a given AVP be a matter of local policy? > > Any of the above makes the expected-* worthwhile IMHO. If none > of the above apply, you're right, we could do without 'em. > > Stephen. > > Pat Calhoun wrote: > > > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: 25-Oct-01 > > Reference: > > Document: cms > > Comment type: Technical > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > Each Diameter application states which AVPs should be encrypted and which > > can be signed. Since this is possible, why bother requiring that the DSAR > > sender to include what AVPs it expects to have signed/encrypted? Isn't > > the AVP definition sufficient? > > -- > ____________________________________________________________ > 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 Fri Oct 26 13:25:09 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11762 for ; Fri, 26 Oct 2001 13:25:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE1B2913C8; Fri, 26 Oct 2001 13:23:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A3C8913CE; Fri, 26 Oct 2001 13:23: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 D8930913CC for ; Fri, 26 Oct 2001 13:22:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF6625DDC5; Fri, 26 Oct 2001 13:22:42 -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 D8C505DDA7 for ; Fri, 26 Oct 2001 13:22:41 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA26080 for ; Fri, 26 Oct 2001 18:22:40 +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 ; Fri, 26 Oct 2001 18:19:12 +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 SAA00749; Fri, 26 Oct 2001 18:25:18 +0100 Message-ID: <3BD99BE7.80644867@baltimore.ie> Date: Fri, 26 Oct 2001 18:22:47 +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: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 221: Why require CMS to send it's expected AVPs? References: <20011025173437.U5663@charizard.diameter.org> <3BD980E0.2F6EF2FC@baltimore.ie> <3BD997AD.7AE6CF1C@interlinknetworks.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 Don, > >Don't we support vendor-specific AVPs or any AVPs where encryption > >is optional? > > Vendor-specific AVPs should have AVP definitions just like standard AVPs. Yes, but say that an intermediary (some "boundary" server) is the DSA endpoint, where the intermidiary itself doesn't know about the AVP? I suppose this argument would also apply to anything that's not part of the base spec. (or am I wrong that such "ignorant intermediaries" are allowed?). > I don't know of any cases where encryption of an AVP should be optional when > a DSA is in place. I am very interested in any examples where encryption > of an AVP should be optional. Fair enough. If there're none, there're none. > Even if encryption is optional, why not leave it up to the sender's local > policy. After all, the sender is the source of the sensitive data. The > receiver will be able to decipher the AVP whether it is encrypted or not. I could imagine that the sender & recipient's policies will differ as to what's sensitive - the expected-* stuff allows us to help there. > >Similarly, won't requiring/not-requiring a signature over a given AVP be > >a matter of local policy? > > It seems like a reasonable simplification to just always sign when a DSA is in > place. A Diameter node can ignore signatures if it chooses. True, but maybe a bit computationally intensive. 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 Fri Oct 26 13:39:53 2001 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 NAA12375 for ; Fri, 26 Oct 2001 13:39:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A417A913CC; Fri, 26 Oct 2001 13:38:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC10391416; Fri, 26 Oct 2001 13:38:40 -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 D8EAD913E2 for ; Fri, 26 Oct 2001 13:26:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDF3E5DDC5; Fri, 26 Oct 2001 13:26:33 -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 F01D75DDA7 for ; Fri, 26 Oct 2001 13:26:32 -0400 (EDT) Received: from knox6046.cisco.com (knox6046.cisco.com [161.44.216.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA16030; Fri, 26 Oct 2001 13:25:55 -0400 (EDT) Received: (from srich@localhost) by knox6046.cisco.com (8.11.3/8.11.3) id f9QHQQJ81967; Fri, 26 Oct 2001 13:26:26 -0400 (EDT) (envelope-from srich) From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15321.40130.221122.51372@knox6046.cisco.com> Date: Fri, 26 Oct 2001 13:26:26 -0400 To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 224: Handling errors in the TCP stream In-Reply-To: <20011025225130.B23269@newman.frascone.com> References: <20011025225130.B23269@newman.frascone.com> X-Mailer: VM 6.93 under Emacs 21.0.106.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with this. sjr David Frascone writes: > Submitter name: David Frascone > Submitter email address: dave@frascone.com > Date first submitted: 25-Oct-01 > Reference: > Document: Base > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > Since TCP is stream oriented, an error in the stream is completely > un-recoverable. Therefore, when an error is detected in the stream, the > connection must be closed. > > Errors can be detected by reserved bits being set, avp lengths being > less than the size of an AVP header, or greater than the diameter message > length. > > There was no input on whether or not to first send a response. Since > an error can occur in a request or in an answer, I think closing the > connection without sending a response is acceptable. > > From owner-aaa-wg@merit.edu Fri Oct 26 13:44:04 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12588 for ; Fri, 26 Oct 2001 13:44:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13C2E9140D; Fri, 26 Oct 2001 13:38:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA4CB91410; Fri, 26 Oct 2001 13:38: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 F05129140D for ; Fri, 26 Oct 2001 13:37:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6E485DDC8; Fri, 26 Oct 2001 13:37:35 -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 091B35DDC5 for ; Fri, 26 Oct 2001 13:37:35 -0400 (EDT) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA16362; Fri, 26 Oct 2001 13:37:02 -0400 (EDT) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id NAA10749; Fri, 26 Oct 2001 13:38:01 -0400 (EDT) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15321.40825.298452.952075@gargle.gargle.HOWL> Date: Fri, 26 Oct 2001 13:38:01 -0400 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the AAAF In-Reply-To: <15320.16169.573651.659223@gargle.gargle.HOWL> References: <15320.16169.573651.659223@gargle.gargle.HOWL> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Because of concerns about the AAAH having access to the FA-HA key when the HA is in the foreign domain, the solution offered by this issue doesn't work. How about a similar answer, but one that allows security? Add the AVP MIP-HAA-to-AMA-Data which is opaque data of type OctetString. This AVP is added to the HAA by the AAAF. On receipt of a successful HAA, the AAAH must move this AVP from the HAA to the AMA. This allows the AAAF to put any needed key information in the HAA and have it available in the AMA. If the AAAF is worried about security, it can encrypt this information in any way it wants. -mark Mark Eklund writes: > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 25-Oct-01 > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html > Document: mobileip > Comment type: Technical > Priority: 1 > Section: 2.4, 5.3, 8.1 > Rationale/Explanation of issue: > > When the HA is in the foreign network and a FA-HA key is requested, > the AAAF generates the key. The AAAF is then responsible for adding > the MIP-FA-to-HA Key to the AMA. This means that the AAAF must > maintain a list containing all MIP-FA-to-HA Key AVPs and their > matching Accounting-Multi-Session-Id AVPs. When each AMA is received, > the AAAF must then consult the list and when it finds a matching > Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA. > > Requested change: > > Instead of requiring the AAAF to add the MIP-FA-to-HA Key AVP to the > AMA, send the MIP-FA-to-HA Key back in the HAA. The AAAH then can > move the MIP-FA-to-HA Key from the HAA to the AMA. > > Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4. > Change MIP-Feature-Vector column HAR = 0-1 to section 8.1 > Change MIP-FA-to-HA-Key column HAA = 0-1 to section 8.1 > > Change the final paragraph of section 5.3 to > > Upon receipt of the HAA, the Diameter server responsible for key > allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the > MIP-FA-to-HA-SPI. If the key is generated at the AAAF, it adds the > MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH. > Depending upon where the HA was located the AAAH either generates the > MIP-FA-to-HA Key AVP itself or extracts the AVP from the HAA sent > by the AAAF. The AAAH adds the MIP-FA-to-HA Key to the AMA. > > -mark From owner-aaa-wg@merit.edu Fri Oct 26 15:25:34 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16925 for ; Fri, 26 Oct 2001 15:25:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77D92913B1; Fri, 26 Oct 2001 15:23:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2242F913D0; Fri, 26 Oct 2001 15:23:49 -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 85E2A913B1 for ; Fri, 26 Oct 2001 15:23:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 697275DDC8; Fri, 26 Oct 2001 15:23:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from h002.d148.aaa.com.148.168.192.in-addr.arpa (unknown [208.224.156.67]) by segue.merit.edu (Postfix) with ESMTP id D8A1B5DDC1 for ; Fri, 26 Oct 2001 15:23:37 -0400 (EDT) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by h002.d148.aaa.com.148.168.192.in-addr.arpa (8.11.0/8.11.0) with ESMTP id f9QJIXw01726 for ; Fri, 26 Oct 2001 15:18:33 -0400 Message-ID: <3BD9B708.734327F2@interlinknetworks.com> Date: Fri, 26 Oct 2001 15:18:32 -0400 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: CMS Security and TLS Certificates Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA16925 It would be nice if the same certificates could be used for both TLS and CMS Security. In order to allow for this, Diameter over TLS and CMS Security should interpret the certificate dNSName in the same way. (The Diameter base draft does not currently address how the certificate dNSName should be used.) From the CMS Security Application draft, section 3.2: >3.2 Certificate Requirements > > Certificates used for the purposes of Diameter MUST conform to the > PKIX profile [4], and MUST also include a Diameter node's FQDN, which > is typically added in the Origin-Host AVP [1], as one of the values > of the subjectAltName extension of the Certificate. The FQDN is to > be encoded as a dNSName within the subjectAltName. > > For Diameter nodes (capable of acting as recipients for > confidentiality), the FQDN MUST be of the form > "Diameter-.". Other Diameter nodes MAY use this naming > scheme. Note that this naming constraint is for PKI purposes only, >. and in no way restricts a Diameter's host name. The CMS Security application requires that the dNSName be set to "Diameter-.". Rather than using this syntax, could we set the dNSName to the Diameter-Identity string defined in the base draft and make this a requirement for both TLS over Diameter and CMS Security? With the recent change to AAA-Server-Cert AVP, does having a certificate per Diameter-Identity make sense? Thanks, Don From owner-aaa-wg@merit.edu Fri Oct 26 15:36:44 2001 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 PAA17248 for ; Fri, 26 Oct 2001 15:36:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 374F49135D; Fri, 26 Oct 2001 15:35:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F357091360; Fri, 26 Oct 2001 15:35: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 CDA499135D for ; Fri, 26 Oct 2001 15:34:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B57845DDC1; Fri, 26 Oct 2001 15:34:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 5664A5DDAD for ; Fri, 26 Oct 2001 15:34:56 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9QJYt006786 for ; Fri, 26 Oct 2001 14:34:55 -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 f9QJYt404786 for ; Fri, 26 Oct 2001 14:34:55 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA24431 for ; Fri, 26 Oct 2001 14:34:54 -0500 (CDT) Received: from ericsson.com (busam60.berkeley.us.am.ericsson.se [138.85.159.210]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA20503 for ; Fri, 26 Oct 2001 14:34:50 -0500 (CDT) Message-ID: <3BD9BAAD.10575E55@ericsson.com> Date: Fri, 26 Oct 2001 12:34:05 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Server-Initiated Re-Auth in Diameter MIPv4 not supported Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Tony Submitter email address: tony.johansson@ericsson.com Date first submitted: 26-Oct-01 Reference: Document: MIP alpha -08 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: In section 8.3 Server-Initiated Re-Auth of the base protocol alpha -08 states the following: "Each Diameter application MUST state whether service-initiated re-auth is supported, since some applications do not allow for access devices to prompt the user for re-auth." However, text is missing in the Diameter Mobile IPv4 application that states that this Diameter application can not deal with Server initiated re-auth. From owner-aaa-wg@merit.edu Sat Oct 27 00:19:06 2001 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 AAA24767 for ; Sat, 27 Oct 2001 00:19:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BFCA59122E; Sat, 27 Oct 2001 00:17:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74FC591296; Sat, 27 Oct 2001 00:17:59 -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 D48309122E for ; Sat, 27 Oct 2001 00:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCE155DD9C; Sat, 27 Oct 2001 00:17:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by segue.merit.edu (Postfix) with ESMTP id 196A95DDAC for ; Sat, 27 Oct 2001 00:17:55 -0400 (EDT) Received: from jariws1 ([62.248.155.34]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011027041753.CPZI5453.fep07-app.kolumbus.fi@jariws1>; Sat, 27 Oct 2001 07:17:53 +0300 Message-ID: <004d01c15e9e$5e84f4e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Don Zick" , References: <3BD9B708.734327F2@interlinknetworks.com> Subject: Re: [AAA-WG]: CMS Security and TLS Certificates Date: Sat, 27 Oct 2001 07:18:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The CMS Security application requires that the dNSName be set to > "Diameter-.". Rather than using this syntax, could we set > the dNSName to the Diameter-Identity string defined in the base draft > and make this a requirement for both TLS over Diameter and > CMS Security? 1) I don't think the certificate syntax allows adding the port etc stuff that we had in Diameter-Identity string. 2) The current format for the CMS security name (Diameter-xxx) is there to act as a poor man's authorization tool: your network can use one PKI, yet not all your devices will be seen as legal diameter devices, only those that are prefixed with "Diameter" (by the way, why the capitalization?) So, removing "Diameter-" is propably not appropriate just to sync the TLS and CMS certs as you suggest. 3) It might though be possible to use the same scheme in TLS (and IKE!) to require that they also use only Diameter-xxx names, for the same authorization reason. Perhaps however this would have less benefit in them, as TLS/IKE both work in a quite independent way and typical current implements would *not* check the names in this manner. So it could be that we can recommend this as a good practise, but in reality it may not be feasible to change the implementations to do the checks! 4) We may not need to do this, since as far as I can see, the certs sufficient for CMS will be perfectly usable also for TLS and IKE. Just set fqdn = Diameter-xxx! No additional authorization check, but hey, this is hop-by-hop so the problem is much smaller. So it would seem that my advice is to not change the specs, unless I missed something. Jari From owner-aaa-wg@merit.edu Sun Oct 28 12:18:03 2001 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 MAA14720 for ; Sun, 28 Oct 2001 12:18:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86E4591242; Sun, 28 Oct 2001 12:17:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50A2791245; Sun, 28 Oct 2001 12:17:50 -0500 (EST) 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 15C1891242 for ; Sun, 28 Oct 2001 12:17:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8B355DDAA; Sun, 28 Oct 2001 12:17:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHANGE01.domain.ecutel.com (unknown [65.201.154.134]) by segue.merit.edu (Postfix) with ESMTP id 980105DDA5 for ; Sun, 28 Oct 2001 12:17:48 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: [AAA-WG]: AAA role for co-located MN Date: Sun, 28 Oct 2001 12:17:41 -0500 Message-ID: Thread-Topic: [AAA-WG]: CMS Security and TLS Certificates Thread-Index: AcFenoggkLWa8zeXRuiU+3nFjGD2aQBNBQEk From: "Qiang Zhang" To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id MAA14720 Hello, As described in several drafts for architectural view or AAA requirement, AAA need for a Co-located MN for IPv4 is rarely described (or did I miss the document?), certain place only mentioned that the AAA for mobility should be supplied by local authority. My question is: In an uncontrolled visiting network, the MN apparently can use HA as NAS and HA talks to AAAH to facilitate the AAA needs. Is there any document for this or is this feasible? Impression is that all the scanrios are trying to use AAA as the first stop thus the signaling path is different from letting MN requesting HA then to AAA. Any insight? Further how about in a IPv6 network? Thanks Qiang From owner-aaa-wg@merit.edu Mon Oct 29 05:47:43 2001 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 FAA08330 for ; Mon, 29 Oct 2001 05:47:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E61C91266; Mon, 29 Oct 2001 05:47:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8413C91268; Mon, 29 Oct 2001 05:47:23 -0500 (EST) 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 BEE2091266 for ; Mon, 29 Oct 2001 05:47:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A0D85DDE3; Mon, 29 Oct 2001 05:47:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 203745DDAE for ; Mon, 29 Oct 2001 05:47:21 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12498; Mon, 29 Oct 2001 03:47:09 -0700 (MST) Received: from vayne (muc-isdn-13 [129.157.164.113]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA21589; Mon, 29 Oct 2001 11:47:17 +0100 (MET) Date: Mon, 29 Oct 2001 09:55:53 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification To: jarno.rajahalme@nokia.com Cc: Erik.Guttman@sun.com, jaakko.rajaniemi@nokia.com, pcalhoun@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" <009CA59D1752DD448E07F8EB2F91175719804D@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 Jarno, > > If there are 3 rules which have 3 options each, there are 9 valid > > combinations. Are all valid? Things get ugly if the options aren't > > independent. Further, more options make interoperation harder to > > verify and protocol implementations more complex and less likely to > > be hardened. > > If the command definition needs all those options they are going to > be there in a form or another. None of them need it now. Why do you think some will in the future? > It will increase the complexity of the ABNF format of the command > definition, but will make the intended syntax of the command more > explicit, and the command definition more understandable. The *command* itself will be more complex as a result. That's what I'm trying to say. > To enable more explicit command definitions in the future, where more > of the command syntax is being described by the ABNF rather than the > English text accompanying it. Expliciteness isn't the issue. Imagine if a TCP implementation in LISTEN state could receive a SYN or a SYN1 or a SYN2. SYN1 and SYN2 are alternatives, different than SYN. Would this simplify the state table of TCP? Would this lead to better interoperability, to more robust and efficient implementations? No. TCP was defined with as few options as possible. When it was discovered that TCP had to be enhanced and extended - that's what folks did - and the base protocol (extension options) allowed for this. So with DIAMETER, we allow for optional AVPs and in the worst case, if we get it wrong, the creation of new Commands. > But to respond to Pat's comment, I am not aware of an existing bug in the > current Diameter specs that this would be a solution for. All the possible > bugs can be fixed just as well by fine tuning the English describing the > command :-) Here I disagree: You can't say in text that either AVP A or AVP B is *required.* The grammar of each command specifies all 'required' AVPs. Either AVP A is required or it isn't, AVP B likewise. We have to decide whether to open the spec up for required message components which are contingent on implementation choice ("Should I send AVP A or AVP B today?") Or should we stick with a definite and unambiguous specification of command message required components? Erik From owner-aaa-wg@merit.edu Mon Oct 29 07:46:13 2001 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 HAA09710 for ; Mon, 29 Oct 2001 07:46:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF9F091268; Mon, 29 Oct 2001 07:36:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A95BC91269; Mon, 29 Oct 2001 07:36:27 -0500 (EST) 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 88DE591268 for ; Mon, 29 Oct 2001 07:36:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67ADF5DDB5; Mon, 29 Oct 2001 07:36:26 -0500 (EST) 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 A7D645DDAE for ; Mon, 29 Oct 2001 07:36:25 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9TCb1A26945 for ; Mon, 29 Oct 2001 14:37:01 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Oct 2001 14:36:23 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 29 Oct 2001 14:36:23 +0200 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB526EA7F@esebe013.NOE.Nokia.com> From: jaakko.rajaniemi@nokia.com To: Erik.Guttman@sun.com, jarno.rajahalme@nokia.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification Date: Mon, 29 Oct 2001 14:36:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, > > If the command definition needs all those options they are going to > > be there in a form or another. > > None of them need it now. Why do you think some will in the future? Well, you could answer that they don't seem to need it because it has not been possible. At least this is true, for example, in the capability negotiation, where this would have been useful (see mail): http://www.merit.edu/mail.archives/aaa-wg/2001-09/msg00091.html What comes to new applications in the future, it is difficult to say what is needed and due to this the base should allow enough possibilities to define ABNF grammar for commands. > > It will increase the complexity of the ABNF format of the command > > definition, but will make the intended syntax of the command more > > explicit, and the command definition more understandable. > > The *command* itself will be more complex as a result. > That's what I'm > trying to say. I think that it is the people who specify commands who make things complex and not alternatives. In the right hands, alternatives can make specifications more clear. Best regards, Jaakko > -----Original Message----- > From: ext Erik Guttman [mailto:Erik.Guttman@sun.com] > Sent: 29 October, 2001 10:56 > To: Rajahalme Jarno (NRC/Helsinki) > Cc: Erik.Guttman@sun.com; Rajaniemi Jaakko (NET/Espoo); > pcalhoun@diameter.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command > Code ABNF > sp ecification > > > Jarno, > > > > If there are 3 rules which have 3 options each, there are 9 valid > > > combinations. Are all valid? Things get ugly if the > options aren't > > > independent. Further, more options make interoperation harder to > > > verify and protocol implementations more complex and less > likely to > > > be hardened. > > > > If the command definition needs all those options they are going to > > be there in a form or another. > > None of them need it now. Why do you think some will in the future? > > > It will increase the complexity of the ABNF format of the command > > definition, but will make the intended syntax of the command more > > explicit, and the command definition more understandable. > > The *command* itself will be more complex as a result. > That's what I'm > trying to say. > > > To enable more explicit command definitions in the future, > where more > > of the command syntax is being described by the ABNF rather > than the > > English text accompanying it. > > Expliciteness isn't the issue. > > Imagine if a TCP implementation in LISTEN state could receive > a SYN or > a SYN1 or a SYN2. SYN1 and SYN2 are alternatives, different > than SYN. > Would this simplify the state table of TCP? Would this lead > to better > interoperability, to more robust and efficient implementations? No. > > TCP was defined with as few options as possible. When it was > discovered > that TCP had to be enhanced and extended - that's what folks > did - and > the base protocol (extension options) allowed for this. So > with DIAMETER, > we allow for optional AVPs and in the worst case, if we get > it wrong, the > creation of new Commands. > > > But to respond to Pat's comment, I am not aware of an > existing bug in the > > current Diameter specs that this would be a solution for. > All the possible > > bugs can be fixed just as well by fine tuning the English > describing the > > command :-) > > Here I disagree: You can't say in text that either AVP A or AVP B is > *required.* The grammar of each command specifies all > 'required' AVPs. > Either AVP A is required or it isn't, AVP B likewise. > > We have to decide whether to open the spec up for required message > components which are contingent on implementation choice > ("Should I send > AVP A or AVP B today?") Or should we stick with a definite and > unambiguous specification of command message required components? > > Erik > From owner-aaa-wg@merit.edu Mon Oct 29 08:00:29 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09919 for ; Mon, 29 Oct 2001 08:00:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5CFF491243; Mon, 29 Oct 2001 07:59:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 224D691269; Mon, 29 Oct 2001 07:59:49 -0500 (EST) 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 D580A91243 for ; Mon, 29 Oct 2001 07:59:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4AC05DDC8; Mon, 29 Oct 2001 07:59:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A18F35DD98 for ; Mon, 29 Oct 2001 07:59:47 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 2F4E781; Mon, 29 Oct 2001 07:59:47 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" , "Mark Eklund" Cc: Subject: RE: [AAA-WG]: Why does AAAF generate keys when HA is in a foreign domain? Date: Mon, 29 Oct 2001 07:57:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20011025192623.B5663@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Pat Calhoun > Sent: Thursday, October 25, 2001 10:26 PM > To: Mark Eklund > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Why does AAAF generate keys when HA is in a > foreign domain? > > Why should the AAAH be aware of keys between nodes in another network? Just > so that it can hack them? I know for a fact that the security ADs would have > serious security concerns about someone not involved in the transactions, > and in another domain, be involved in key generation when it shouldn't. Technically speaking, in this case the AAAH knows the other two keys (ha/mn, fa/mn), even though the parties using these keys are in the other domain. And the AAAH always knows the mn-fa key, even though mn-fa transactions are always in the other domain, no matter where the HA lives. Not suggesting this is wrong or could be avoided, just an observation. > PatC > On Thu, Oct 25, 2001 at 01:20:17PM -0400, Mark Eklund wrote: > > All, > > > > I just sent out an issue, "ISSUE: MIP-FA-to-HA being added to the AMA > > by the AAAF" that deals with the fact that when the HA is in the > > foreign domain, the AAAF generates the FA-to-HA keys. I'm just > > curious what keeps us from being consistent and always having the AAAH > > generate the keys. > > > > Is there a problem with the AAAH knowing what the FA-to-HA key for > > that session will be? What kind of security issues would this create? > > > > -mark > > > From owner-aaa-wg@merit.edu Mon Oct 29 08:14:05 2001 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 IAA10243 for ; Mon, 29 Oct 2001 08:14:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3CB191269; Mon, 29 Oct 2001 08:13:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 956399126A; Mon, 29 Oct 2001 08:13:38 -0500 (EST) 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 223CE91269 for ; Mon, 29 Oct 2001 08:13:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00F685DDE3; Mon, 29 Oct 2001 08:13:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B44765DDC8 for ; Mon, 29 Oct 2001 08:13:35 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 5CBB581; Mon, 29 Oct 2001 08:13:35 -0500 (EST) From: "Bob Kopacz" To: "Mark Eklund" Cc: Subject: RE: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the AAAF Date: Mon, 29 Oct 2001 08:11:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <15321.40825.298452.952075@gargle.gargle.HOWL> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mark, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Mark Eklund > Sent: Friday, October 26, 2001 1:38 PM > To: Mark Eklund > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the > AAAF > > All, > > Because of concerns about the AAAH having access to the FA-HA key when > the HA is in the foreign domain, the solution offered by this issue > doesn't work. How about a similar answer, but one that allows > security? > > Add the AVP MIP-HAA-to-AMA-Data which is opaque data of type > OctetString. This AVP is added to the HAA by the AAAF. On receipt of > a successful HAA, the AAAH must move this AVP from the HAA to the AMA. > > This allows the AAAF to put any needed key information in the HAA and > have it available in the AMA. If the AAAF is worried about security, > it can encrypt this information in any way it wants. One little snag. When Pat was at the bakeoff last Thursday, I asked if, when the AAAF has offered to allocate an HA in the foreign network, if the AAAH needs to send the HAR to the AAAF which sent the AMR (the FA's AAAF), or if the HAR can be sent to any old AAAF in the foreign domain. Because I wanted to know whether the AAAH should include a Destination-Host AVP in the HAR, or just the Destination-Realm. The answer was that the HAR could go to any AAAF, so don't include the Destination-Host AVP in the HAR. What this means is that the MIP-HAA-to-AMA-Data AVP, if encrypted, must be decrypted by the FA's AAAF, if the FA's AAAF is a different server from the HA's AAAF. I guess this also means that it doesn't do the HA's AAAF any good to cache the generated key and multi-session-id, since he may not be the guy who receives the AMA. > -mark > > Mark Eklund writes: > > Submitter name: Mark Eklund > > Submitter email address: meklund@cisco.com > > Date first submitted: 25-Oct-01 > > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html > > Document: mobileip > > Comment type: Technical > > Priority: 1 > > Section: 2.4, 5.3, 8.1 > > Rationale/Explanation of issue: > > > > When the HA is in the foreign network and a FA-HA key is requested, > > the AAAF generates the key. The AAAF is then responsible for adding > > the MIP-FA-to-HA Key to the AMA. This means that the AAAF must > > maintain a list containing all MIP-FA-to-HA Key AVPs and their > > matching Accounting-Multi-Session-Id AVPs. When each AMA is received, > > the AAAF must then consult the list and when it finds a matching > > Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA. > > > > Requested change: > > > > Instead of requiring the AAAF to add the MIP-FA-to-HA Key AVP to the > > AMA, send the MIP-FA-to-HA Key back in the HAA. The AAAH then can > > move the MIP-FA-to-HA Key from the HAA to the AMA. > > > > Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4. > > Change MIP-Feature-Vector column HAR = 0-1 to section 8.1 > > Change MIP-FA-to-HA-Key column HAA = 0-1 to section 8.1 > > > > Change the final paragraph of section 5.3 to > > > > Upon receipt of the HAA, the Diameter server responsible for key > > allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the > > MIP-FA-to-HA-SPI. If the key is generated at the AAAF, it adds the > > MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH. > > Depending upon where the HA was located the AAAH either generates the > > MIP-FA-to-HA Key AVP itself or extracts the AVP from the HAA sent > > by the AAAF. The AAAH adds the MIP-FA-to-HA Key to the AMA. > > > > -mark > From owner-aaa-wg@merit.edu Mon Oct 29 10:11:37 2001 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 KAA16553 for ; Mon, 29 Oct 2001 10:11:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBD1A9126C; Mon, 29 Oct 2001 10:11:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9AD69126D; Mon, 29 Oct 2001 10:11:21 -0500 (EST) 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 B17B69126C for ; Mon, 29 Oct 2001 10:11:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 994E75DD99; Mon, 29 Oct 2001 10:11:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 860545DD98 for ; Mon, 29 Oct 2001 10:11:20 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 23F5D81; Mon, 29 Oct 2001 10:11:20 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 219: AMA AVP issue when failure occurs on AAAH Date: Mon, 29 Oct 2001 10:08:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20011025173353.S5663@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, Also, when the AMA is being sent by a redirect agent with a Redirect-Indication result-code, the ABNF requires some AVPs that the redirect server won't be sending (e.g. Session-Timeout). This same issue also applies to HAAs. That is, an HAA with a negative result-code probably requires fewer AVPs than a successful HAA. Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Pat Calhoun > Sent: Thursday, October 25, 2001 8:34 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 219: AMA AVP issue when failure occurs on AAAH > > > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: MIP > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > If the mobile is not authenticated successfully (or some other error > occurs on AAAH), the ABNF requires some AVPs that may not be available. > > From owner-aaa-wg@merit.edu Tue Oct 30 07:13:00 2001 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 HAA24735 for ; Tue, 30 Oct 2001 07:13:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C971591273; Tue, 30 Oct 2001 07:12:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9934F91282; Tue, 30 Oct 2001 07:12:46 -0500 (EST) 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 7CD6291273 for ; Tue, 30 Oct 2001 07:12:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 559635DDA2; Tue, 30 Oct 2001 07:12:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C3F2A5DD96 for ; Tue, 30 Oct 2001 07:12:44 -0500 (EST) Received: (qmail 25007 invoked by uid 500); 30 Oct 2001 11:56:55 -0000 Date: Tue, 30 Oct 2001 03:56:55 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 204: How to handle CER from unkwown peer Message-ID: <20011030035655.C24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here is the proposed text to handle this issue: 5.3 Capabilities Exchange [...] Receipt of a CER from an unknown peer will cause the a CEA to be returned with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is used to inform the peer that it has not been configured to communicate with the receiver, and doesn't wish to establish a Diameter session. [...] 7.1.5 Permanent Failures [...] DIAMETER_UNKNOWN_PEER 5019 A CER was received from a peer that is unknown, and the sender of the CEA doesn't wish to establish a Diameter transport. Comments welcomed, PatC From owner-aaa-wg@merit.edu Tue Oct 30 07:18:07 2001 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 HAA25101 for ; Tue, 30 Oct 2001 07:18:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A405791282; Tue, 30 Oct 2001 07:17:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0EC191289; Tue, 30 Oct 2001 07:17:38 -0500 (EST) 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 7AB1291282 for ; Tue, 30 Oct 2001 07:17:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55B7D5DDA2; Tue, 30 Oct 2001 07:17:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C4BDC5DD96 for ; Tue, 30 Oct 2001 07:17:26 -0500 (EST) Received: (qmail 25038 invoked by uid 500); 30 Oct 2001 12:01:38 -0000 Date: Tue, 30 Oct 2001 04:01:38 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 205: Should AVPs be ordered? Message-ID: <20011030040138.D24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025172858.E5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025172858.E5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:28:58PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I am not quite sure where the best place to fix this particular issue is, so here is my recommendation: 3.2 Command Code ABNF [...] required = [qual] "{" avp-spec "}" ; The AVP MUST be present and can appear ; anywhere in the message. optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. The AVP can ; appear anywhere in the message. Comments welcomed, PatC From owner-aaa-wg@merit.edu Tue Oct 30 07:24:45 2001 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 HAA25379 for ; Tue, 30 Oct 2001 07:24:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 94E4591289; Tue, 30 Oct 2001 07:24:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 607C09128E; Tue, 30 Oct 2001 07:24:30 -0500 (EST) 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 588FF91289 for ; Tue, 30 Oct 2001 07:24:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3EE645DDA2; Tue, 30 Oct 2001 07:24:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id ACF1D5DD96 for ; Tue, 30 Oct 2001 07:24:28 -0500 (EST) Received: (qmail 25263 invoked by uid 500); 30 Oct 2001 12:08:39 -0000 Date: Tue, 30 Oct 2001 04:08:39 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 207: AAA URI inconsistent Message-ID: <20011030040839.E24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025172947.G5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025172947.G5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:29:47PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here is my proposed text: 4.4 Derived AVP Data Formats [...] Diameter-Identity = "aaa://" fqdn [ port ] [ transport ] [ protocol ] [ security ] [...] and changed: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp to: aaa://host.abc.com;transport=tcp aaa://host.abc.com:6666;transport=tcp Comments welcomed, PatC From owner-aaa-wg@merit.edu Tue Oct 30 07:28:42 2001 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 HAA25497 for ; Tue, 30 Oct 2001 07:28:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBA949128E; Tue, 30 Oct 2001 07:28:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A939191298; Tue, 30 Oct 2001 07:28:20 -0500 (EST) 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 A763E9128E for ; Tue, 30 Oct 2001 07:28:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D01B5DDCA; Tue, 30 Oct 2001 07:28:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 43F715DDA2 for ; Tue, 30 Oct 2001 07:28:19 -0500 (EST) Received: (qmail 25295 invoked by uid 500); 30 Oct 2001 12:12:30 -0000 Date: Tue, 30 Oct 2001 04:12:30 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election Message-ID: <20011030041230.F24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025173011.H5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025173011.H5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:30:11PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I wish to reject this issue. If you look closely at the line in the state machine in question, it causes a CEA to be sent on the Receiver socket, while the DRP is sent on the Initiator socket. This is the result of an election. Could the folks that originally wanted this fixed please speak up. Perhaps I missed something. PatC On Thu, Oct 25, 2001 at 05:30:11PM -0700, Pat Calhoun wrote: > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: base > Comment type: Technical > Priority: 1 > Section: 5.6 > Rationale/Explanation of issue: > > The last state machine statement is incorrect. > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > I-Rcv-DPR I-Snd-DPA, R-Open > R-Snd-CEA > I-Rcv-CEA R-Snd-DPR I-Open > > If a CEA is returned with the proper error code, there is no reason > to send a DPR. Add the Result-Code value, and remove the DPR here. > From owner-aaa-wg@merit.edu Tue Oct 30 07:32:24 2001 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 HAA25723 for ; Tue, 30 Oct 2001 07:32:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF49991298; Tue, 30 Oct 2001 07:31:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0FFD9129A; Tue, 30 Oct 2001 07:31:55 -0500 (EST) 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 98CF991298 for ; Tue, 30 Oct 2001 07:31:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 727AA5DD96; Tue, 30 Oct 2001 07:31:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E33375DD95 for ; Tue, 30 Oct 2001 07:31:53 -0500 (EST) Received: (qmail 25321 invoked by uid 500); 30 Oct 2001 12:16:05 -0000 Date: Tue, 30 Oct 2001 04:16:05 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 209: Authorization-Lifetime inconsistency Message-ID: <20011030041605.G24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025173028.I5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025173028.I5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:30:28PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Since a new AVP, called the MIP-Key-Lifetime, now replaces the use of the Authorization-Lifetime in the MIP spec, this issue is no longer valid. I will reject this issue. PatC On Thu, Oct 25, 2001 at 05:30:28PM -0700, Pat Calhoun wrote: > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: base, MIP > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > In the base draft, the Authorization-Lifetime set to 0 means immediate > re-auth. In the MIP draft 0 means infinity. Fix the MIP draft to be > consistent with the base draft. > From owner-aaa-wg@merit.edu Tue Oct 30 07:37:48 2001 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 HAA25887 for ; Tue, 30 Oct 2001 07:37:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64A7891299; Tue, 30 Oct 2001 07:37:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3449B9129A; Tue, 30 Oct 2001 07:37:28 -0500 (EST) 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 2C54D91299 for ; Tue, 30 Oct 2001 07:37:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B8375DD9A; Tue, 30 Oct 2001 07:37:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B5F5A5DD95 for ; Tue, 30 Oct 2001 07:37:26 -0500 (EST) Received: (qmail 25360 invoked by uid 500); 30 Oct 2001 12:21:37 -0000 Date: Tue, 30 Oct 2001 04:21:37 -0800 From: Pat Calhoun To: "Patil Basavaraj (NET/Dallas)" Cc: "'ext Pat Calhoun'" , aaa-wg@merit.edu, "'Mobile IP'" Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Message-ID: <20011030042137.H24979@charizard.diameter.org> Mail-Followup-To: "Patil Basavaraj (NET/Dallas)" , 'ext Pat Calhoun' , aaa-wg@merit.edu, 'Mobile IP' References: <697DAA22C5004B4596E033803A7CEF444CCF62@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCF62@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Fri, Oct 26, 2001 at 11:53:16AM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk I guess I missed the conclusion ofthe GNAIE spec. The extension mentioned below has many benefits, and it would be even better if it was in an FQDN format than an NAI. This extension really will be required to the proper operation of MobileIP+AAA. Are you stating that the AAA WG should include the definition of the extension in one of it's documents? PatC On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas) wrote: > > Pat, > > The GNAIE I-D is in the process of being deprecated as a WG document. > So refering to the GNAIE as a way to fix it may not be the solution. As > I > have pointed out to you and the other authors of the GNAIE I-D, the I-D > that needs a specific NAI extension ought to define it rather than > having a > placeholder for extensions I-D which is reference by others. > The FA-NAI specified in GNAIE should (or can) be specified in the > reg-tun > I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 > I-D. So far the HA-NAI has not been really shown as a requirement by any > other I-Ds in the Mobile IP WG. > > -Basavaraj > > > > > > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: 25-Oct-01 > > Reference: > > Document: MIP > > Comment type: Technical > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > Once a mobile has been assigned a home agent, if a subsequent > > HAR is to > > be sent, a new AAAH has no way to map the IP address in the > > registration > > request to a Destination-Host AVP of the Home Agent. > > > > Fix > > > > The GNAIE ID is being updated to reflect comments of the IESG. In this > > document we will specify that the HA may include its NAI in the > > Registration Reply, and if so, the mobile node must include > > the same extension > > in subsequent registration requests. This will require some > > Mobile IP WG > > involvement. > > From owner-aaa-wg@merit.edu Tue Oct 30 07:41:33 2001 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 HAA26141 for ; Tue, 30 Oct 2001 07:41:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E54469129A; Tue, 30 Oct 2001 07:41:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4F349129B; Tue, 30 Oct 2001 07:41:20 -0500 (EST) 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 96AAA9129A for ; Tue, 30 Oct 2001 07:41:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C0FA5DD9A; Tue, 30 Oct 2001 07:41:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 270115DD95 for ; Tue, 30 Oct 2001 07:41:19 -0500 (EST) Received: (qmail 25401 invoked by uid 500); 30 Oct 2001 12:25:30 -0000 Date: Tue, 30 Oct 2001 04:25:30 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 213: MN-AAA SPI must be included in the HAR message Message-ID: <20011030042530.I24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025173155.M5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025173155.M5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:31:55PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here are my fixes for this particular issue (which is the inclusion of the MN-AAA SPI in the AVP): 6.5 MIP-MN-to-FA-Key AVP [...] MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Key-Material } { MIP-MN-AAA-SPI } * [ AVP ] [...] 6.6 MIP-MN-to-HA-Key AVP [...] MIP-MN-to-HA-Key ::= < AVP Header: 331 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Key-Material } { MIP-MN-AAA-SPI } * [ AVP ] Comments welcomed, PatC On Thu, Oct 25, 2001 at 05:31:55PM -0700, Pat Calhoun wrote: > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: MIP > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > The Home Agent needs to have access to the MN-AAA SPI in order to create > the Mobile AAA key extensions. This information is not sent by the AAAH > to the home agent. Therefore the AAAH must include the MIP-MN-AAA-SPI > AVP in the HAR to the HA. > > From owner-aaa-wg@merit.edu Tue Oct 30 07:44:25 2001 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 HAA26259 for ; Tue, 30 Oct 2001 07:44:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 453079129B; Tue, 30 Oct 2001 07:44:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16D799129C; Tue, 30 Oct 2001 07:44:05 -0500 (EST) 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 10F9E9129B for ; Tue, 30 Oct 2001 07:44:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id EBA255DD95; Tue, 30 Oct 2001 07:44:03 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5C0485DD9A for ; Tue, 30 Oct 2001 07:44:03 -0500 (EST) Received: (qmail 25430 invoked by uid 500); 30 Oct 2001 12:28:14 -0000 Date: Tue, 30 Oct 2001 04:28:14 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 214: Unknown-User Result-Code provides too much info Message-ID: <20011030042814.J24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025173214.N5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025173214.N5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:32:14PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I modified the text to read as follows: DIAMETER_USER_UNKNOWN 5001 A request was received for a user that is unknown, therefore authentication and/or authorization failed. Implementations may wish to use DIAMETER_AUTHENTICATION_REJECTED instead of this Result-Code value, since it is felt that returning an error stating that a user is unknown may be providing too much information to malicious users. Comments welcomed, PatC On Thu, Oct 25, 2001 at 05:32:14PM -0700, Pat Calhoun wrote: > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: base > Comment type: Technical > Priority: 1 > Section: 7.1 > Rationale/Explanation of issue: > > Some text should be provided in the Result-Code value to state that > an alternative is to use Authentication-Failure. It is felt that Unknown > User provides too much info, and could lead to certain types of attacks. > From owner-aaa-wg@merit.edu Tue Oct 30 07:51:34 2001 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 HAA26561 for ; Tue, 30 Oct 2001 07:51:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19DBB9129C; Tue, 30 Oct 2001 07:51:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBA699129D; Tue, 30 Oct 2001 07:51:22 -0500 (EST) 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 C77D59129C for ; Tue, 30 Oct 2001 07:51:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F74E5DD9A; Tue, 30 Oct 2001 07:51:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 597495DD95 for ; Tue, 30 Oct 2001 07:51:21 -0500 (EST) Received: (qmail 25471 invoked by uid 500); 30 Oct 2001 12:35:32 -0000 Date: Tue, 30 Oct 2001 04:35:32 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 216: Home Agent MUST support home address allocation Message-ID: <20011030043532.L24979@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011025173257.P5663@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011025173257.P5663@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Oct 25, 2001 at 05:32:57PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I modified some text to make this clearer. Specifically, the last two sentences in the paragraph below have been changed. 1.2 Inter-Realm Mobile IP [...] The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the Mobile IP Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a home address for the mobile node, while the Home Agent MUST support home address allocation. In the event the AAAH handles address allocation, it includes it in a MIP-Mobile-Node-Address AVP within the HAR. The absence of this AVP informs the Home Agent to perform the allocation. Comments welcomed, PatC On Thu, Oct 25, 2001 at 05:32:57PM -0700, Pat Calhoun wrote: > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@diameter.org > Date first submitted: 25-Oct-01 > Reference: > Document: MIP > Comment type: Technical > Priority: 1 > Section: 1.2 > Rationale/Explanation of issue: > > The draft doesn't actually state that the Home Agent MUST support > home address allocation, but the draft does state that the AAAH MAY > do it. The lack of a MUST can cause interoperability problems > From owner-aaa-wg@merit.edu Tue Oct 30 08:27:04 2001 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 IAA28091 for ; Tue, 30 Oct 2001 08:27:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2740C9134A; Tue, 30 Oct 2001 08:26:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F099691357; Tue, 30 Oct 2001 08:26:48 -0500 (EST) 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 033FE9134A for ; Tue, 30 Oct 2001 08:26:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id E01265DD9F; Tue, 30 Oct 2001 08:26:47 -0500 (EST) 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 412EF5DD95 for ; Tue, 30 Oct 2001 08:26:47 -0500 (EST) Received: (qmail 31417 invoked by uid 500); 30 Oct 2001 13:26:46 -0000 Date: Tue, 30 Oct 2001 07:26:46 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer Message-ID: <20011030072646.B20047@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20011030035655.C24979@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011030035655.C24979@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Oct 30, 2001 at 03:56:55AM -0800 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Also, the other avps should be optional. A Diameter server would not want to inform a malicious (unknown) host of it's version, or of all the applications it supports. On Tue, Oct 30, 2001 at 03:56:55AM -0800, Pat Calhoun wrote: > All, > > Here is the proposed text to handle this issue: > > 5.3 Capabilities Exchange > > [...] > Receipt of a CER from an unknown peer will cause the a CEA to be returned > with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is > used to inform the peer that it has not been configured to communicate with > the receiver, and doesn't wish to establish a Diameter session. > [...] > > 7.1.5 Permanent Failures > > [...] > DIAMETER_UNKNOWN_PEER 5019 > A CER was received from a peer that is unknown, and the sender of > the CEA doesn't wish to establish a Diameter transport. > > Comments welcomed, > > PatC From owner-aaa-wg@merit.edu Tue Oct 30 09:04:46 2001 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 JAA29993 for ; Tue, 30 Oct 2001 09:04:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7875691208; Tue, 30 Oct 2001 09:04:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4864391357; Tue, 30 Oct 2001 09:04:29 -0500 (EST) 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 463EA91208 for ; Tue, 30 Oct 2001 09:04:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BB745DD9F; Tue, 30 Oct 2001 09:04:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 8AEC85DD95 for ; Tue, 30 Oct 2001 09:04:27 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9UE4QX16215 for aaa-wg@merit.edu; Tue, 30 Oct 2001 09:04:27 -0500 (EST) (envelope-from barney) Date: Tue, 30 Oct 2001 09:04:26 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 214: Unknown-User Result-Code provides too much info Message-ID: <20011030090426.A16126@tp.databus.com> References: <20011025173214.N5663@charizard.diameter.org> <20011030042814.J24979@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011030042814.J24979@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Oct 30, 2001 at 04:28:14AM -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk I'd undefine the error code altogether. It invites a very poor security practice even while warning against it. The server can always put something in its own logs that helps debugging without compromising security. On Tue, Oct 30, 2001 at 04:28:14AM -0800, Pat Calhoun wrote: > All, > > I modified the text to read as follows: > > DIAMETER_USER_UNKNOWN 5001 > A request was received for a user that is unknown, therefore > authentication and/or authorization failed. Implementations may > wish to use DIAMETER_AUTHENTICATION_REJECTED instead of this > Result-Code value, since it is felt that returning an error > stating that a user is unknown may be providing too much > information to malicious users. > > Comments welcomed, > > PatC > On Thu, Oct 25, 2001 at 05:32:14PM -0700, Pat Calhoun wrote: > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: 25-Oct-01 > > Reference: > > Document: base > > Comment type: Technical > > Priority: 1 > > Section: 7.1 > > Rationale/Explanation of issue: > > > > Some text should be provided in the Result-Code value to state that > > an alternative is to use Authentication-Failure. It is felt that Unknown > > User provides too much info, and could lead to certain types of attacks. > > -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. From owner-aaa-wg@merit.edu Tue Oct 30 09:25:01 2001 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 JAA01280 for ; Tue, 30 Oct 2001 09:25:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 444D791357; Tue, 30 Oct 2001 09:24:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1569B9135A; Tue, 30 Oct 2001 09:24:50 -0500 (EST) 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 EBD7591357 for ; Tue, 30 Oct 2001 09:24:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFA0C5DDB7; Tue, 30 Oct 2001 09:24:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id AA1025DDA2 for ; Tue, 30 Oct 2001 09:24:48 -0500 (EST) Received: from interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 4D49B79 for ; Tue, 30 Oct 2001 09:24:48 -0500 (EST) Message-ID: <3BDEB818.B1D445BF@interlinknetworks.com> Date: Tue, 30 Oct 2001 09:24:24 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Security and TLS Certificates References: <3BD9B708.734327F2@interlinknetworks.com> <004d01c15e9e$5e84f4e0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jari, OK, the "Diameter-." syntax sounds fine. I was a little concerned about the case of multiple Diameter nodes running on the same host with the same FQDN, but I guess that's not a case worth worrrying too much about. I do have a couple of questions about TLS. I'm not sure I followed your points #3 and #4 below. I have code that checks that the TLS certificate Common Name matches the FQDN of the connecting peer. CMS Security requires the FQDN to be put into the certificate dNSName, not the certificate Common Name. Wouldn't it be helpful if the base draft stated that the certficate dNSName must be set in the same manner for both TLS and CMS Security? Thanks, Don Jari Arkko wrote: > > The CMS Security application requires that the dNSName be set to > > "Diameter-.". Rather than using this syntax, could we set > > the dNSName to the Diameter-Identity string defined in the base draft > > and make this a requirement for both TLS over Diameter and > > CMS Security? > > 1) I don't think the certificate syntax allows adding the port etc stuff > that we had in Diameter-Identity string. > > 2) The current format for the CMS security name (Diameter-xxx) > is there to act as a poor man's authorization tool: your network can > use one PKI, yet not all your devices will be seen as legal diameter > devices, only those that are prefixed with "Diameter" (by the way, why > the capitalization?) So, removing "Diameter-" is propably not > appropriate just to sync the TLS and CMS certs as you suggest. > > 3) It might though be possible to use the same scheme in TLS (and > IKE!) to require that they also use only Diameter-xxx names, for the > same authorization reason. Perhaps however this would have less > benefit in them, as TLS/IKE both work in a quite independent way > and typical current implements would *not* check the names in > this manner. So it could be that we can recommend this as a good > practise, but in reality it may not be feasible to change the implementations > to do the checks! > > 4) We may not need to do this, since as far as I can see, the certs > sufficient for CMS will be perfectly usable also for TLS and IKE. > Just set fqdn = Diameter-xxx! No additional authorization check, > but hey, this is hop-by-hop so the problem is much smaller. > > So it would seem that my advice is to not change the specs, > unless I missed something. > > Jari From owner-aaa-wg@merit.edu Tue Oct 30 09:54:54 2001 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 JAA02819 for ; Tue, 30 Oct 2001 09:54:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B55E9120F; Tue, 30 Oct 2001 09:54:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB69D91218; Tue, 30 Oct 2001 09:54:42 -0500 (EST) 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 BAC1D9120F for ; Tue, 30 Oct 2001 09:54:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9479F5DDB7; Tue, 30 Oct 2001 09:54:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7C0DE5DD95 for ; Tue, 30 Oct 2001 09:54:21 -0500 (EST) Received: from interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 1D18F79 for ; Tue, 30 Oct 2001 09:54:06 -0500 (EST) Message-ID: <3BDEBEF6.28C62789@interlinknetworks.com> Date: Tue, 30 Oct 2001 09:53:42 -0500 From: Don Zick X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election References: <20011025173011.H5663@charizard.diameter.org> <20011030041230.F24979@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think when the issue was brought up a request was made to either remove the DPR from the state machine during the election process or add a Disconnect-Cause that would be appropriate for this DPR. Is there a Disconnect-Cause appropriate for this DPR? Thanks, Don Pat Calhoun wrote: > All, > > I wish to reject this issue. If you look closely at the line in the state > machine in question, it causes a CEA to be sent on the Receiver socket, while > the DRP is sent on the Initiator socket. This is the result of an election. > > Could the folks that originally wanted this fixed please speak up. Perhaps > I missed something. > > PatC > On Thu, Oct 25, 2001 at 05:30:11PM -0700, Pat Calhoun wrote: > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: 25-Oct-01 > > Reference: > > Document: base > > Comment type: Technical > > Priority: 1 > > Section: 5.6 > > Rationale/Explanation of issue: > > > > The last state machine statement is incorrect. > > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > I-Rcv-DPR I-Snd-DPA, R-Open > > R-Snd-CEA > > I-Rcv-CEA R-Snd-DPR I-Open > > > > If a CEA is returned with the proper error code, there is no reason > > to send a DPR. Add the Result-Code value, and remove the DPR here. > > From owner-aaa-wg@merit.edu Tue Oct 30 10:31:53 2001 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 KAA04145 for ; Tue, 30 Oct 2001 10:31:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B71489135A; Tue, 30 Oct 2001 10:31:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 714C19135B; Tue, 30 Oct 2001 10:31:26 -0500 (EST) 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 DE2989135A for ; Tue, 30 Oct 2001 10:31:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1F365DDA2; Tue, 30 Oct 2001 10:31:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (unknown [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 787DF5DD95 for ; Tue, 30 Oct 2001 10:31:24 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f9THj6601248 for ; Mon, 29 Oct 2001 12:46:26 -0500 Message-ID: <3BDD95A1.7CC049FB@interlinknetworks.com> Date: Mon, 29 Oct 2001 12:45:05 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Security and TLS Certificates References: <3BD9B708.734327F2@interlinknetworks.com> <004d01c15e9e$5e84f4e0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA04145 Hi Jari, Okay, the "Diameter-." convention for the certificate dNSName should be fine for CMS. I was a little concerned about the case where multiple Diameter nodes are configured on the same host with the same FQDN, but I guess that's not a case worth worrrying too much about. I do have some questions about TLS. (I didn't completely follow what you said in #3 and #4 below.) During TLS authentication, my code currently checks the certificate Common Name field to make sure that it matches the FQDN of the configured peer. I could just as easily check the certificate dNSName field instead of the Common Name field. Wouldn't it be helpful for interoperability if the base protocol specification stated that for TLS the certificate dNSName should follow the same conventions that are used for CMS certificates? Also, TLS usually performs server authentication but often does not perform client authentication. Diameter is a peer to peer protocol where it makes as much sense to authenticate the client as it does the server. I think it would be helpful if the base draft stated that when TLS authentication is performed, client authentication as well as server authentication is performed. Your thoughts? Thanks, Don Jari Arkko wrote: > > The CMS Security application requires that the dNSName be set to > > "Diameter-.". Rather than using this syntax, could we set > > the dNSName to the Diameter-Identity string defined in the base draft > > and make this a requirement for both TLS over Diameter and > > CMS Security? > > 1) I don't think the certificate syntax allows adding the port etc stuff > that we had in Diameter-Identity string. > > 2) The current format for the CMS security name (Diameter-xxx) > is there to act as a poor man's authorization tool: your network can > use one PKI, yet not all your devices will be seen as legal diameter > devices, only those that are prefixed with "Diameter" (by the way, why > the capitalization?) So, removing "Diameter-" is propably not > appropriate just to sync the TLS and CMS certs as you suggest. > > 3) It might though be possible to use the same scheme in TLS (and > IKE!) to require that they also use only Diameter-xxx names, for the > same authorization reason. Perhaps however this would have less > benefit in them, as TLS/IKE both work in a quite independent way > and typical current implements would *not* check the names in > this manner. So it could be that we can recommend this as a good > practise, but in reality it may not be feasible to change the implementations > to do the checks! > > 4) We may not need to do this, since as far as I can see, the certs > sufficient for CMS will be perfectly usable also for TLS and IKE. > Just set fqdn = Diameter-xxx! No additional authorization check, > but hey, this is hop-by-hop so the problem is much smaller. > > So it would seem that my advice is to not change the specs, > unless I missed something. > > Jari From owner-aaa-wg@merit.edu Tue Oct 30 10:39:55 2001 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 KAA04407 for ; Tue, 30 Oct 2001 10:39:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 918319129F; Tue, 30 Oct 2001 10:39:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D0B89135B; Tue, 30 Oct 2001 10:39:44 -0500 (EST) 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 43BBF9129F for ; Tue, 30 Oct 2001 10:39:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id F02F95DDA2; Tue, 30 Oct 2001 10:39:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DCCA65DD95 for ; Tue, 30 Oct 2001 10:39:41 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 7390A7A; Tue, 30 Oct 2001 10:39:41 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 211: When should Destination-Host be present in HAR? Date: Tue, 30 Oct 2001 10:37:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011025173110.K5663@charizard.diameter.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, The question that prompted this issue was: Q1: When first setting up the mobile node's session, if the AAAF has offered to allocate a HA in the foreign domain and the AAAH has accepted the AAAF's offer, does the AAAH need to send the HAR to the specific AAAF which forwarded the AMR, or can the HAR be receive by any old AAA server in the foreign network? The draft is unclear. From the text and diagrams in the mobile-ip draft, it appears that the AAAH targets the HAR to the specific AAAF which forwarded the AMR. All diagrams show the the HAR going to the AAAF which sent the AMR, and the text contains phrases like: "... the AAAH sends the HAR message to *the* AAAF ..." But based on our bakeoff conversations, my understanding now is that the HAR could be sent to any AAA server in the foreign realm, not necessarily the one that sent the AMR. So this initial HAR would contain a Destination-Realm and not a Destination-Host. Anyway, whichever way is correct, it would be good to clarify the draft, as follows (in section 1.4): "If the HA hasn't yet been allocated by the foreign domain, the HAR sent by the AAAH back to the foreign realm will not necessarily be received by the same AAAF which sent the AMR." or if the above is not true: "If the HA hasn't yet been allocated by the foreign domain, the HAR sent by the AAAH back to the foreign realm is sent to the same AAAF which sent the AMR. The AAAH must set the value of the HAR's Destination-Host AVP to the AAAF's DiameterIdentity. The AAAH determines the AAAF's DiameterIdentity as follows: If there are two or more Route-Record AVPs in the AMR, the 2nd Route-Record AVP contains the AAAF's DiameterIdentity (the 1st Route-Record contains the FA's identity). If there are fewer than 2 Route-Record AVPs, then the peer which sent the AMR to the AAAH is the AAAF." Also, two more questions, If this HAR is received and processed by an AAAF2 other than the AAAF1 which sent the AMR: Q2: If AAAF1 has offered to allocate an HA in the foreign network, how does he know that AAAF2 can make good on this offer? AAAF2 may not have any HAs to talk to. Q3: If AAAF1 has offered to allocated a HA in the foreign network, he sends his candiate HA in the new "Candidate-Home-Agent-Host" AVP (issue #223). The AAAH's HAR then needs to convey this candidate HA to AAAF2, and AAAF2 must be able to route to this HA. Thanks, Bob K. > In the MIP draft, it isn't really clear when the Destination-Host should > be present in the HAR when the HA is assigned in a foreign domain. The > text and figure need to be cleaned up. From owner-aaa-wg@merit.edu Tue Oct 30 11:05:06 2001 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 LAA05189 for ; Tue, 30 Oct 2001 11:05:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFD769135B; Tue, 30 Oct 2001 11:04:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5F7C9135C; Tue, 30 Oct 2001 11:04:55 -0500 (EST) 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 9D25A9135B for ; Tue, 30 Oct 2001 11:04:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 844FD5DDA2; Tue, 30 Oct 2001 11:04:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id A11535DD9F for ; Tue, 30 Oct 2001 11:04:53 -0500 (EST) Received: from jariws1 ([62.248.155.34]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011030160452.HIRY13228.fep01-app.kolumbus.fi@jariws1>; Tue, 30 Oct 2001 18:04:52 +0200 Message-ID: <00fa01c1615c$ab639440$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Don Zick" , References: <3BD9B708.734327F2@interlinknetworks.com> <004d01c15e9e$5e84f4e0$8a1b6e0a@arenanet.fi> <3BDD95A1.7CC049FB@interlinknetworks.com> Subject: Re: [AAA-WG]: CMS Security and TLS Certificates Date: Tue, 30 Oct 2001 18:05:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I was a little concerned > about the case of multiple Diameter nodes running on the same host with the same > FQDN, but I guess that's not a case worth worrrying too much about. Yes. If you need to run several Diameter instances on the same box, and yet with different security certificates, then inventing additional FQDNs might be your solution. > I do have a couple of questions about TLS. I'm not sure I followed your points > #3 and #4 below. I have code that checks that the TLS certificate Common Name > matches the FQDN of the connecting peer. CMS Security requires the FQDN to be > put into the certificate dNSName, not the certificate Common Name. Wouldn't it > be helpful if the base draft stated that the certficate dNSName must be set in > the same manner for both TLS and CMS Security? What I meant was that your standard TLS library would propably not check that the peer's certificate has a name that uses the pattern 'Diameter-xxx'. Of course, you can add this to a library (if you have access to it), or you can build additional code in your application to do this. However, what I'm saying is that I find these things more necessary in the case of CMS end-to-end than in TLS h2h. Therefore, I wouldn't like to put additional requirements to TLS libraries or IPsec/IKE implementations that they do any sort of additional checks beyond those they currently already perform. > Also, TLS usually performs server authentication but often does not perform > client authentication. Diameter is a peer to peer protocol where it makes as > much sense to authenticate the client as it does the server. I think it would > be helpful if the base draft stated that when TLS authentication is performed, > client authentication as well as server authentication is performed. Good point. This indeed has to be done, and here we don't have the concept of HTTP authentication to cover for the client side authentication. Let's add some text to the spec to require the above. Jari From owner-aaa-wg@merit.edu Tue Oct 30 11:40:56 2001 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 LAA06502 for ; Tue, 30 Oct 2001 11:40:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1475591217; Tue, 30 Oct 2001 11:40:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D68829135C; Tue, 30 Oct 2001 11:40:44 -0500 (EST) 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 D046191217 for ; Tue, 30 Oct 2001 11:40:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id A68755DD9F; Tue, 30 Oct 2001 11:40:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 617C95DD93 for ; Tue, 30 Oct 2001 11:40:43 -0500 (EST) Received: (qmail 29631 invoked by uid 500); 30 Oct 2001 16:24:54 -0000 Date: Tue, 30 Oct 2001 08:24:53 -0800 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer Message-ID: <20011030082453.E29538@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20011030035655.C24979@charizard.diameter.org> <20011030072646.B20047@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011030072646.B20047@newman.frascone.com>; from dave@frascone.com on Tue, Oct 30, 2001 at 07:26:46AM -0600 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 30, 2001 at 07:26:46AM -0600, David Frascone wrote: > Also, the other avps should be optional. A Diameter server would not want > to inform a malicious (unknown) host of it's version, or of all the > applications it supports. and why? What is the damage caused by sending this information? PatC > > On Tue, Oct 30, 2001 at 03:56:55AM -0800, Pat Calhoun wrote: > > All, > > > > Here is the proposed text to handle this issue: > > > > 5.3 Capabilities Exchange > > > > [...] > > Receipt of a CER from an unknown peer will cause the a CEA to be returned > > with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is > > used to inform the peer that it has not been configured to communicate with > > the receiver, and doesn't wish to establish a Diameter session. > > [...] > > > > 7.1.5 Permanent Failures > > > > [...] > > DIAMETER_UNKNOWN_PEER 5019 > > A CER was received from a peer that is unknown, and the sender of > > the CEA doesn't wish to establish a Diameter transport. > > > > Comments welcomed, > > > > PatC From owner-aaa-wg@merit.edu Tue Oct 30 15:08:09 2001 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 PAA13309 for ; Tue, 30 Oct 2001 15:08:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF5F99135E; Tue, 30 Oct 2001 15:07:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B07C39135F; Tue, 30 Oct 2001 15:07:54 -0500 (EST) 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 A71049135E for ; Tue, 30 Oct 2001 15:07:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C7485DDBF; Tue, 30 Oct 2001 15:07:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 698EE5DDBB for ; Tue, 30 Oct 2001 15:07:53 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id F307579; Tue, 30 Oct 2001 15:07:52 -0500 (EST) From: "Bob Kopacz" To: "Steve Rich" , "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election Date: Tue, 30 Oct 2001 15:05:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15327.1580.117792.28267@knox6046.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, My recollection was that we talked about adding a DPR cause code, but later decided not to send DPRs during the election process, only in Open state. But my recollections are often wrong, and this wasn't my issue. Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Steve Rich > Sent: Tuesday, October 30, 2001 2:58 PM > To: Pat Calhoun > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case > of election > > > Pat Calhoun writes: > > All, > > > > I wish to reject this issue. If you look closely at the line in the state > > machine in question, it causes a CEA to be sent on the Receiver > socket, while > > the DRP is sent on the Initiator socket. This is the result of an election. > > I think the discussion came around to adding a DPR cause code > appropriate for closing the socket. > > sjr > > > > > Could the folks that originally wanted this fixed please speak up. Perhaps > > I missed something. > > > > PatC > > On Thu, Oct 25, 2001 at 05:30:11PM -0700, Pat Calhoun wrote: > > > Submitter name: Pat Calhoun > > > Submitter email address: pcalhoun@diameter.org > > > Date first submitted: 25-Oct-01 > > > Reference: > > > Document: base > > > Comment type: Technical > > > Priority: 1 > > > Section: 5.6 > > > Rationale/Explanation of issue: > > > > > > The last state machine statement is incorrect. > > > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > > I-Rcv-DPR I-Snd-DPA, R-Open > > > R-Snd-CEA > > > I-Rcv-CEA R-Snd-DPR I-Open > > > > > > If a CEA is returned with the proper error code, there is no reason > > > to send a DPR. Add the Result-Code value, and remove the DPR here. > > > > > > From owner-aaa-wg@merit.edu Tue Oct 30 15:15:12 2001 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 PAA13402 for ; Tue, 30 Oct 2001 15:15:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1C59912A7; Tue, 30 Oct 2001 14:58:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB5C09135E; Tue, 30 Oct 2001 14:58:55 -0500 (EST) 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 99315912A7 for ; Tue, 30 Oct 2001 14:58:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6D42B5DDBF; Tue, 30 Oct 2001 14:58:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (unknown [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 973375DD93 for ; Tue, 30 Oct 2001 14:58:53 -0500 (EST) Received: from knox6046.cisco.com (knox6046.cisco.com [161.44.216.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA26041; Tue, 30 Oct 2001 14:56:57 -0500 (EST) Received: (from srich@localhost) by knox6046.cisco.com (8.11.3/8.11.3) id f9UJvWu96908; Tue, 30 Oct 2001 14:57:32 -0500 (EST) (envelope-from srich) From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15327.1580.117792.28267@knox6046.cisco.com> Date: Tue, 30 Oct 2001 14:57:32 -0500 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election In-Reply-To: <20011030041230.F24979@charizard.diameter.org> References: <20011025173011.H5663@charizard.diameter.org> <20011030041230.F24979@charizard.diameter.org> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun writes: > All, > > I wish to reject this issue. If you look closely at the line in the state > machine in question, it causes a CEA to be sent on the Receiver socket, while > the DRP is sent on the Initiator socket. This is the result of an election. I think the discussion came around to adding a DPR cause code appropriate for closing the socket. sjr > > Could the folks that originally wanted this fixed please speak up. Perhaps > I missed something. > > PatC > On Thu, Oct 25, 2001 at 05:30:11PM -0700, Pat Calhoun wrote: > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: 25-Oct-01 > > Reference: > > Document: base > > Comment type: Technical > > Priority: 1 > > Section: 5.6 > > Rationale/Explanation of issue: > > > > The last state machine statement is incorrect. > > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > I-Rcv-DPR I-Snd-DPA, R-Open > > R-Snd-CEA > > I-Rcv-CEA R-Snd-DPR I-Open > > > > If a CEA is returned with the proper error code, there is no reason > > to send a DPR. Add the Result-Code value, and remove the DPR here. > > > From owner-aaa-wg@merit.edu Tue Oct 30 16:00:02 2001 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 QAA14256 for ; Tue, 30 Oct 2001 16:00:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 520489135C; Tue, 30 Oct 2001 15:59:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1702791361; Tue, 30 Oct 2001 15:59:52 -0500 (EST) 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 0D8EE9135C for ; Tue, 30 Oct 2001 15:59:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id E638B5DDAB; Tue, 30 Oct 2001 15:59:50 -0500 (EST) 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 1E07E5DD93 for ; Tue, 30 Oct 2001 15:59:50 -0500 (EST) Received: from knox6046.cisco.com (knox6046.cisco.com [161.44.216.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA27957; Tue, 30 Oct 2001 15:58:41 -0500 (EST) Received: (from srich@localhost) by knox6046.cisco.com (8.11.3/8.11.3) id f9UKxGn96997; Tue, 30 Oct 2001 15:59:16 -0500 (EST) (envelope-from srich) From: Steve Rich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15327.5284.290606.619097@knox6046.cisco.com> Date: Tue, 30 Oct 2001 15:59:16 -0500 To: "Bob Kopacz" Cc: "Steve Rich" , "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election In-Reply-To: References: <15327.1580.117792.28267@knox6046.cisco.com> X-Mailer: VM 6.93 under Emacs 21.1.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Bob. It was my issue. :) I, for one, don't see the dropping one of the two sockets opened during a glare condition and subsequent election as a ``Peer Disconnection'', per se, but that could just be my interpretation. sjr Bob Kopacz writes: > Hi, > > My recollection was that we talked about adding a DPR cause code, > but later decided not to send DPRs during the election process, > only in Open state. > > But my recollections are often wrong, and this wasn't my issue. > > Bob K. > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Steve Rich > > Sent: Tuesday, October 30, 2001 2:58 PM > > To: Pat Calhoun > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case > > of election > > > > > > Pat Calhoun writes: > > > All, > > > > > > I wish to reject this issue. If you look closely at the line in the state > > > machine in question, it causes a CEA to be sent on the Receiver > > socket, while > > > the DRP is sent on the Initiator socket. This is the result of an election. > > > > I think the discussion came around to adding a DPR cause code > > appropriate for closing the socket. > > > > sjr > > > > > > > > Could the folks that originally wanted this fixed please speak up. Perhaps > > > I missed something. > > > > > > PatC > > > On Thu, Oct 25, 2001 at 05:30:11PM -0700, Pat Calhoun wrote: > > > > Submitter name: Pat Calhoun > > > > Submitter email address: pcalhoun@diameter.org > > > > Date first submitted: 25-Oct-01 > > > > Reference: > > > > Document: base > > > > Comment type: Technical > > > > Priority: 1 > > > > Section: 5.6 > > > > Rationale/Explanation of issue: > > > > > > > > The last state machine statement is incorrect. > > > > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > > > I-Rcv-DPR I-Snd-DPA, R-Open > > > > R-Snd-CEA > > > > I-Rcv-CEA R-Snd-DPR I-Open > > > > > > > > If a CEA is returned with the proper error code, there is no reason > > > > to send a DPR. Add the Result-Code value, and remove the DPR here. > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Oct 30 17:20:17 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16056 for ; Tue, 30 Oct 2001 17:20:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23D0891361; Tue, 30 Oct 2001 17:18:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF4E491367; Tue, 30 Oct 2001 17:18:13 -0500 (EST) 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 0371691361 for ; Tue, 30 Oct 2001 17:18:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDB485DD96; Tue, 30 Oct 2001 17:18:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 57D235DD93 for ; Tue, 30 Oct 2001 17:18:09 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9UMIkQ08936 for ; Tue, 30 Oct 2001 16:18:46 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Oct 2001 16:18:08 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Oct 2001 16:18:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Date: Tue, 30 Oct 2001 16:18:10 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CCFA9@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Thread-Index: AcFhP6V62MF9g80xEdWryQAIx6S5QwAUQ7kw From: "Patil Basavaraj (NET/Dallas)" To: "'ext Pat Calhoun'" Cc: , "'Mobile IP'" X-OriginalArrivalTime: 30 Oct 2001 22:18:11.0314 (UTC) FILETIME=[C2B87D20:01C16190] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA16056 Comments below: >I guess I missed the conclusion ofthe GNAIE spec. The extension mentioned >below has many benefits, and it would be even better if it was in an FQDN >format than an NAI. This extension really will be required to the proper >operation of MobileIP+AAA. Are you stating that the AAA WG should include >the definition of the extension in one of it's documents? > >PatC Pat, I was alluding to having the HA-NAI being specified in the AAA WG, but it does not look like that makes much sense. So lets ignore that. Why is the HA-NAI absolutely required for proper operation of MIP+AAA? I do realize the HA can be assigned in a foreign domain (as mentioned in the MIP-Diameter I-D), but fail to see how you really use the HA-NAI . Maybe I am misunderstanding the problem here. Once a MN has been assigned an HA (Home or Foreign), would'nt the MN send subsequent registrations to the HA via its IP address? A new HAR at a new AAAH is a result of a reg-req from the MN. Why would this new reg-req not include the address of the HA if it had been previously assigned unless it wants a new HA (in which case it is equivalent to initial registration). -Basavaraj >On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas) wrote: >> >> Pat, >> >> The GNAIE I-D is in the process of being deprecated as a WG document. >> So refering to the GNAIE as a way to fix it may not be the solution. As >> I >> have pointed out to you and the other authors of the GNAIE I-D, the I-D >> that needs a specific NAI extension ought to define it rather than >> having a >> placeholder for extensions I-D which is reference by others. >> The FA-NAI specified in GNAIE should (or can) be specified in the >> reg-tun >> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 >> I-D. So far the HA-NAI has not been really shown as a requirement by any >> other I-Ds in the Mobile IP WG. >> >> -Basavaraj >> >> > >> > >> > Submitter name: Pat Calhoun >> > Submitter email address: pcalhoun@diameter.org >> > Date first submitted: 25-Oct-01 >> > Reference: >> > Document: MIP >> > Comment type: Technical >> > Priority: 1 >> > Section: >> > Rationale/Explanation of issue: >> > >> > Once a mobile has been assigned a home agent, if a subsequent >> > HAR is to >> > be sent, a new AAAH has no way to map the IP address in the >> > registration >> > request to a Destination-Host AVP of the Home Agent. >> > >> > Fix >> > >> > The GNAIE ID is being updated to reflect comments of the IESG. In this >> > document we will specify that the HA may include its NAI in the >> > Registration Reply, and if so, the mobile node must include >> > the same extension >> > in subsequent registration requests. This will require some >> > Mobile IP WG >> > involvement. >> > > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, October 30, 2001 6:22 AM > To: Patil Basavaraj (NET/Dallas) > Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP' > Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the > Destination-Host of a previously assigned foreign HA? > > > I guess I missed the conclusion ofthe GNAIE spec. The > extension mentioned > below has many benefits, and it would be even better if it > was in an FQDN > format than an NAI. This extension really will be required to > the proper > operation of MobileIP+AAA. Are you stating that the AAA WG > should include > the definition of the extension in one of it's documents? > > PatC > On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj > (NET/Dallas) wrote: > > > > Pat, > > > > The GNAIE I-D is in the process of being deprecated as a WG > document. > > So refering to the GNAIE as a way to fix it may not be the > solution. As > > I > > have pointed out to you and the other authors of the GNAIE > I-D, the I-D > > that needs a specific NAI extension ought to define it rather than > > having a > > placeholder for extensions I-D which is reference by others. > > The FA-NAI specified in GNAIE should (or can) be specified in the > > reg-tun > > I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 > > I-D. So far the HA-NAI has not been really shown as a > requirement by any > > other I-Ds in the Mobile IP WG. > > > > -Basavaraj > > > > > > > > > > > Submitter name: Pat Calhoun > > > Submitter email address: pcalhoun@diameter.org > > > Date first submitted: 25-Oct-01 > > > Reference: > > > Document: MIP > > > Comment type: Technical > > > Priority: 1 > > > Section: > > > Rationale/Explanation of issue: > > > > > > Once a mobile has been assigned a home agent, if a subsequent > > > HAR is to > > > be sent, a new AAAH has no way to map the IP address in the > > > registration > > > request to a Destination-Host AVP of the Home Agent. > > > > > > Fix > > > > > > The GNAIE ID is being updated to reflect comments of the > IESG. In this > > > document we will specify that the HA may include its NAI in the > > > Registration Reply, and if so, the mobile node must include > > > the same extension > > > in subsequent registration requests. This will require some > > > Mobile IP WG > > > involvement. > > > > From owner-aaa-wg@merit.edu Tue Oct 30 17:24:41 2001 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 RAA16133 for ; Tue, 30 Oct 2001 17:24:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF58491365; Tue, 30 Oct 2001 17:24:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B656191366; Tue, 30 Oct 2001 17:24:29 -0500 (EST) 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 A6CBA91365 for ; Tue, 30 Oct 2001 17:24:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81FD65DD96; Tue, 30 Oct 2001 17:24:28 -0500 (EST) 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 A96505DD93 for ; Tue, 30 Oct 2001 17:24:27 -0500 (EST) Received: from knox6039.cisco.com (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00333; Tue, 30 Oct 2001 17:23:50 -0500 (EST) Received: (from meklund@localhost) by knox6039.cisco.com (8.9.3+Sun/8.9.3) id RAA13922; Tue, 30 Oct 2001 17:24:55 -0500 (EST) X-Authentication-Warning: knox6039.cisco.com: meklund set sender to meklund@cisco.com using -f From: Mark Eklund MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15327.10423.207282.352839@gargle.gargle.HOWL> Date: Tue, 30 Oct 2001 17:24:55 -0500 To: "Bob Kopacz" Cc: "Mark Eklund" , Subject: RE: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the AAAF In-Reply-To: References: <15321.40825.298452.952075@gargle.gargle.HOWL> X-Mailer: VM 6.93 under Emacs 20.4.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz writes: > Hi Mark, > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Mark Eklund > > Sent: Friday, October 26, 2001 1:38 PM > > To: Mark Eklund > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: ISSUE: MIP-FA-to-HA being added to the AMA by the > > AAAF > > > > All, > > > > Because of concerns about the AAAH having access to the FA-HA key when > > the HA is in the foreign domain, the solution offered by this issue > > doesn't work. How about a similar answer, but one that allows > > security? > > > > Add the AVP MIP-HAA-to-AMA-Data which is opaque data of type > > OctetString. This AVP is added to the HAA by the AAAF. On receipt of > > a successful HAA, the AAAH must move this AVP from the HAA to the AMA. > > > > This allows the AAAF to put any needed key information in the HAA and > > have it available in the AMA. If the AAAF is worried about security, > > it can encrypt this information in any way it wants. > > One little snag. When Pat was at the bakeoff last Thursday, I asked if, > when the AAAF has offered to allocate an HA in the foreign network, if > the AAAH needs to send the HAR to the AAAF which sent the AMR (the FA's > AAAF), or if the HAR can be sent to any old AAAF in the foreign domain. > Because I wanted to know whether the AAAH should include a Destination-Host > AVP in the HAR, or just the Destination-Realm. The answer was that > the HAR could go to any AAAF, so don't include the Destination-Host AVP > in the HAR. > > What this means is that the MIP-HAA-to-AMA-Data AVP, if encrypted, > must be decrypted by the FA's AAAF, if the FA's AAAF is a different > server from the HA's AAAF. > > I guess this also means that it doesn't do the HA's AAAF any good > to cache the generated key and multi-session-id, since he may not > be the guy who receives the AMA. I've been thinking about this. I see several options. 1. Allow the AAAH to generate the keys for the foreign domain. * There is likely a security problem with this. 2. Use CMS to somehow encrypt the AVP and return it. * I don't think CMS will work that way. The second AAAF has to be told the first AAAF in the HAR. The AAAH has to copy the secure AVP to the AMA. If the AAAH has a security association with the FA, I'm not certain you could mix and match security associations. 3. Do the MIP-HAA-to-AMA-Data as I have suggested above. * This would mean that all the AAAF in the same domain would have a common format for what the MIP-HAA-to-AMA-Data AVP contains and if there is a form of encryption, that they would have handle decryption through a proprietary method. 4. Make no changes to Diameter and require a global database between all AAAF's in that foreign domain. * A viable solution, but the AAAF's would have to share a proprietary database. 5. Allow the MIP-HAA-to-AMA-Data avp to be sent and copied from the HAA to the AMA. * This has the same security concerns as #1. I'm leaning toward a combination of 4 and 5. If the foreign domain is not concerned about security of its FA-HA key, then it can use 5. Otherwise, it will need to use a proprietary database. -mark > > > -mark > > > > Mark Eklund writes: > > > Submitter name: Mark Eklund > > > Submitter email address: meklund@cisco.com > > > Date first submitted: 25-Oct-01 > > > Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html > > > Document: mobileip > > > Comment type: Technical > > > Priority: 1 > > > Section: 2.4, 5.3, 8.1 > > > Rationale/Explanation of issue: > > > > > > When the HA is in the foreign network and a FA-HA key is requested, > > > the AAAF generates the key. The AAAF is then responsible for adding > > > the MIP-FA-to-HA Key to the AMA. This means that the AAAF must > > > maintain a list containing all MIP-FA-to-HA Key AVPs and their > > > matching Accounting-Multi-Session-Id AVPs. When each AMA is received, > > > the AAAF must then consult the list and when it finds a matching > > > Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA. > > > > > > Requested change: > > > > > > Instead of requiring the AAAF to add the MIP-FA-to-HA Key AVP to the > > > AMA, send the MIP-FA-to-HA Key back in the HAA. The AAAH then can > > > move the MIP-FA-to-HA Key from the HAA to the AMA. > > > > > > Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4. > > > Change MIP-Feature-Vector column HAR = 0-1 to section 8.1 > > > Change MIP-FA-to-HA-Key column HAA = 0-1 to section 8.1 > > > > > > Change the final paragraph of section 5.3 to > > > > > > Upon receipt of the HAA, the Diameter server responsible for key > > > allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the > > > MIP-FA-to-HA-SPI. If the key is generated at the AAAF, it adds the > > > MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH. > > > Depending upon where the HA was located the AAAH either generates the > > > MIP-FA-to-HA Key AVP itself or extracts the AVP from the HAA sent > > > by the AAAF. The AAAH adds the MIP-FA-to-HA Key to the AMA. > > > > > > -mark > > From owner-aaa-wg@merit.edu Tue Oct 30 19:29:46 2001 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 TAA17632 for ; Tue, 30 Oct 2001 19:29:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A78BE912AC; Tue, 30 Oct 2001 19:29:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7323691363; Tue, 30 Oct 2001 19:29:24 -0500 (EST) 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 4EC7D912AC for ; Tue, 30 Oct 2001 19:29:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A3C95DD96; Tue, 30 Oct 2001 19:29:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id C188B5DD92 for ; Tue, 30 Oct 2001 19:29:22 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9V0TM017441 for ; Tue, 30 Oct 2001 18:29:22 -0600 (CST) 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 f9V0TMo09417 for ; Tue, 30 Oct 2001 18:29:22 -0600 (CST) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA09844 for ; Tue, 30 Oct 2001 18:29:21 -0600 (CST) Received: from ericberk107 (rmt160216.am.ericsson.se [138.85.160.216]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id SAA28644 for ; Tue, 30 Oct 2001 18:29:16 -0600 (CST) Message-ID: <01a301c161a3$14d98dd0$d8a0558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: References: <20011030035655.C24979@charizard.diameter.org> Subject: [AAA-WG]: New Issue: End to end identifier Date: Tue, 30 Oct 2001 16:29:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: 10/30/01 Reference: none Document: Base-08-alpha Comment type: 'T'echnical Priority: '1' Should fix Section: 3.0 Diameter Header Rationale/Explanation of issue: On diameter servers which may utilize multiple (and potentially many) processors, forcing the end-to-end identifier to be monotonically increased by one for every message sent will probably cause scalability issues. This is due to the fact that this identifier would have to be in shared memory, and would require mutually exclusive access amongst all processors in order to update the value, thus slowing down all other diameter processes waiting to send a message. Requested change: In the sentence below, remove the phrase "by incrementing the identifier by one (1)." After all, the method of ensuring the uniqueness of an identifer is probably more of an implementation issue anyway, right? Senders of request or answer messages MUST insert a unique identifier on each message, by incrementing the identifier by one (1). From owner-aaa-wg@merit.edu Tue Oct 30 22:45:10 2001 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 WAA21378 for ; Tue, 30 Oct 2001 22:45:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31C2991206; Tue, 30 Oct 2001 22:44:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1BE191211; Tue, 30 Oct 2001 22:44:57 -0500 (EST) 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 D539491206 for ; Tue, 30 Oct 2001 22:44:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1E855DDBE; Tue, 30 Oct 2001 22:44:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2E8865DD96 for ; Tue, 30 Oct 2001 22:44:56 -0500 (EST) Received: (qmail 32045 invoked by uid 500); 31 Oct 2001 03:29:01 -0000 Date: Tue, 30 Oct 2001 19:29:01 -0800 From: Pat Calhoun To: "Patil Basavaraj (NET/Dallas)" Cc: "'ext Pat Calhoun'" , aaa-wg@merit.edu, "'Mobile IP'" Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Message-ID: <20011030192900.A32037@charizard.diameter.org> Mail-Followup-To: "Patil Basavaraj (NET/Dallas)" , 'ext Pat Calhoun' , aaa-wg@merit.edu, 'Mobile IP' References: <697DAA22C5004B4596E033803A7CEF444CCFA9@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCFA9@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Tue, Oct 30, 2001 at 04:18:10PM -0600 Sender: owner-aaa-wg@merit.edu Precedence: bulk The problem has to do with re-registrations. Since the AAAH is stateless, it may not know the FQDN of the Home Agent assigned. All it has is the IP address, and folks felt that IP->FQDN translation may not be reliable in certain environments. So if the mobile could state the HA's FQDN, that would solve all of the problems. PatC On Tue, Oct 30, 2001 at 04:18:10PM -0600, Patil Basavaraj (NET/Dallas) wrote: > > Comments below: > > >I guess I missed the conclusion ofthe GNAIE spec. The extension > mentioned > >below has many benefits, and it would be even better if it was in an > FQDN > >format than an NAI. This extension really will be required to the > proper > >operation of MobileIP+AAA. Are you stating that the AAA WG should > include > >the definition of the extension in one of it's documents? > > > >PatC > > Pat, > > I was alluding to having the HA-NAI being specified in the AAA WG, but > it does not look like that makes much sense. So lets ignore that. > > Why is the HA-NAI absolutely required for proper operation of MIP+AAA? > I do realize the HA can be assigned in a foreign domain (as mentioned > in the MIP-Diameter I-D), but fail to see how you really use the > HA-NAI . Maybe I am misunderstanding the problem here. > > Once a MN has been assigned an HA (Home or Foreign), would'nt the MN > send subsequent registrations to the HA via its IP address? A new HAR > at a new AAAH is a result of a reg-req from the MN. Why would this new > reg-req not include the address of the HA if it had been previously > assigned unless it wants a new HA (in which case it is equivalent to > initial registration). > > -Basavaraj > > >On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas) > wrote: > >> > >> Pat, > >> > >> The GNAIE I-D is in the process of being deprecated as a WG document. > >> So refering to the GNAIE as a way to fix it may not be the solution. > As > >> I > >> have pointed out to you and the other authors of the GNAIE I-D, the > I-D > >> that needs a specific NAI extension ought to define it rather than > >> having a > >> placeholder for extensions I-D which is reference by others. > >> The FA-NAI specified in GNAIE should (or can) be specified in the > >> reg-tun > >> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 > >> I-D. So far the HA-NAI has not been really shown as a requirement by > any > >> other I-Ds in the Mobile IP WG. > >> > >> -Basavaraj > >> > >> > > >> > > >> > Submitter name: Pat Calhoun > >> > Submitter email address: pcalhoun@diameter.org > >> > Date first submitted: 25-Oct-01 > >> > Reference: > >> > Document: MIP > >> > Comment type: Technical > >> > Priority: 1 > >> > Section: > >> > Rationale/Explanation of issue: > >> > > >> > Once a mobile has been assigned a home agent, if a subsequent > >> > HAR is to > >> > be sent, a new AAAH has no way to map the IP address in the > >> > registration > >> > request to a Destination-Host AVP of the Home Agent. > >> > > >> > Fix > >> > > >> > The GNAIE ID is being updated to reflect comments of the IESG. In > this > >> > document we will specify that the HA may include its NAI in the > >> > Registration Reply, and if so, the mobile node must include > >> > the same extension > >> > in subsequent registration requests. This will require some > >> > Mobile IP WG > >> > involvement. > >> > > > > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Tuesday, October 30, 2001 6:22 AM > > To: Patil Basavaraj (NET/Dallas) > > Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP' > > Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the > > Destination-Host of a previously assigned foreign HA? > > > > > > I guess I missed the conclusion ofthe GNAIE spec. The > > extension mentioned > > below has many benefits, and it would be even better if it > > was in an FQDN > > format than an NAI. This extension really will be required to > > the proper > > operation of MobileIP+AAA. Are you stating that the AAA WG > > should include > > the definition of the extension in one of it's documents? > > > > PatC > > On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj > > (NET/Dallas) wrote: > > > > > > Pat, > > > > > > The GNAIE I-D is in the process of being deprecated as a WG > > document. > > > So refering to the GNAIE as a way to fix it may not be the > > solution. As > > > I > > > have pointed out to you and the other authors of the GNAIE > > I-D, the I-D > > > that needs a specific NAI extension ought to define it rather than > > > having a > > > placeholder for extensions I-D which is reference by others. > > > The FA-NAI specified in GNAIE should (or can) be specified in the > > > reg-tun > > > I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 > > > I-D. So far the HA-NAI has not been really shown as a > > requirement by any > > > other I-Ds in the Mobile IP WG. > > > > > > -Basavaraj > > > > > > > > > > > > > > > Submitter name: Pat Calhoun > > > > Submitter email address: pcalhoun@diameter.org > > > > Date first submitted: 25-Oct-01 > > > > Reference: > > > > Document: MIP > > > > Comment type: Technical > > > > Priority: 1 > > > > Section: > > > > Rationale/Explanation of issue: > > > > > > > > Once a mobile has been assigned a home agent, if a subsequent > > > > HAR is to > > > > be sent, a new AAAH has no way to map the IP address in the > > > > registration > > > > request to a Destination-Host AVP of the Home Agent. > > > > > > > > Fix > > > > > > > > The GNAIE ID is being updated to reflect comments of the > > IESG. In this > > > > document we will specify that the HA may include its NAI in the > > > > Registration Reply, and if so, the mobile node must include > > > > the same extension > > > > in subsequent registration requests. This will require some > > > > Mobile IP WG > > > > involvement. > > > > > > From owner-aaa-wg@merit.edu Wed Oct 31 00:31:25 2001 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 AAA22678 for ; Wed, 31 Oct 2001 00:31:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 53FBE91211; Wed, 31 Oct 2001 00:30:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A0129121D; Wed, 31 Oct 2001 00:30:17 -0500 (EST) 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 D2EC791211 for ; Wed, 31 Oct 2001 00:30:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id A63C65DD92; Wed, 31 Oct 2001 00:30:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 20C7B5DD8F for ; Wed, 31 Oct 2001 00:30:15 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9V5UIQ02818 for ; Tue, 30 Oct 2001 23:30:18 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Oct 2001 23:30:14 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Oct 2001 23:30:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Date: Tue, 30 Oct 2001 23:30:13 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CCFB0@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Thread-Index: AcFhvmnpN/5rD82xEdWpXgBQi2kYTQADp9Qg From: "Patil Basavaraj (NET/Dallas)" To: "'ext Pat Calhoun'" Cc: , "'Mobile IP'" X-OriginalArrivalTime: 31 Oct 2001 05:30:13.0768 (UTC) FILETIME=[1DB51080:01C161CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA22678 >(The problem has to do with re-registrations. Since the AAAH is stateless, >it may not know the FQDN of the Home Agent assigned. All it has is the IP >address, and folks felt that IP->FQDN translation may not be reliable in >certain environments. Possibly. But are there are any real requirements or example scenarios where the FQDN of the HA is required and how the AAAH utilises this info? Also why would re-registrations utilize the AAA network elements? The MN can directly send subsequent registrations to the HA that has been previously assigned to it via AAAH (maybe in a foreign domain). >So if the mobile could state the HA's FQDN, that would >solve all of the problems. Not sure if we really have a strong argument for having the MN send the FQDN of the HA to the AAAH here yet. > >PatC -Basavaraj On Tue, Oct 30, 2001 at 04:18:10PM -0600, Patil Basavaraj (NET/Dallas) wrote: > > Comments below: > > >I guess I missed the conclusion ofthe GNAIE spec. The extension > mentioned > >below has many benefits, and it would be even better if it was in an > FQDN > >format than an NAI. This extension really will be required to the > proper > >operation of MobileIP+AAA. Are you stating that the AAA WG should > include > >the definition of the extension in one of it's documents? > > > >PatC > > Pat, > > I was alluding to having the HA-NAI being specified in the AAA WG, but > it does not look like that makes much sense. So lets ignore that. > > Why is the HA-NAI absolutely required for proper operation of MIP+AAA? > I do realize the HA can be assigned in a foreign domain (as mentioned > in the MIP-Diameter I-D), but fail to see how you really use the > HA-NAI . Maybe I am misunderstanding the problem here. > > Once a MN has been assigned an HA (Home or Foreign), would'nt the MN > send subsequent registrations to the HA via its IP address? A new HAR > at a new AAAH is a result of a reg-req from the MN. Why would this new > reg-req not include the address of the HA if it had been previously > assigned unless it wants a new HA (in which case it is equivalent to > initial registration). > > -Basavaraj > > >On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj (NET/Dallas) > wrote: > >> > >> Pat, > >> > >> The GNAIE I-D is in the process of being deprecated as a WG document. > >> So refering to the GNAIE as a way to fix it may not be the solution. > As > >> I > >> have pointed out to you and the other authors of the GNAIE I-D, the > I-D > >> that needs a specific NAI extension ought to define it rather than > >> having a > >> placeholder for extensions I-D which is reference by others. > >> The FA-NAI specified in GNAIE should (or can) be specified in the > >> reg-tun > >> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 > >> I-D. So far the HA-NAI has not been really shown as a requirement by > any > >> other I-Ds in the Mobile IP WG. > >> > >> -Basavaraj > >> > >> > > >> > > >> > Submitter name: Pat Calhoun > >> > Submitter email address: pcalhoun@diameter.org > >> > Date first submitted: 25-Oct-01 > >> > Reference: > >> > Document: MIP > >> > Comment type: Technical > >> > Priority: 1 > >> > Section: > >> > Rationale/Explanation of issue: > >> > > >> > Once a mobile has been assigned a home agent, if a subsequent > >> > HAR is to > >> > be sent, a new AAAH has no way to map the IP address in the > >> > registration > >> > request to a Destination-Host AVP of the Home Agent. > >> > > >> > Fix > >> > > >> > The GNAIE ID is being updated to reflect comments of the IESG. In > this > >> > document we will specify that the HA may include its NAI in the > >> > Registration Reply, and if so, the mobile node must include > >> > the same extension > >> > in subsequent registration requests. This will require some > >> > Mobile IP WG > >> > involvement. > >> > > > > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Tuesday, October 30, 2001 6:22 AM > > To: Patil Basavaraj (NET/Dallas) > > Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP' > > Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the > > Destination-Host of a previously assigned foreign HA? > > > > > > I guess I missed the conclusion ofthe GNAIE spec. The > > extension mentioned > > below has many benefits, and it would be even better if it > > was in an FQDN > > format than an NAI. This extension really will be required to > > the proper > > operation of MobileIP+AAA. Are you stating that the AAA WG > > should include > > the definition of the extension in one of it's documents? > > > > PatC > > On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj > > (NET/Dallas) wrote: > > > > > > Pat, > > > > > > The GNAIE I-D is in the process of being deprecated as a WG > > document. > > > So refering to the GNAIE as a way to fix it may not be the > > solution. As > > > I > > > have pointed out to you and the other authors of the GNAIE > > I-D, the I-D > > > that needs a specific NAI extension ought to define it rather than > > > having a > > > placeholder for extensions I-D which is reference by others. > > > The FA-NAI specified in GNAIE should (or can) be specified in the > > > reg-tun > > > I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 > > > I-D. So far the HA-NAI has not been really shown as a > > requirement by any > > > other I-Ds in the Mobile IP WG. > > > > > > -Basavaraj > > > > > > > > > > > > > > > Submitter name: Pat Calhoun > > > > Submitter email address: pcalhoun@diameter.org > > > > Date first submitted: 25-Oct-01 > > > > Reference: > > > > Document: MIP > > > > Comment type: Technical > > > > Priority: 1 > > > > Section: > > > > Rationale/Explanation of issue: > > > > > > > > Once a mobile has been assigned a home agent, if a subsequent > > > > HAR is to > > > > be sent, a new AAAH has no way to map the IP address in the > > > > registration > > > > request to a Destination-Host AVP of the Home Agent. > > > > > > > > Fix > > > > > > > > The GNAIE ID is being updated to reflect comments of the > > IESG. In this > > > > document we will specify that the HA may include its NAI in the > > > > Registration Reply, and if so, the mobile node must include > > > > the same extension > > > > in subsequent registration requests. This will require some > > > > Mobile IP WG > > > > involvement. > > > > > > From owner-aaa-wg@merit.edu Wed Oct 31 01:47:25 2001 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 BAA28604 for ; Wed, 31 Oct 2001 01:47:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA4189121D; Wed, 31 Oct 2001 01:46:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A256F9121E; Wed, 31 Oct 2001 01:46:42 -0500 (EST) 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 9C22A9121D for ; Wed, 31 Oct 2001 01:46:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 726F15DD92; Wed, 31 Oct 2001 01:46:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 8F2485DD8F for ; Wed, 31 Oct 2001 01:46:40 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f9V6kew20438 for aaa-wg@merit.edu; Wed, 31 Oct 2001 01:46:40 -0500 (EST) (envelope-from barney) Date: Wed, 31 Oct 2001 01:46:35 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: New Issue: End to end identifier Message-ID: <20011031014635.B20029@tp.databus.com> References: <20011030035655.C24979@charizard.diameter.org> <01a301c161a3$14d98dd0$d8a0558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01a301c161a3$14d98dd0$d8a0558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Tue, Oct 30, 2001 at 04:29:02PM -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk I cannot imagine any implementation where a single spinlock-protected increment would even be measurable, so I'd urge rejection of this issue. Do all these processors share a single transport connection? If so, there are many more accesses that need protection. If not, you're making scalability problems for your peer. If you don't have shared memory, do the id assignment and increment in the process that owns the transport. Or allocate N id's per invocation. I don't see a requirement here to actually transmit the messages in id order. On Tue, Oct 30, 2001 at 04:29:02PM -0800, Kevin Purser wrote: > Submitter name: Kevin Purser > Submitter email address: kevin.purser@ericsson.com > Date first submitted: 10/30/01 > Reference: none > Document: Base-08-alpha > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 3.0 Diameter Header > Rationale/Explanation of issue: > > On diameter servers which may utilize multiple (and potentially many) > processors, forcing the end-to-end identifier to be monotonically increased > by one for every message sent will probably cause scalability issues. This > is due to the fact that this identifier would have to be in shared memory, > and would require mutually exclusive access amongst all processors in order > to update the value, thus slowing down all other diameter processes waiting > to send a message. > > Requested change: > In the sentence below, remove the phrase "by incrementing the identifier by > one (1)." After all, the method of ensuring the uniqueness of an identifer > is probably more of an implementation issue anyway, right? > > Senders of request or answer messages MUST > insert a unique identifier on each message, by incrementing the > identifier by one (1). > > -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. From owner-aaa-wg@merit.edu Wed Oct 31 09:46:20 2001 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 JAA20406 for ; Wed, 31 Oct 2001 09:46:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BBE9E9120C; Wed, 31 Oct 2001 09:45:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85D0B91223; Wed, 31 Oct 2001 09:45:16 -0500 (EST) 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 59CED9120C for ; Wed, 31 Oct 2001 09:45:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 31D1E5DD8E; Wed, 31 Oct 2001 09:45:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E354A5DDB8 for ; Wed, 31 Oct 2001 09:45:14 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 0FC3174; Wed, 31 Oct 2001 09:45:14 -0500 (EST) From: "Bob Kopacz" To: "Barney Wolff" , Subject: RE: [AAA-WG]: New Issue: End to end identifier Date: Wed, 31 Oct 2001 09:42:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20011031014635.B20029@tp.databus.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Barney and Kevin, I'd like to see this accepted, for the same reasons that Kevin stated, plus more. This isn't actually a new issue. Issue#93 is about the e-t-e identifier. I re-opened this issue in an email on 10-12-2001, because I saw what I believe to be a flaw in the current draft regarding e-t-e identifier. I also requested that the "increment by 1" requirement be removed. There were a few emails exchanged among Pat, Barney, Mark, and myself, but then the thread quietly died without resolution. Here's a rehash of my thinking as to why the "increment by 1" is unuseful and unnecessary: The "increment by 1" requirement seems to be an over-specification which imposes restrictions on the message originator's implementation, is undetectable by the message's recipient, and doesn't benefit the message's recipient. The previous thread concluded that a receiver could not make use of the "increment by 1". Chiefly, a recipient may receive an unordered and vanishingly small percentage of a client's Diameter messages. I was also thinking that the "increment by 1" might cause complications for multi-process Diameter implementations. For example, imagine a Diameter server implemented as three communicating processes: The NASREQ application is one process. The Mobile-IP application is a second process. And there is a third lower-level process which handles the Diameter base protocol and the TCP/SCTP connections. When the NASREQ application or Mobile-IP application originate a message, they pass it to the lower-level process for transmission. If there is an "increment by 1" rule, then the applications would need to access some common "end-to-end-identifier allocator". Or the applications would have to let the lower-level transport process assign the end-to-end-identifier, but then the lower-level transport process would have to return it to the application process. If there wasn't an "increment by 1" rule, than each application could manage its own end-to-end-identifier allocation, as long as it didn't clash with the end-to-end-identifiers allocated by other processes. To ensure a non-clash in this example, the NASREQ application could assign even-numbered end-to-end-identifiers, while the Mobile-IP application could assign odd-numbered end-to-end-identifiers. In this case, then, each application would be incrementing by two rather than one. Bob K. > From: owner-aaa-wg@merit.edu on behalf of Barney Wolff > [barney@databus.com] > Sent: Wednesday, October 31, 2001 1:47 AM > To: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: New Issue: End to end identifier > > I cannot imagine any implementation where a single spinlock-protected > increment would even be measurable, so I'd urge rejection of this issue. > Do all these processors share a single transport connection? If so, > there are many more accesses that need protection. If not, you're > making scalability problems for your peer. > > If you don't have shared memory, do the id assignment and increment in > the process that owns the transport. Or allocate N id's per invocation. > I don't see a requirement here to actually transmit the messages in > id order. > > On Tue, Oct 30, 2001 at 04:29:02PM -0800, Kevin Purser wrote: > > Submitter name: Kevin Purser > > Submitter email address: kevin.purser@ericsson.com > > Date first submitted: 10/30/01 > > Reference: none > > Document: Base-08-alpha > > Comment type: 'T'echnical > > Priority: '1' Should fix > > Section: 3.0 Diameter Header > > Rationale/Explanation of issue: > > > > On diameter servers which may utilize multiple (and potentially many) > > processors, forcing the end-to-end identifier to be monotonically increased > > by one for every message sent will probably cause scalability issues. This > > is due to the fact that this identifier would have to be in shared memory, > > and would require mutually exclusive access amongst all processors in order > > to update the value, thus slowing down all other diameter processes waiting > > to send a message. > > > > Requested change: > > In the sentence below, remove the phrase "by incrementing the identifier by > > one (1)." After all, the method of ensuring the uniqueness of an identifer > > is probably more of an implementation issue anyway, right? > > > > Senders of request or answer messages MUST > > insert a unique identifier on each message, by incrementing the > > identifier by one (1). > > > > > > -- > Barney Wolff Bob K. From owner-aaa-wg@merit.edu Wed Oct 31 09:59:41 2001 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 JAA20793 for ; Wed, 31 Oct 2001 09:59:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 69C9791223; Wed, 31 Oct 2001 09:59:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BC10912AB; Wed, 31 Oct 2001 09:59:29 -0500 (EST) 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 2F70291223 for ; Wed, 31 Oct 2001 09:59:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0CEBC5DDCF; Wed, 31 Oct 2001 09:59:28 -0500 (EST) 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 676025DDB2 for ; Wed, 31 Oct 2001 09:59:27 -0500 (EST) Received: (qmail 11170 invoked by uid 500); 31 Oct 2001 14:59:26 -0000 Date: Wed, 31 Oct 2001 08:59:25 -0600 From: David Frascone To: Kevin Purser Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: New Issue: End to end identifier Message-ID: <20011031085925.A11153@newman.frascone.com> Mail-Followup-To: Kevin Purser , aaa-wg@merit.edu References: <20011030035655.C24979@charizard.diameter.org> <01a301c161a3$14d98dd0$d8a0558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01a301c161a3$14d98dd0$d8a0558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Tue, Oct 30, 2001 at 04:29:02PM -0800 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I agree that it is an implementation issue. I think "implementing by one" should be removed and left up to the implementor. On Tue, Oct 30, 2001 at 04:29:02PM -0800, Kevin Purser wrote: > Submitter name: Kevin Purser > Submitter email address: kevin.purser@ericsson.com > Date first submitted: 10/30/01 > Reference: none > Document: Base-08-alpha > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 3.0 Diameter Header > Rationale/Explanation of issue: > > On diameter servers which may utilize multiple (and potentially many) > processors, forcing the end-to-end identifier to be monotonically increased > by one for every message sent will probably cause scalability issues. This > is due to the fact that this identifier would have to be in shared memory, > and would require mutually exclusive access amongst all processors in order > to update the value, thus slowing down all other diameter processes waiting > to send a message. > > Requested change: > In the sentence below, remove the phrase "by incrementing the identifier by > one (1)." After all, the method of ensuring the uniqueness of an identifer > is probably more of an implementation issue anyway, right? > > Senders of request or answer messages MUST > insert a unique identifier on each message, by incrementing the > identifier by one (1). > > From owner-aaa-wg@merit.edu Wed Oct 31 10:09:25 2001 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 KAA21125 for ; Wed, 31 Oct 2001 10:09:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C590D912AD; Wed, 31 Oct 2001 10:09:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91282912AE; Wed, 31 Oct 2001 10:09:03 -0500 (EST) 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 715F3912AD for ; Wed, 31 Oct 2001 10:09:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 506685DDB2; Wed, 31 Oct 2001 10:09:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id BB0BB5DD8E for ; Wed, 31 Oct 2001 10:08:59 -0500 (EST) Received: from fredrikj (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA16451; Wed, 31 Oct 2001 16:08:36 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" , "Patil Basavaraj (NET/Dallas)" Cc: , "'Mobile IP'" Subject: RE: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Date: Wed, 31 Oct 2001 16:09:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011030042137.H24979@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit if we are specifying the new extension in the MIPv4 Application for diameter, can we then make it a URI instead, that way we will have all information we'll ever need, such as port and transport. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 30 oktober 2001 13:22 >To: Patil Basavaraj (NET/Dallas) >Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu; 'Mobile IP' >Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the >Destination-Host of a previously assigned foreign HA? > > >I guess I missed the conclusion ofthe GNAIE spec. The extension mentioned >below has many benefits, and it would be even better if it was in an FQDN >format than an NAI. This extension really will be required to the proper >operation of MobileIP+AAA. Are you stating that the AAA WG should include >the definition of the extension in one of it's documents? > >PatC >On Fri, Oct 26, 2001 at 11:53:16AM -0500, Patil Basavaraj >(NET/Dallas) wrote: >> >> Pat, >> >> The GNAIE I-D is in the process of being deprecated as a WG document. >> So refering to the GNAIE as a way to fix it may not be the solution. As >> I >> have pointed out to you and the other authors of the GNAIE I-D, the I-D >> that needs a specific NAI extension ought to define it rather than >> having a >> placeholder for extensions I-D which is reference by others. >> The FA-NAI specified in GNAIE should (or can) be specified in the >> reg-tun >> I-D i MIP WG and the HA-NAI can be specified in this Diameter-MIPv4 >> I-D. So far the HA-NAI has not been really shown as a requirement by any >> other I-Ds in the Mobile IP WG. >> >> -Basavaraj >> >> > >> > >> > Submitter name: Pat Calhoun >> > Submitter email address: pcalhoun@diameter.org >> > Date first submitted: 25-Oct-01 >> > Reference: >> > Document: MIP >> > Comment type: Technical >> > Priority: 1 >> > Section: >> > Rationale/Explanation of issue: >> > >> > Once a mobile has been assigned a home agent, if a subsequent >> > HAR is to >> > be sent, a new AAAH has no way to map the IP address in the >> > registration >> > request to a Destination-Host AVP of the Home Agent. >> > >> > Fix >> > >> > The GNAIE ID is being updated to reflect comments of the IESG. In this >> > document we will specify that the HA may include its NAI in the >> > Registration Reply, and if so, the mobile node must include >> > the same extension >> > in subsequent registration requests. This will require some >> > Mobile IP WG >> > involvement. >> > From owner-aaa-wg@merit.edu Wed Oct 31 10:42:24 2001 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 KAA22073 for ; Wed, 31 Oct 2001 10:42:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0C67912AE; Wed, 31 Oct 2001 10:42:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A83F9912AF; Wed, 31 Oct 2001 10:42:13 -0500 (EST) 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 9423A912AE for ; Wed, 31 Oct 2001 10:42:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 694DE5DDDE; Wed, 31 Oct 2001 10:42:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1DCE15DD8E for ; Wed, 31 Oct 2001 10:42:12 -0500 (EST) Received: (qmail 1704 invoked by uid 500); 31 Oct 2001 15:26:19 -0000 Date: Wed, 31 Oct 2001 07:26:19 -0800 From: Pat Calhoun To: "Patil Basavaraj (NET/Dallas)" Cc: "'ext Pat Calhoun'" , aaa-wg@merit.edu, "'Mobile IP'" Subject: Re: [AAA-WG]: Issue 212: How does the AAAH know the Destination-Host of a previously assigned foreign HA? Message-ID: <20011031072618.A1694@charizard.diameter.org> Mail-Followup-To: "Patil Basavaraj (NET/Dallas)" , 'ext Pat Calhoun' , aaa-wg@merit.edu, 'Mobile IP' References: <697DAA22C5004B4596E033803A7CEF444CCFB0@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CCFB0@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Tue, Oct 30, 2001 at 11:30:13PM -0600 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 30, 2001 at 11:30:13PM -0600, Patil Basavaraj (NET/Dallas) wrote: > > >(The problem has to do with re-registrations. Since the AAAH is > stateless, > >it may not know the FQDN of the Home Agent assigned. All it has is the > IP > >address, and folks felt that IP->FQDN translation may not be reliable > in > >certain environments. > > Possibly. But are there are any real requirements or example scenarios > where the FQDN of the HA is required and how the AAAH utilises this > info? yes, without it the protocol doesn't work (hope that's a good enough requirement :) > Also why would re-registrations utilize the AAA network elements? The > MN can directly send subsequent registrations to the HA that has been > previously assigned to it via AAAH (maybe in a foreign domain). this can occur in two circumstances: 1. Mobile moves to a new foreign agent (once the fast handoff/CT work is complete perhaps the FAs in a domain will be able to share keys, but for now this isn't possible) 2. Once #1 is resolved, when the mobile uses a foreign agent in a new domain > > >So if the mobile could state the HA's FQDN, that would > >solve all of the problems. > > Not sure if we really have a strong argument for having the MN send > the FQDN of the HA to the AAAH here yet. Well, as I mentioned, without this info, MIP+AAA doesn't work. When an AAAH receives a registration request, it doesn't know the identity of the Home Agent. It does have an IP address, but it needs to know how to route the message via Diameter, and this is based on FQDN (to provide inter domain message routing). So if the AAAH only gets an IP address, it would have to map it to FQDN via DNS, and some folks are arguing that this is the wrong approach. If others feel that this is sufficient, please speak up. All I have is data from the parties implying this is not a workable solution. PatC From owner-aaa-wg@merit.edu Wed Oct 31 10:44:27 2001 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 KAA22166 for ; Wed, 31 Oct 2001 10:44:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EDEF912AF; Wed, 31 Oct 2001 10:44:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F09B5912B0; Wed, 31 Oct 2001 10:44:16 -0500 (EST) 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 E08D5912AF for ; Wed, 31 Oct 2001 10:44:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA5BD5DDDA; Wed, 31 Oct 2001 10:44:15 -0500 (EST) 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 C1D4A5DD8E for ; Wed, 31 Oct 2001 10:44:14 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9VFiqA25726 for ; Wed, 31 Oct 2001 17:44:52 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 31 Oct 2001 17:44:12 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 31 Oct 2001 17:44:12 +0200 Message-ID: <9E3407CE45911B4097632389B77B20230DC584@esebe014.NOE.Nokia.com> From: Adrian.Constantin@nokia.com To: diameter@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: Sessions in API specification Date: Wed, 31 Oct 2001 17:43:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi! I know that the API specification is not synchronized with the latest base protocol (BP) spec., but it would be very useful to clarify few things related to the session, as it is defined in API doc. 1. Some features of the API-session make it look more like BP user sessions (section 8 - diameter-07): - C API uses the userName as a parameter of the AAAStartSession() - Java API has a method AAASessionManager::getNetworkSessionId() which makes the relationship between API-session and BP-session 1-1. 2. Other features make the API-session look more like an identifier of the peer connection. - Java API uses the server address (I understand it as the peer address, because that's the only information that the base protocol keeps) for starting a session. This ties the session to the peer which makes a failover procedure very complicated. 3. Who keeps the user session state machine and who generates the Session-Id AVP? Because the information affecting the session state machine is in the application domain (the application generates and understands the corresponding messages) it seems more natural that the application implementation also keeps the session state. If so, it is also the responsibility of the application to generate the Session-Id AVP and add it to the message. If the base protocol library keeps the session state machine (as suggested in Java API) then the library would have to take the info related to this state machine from the application messages. This means that the library should check each message sent and extract the information related to the session. Regards, Adrian From owner-aaa-wg@merit.edu Wed Oct 31 10:51:27 2001 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 KAA22346 for ; Wed, 31 Oct 2001 10:51:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DEDB0912B0; Wed, 31 Oct 2001 10:51:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B087D912B1; Wed, 31 Oct 2001 10:51:05 -0500 (EST) 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 B6CC7912B0 for ; Wed, 31 Oct 2001 10:51:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AAB75DDDE; Wed, 31 Oct 2001 10:51:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E95895DD8E for ; Wed, 31 Oct 2001 10:51:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA40277 for ; Wed, 31 Oct 2001 07:42:10 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 31 Oct 2001 07:42:10 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Agenda for IETF 51 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a call for agenda items for IETF 51. We will have two sessions. From owner-aaa-wg@merit.edu Wed Oct 31 11:08:07 2001 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 LAA22923 for ; Wed, 31 Oct 2001 11:08:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C4AA912B1; Wed, 31 Oct 2001 11:07:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BF8F912B2; Wed, 31 Oct 2001 11:07:47 -0500 (EST) 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 13FF2912B1 for ; Wed, 31 Oct 2001 11:07:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCD2D5DDDC; Wed, 31 Oct 2001 11:07:45 -0500 (EST) 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 47DDD5DDC2 for ; Wed, 31 Oct 2001 11:07:45 -0500 (EST) Received: (qmail 11863 invoked by uid 500); 31 Oct 2001 16:07:44 -0000 Date: Wed, 31 Oct 2001 10:07:44 -0600 From: David Frascone To: Adrian.Constantin@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Sessions in API specification Message-ID: <20011031100744.B11153@newman.frascone.com> Mail-Followup-To: Adrian.Constantin@nokia.com, aaa-wg@merit.edu References: <9E3407CE45911B4097632389B77B20230DC584@esebe014.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9E3407CE45911B4097632389B77B20230DC584@esebe014.NOE.Nokia.com>; from Adrian.Constantin@nokia.com on Wed, Oct 31, 2001 at 05:43:57PM +0200 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Since it's now a WG document, I'm not cross-posting this response to diameter@diameter.org. On Wed, Oct 31, 2001 at 05:43:57PM +0200, Adrian.Constantin@nokia.com wrote: > I know that the API specification is not synchronized with the latest base > protocol (BP) spec., but it would be very useful to clarify few things > related to the session, as it is defined in API doc. > > 1. Some features of the API-session make it look more like BP user sessions > (section 8 - diameter-07): > - C API uses the userName as a parameter of the AAAStartSession() The sessions in the API are *completely* out of date. They need to be re-done. Currently, the sessions in the API do *not* correspond to sessions in the Diameter protocol. They were instituted before Diameter sessions were formalized. In the API, it was a way to match up requests and responses at the API layer, not at the protocol layer. So, I guess the answer to your question, in short, is: The API draft is badly out of date :( I'll be working on updating it soon. -Dave From owner-aaa-wg@merit.edu Wed Oct 31 13:07:55 2001 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 NAA26468 for ; Wed, 31 Oct 2001 13:07:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03024912B3; Wed, 31 Oct 2001 13:07:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9081912B4; Wed, 31 Oct 2001 13:07:41 -0500 (EST) 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 B4ECA912B3 for ; Wed, 31 Oct 2001 13:07:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 868195DDDF; Wed, 31 Oct 2001 13:07:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 270CC5DD8E for ; Wed, 31 Oct 2001 13:07:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9VI7Z017206; Wed, 31 Oct 2001 12:07:35 -0600 (CST) 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 f9VI7Ye29972; Wed, 31 Oct 2001 12:07:34 -0600 (CST) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA26952; Wed, 31 Oct 2001 12:07:34 -0600 (CST) Received: from ericsson.com (rcur181ip232.ericsson.se [147.214.181.232]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA11018; Wed, 31 Oct 2001 12:07:29 -0600 (CST) Message-ID: <3BE03DB1.BD12382F@ericsson.com> Date: Wed, 31 Oct 2001 10:06:41 -0800 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Steve Rich , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case of election 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 agree. I think we said that a CEA with a new result-code set "Disconnect peer" on the loosing connection instead of DPR/DPA. And only use DPR's on open state connections. /Tony Bob Kopacz wrote: > > Hi, > > My recollection was that we talked about adding a DPR cause code, > but later decided not to send DPRs during the election process, > only in Open state. > > But my recollections are often wrong, and this wasn't my issue. > > Bob K. > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > > Steve Rich > > Sent: Tuesday, October 30, 2001 2:58 PM > > To: Pat Calhoun > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case > > of election > > > > > > Pat Calhoun writes: > > > All, > > > > > > I wish to reject this issue. If you look closely at the line in the state > > > machine in question, it causes a CEA to be sent on the Receiver > > socket, while > > > the DRP is sent on the Initiator socket. This is the result of an election. > > > > I think the discussion came around to adding a DPR cause code > > appropriate for closing the socket. > > > > sjr > > > > > > > > Could the folks that originally wanted this fixed please speak up. Perhaps > > > I missed something. > > > > > > PatC > > > On Thu, Oct 25, 2001 at 05:30:11PM -0700, Pat Calhoun wrote: > > > > Submitter name: Pat Calhoun > > > > Submitter email address: pcalhoun@diameter.org > > > > Date first submitted: 25-Oct-01 > > > > Reference: > > > > Document: base > > > > Comment type: Technical > > > > Priority: 1 > > > > Section: 5.6 > > > > Rationale/Explanation of issue: > > > > > > > > The last state machine statement is incorrect. > > > > Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > > > I-Rcv-DPR I-Snd-DPA, R-Open > > > > R-Snd-CEA > > > > I-Rcv-CEA R-Snd-DPR I-Open > > > > > > > > If a CEA is returned with the proper error code, there is no reason > > > > to send a DPR. Add the Result-Code value, and remove the DPR here. > > > > > > > > > From owner-aaa-wg@merit.edu Wed Oct 31 13:24:04 2001 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 NAA27133 for ; Wed, 31 Oct 2001 13:24:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B668A91213; Wed, 31 Oct 2001 13:23:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86665912B4; Wed, 31 Oct 2001 13:23:42 -0500 (EST) 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 822F691213 for ; Wed, 31 Oct 2001 13:23:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B82B5DDDF; Wed, 31 Oct 2001 13:23:41 -0500 (EST) 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 DDACA5DD8E for ; Wed, 31 Oct 2001 13:23:40 -0500 (EST) Received: (qmail 13671 invoked by uid 500); 31 Oct 2001 18:23:40 -0000 Date: Wed, 31 Oct 2001 12:23:40 -0600 From: David Frascone To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Connectathon 2002 Message-ID: <20011031122339.F12689@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Apologies for the cross post :) I have been asked to find out if anyone is planning on testing Diameter Implementations at the Connectathon next year. (The Connectathon announcement is below) Please send me a note (privately) if you are planning on testing Diameter. (If the turn out is low, Diameter will not be added to the Agenda) Thanks in advance, Dave ----- Connectathon 2002 Announcement -------- The Connectathon team is delighted to announce its 16th annual event will take place as scheduled. Connectathon 2002, an interoperability testing event for engineers only, will be held Feb. 28-Mar. 7, 2002 in San Jose, California. Sponsored by Sun Microsystems, Inc., Connectathon hosts over 50 companies from around the globe in an effort to test and debug source code. Currently, the following technologies and protocols are on the agenda: NFS versions 2, 3 and 4 NFS over RDMA WebNFS Lock Manager NIS/NIS+ Automounter Kerberos IPv6 IPsec Mobile IPv4 Mobile IPv6 Secure Shell NDMP Based on demand, in addition we are considering to offer: Service Location Protocol Diameter/AAA CIFS ATM If you are interested in testing any of the above 4 protocols, please send a note to Cthon@Sun.com and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars with speakers addressing various topics. The registration deadline is February 7, 2002. An Early Bird Discount on station fees is available to those who register and pay by December 31, 2001. For registration information, please see our web site at http://www.connectathon.org. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 16th annual Connectathon event! Audrey Van Belleghem Connectathon Manager From owner-aaa-wg@merit.edu Wed Oct 31 14:55:34 2001 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 OAA29182 for ; Wed, 31 Oct 2001 14:55:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E33C4912B5; Wed, 31 Oct 2001 14:55:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4E28912B6; Wed, 31 Oct 2001 14:55:23 -0500 (EST) 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 A6D42912B5 for ; Wed, 31 Oct 2001 14:55:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 811F75DDDF; Wed, 31 Oct 2001 14:55:22 -0500 (EST) 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 05DF15DDB0 for ; Wed, 31 Oct 2001 14:55:22 -0500 (EST) 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 f9VJtLY28289; Wed, 31 Oct 2001 13:55:21 -0600 (CST) 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 f9VJtKC19121; Wed, 31 Oct 2001 13:55:20 -0600 (CST) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA05430; Wed, 31 Oct 2001 13:55:20 -0600 (CST) Received: from ericsson.com (rcur181ip232.ericsson.se [147.214.181.232]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA12886; Wed, 31 Oct 2001 13:55:15 -0600 (CST) Message-ID: <3BE056F3.374D85D2@ericsson.com> Date: Wed, 31 Oct 2001 11:54:27 -0800 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer References: <20011030035655.C24979@charizard.diameter.org> <20011030072646.B20047@newman.frascone.com> <20011030082453.E29538@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Didn't we agree that some text should be added that state that a host MAY silently discard a received CER with unknown host and disconnect, without returning a CEA to prevent a malicious hacker to discover valid Diameter server/client. But my recollection may be wrong. /Tony Pat Calhoun wrote: > > On Tue, Oct 30, 2001 at 07:26:46AM -0600, David Frascone wrote: > > Also, the other avps should be optional. A Diameter server would not want > > to inform a malicious (unknown) host of it's version, or of all the > > applications it supports. > > and why? What is the damage caused by sending this information? > > PatC > > > > On Tue, Oct 30, 2001 at 03:56:55AM -0800, Pat Calhoun wrote: > > > All, > > > > > > Here is the proposed text to handle this issue: > > > > > > 5.3 Capabilities Exchange > > > > > > [...] > > > Receipt of a CER from an unknown peer will cause the a CEA to be returned > > > with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is > > > used to inform the peer that it has not been configured to communicate with > > > the receiver, and doesn't wish to establish a Diameter session. > > > [...] > > > > > > 7.1.5 Permanent Failures > > > > > > [...] > > > DIAMETER_UNKNOWN_PEER 5019 > > > A CER was received from a peer that is unknown, and the sender of > > > the CEA doesn't wish to establish a Diameter transport. > > > > > > Comments welcomed, > > > > > > PatC From owner-aaa-wg@merit.edu Wed Oct 31 14:56:54 2001 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 OAA29227 for ; Wed, 31 Oct 2001 14:56:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B09AD912B6; Wed, 31 Oct 2001 14:56:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A1A9912B7; Wed, 31 Oct 2001 14:56:36 -0500 (EST) 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 5FECC912B6 for ; Wed, 31 Oct 2001 14:56:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 445545DDDF; Wed, 31 Oct 2001 14:56:35 -0500 (EST) 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 BDA465DDB0 for ; Wed, 31 Oct 2001 14:56:34 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f9VJuYY29113 for ; Wed, 31 Oct 2001 13:56:34 -0600 (CST) 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 f9VJuXC14221 for ; Wed, 31 Oct 2001 13:56:34 -0600 (CST) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA05558 for ; Wed, 31 Oct 2001 13:56:33 -0600 (CST) Received: from ericberk107 ([138.85.159.140]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id NAA12916 for ; Wed, 31 Oct 2001 13:56:29 -0600 (CST) Message-ID: <00af01c16246$23be2060$8c9f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: References: <20011031122339.F12689@newman.frascone.com> Subject: [AAA-WG]: Question regarding FA-HA session key Date: Wed, 31 Oct 2001 11:56:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I have looked at the aaa-key-08 and mobileip-08-alpha drafts, and I can't seem to find a particular detail regarding the MIP session key used between the FA and HA. It is apparently an OctetString (as the MIP-Session-Key AVP is defined), but the length of this string isn't defined- have I missed it somewhere else? If not, wouldn't it be a good idea state somewhere the length (in bytes) of the key, or at least define a required minimum key length (just as aaa-key-08 defines a minimum length of 64 bits for MN-* key material)? -Kev From owner-aaa-wg@merit.edu Wed Oct 31 15:02:18 2001 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 PAA29399 for ; Wed, 31 Oct 2001 15:02:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FA09912B7; Wed, 31 Oct 2001 15:01:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF52E912B8; Wed, 31 Oct 2001 15:01:57 -0500 (EST) 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 D1107912B7 for ; Wed, 31 Oct 2001 15:01:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id B79BC5DDDF; Wed, 31 Oct 2001 15:01:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 56A205DDB0 for ; Wed, 31 Oct 2001 15:01:56 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f9VK1q023614; Wed, 31 Oct 2001 14:01:52 -0600 (CST) 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 f9VK1pu11721; Wed, 31 Oct 2001 14:01:51 -0600 (CST) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA06006; Wed, 31 Oct 2001 14:01:51 -0600 (CST) Received: from ericsson.com (rcur181ip232.ericsson.se [147.214.181.232]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA13015; Wed, 31 Oct 2001 14:01:46 -0600 (CST) Message-ID: <3BE0587A.3C9CE30D@ericsson.com> Date: Wed, 31 Oct 2001 12:00:58 -0800 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 216: Home Agent MUST support home address allocation References: <20011025173257.P5663@charizard.diameter.org> <20011030043532.L24979@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Looks good to me. /Tony Pat Calhoun wrote: > > All, > > I modified some text to make this clearer. Specifically, the last two > sentences in the paragraph below have been changed. > > 1.2 Inter-Realm Mobile IP > > [...] > The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains the > Mobile IP Registration Request message data encapsulated in the > MIP-Reg-Request AVP, to the assigned or requested Home Agent. The AAAH > MAY allocate a home address for the mobile node, while the Home Agent MUST > support home address allocation. In the event the AAAH handles address > allocation, it includes it in a MIP-Mobile-Node-Address AVP within the HAR. > The absence of this AVP informs the Home Agent to perform the allocation. > > Comments welcomed, > > PatC > On Thu, Oct 25, 2001 at 05:32:57PM -0700, Pat Calhoun wrote: > > Submitter name: Pat Calhoun > > Submitter email address: pcalhoun@diameter.org > > Date first submitted: 25-Oct-01 > > Reference: > > Document: MIP > > Comment type: Technical > > Priority: 1 > > Section: 1.2 > > Rationale/Explanation of issue: > > > > The draft doesn't actually state that the Home Agent MUST support > > home address allocation, but the draft does state that the AAAH MAY > > do it. The lack of a MUST can cause interoperability problems > > From owner-aaa-wg@merit.edu Wed Oct 31 15:08:54 2001 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 PAA29513 for ; Wed, 31 Oct 2001 15:08:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 111EB91226; Wed, 31 Oct 2001 15:08:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D540E912B8; Wed, 31 Oct 2001 15:08:42 -0500 (EST) 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 AA67091226 for ; Wed, 31 Oct 2001 15:08:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 918C15DDE4; Wed, 31 Oct 2001 15:08:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7E2E65DDDF for ; Wed, 31 Oct 2001 15:08:41 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 20DAE7A; Wed, 31 Oct 2001 15:08:41 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Issue 204: How to handle CER from unkwown peer Date: Wed, 31 Oct 2001 15:06:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3BE056F3.374D85D2@ericsson.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Here's what Don and I recall: At the little round table discussion we had a couple days before Pat came, we talked about two things when receiving a CER from an unknown peer: 1. silently dropping the connection, no response; or 2. respond with a negative stripped-down CEA, which doesn't reveal the server's identity or supported applications, etc. I think when Pat showed up, we talked about the silent discard and the negative CEA, but don't think we talked about the negative CEA being stripped down. Bob K. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Tony Johansson > Sent: Wednesday, October 31, 2001 2:54 PM > To: Pat Calhoun > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer > > > Didn't we agree that some text should be added that state that a host > MAY silently discard a received CER with unknown host and disconnect, > without returning a CEA to prevent a malicious hacker to discover valid > Diameter server/client. > > But my recollection may be wrong. > > /Tony > > Pat Calhoun wrote: > > > > On Tue, Oct 30, 2001 at 07:26:46AM -0600, David Frascone wrote: > > > Also, the other avps should be optional. A Diameter server would not want > > > to inform a malicious (unknown) host of it's version, or of all the > > > applications it supports. > > > > and why? What is the damage caused by sending this information? > > > > PatC > > > > > > On Tue, Oct 30, 2001 at 03:56:55AM -0800, Pat Calhoun wrote: > > > > All, > > > > > > > > Here is the proposed text to handle this issue: > > > > > > > > 5.3 Capabilities Exchange > > > > > > > > [...] > > > > Receipt of a CER from an unknown peer will cause the a CEA to > be returned > > > > with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is > > > > used to inform the peer that it has not been configured to > communicate with > > > > the receiver, and doesn't wish to establish a Diameter session. > > > > [...] > > > > > > > > 7.1.5 Permanent Failures > > > > > > > > [...] > > > > DIAMETER_UNKNOWN_PEER 5019 > > > > A CER was received from a peer that is unknown, and > the sender of > > > > the CEA doesn't wish to establish a Diameter transport. > > > > > > > > Comments welcomed, > > > > > > > > PatC > From owner-aaa-wg@merit.edu Wed Oct 31 15:29:09 2001 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 PAA00151 for ; Wed, 31 Oct 2001 15:29:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F039E912BA; Wed, 31 Oct 2001 15:28:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9C8B912BB; Wed, 31 Oct 2001 15:28:48 -0500 (EST) 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 B7E86912BA for ; Wed, 31 Oct 2001 15:28:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 977F05DDF3; Wed, 31 Oct 2001 15:28:47 -0500 (EST) 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 223715DDDF for ; Wed, 31 Oct 2001 15:28:47 -0500 (EST) Received: (qmail 15942 invoked by uid 500); 31 Oct 2001 20:28:46 -0000 Date: Wed, 31 Oct 2001 14:28:45 -0600 From: David Frascone To: Tony Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer Message-ID: <20011031142845.A14976@newman.frascone.com> Mail-Followup-To: Tony Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20011030035655.C24979@charizard.diameter.org> <20011030072646.B20047@newman.frascone.com> <20011030082453.E29538@charizard.diameter.org> <3BE056F3.374D85D2@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE056F3.374D85D2@ericsson.com>; from tony.johansson@ericsson.com on Wed, Oct 31, 2001 at 11:54:27AM -0800 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I thought we did, but I can live with not returning any extra information. On Wed, Oct 31, 2001 at 11:54:27AM -0800, Tony Johansson wrote: > Didn't we agree that some text should be added that state that a host > MAY silently discard a received CER with unknown host and disconnect, > without returning a CEA to prevent a malicious hacker to discover valid > Diameter server/client. > > But my recollection may be wrong. > > /Tony > > Pat Calhoun wrote: > > > > On Tue, Oct 30, 2001 at 07:26:46AM -0600, David Frascone wrote: > > > Also, the other avps should be optional. A Diameter server would not want > > > to inform a malicious (unknown) host of it's version, or of all the > > > applications it supports. > > > > and why? What is the damage caused by sending this information? > > > > PatC > > > > > > On Tue, Oct 30, 2001 at 03:56:55AM -0800, Pat Calhoun wrote: > > > > All, > > > > > > > > Here is the proposed text to handle this issue: > > > > > > > > 5.3 Capabilities Exchange > > > > > > > > [...] > > > > Receipt of a CER from an unknown peer will cause the a CEA to be returned > > > > with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is > > > > used to inform the peer that it has not been configured to communicate with > > > > the receiver, and doesn't wish to establish a Diameter session. > > > > [...] > > > > > > > > 7.1.5 Permanent Failures > > > > > > > > [...] > > > > DIAMETER_UNKNOWN_PEER 5019 > > > > A CER was received from a peer that is unknown, and the sender of > > > > the CEA doesn't wish to establish a Diameter transport. > > > > > > > > Comments welcomed, > > > > > > > > PatC