From owner-aaa-wg@merit.edu Sat Sep 1 00:04: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 AAA24604 for ; Sat, 1 Sep 2001 00:04:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EECE91276; Sat, 1 Sep 2001 00:05:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CAA59127B; Sat, 1 Sep 2001 00: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 0CB4891276 for ; Sat, 1 Sep 2001 00:05:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6AD35DDAE; Sat, 1 Sep 2001 00:05:36 -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 697285DD94 for ; Sat, 1 Sep 2001 00:05:36 -0400 (EDT) Received: from gwzpc (sjc-vpn1-52.cisco.com [10.21.96.52]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA09561; Fri, 31 Aug 2001 21:04:32 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Bernard Aboba" Cc: Subject: RE: [AAA-WG]: Bernard's implied issues Date: Fri, 31 Aug 2001 21:03:45 -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 V5.00.2615.200 Importance: Normal In-Reply-To: <20010831201745.A24625@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@diameter.org] writes: > So folks feel comfortable with straight auth and encr transforms being > encoded, with no actual implied usage? > > Should 3DES-CBC be used with IPSec, WEP, ??? > > Maybe RC4-128 could be used with TLS?? I think a better question is, "What is the difference between the keys used with the same algorithm in different protocols?" Is there some fundamental difference between 3DES keys for PPP and 3DES keys for IPSEC? Or 128-bit RC4 keys for MPPE or TLS? I don't think so. > > I'm not sure I'm too crazy on this. I MUCH prefer keeping > the draft as-is. BTW, I'm not too thrilled w/making the key lifetime dependant on the authorization lifetime: I can think of many situations in which a user might be authorized for unlimited service, but encryption keys need to be chamged at a regular interval. Also, the current language seems to assume that the NAS will go back to the AAA server whenever new keys are needed, which is certainly not the case. > > PatC > On Fri, Aug 31, 2001 at 04:48:49PM -0700, Bernard Aboba wrote: > > >I dispute that WEP constitues a ciphersuite. Perhaps RC4-128? > > > > This does make more sense. So instead of MPPE and WEP, we'd have: > > > > RC4-40 [MPPE, WEP] > > RC4-128 [MPPE, WEP-128] > > 3DES-CBC [PPP 3DES] > > DES-CBC [PPP DES] > > > > I'd suggest that the ciphersuite code be structured as two > > two-octet fields, one for auth, one for encryption: > > > > Auth Encryption > > ==== ========== > > None None > > HMAC-MD5 RC4-40 > > HMAC-SHA1 RC4-128 > > AES-CBC-MAC DES-CBC > > 3DES-CBC > > AES-CBC > > AES-CTR > > > > > > So PPP DES would be DES-CBC with NONE, MPPE would be RC4-40 with NONE, > > etc. > > > From owner-aaa-wg@merit.edu Sat Sep 1 00:41: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 AAA24920 for ; Sat, 1 Sep 2001 00:41:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D54999127B; Sat, 1 Sep 2001 00:42:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A71E99127C; Sat, 1 Sep 2001 00: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 92D569127B for ; Sat, 1 Sep 2001 00:42:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 689715DDC9; Sat, 1 Sep 2001 00:42:53 -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 8E6FC5DD94 for ; Sat, 1 Sep 2001 00:42:52 -0400 (EDT) Received: from jariws1 ([212.54.16.198]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010901044250.XSOQ15145.fep07-app.kolumbus.fi@jariws1>; Sat, 1 Sep 2001 07:42:50 +0300 Message-ID: <012a01c132a0$91fe41c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Pat Calhoun" , "Bernard Aboba" Cc: References: Subject: Re: [AAA-WG]: Bernard's implied issues Date: Sat, 1 Sep 2001 07:42:56 +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 > > So folks feel comfortable with straight auth and encr transforms being > > encoded, with no actual implied usage? > > > > Should 3DES-CBC be used with IPSec, WEP, ??? > > > > Maybe RC4-128 could be used with TLS?? I seem to like the pure algorithm approach more, because it would be better usable in new contexts. However, the issue with straight algorithms is that a NAS might not know what it needs to do, say if it has ESP DES and PPP-DES, which one will it choose? Also, protocols like ESP have more options than just the algorithms. One way to deal with this is to just bundle everything with the usage, e.g. PPP-CBC-DES-NO-AUTH. Another way to deal with this is to have a set of AVPs now that enables us to express our known combinations now (Usage, Encryption Alg, Integrity Alg), with the expectation that if somebody wants to define how this works for IPsec, he needs to add new AVPs -- later. I would perhaps like the latter approach more. Jari From owner-aaa-wg@merit.edu Sat Sep 1 13:03: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 NAA16144 for ; Sat, 1 Sep 2001 13:03:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26A1891259; Sat, 1 Sep 2001 13:04:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D203F9125C; Sat, 1 Sep 2001 13:04: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 C1C8391259 for ; Sat, 1 Sep 2001 13:04:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 936785DDBF; Sat, 1 Sep 2001 13:04:28 -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 E25DF5DD90 for ; Sat, 1 Sep 2001 13:04:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA40683; Sat, 1 Sep 2001 09:56:10 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 1 Sep 2001 09:56:10 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Bernard's implied issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yes; I suppose that algorithms that do both auth& encryption (e.g. AES-OCB) > could just use the same value in both fields, right? BTW, while we're here > I wonder if it would be a good idea to add an (optional) IV to the group, > for block ciphers (and the misbegotten WEP ;-)? > So the AAA server would provide the starting IV? From owner-aaa-wg@merit.edu Sat Sep 1 13:07: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 NAA16169 for ; Sat, 1 Sep 2001 13:07:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 214B99125C; Sat, 1 Sep 2001 13:08:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E121E91261; Sat, 1 Sep 2001 13:08: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 DB1709125C for ; Sat, 1 Sep 2001 13:08:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B93265DDBF; Sat, 1 Sep 2001 13:08:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 04FB05DD90 for ; Sat, 1 Sep 2001 13:08:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA40705; Sat, 1 Sep 2001 10:00:07 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 1 Sep 2001 10:00:07 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Bernard's implied issues 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 think a better question is, "What is the difference between the keys used > with the same algorithm in different protocols?" Is there some fundamental > difference between 3DES keys for PPP and 3DES keys for IPSEC? Or 128-bit > RC4 keys for MPPE or TLS? I don't think so. > Yes, the existing draft language will cause an explosion of ciphersuites, for no useful purpose. > > > > I'm not sure I'm too crazy on this. I MUCH prefer keeping > > the draft as-is. > > BTW, I'm not too thrilled w/making the key lifetime dependant on the > authorization lifetime: I can think of many situations in which a user > might be authorized for unlimited service, but encryption keys need to be > chamged at a regular interval. Also, the current language seems to assume > that the NAS will go back to the AAA server whenever new keys are needed, > which is certainly not the case. > Yes, this is broken. From owner-aaa-wg@merit.edu Sat Sep 1 13:13: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 NAA16242 for ; Sat, 1 Sep 2001 13:13:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51C6B91261; Sat, 1 Sep 2001 13:14:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D7AB91264; Sat, 1 Sep 2001 13:14: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 F122991261 for ; Sat, 1 Sep 2001 13:14:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1EB95DDBF; Sat, 1 Sep 2001 13:14:32 -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 083DA5DD90 for ; Sat, 1 Sep 2001 13:14:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA40716; Sat, 1 Sep 2001 10:06:12 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 1 Sep 2001 10:06:12 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: gwz@cisco.com, Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues In-Reply-To: <012a01c132a0$91fe41c0$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I seem to like the pure algorithm approach more, because > it would be better usable in new contexts. However, the > issue with straight algorithms is that a NAS might not > know what it needs to do, say if it has ESP DES and PPP-DES, > which one will it choose? Also, protocols like ESP have more > options than just the algorithms. > That is handled by other AVPs. ESP DES can only be provided if there are Tunnel AVPs present. PPP encryption algorithms are negotiated later, in ECP. So you would need to provide the NAS with a list of acceptable algorithms to be negotiated within ECP. Right now the Grouped AVP isn't structured correctly for this. You'd have to provide a separate key for each algorithm you could negotiate. It makes more sense to provide the key, and list of potential algorithms separately. > One way to deal with this is to just bundle everything > with the usage, e.g. PPP-CBC-DES-NO-AUTH. > Another way to deal with this is to have a set of > AVPs now that enables us to express our known > combinations now (Usage, Encryption Alg, Integrity > Alg), with the expectation that if somebody wants to > define how this works for IPsec, he needs to add new > AVPs -- later. > From owner-aaa-wg@merit.edu Sat Sep 1 13:23: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 NAA16342 for ; Sat, 1 Sep 2001 13:23:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C687691264; Sat, 1 Sep 2001 13:23:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 944C9912CD; Sat, 1 Sep 2001 13:23: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 861A091264 for ; Sat, 1 Sep 2001 13:23:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 551445DDBF; Sat, 1 Sep 2001 13:23:57 -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 C66CD5DD90 for ; Sat, 1 Sep 2001 13:23:56 -0400 (EDT) Received: from gwzpc (sjc-vpn2-86.cisco.com [10.21.112.86]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA02533; Sat, 1 Sep 2001 10:22:53 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: "Pat Calhoun" , Subject: RE: [AAA-WG]: Bernard's implied issues Date: Sat, 1 Sep 2001 10:22:51 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > Yes; I suppose that algorithms that do both auth& encryption > (e.g. AES-OCB) > > could just use the same value in both fields, right? BTW, > while we're here > > I wonder if it would be a good idea to add an (optional) IV to > the group, > > for block ciphers (and the misbegotten WEP ;-)? > > > So the AAA server would provide the starting IV? Possibly, yes. This would seem to make sense at least in the EAP-TLS case, since the IVs are derived on the EAP server and presumably returned to the NAS (although I just noticed that RFC 2716 says "The peer encryption key (the one used for encrypting data from peer to EAP server)" when I ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't see any reason why the peer would need to encrypt EAP server-bound data in the protocol). > > From owner-aaa-wg@merit.edu Sat Sep 1 14:00: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 OAA16639 for ; Sat, 1 Sep 2001 14:00:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B3AB9912CD; Sat, 1 Sep 2001 14:00:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D6E2912F8; Sat, 1 Sep 2001 14:00: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 DFAF8912CD for ; Sat, 1 Sep 2001 14:00:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B88F5DDCA; Sat, 1 Sep 2001 14:00:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DFB0C5DD90 for ; Sat, 1 Sep 2001 14:00:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA40768; Sat, 1 Sep 2001 10:51:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sat, 1 Sep 2001 10:51:56 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Bernard's implied issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > So the AAA server would provide the starting IV? > > Possibly, yes. This would seem to make sense at least in the EAP-TLS case, > since the IVs are derived on the EAP server and presumably returned to the > NAS (although I just noticed that RFC 2716 says "The peer encryption key > (the one used for encrypting data from peer to EAP server)" when I > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > can't see any reason why the peer would need to encrypt EAP server-bound > data in the protocol). > Couldn't the IV be returned as part of the key? For example, in WEP-128, there is a 24-bit IV and 104-bit key. The RFC 2716 quote above is a typo. Encryption only occurs between the peer and the NAS. From owner-aaa-wg@merit.edu Sat Sep 1 14:20: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 OAA16822 for ; Sat, 1 Sep 2001 14:20:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50C12912F9; Sat, 1 Sep 2001 14:21:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1841E912FA; Sat, 1 Sep 2001 14:21: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 0224D912F9 for ; Sat, 1 Sep 2001 14:21:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D451E5DDD3; Sat, 1 Sep 2001 14:21:18 -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 572995DDCE for ; Sat, 1 Sep 2001 14:21:18 -0400 (EDT) Received: from gwzpc (sjc-vpn2-86.cisco.com [10.21.112.86]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA19289; Sat, 1 Sep 2001 11:20:36 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: "Pat Calhoun" , Subject: RE: [AAA-WG]: Bernard's implied issues Date: Sat, 1 Sep 2001 11:19:55 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > > So the AAA server would provide the starting IV? > > > > Possibly, yes. This would seem to make sense at least in the > EAP-TLS case, > > since the IVs are derived on the EAP server and presumably > returned to the > > NAS (although I just noticed that RFC 2716 says "The peer encryption key > > (the one used for encrypting data from peer to EAP server)" when I > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > can't see any reason why the peer would need to encrypt EAP server-bound > > data in the protocol). > > > > Couldn't the IV be returned as part of the key? For example, in WEP-128, > there is a 24-bit IV and 104-bit key. I suppose so, though they really are logically separate entities... > > The RFC 2716 quote above is a typo. Encryption only occurs between the > peer and the NAS. > > From owner-aaa-wg@merit.edu Sat Sep 1 15:38: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 PAA17290 for ; Sat, 1 Sep 2001 15:38:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0CB1E9130B; Sat, 1 Sep 2001 15:39:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D028A9131C; Sat, 1 Sep 2001 15:39: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 B84759130B for ; Sat, 1 Sep 2001 15:39:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 980705DD9F; Sat, 1 Sep 2001 15:39:13 -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 10EA05DD90 for ; Sat, 1 Sep 2001 15:39:13 -0400 (EDT) Received: (qmail 28221 invoked by uid 500); 1 Sep 2001 19:26:34 -0000 Date: Sat, 1 Sep 2001 12:26:34 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Jari Arkko , gwz@cisco.com, Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues Message-ID: <20010901122634.A28210@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Jari Arkko , gwz@cisco.com, Pat Calhoun , aaa-wg@merit.edu References: <012a01c132a0$91fe41c0$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Sat, Sep 01, 2001 at 10:06:12AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > That is handled by other AVPs. ESP DES can only be provided > if there are Tunnel AVPs present. PPP encryption algorithms are negotiated > later, in ECP. So you would need to provide the NAS with a list of > acceptable algorithms to be negotiated within ECP. Right now the Grouped > AVP isn't structured correctly for this. You'd have to provide a separate > key for each algorithm you could negotiate. It makes more sense to provide > the key, and list of potential algorithms separately. Then open issue, and propose text, please. PatC From owner-aaa-wg@merit.edu Mon Sep 3 03:47: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 DAA05482 for ; Mon, 3 Sep 2001 03:47:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C568E91230; Mon, 3 Sep 2001 03:48:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D4179121D; Mon, 3 Sep 2001 03:48: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 829C291230 for ; Mon, 3 Sep 2001 03:47:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 579CC5DDD0; Mon, 3 Sep 2001 03:47:49 -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 4816A5DDA3 for ; Mon, 3 Sep 2001 03:47:48 -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.10.1/WIREfire-1.3) with ESMTP id f837ljv15557 for ; Mon, 3 Sep 2001 09:47:47 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA10923; Mon, 3 Sep 2001 09:47:42 +0200 (MET DST) Message-ID: <3B9335F1.C642675E@rioja.ericsson.se> Date: Mon, 03 Sep 2001 09:49:05 +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]: Update: The Remaining Issues References: <20010830205637.G15109@charizard.diameter.org> <20010831100756.C22080@charizard.diameter.org> <008201c1324a$a365a1c0$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 Jari Arkko wrote: > > > Issue 150: Steven and I both agree that adding an S/MIME & CMS introduction > > is really unnecessary, and we propose rejecting this issue. I > > am waiting for WG input before proceeding. > > Well, after reading the issue and the exchanged e-mails, I too started > to wonder why section 6.2 uses CMS directly, and 6.1 via S/MIME. > Is this really so, or does this part need clarification? Or should I > read the document again, carefully? ;-) Maybe we both might do it ;-)) Maybe I should read again CMS specification... > I agree though that we don't need an introduction to S/MIME and > CMS in this document. But some statement at the beginning on > why CMS was selected might be in order. Say, at the end of 1.0, > add "The Diameter CMS application provides end-to-end > security within a Diameter network involving proxies. It > leverages Cryptographic Message Syntax (CMS), > an application layer encapsulation format. CMS is > widely used, and also forms the basis for the secure MIME > format (S/MIME)." It looks coherent. I would move either the mention to S/MIME toolkit from its present placement to the suggested by Jari. Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 3 05:03: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 FAA06073 for ; Mon, 3 Sep 2001 05:03:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A544C91224; Mon, 3 Sep 2001 05:04:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F69D91233; Mon, 3 Sep 2001 05:04: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 60B6C91224 for ; Mon, 3 Sep 2001 05:04:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20E7D5DDFF; Mon, 3 Sep 2001 05:04:25 -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 D09265DD96 for ; Mon, 3 Sep 2001 05:04:19 -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.10.1/WIREfire-1.3) with ESMTP id f8394Hv26265 for ; Mon, 3 Sep 2001 11:04:18 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA17664; Mon, 3 Sep 2001 11:04:14 +0200 (MET DST) Message-ID: <3B9347E1.64D3F6C9@rioja.ericsson.se> Date: Mon, 03 Sep 2001 11:05:37 +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: [AAA-WG]: [issue] DSA error codes Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-03 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html Document: Base-07, CMS-02 Comment type: T Priority: 1 Section: Rationale/Explanation of issue: Apart from the error codes related to OCSP there are only two other errors: DIAMETER_KEY_UNKNOWN and DIAMETER_INVALID_CMS_DATA. The former is related to the locally stored encryption key (symmetric) while the later talks about CMS-*-Data AVPs. The Base Protocol draft (7.1.3) states: DIAMETER_INVALID_CMS_DATA 3006 The Request did not contain a valid CMS-Data [11] AVP. While in the CMS Security draft (7.2) it is said that: DIAMETER_INVALID_CMS_DATA 5019 This error code is returned when a CMS-Data AVP is received with an invalid ContentInfo object. As stated in the reference mail, my first concern is about the definition (which is slightly different) and the type of error (in the base draft it's a protocol error while in the CMS draft it's a permanent failure). My second concern is about the error situations related to CMS. I can foresee the following: - In a DSA setup dialogue, the initiator can provide a set of "direct trust" CA which isn't supported by the receiver. I understand that a permanent failure code error must be issued. - In a DSA setup dialogue, the initiator, once received the DSAA, might fail to verify the conditions listed in section 3.1 of the CMS draft. Like no ACK is foreseen in the specification, I understant that when in a subsequent Diameter message, the initiator receives an AVP related to CMS, this node should issue a permanent error. For example, DIAMETER_NO_DSA_ESTABLISHED - If a Diameter node receives a message with encrypted or signed AVPs once the DSA has expired (or even with no previous DSA established), the node should issue another error. Maybe, DIAMETER_DSA_EXPIRED (or maybe making use of the former code suggested). Requested change: I suggest unifying the definition of DIAMETER_INVALID_CMS_DATA in both drafts (or maybe dropping the mention of the error in base draft). For the rest of concerns, I'd add some clarifying text in order to state wheter those are really error situations or not. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Mon Sep 3 09:24: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 JAA09353 for ; Mon, 3 Sep 2001 09:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0CC0691205; Mon, 3 Sep 2001 09:25:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAC459122F; Mon, 3 Sep 2001 09:25: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 B44A191205 for ; Mon, 3 Sep 2001 09:25:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BC555DDA0; Mon, 3 Sep 2001 09:25:23 -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 90E515DD96 for ; Mon, 3 Sep 2001 09:25:22 -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.10.1/WIREfire-1.3) with ESMTP id f83DPKv18364 for ; Mon, 3 Sep 2001 15:25:21 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA09900; Mon, 3 Sep 2001 15:25:17 +0200 (MET DST) Message-ID: <3B938512.BC2DD123@rioja.ericsson.se> Date: Mon, 03 Sep 2001 15:26:42 +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: [AAA-WG]: [issue] DSA error codes (cont) References: <3B9347E1.64D3F6C9@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 Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-03 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02002.html, http://www.merit.edu/mail.archives/aaa-wg/msg02022.html Document: Base-07, CMS-02 Comment type: T Priority: 1 Section: Base (7.1.3), CMS (6.2) Rationale/Explanation of issue: Apart from what I wrote in http://www.merit.edu/mail.archives/aaa-wg/msg02022.html, I'd like to add the following: The Base Protocol draft (7.1.3) states: DIAMETER_CMS_SECURITY 3008 A proxy has detected that CMS security has been applied to portions of the Diameter message, and the proxy does not allow this security mode since it needs to alter the message by applying some local policies. I suppose that this error code has been superseded by the error codes defined in CMS-02 1.2 (Establishing Security Relationships through proxy agents). Also, the CMS-02 draft (section 6.1) says that: If the signature cannot be verified correctly, a response with the Result-Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned. I haven't found such a error code in Base-07 Requested change: a) Drop error 3008 from base draft. b) Correct which error code is issued when the signature isn't properly verified. 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 Mon Sep 3 13:54: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 NAA12625 for ; Mon, 3 Sep 2001 13:54:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB6869120A; Mon, 3 Sep 2001 13:55:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 795649120C; Mon, 3 Sep 2001 13:55: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 2C10E9120A for ; Mon, 3 Sep 2001 13:55:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10A155DDAA; Mon, 3 Sep 2001 13:55: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 C24715DD9E for ; Mon, 3 Sep 2001 13:55:30 -0400 (EDT) Received: (qmail 19766 invoked by uid 500); 3 Sep 2001 17:42:46 -0000 Date: Mon, 3 Sep 2001 10:42:46 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] DSA error codes Message-ID: <20010903104246.B19656@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B9347E1.64D3F6C9@rioja.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: <3B9347E1.64D3F6C9@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 03, 2001 at 11:05:37AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Requested change: > > I suggest unifying the definition of DIAMETER_INVALID_CMS_DATA in both > drafts (or maybe dropping the mention of the error in base draft). Done, the one in the base protocol draft has been removed. > For the rest of concerns, I'd add some clarifying text in order to > state wheter those are really error situations or not. > The following result codes have been added: DIAMETER_NO_COMMON_TRUST 5020 This error code is returned when a receiver receives a PDSR for which it has no common trust with the sender, which is required to establish the DSA. DIAMETER_NO_DSA_ESTABLISHED 5021 A Diameter message refers to a Diameter Security Association which does not exist. DIAMETER_DSA_EXPIRED 5022 A Diameter message refers to a Diameter Security Association which has expired. Thanks, PatC From owner-aaa-wg@merit.edu Mon Sep 3 14:00: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 OAA12690 for ; Mon, 3 Sep 2001 14:00:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7153D9120C; Mon, 3 Sep 2001 14:00:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 351C091220; Mon, 3 Sep 2001 14:00: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 1EA3A9120C for ; Mon, 3 Sep 2001 14:00:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E98635DD9E; Mon, 3 Sep 2001 14:00: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 D63CC5DD96 for ; Mon, 3 Sep 2001 14:00:15 -0400 (EDT) Received: (qmail 19793 invoked by uid 500); 3 Sep 2001 17:47:29 -0000 Date: Mon, 3 Sep 2001 10:47:29 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] DSA error codes (cont) Message-ID: <20010903104729.C19656@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B9347E1.64D3F6C9@rioja.ericsson.se> <3B938512.BC2DD123@rioja.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: <3B938512.BC2DD123@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 03, 2001 at 03:26:42PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Requested change: > > a) Drop error 3008 from base draft. done > b) Correct which error code is issued when the signature isn't > properly verified. DIAMETER_INVALID_AUTH 4012 The signature in the CMS-Signed-Data AVP is invalid. Thanks, PatC From owner-aaa-wg@merit.edu Mon Sep 3 14:23: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 OAA12985 for ; Mon, 3 Sep 2001 14:23:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2743F91208; Mon, 3 Sep 2001 14:24:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF6D591221; Mon, 3 Sep 2001 14:24: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 D6ECD91208 for ; Mon, 3 Sep 2001 14:24:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB3F85DD9E; Mon, 3 Sep 2001 14:24: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 62A175DD96 for ; Mon, 3 Sep 2001 14:24:06 -0400 (EDT) Received: (qmail 19854 invoked by uid 500); 3 Sep 2001 18:11:22 -0000 Date: Mon, 3 Sep 2001 11:11:22 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions Message-ID: <20010903111122.D19656@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.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: <3B8F3DC2.B94F6A49@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Fri, Aug 31, 2001 at 09:33:22AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > of course that adding an S/MIME and CMS introduction would be > unnecessary. Some precisions either: > > - While there's a specific mention of MIME encoding of AVPs in 6.1 > (CMS-Signed-Data AVP): > > This means that where a set of AVPs is protected using CMS, the set > MUST first be encoded according to MIME encoding rules specified > below. correct. > > and in the same paragraph (though talking about encryption + signing): > > The resulting CMS object MUST then be MIME encoded producing an > application/pkcs7-mime MIME type which is then used as the content > of the EnvelopedData. right. > > there's no explicit mention of MIME enconding in 6.2 > (CMS-Encrypted-Data AVP). My oppinion is that such explicit mention to > MIME should be included in 6.2 (at least if MIME enconding is > necessary). ok, here's the scoop (as I understand it). 6.1 specifies how the CMS-Signed-Data AVP is created. This is done by taking a bunch of AVPs, putting them through the signing transform, and taking the result, which is included in the AVP itself. However, the AVPs themselves are never encoded in any MIME format when included in the message. 6.2, on the other hand, is completely different. The encrypted data is included in the CMS-Encrypted-Data AVP. So, in 6.1 the process is different from 6.2. I believe that Stephen will need to help us out here with any additional clarifications. > > BTW, where are the MIME encoding rules specified "below"? ok, that was wrong, and I've included the references to MIME, which discusses the encoding mechanisms. As far as the intro paragraph, I've come up with the following at the end of section 1.0: This Diameter application makes use of Cryptographic Message Syntax (CMS), which a method used to secure MIME (S/MIME) messages. This application was designed to allow for Diameter implementations to use existing S/MIME toolkits in order to comply with this specification. so, we're nearly there. PatC From owner-aaa-wg@merit.edu Mon Sep 3 14:26: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 OAA13031 for ; Mon, 3 Sep 2001 14:26:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13A7291221; Mon, 3 Sep 2001 14:27:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7B7B91224; Mon, 3 Sep 2001 14:27: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 BF40791221 for ; Mon, 3 Sep 2001 14:27:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 92B3A5DD9E; Mon, 3 Sep 2001 14:27: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 532205DD96 for ; Mon, 3 Sep 2001 14:27:37 -0400 (EDT) Received: (qmail 19876 invoked by uid 500); 3 Sep 2001 18:14:53 -0000 Date: Mon, 3 Sep 2001 11:14:53 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Update on remaining issues Message-ID: <20010903111453.F19656@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 Here's an update: Issue 123: Still waiting for WG comments Issue 150: Waiting for Stephen Farrell's input on helping make text consistent in 6.1 anf 6.2 Issue ???: Bernard and Glen have implied that the NASREQ spec's references to keys is incorrect. I am waiting for them to file an issue and propose some text. PatC From owner-aaa-wg@merit.edu Mon Sep 3 21: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 VAA16976 for ; Mon, 3 Sep 2001 21:36:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44A1F91224; Mon, 3 Sep 2001 21:37:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18B7591228; Mon, 3 Sep 2001 21:37: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 24B2691224 for ; Mon, 3 Sep 2001 21:37:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 003E55DDB4; Mon, 3 Sep 2001 21:37:34 -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 D6AC55DDAF for ; Mon, 3 Sep 2001 21:37:33 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15e59h-000LSu-00 for aaa-wg@merit.edu; Mon, 03 Sep 2001 18:37:33 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-ietf-aaa-diameter-07.txt Message-Id: Date: Mon, 03 Sep 2001 18:37:33 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit i have heard whineing that the motivation in the introduction of is insufficient. it "does not actually present a full picture." it seems to kinda tell a history, which, while nice, does not crisply lay out the application domain and goals. could a ticket be opened on this, please? thanks. randy From owner-aaa-wg@merit.edu Mon Sep 3 21:38: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 VAA17002 for ; Mon, 3 Sep 2001 21:38:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAD0F91228; Mon, 3 Sep 2001 21:40:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAB599122D; Mon, 3 Sep 2001 21:40: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 9858591228 for ; Mon, 3 Sep 2001 21:40:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 664135DDAF; Mon, 3 Sep 2001 21:40: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 C13555DDDC for ; Mon, 3 Sep 2001 21:40:05 -0400 (EDT) Received: (qmail 21311 invoked by uid 500); 4 Sep 2001 01:27:20 -0000 Date: Mon, 3 Sep 2001 18:27:20 -0700 From: Pat Calhoun To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07.txt Message-ID: <20010903182720.C20463@charizard.diameter.org> Mail-Followup-To: Randy Bush , 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 randy@psg.com on Mon, Sep 03, 2001 at 06:37:33PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Just out of curiosity, doesn't section 1.1, which defines what the protocol does, address your issue? If so, is it just a question of re-organizing the text? PatC On Mon, Sep 03, 2001 at 06:37:33PM -0700, Randy Bush wrote: > i have heard whineing that the motivation in the introduction of > is insufficient. it "does not actually > present a full picture." > > it seems to kinda tell a history, which, while nice, does not crisply lay > out the application domain and goals. > > could a ticket be opened on this, please? thanks. > > randy From owner-aaa-wg@merit.edu Tue Sep 4 05:08: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 FAA06290 for ; Tue, 4 Sep 2001 05:08:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 775689120A; Tue, 4 Sep 2001 05:09:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 476A59120C; Tue, 4 Sep 2001 05:09: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 1A7409120A for ; Tue, 4 Sep 2001 05:09:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D86685DDB4; Tue, 4 Sep 2001 05:09:24 -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 BB1A25DD8C for ; Tue, 4 Sep 2001 05:09:23 -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.10.1/WIREfire-1.3) with ESMTP id f8499Iv12224 for ; Tue, 4 Sep 2001 11:09:18 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA14811; Tue, 4 Sep 2001 11:09:15 +0200 (MET DST) Message-ID: <3B949A95.F8AFBF53@rioja.ericsson.se> Date: Tue, 04 Sep 2001 11:10:45 +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] DSA error codes References: <3B9347E1.64D3F6C9@rioja.ericsson.se> <20010903104246.B19656@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 Calhoun wrote: > > The following result codes have been added: > > DIAMETER_NO_DSA_ESTABLISHED 5021 > A Diameter message refers to a Diameter Security Association which > does not exist. > > DIAMETER_DSA_EXPIRED 5022 > A Diameter message refers to a Diameter Security Association which > has expired. May I suppose that appropriate references to this result codes have been added to the draft (let's say to chapter 3.1)? For example, before the sentence "The destination node returns the ...", I would add a paragraph similar to the following: Once received a DSA-Request, the destination node MUST verify that: - The digital signature included in the CMS-Signed-Data AVP can be verified (i.e. proper digital certificates are available to verify the digital signature). - One of the Local-CA-info AVP values from the DSA-Request message can act as the top CA of a certificate chain down to the CA which has issued all the end entity certificates of the AAA servers in the Home Domain. Otherwise a DSA-Answer with a Result-Code DIAMETER_NO_DSA_ESTABLISHED must be issued. [Maybe something here about OCSP, but really after so many changes I'd need an up to date draft to sugest coherent changes] Again, after the list of conditions written down in page 11, I'd add somthing like the following: If the initiator fail to verify all the conditions, the DSA MUST NOT be considered as established. As no explicit acknowlegment is considered by the protocol, when in a subsequent Diameter message, the initiator receives an AVP related to this failed DSA it should issue a Diameter message with a Result-Code DIAMETER_NO_DSA_ESTABLISHED Comments? // M.A. From owner-aaa-wg@merit.edu Tue Sep 4 05:26: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 FAA06498 for ; Tue, 4 Sep 2001 05:26:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A6DB791213; Tue, 4 Sep 2001 05:27:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78E0C91214; Tue, 4 Sep 2001 05:27: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 43EAA91213 for ; Tue, 4 Sep 2001 05:27:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23CA95DDB4; Tue, 4 Sep 2001 05:27: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 14B245DD8C for ; Tue, 4 Sep 2001 05:27: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 f849R0K19271 for ; Tue, 4 Sep 2001 11:27:02 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA16111; Tue, 4 Sep 2001 11:26:58 +0200 (MET DST) Message-ID: <3B949EBC.79BEF65E@rioja.ericsson.se> Date: Tue, 04 Sep 2001 11:28:28 +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: [AAA-WG]: [issue] DSA error codes (III) References: <3B9347E1.64D3F6C9@rioja.ericsson.se> <3B938512.BC2DD123@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 Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-04 Reference: Document: CMS-02 Comment type: T Priority: 1 Section: 6.2 Rationale/Explanation of issue: In chapter 6.2 it's written down that: When a conforming implementation receives a Diameter message which contains encrypted AVPs within a CMS EnvelopedData, 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. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST indicate an error. Two error situations are pointed: - When the DSA recipient isn't in the list of recipients of EnvelopedData. - Being in the recipient list, an error occurs during decryption. However, no Result-Code is provided in such situations. Requested change: a) create appropriate result codes (maybe DIAMETER_NO_DSA_RECIPIENT and DIAMETER_DSA_DECRYPTION_FAILED) b) clarify the previous paragraph including references to appropriate result codes Regards // M.A. From owner-aaa-wg@merit.edu Tue Sep 4 05:38: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 FAA06613 for ; Tue, 4 Sep 2001 05:38:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76F5A91201; Tue, 4 Sep 2001 05:39:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CDC491214; Tue, 4 Sep 2001 05:39: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 0BF4191201 for ; Tue, 4 Sep 2001 05:39:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D72865DDB4; Tue, 4 Sep 2001 05:39:17 -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 A66605DD8C for ; Tue, 4 Sep 2001 05:39:12 -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 f849dAK29157 for ; Tue, 4 Sep 2001 11:39:11 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA17084; Tue, 4 Sep 2001 11:39:07 +0200 (MET DST) Message-ID: <3B94A196.7C8BBDDF@rioja.ericsson.se> Date: Tue, 04 Sep 2001 11:40:38 +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] DSA error codes References: <3B9347E1.64D3F6C9@rioja.ericsson.se> <20010903104246.B19656@charizard.diameter.org> <3B949A95.F8AFBF53@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 Something missed: Miguel Ángel Monjas Llorente wrote: > > Once received a DSA-Request, the destination node MUST verify that: > > - The digital signature included in the CMS-Signed-Data AVP can > be verified (i.e. proper digital certificates are available to > verify the digital signature). > - One of the Local-CA-info AVP values from the DSA-Request message > can act as the top CA of a certificate chain down to the CA > which has issued all the end entity certificates of the AAA > servers in the Home Domain. - It may agree on a TTL less or equal to the provided in the DSAA (via the DSA-TTL AVP or the earliest expiration of all certificates included in the message) > Otherwise a DSA-Answer with a Result-Code > DIAMETER_NO_DSA_ESTABLISHED must be issued. Regards // M.A. From owner-aaa-wg@merit.edu Tue Sep 4 05:43: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 FAA06710 for ; Tue, 4 Sep 2001 05:43:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAA6191214; Tue, 4 Sep 2001 05:44:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98A579122D; Tue, 4 Sep 2001 05:44: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 47C6591214 for ; Tue, 4 Sep 2001 05:44:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C9225DDB4; Tue, 4 Sep 2001 05:44:49 -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 BFC735DD8C for ; Tue, 4 Sep 2001 05:44:43 -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.10.1/WIREfire-1.3) with ESMTP id f849icv14974 for ; Tue, 4 Sep 2001 11:44:39 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA17619; Tue, 4 Sep 2001 11:44:36 +0200 (MET DST) Message-ID: <3B94A2DE.EC49FECA@rioja.ericsson.se> Date: Tue, 04 Sep 2001 11:46:06 +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: [AAA-WG]: [issue] Reference change in CMS-02 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-08-04 Reference: Document: CMS-02 Comment type: E Priority: S Section: 3.1 Rationale/Explanation of issue: The following item doesn't follow the convention to use references: - the certificate chain selected is cryptographically correct, passes the (relevant parts of the) rfc2459 path validation algorithm and terminates at a CA mentioned in the DSAR message The rest of references uses the form [x], where x is the number of the reference in 11.0 Requested change: Replace the quoted paragraph with the following: - the certificate chain selected is cryptographically correct, passes the (relevant parts of the)path validation algorithm specified in [4] and terminates at a CA mentioned in the DSAR message 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Tue Sep 4 06:42: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 GAA07083 for ; Tue, 4 Sep 2001 06:42:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D678C91212; Tue, 4 Sep 2001 06:43:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A26F99122D; Tue, 4 Sep 2001 06:43: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 7DC2C91212 for ; Tue, 4 Sep 2001 06:43:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58ED05DDCA; Tue, 4 Sep 2001 06:43:02 -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 795065DD8C for ; Tue, 4 Sep 2001 06:43:01 -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.10.1/WIREfire-1.3) with ESMTP id f84Aguv24058 for ; Tue, 4 Sep 2001 12:42:56 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA22306; Tue, 4 Sep 2001 12:42:53 +0200 (MET DST) Message-ID: <3B94B088.B6CB7441@rioja.ericsson.se> Date: Tue, 04 Sep 2001 12:44:24 +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] DSA error codes References: <3B9347E1.64D3F6C9@rioja.ericsson.se> <20010903104246.B19656@charizard.diameter.org> <3B949A95.F8AFBF53@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 Something missed again: Miguel Ángel Monjas Llorente wrote: > Again, after the list of conditions written down in page 11, I'd add > somthing like the following: > > If the initiator fail to verify all the conditions, the DSA MUST > NOT be considered as established. As no explicit acknowlegment > is considered by the protocol, when in a subsequent Diameter > message, the initiator receives an AVP related to this failed DSA > it should issue a Diameter message with a Result-Code > DIAMETER_NO_DSA_ESTABLISHED What implies that the sentence previous to the list of items should be dropped. At the moment, it's said: The originating Diameter node now has to check the response. Any failure results in error messages and auditing and not sending the Diameter message. Checks: - the certificate chain selected is cryptographically ... A more proper solution might be: The originating Diameter node now has to check the DSA-Answer: - the certificate chain provided is cryptographically ... And the previously issued paragraph after the list of checks. Regards // M.A. From owner-aaa-wg@merit.edu Tue Sep 4 08:22: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 IAA11452 for ; Tue, 4 Sep 2001 08:22:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C16349122D; Tue, 4 Sep 2001 08:23:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9369B9122E; Tue, 4 Sep 2001 08: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 8305E9122D for ; Tue, 4 Sep 2001 08:23:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 345F75DDF8; Tue, 4 Sep 2001 08:23:47 -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 2F91E5DDB9 for ; Tue, 4 Sep 2001 08:23:46 -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 f84COC304059 for ; Tue, 4 Sep 2001 15:24:12 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Sep 2001 15:23:43 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWD495>; Tue, 4 Sep 2001 15:23:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBA94@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: fredrik.johansson@ipunplugged.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 128: duplicate packet detection failure case Date: Tue, 4 Sep 2001 15:23:30 +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 Fredrik, > I don't like the idea of sending empty dummy packets, isn't > it enough to use the end-to-end identifier in the endpoints > to detect duplicate packets. If there are some duplicate packets > on the intermediate nodes, then so be it, it's just some extra > traffic, not that much processing. Sorry for not responding sooner - I have been busy with a last call of my own. Sending the empty test packets (due to the non-responded messages) to the recovered original peer node may not be the only way. It was just one suggestion on how to improve the duplicate packet removal efficiency in a node/link failure case. There can be a checking efficiency improvement possibility also with a minimal proposal. A network or node failure will create lots of problems, of course. We want to make sure that the mechanisms for overcoming and dealing with these failures is as robust as possible. A minimalist-change proposal would be just to include a "possibly duplicated" packet flag to the message header. I will try to make a more coherent proposal. best regards, John From owner-aaa-wg@merit.edu Tue Sep 4 09:03: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 JAA13491 for ; Tue, 4 Sep 2001 09:03:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 413999122E; Tue, 4 Sep 2001 09:04:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F2A391230; Tue, 4 Sep 2001 09:04: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 E0A999122E for ; Tue, 4 Sep 2001 09:04:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5D795DDE0; Tue, 4 Sep 2001 09:04:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B6EBB5DD8E for ; Tue, 4 Sep 2001 09:04:28 -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 f84D4u300124 for ; Tue, 4 Sep 2001 16:04:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Sep 2001 16:04:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWDXHV>; Tue, 4 Sep 2001 16:04:19 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4ED@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 87: Move filter-rule AVP to base Date: Tue, 4 Sep 2001 16:04:13 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13491 Pat, Would it be inappropriate at this time to ask the QoSFilterRule to be extended to include an optional IPv6 flow label value (20 bits) to be matched by the filter? Jarno > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 1. heinäkuuta 2001 2:40 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 87: Move filter-rule AVP to base > > > All, > > Below is the proposed text for this issue. Comments > appreciated, but proposed > text even more :) > > Thanks, > > PatC > ---- > IPFilterRule > The IPFilterRule format is derived from the OctetString AVP > Base Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. Packets may be filtered based > on the following information that is associated with it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > TCP flags > IP fragment flag > IP options > ICMP types > > Rules for the appropriate direction are evaluated in order, > with the first matched rule terminating the evaluation. Each > packet is evaluated once. If no rule matches, the packet is > dropped if the last rule evaluated was a permit, and > passed if > the last rule was a deny. > > IPFilterRule filters MUST follow the format: > > action dir proto from src to dst [options] > > action permit - Allow packets that match the rule. > deny - Drop packets that match the rule. > > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > > The
may be specified as: > ipno An IPv4 or IPv6 number in dotted- > quad or canonical IPv6 form. Only > this exact IP number will > match the > rule. > ipno/bits An IP number as above with a mask > width of the form 1.2.3.4/24. In > this case all IP numbers from > > > > Calhoun et al. expires December 2001 > [Page 34] > > > > > > Internet-Draft > June 2001 > > > 1.2.3.0 to 1.2.3.255 will match. > The bit width MUST be > valid for the > IP version and the IP number MUST > NOT have bits set beyond the mask. > > The sense of the match can be inverted by > preceding an address with the not modifier, > causing all other addresses to be matched > instead. This does not affect the > selection of > port numbers. > > The keyword "any" is 0.0.0.0/0 or the IPv6 > equivalent. The keyword "assigned" is the > address or set of addresses > assigned to the > terminal. The first rule SHOULD > be "deny in > ip !assigned". > > With the TCP, UDP and SCTP > protocols, optional > ports may be specified as: > > {port|port-port}[,port[,...]] > > The `-' notation specifies a range of ports > (including boundaries). > > Fragmented packets which have a > non-zero offset > (i.e. not the first fragment) will > never match > a rule which has one or more port > specifications. See the frag option for > details on matching fragmented packets. > > options: > frag Match if the packet is a fragment and > this is not > the first fragment of the datagram. > frag may not > be used in conjunction with either tcpflags or > TCP/UDP port specifications. > > ipoptions spec > Match if the IP header contains the comma > separated list of options specified in > spec. The > supported IP options are: > > ssrr (strict source route), lsrr (loose source > route), rr (record packet route) and ts > (timestamp). The absence of a particular option > may be denoted with a `!'. > > tcpoptions spec > > > > Calhoun et al. expires December 2001 > [Page 35] > > > > > > Internet-Draft > June 2001 > > > Match if the TCP header contains the comma > separated list of options specified in > spec. The > supported TCP options are: > > mss (maximum segment size), window (tcp window > advertisement), sack (selective ack), > ts (rfc1323 > timestamp) and cc (rfc1644 t/tcp connection > count). The absence of a particular option may > be denoted with a `!'. > > established > TCP packets only. Match packets that > have the RST > or ACK bits set. > > setup TCP packets only. Match packets that > have the SYN > bit set but no ACK bit. > > tcpflags spec > TCP packets only. Match if the TCP header > contains the comma separated list of flags > specified in spec. The supported TCP flags are: > > fin, syn, rst, psh, ack and urg. The > absence of a > particular flag may be denoted with a > `!'. A rule > which contains a tcpflags > specification can never > match a fragmented packet which has a non-zero > offset. See the frag option for details on > matching fragmented packets. > > icmptypes types > ICMP packets only. Match if the ICMP > type is in > the list types. The list may be > specified as any > combination of ranges or individual types > separated by commas. The supported ICMP types > are: > > echo reply (0), destination unreachable (3), > source quench (4), redirect (5), echo request > (8), router advertisement (9), router > solicitation (10), time-to-live > exceeded (11), IP > header bad (12), timestamp request (13), > timestamp reply (14), information request (15), > information reply (16), address mask > request (17) > and address mask reply (18). > > There is one kind of packet that the access device > MUST always > discard, that is an IP fragment with a fragment > offset of one. > This is a valid packet, but it only has one use, to try to > > > > Calhoun et al. expires December 2001 > [Page 36] > > > > > > Internet-Draft > June 2001 > > > circumvent firewalls. > > An access device that is unable to interpret or > apply a deny > rule MUST terminate the session. An access device that is > unable to interpret or apply a permit rule MAY > apply a more > restrictive rule. An access device MAY apply > deny rules of > its own before the supplied rules, for example to protect > the access device owner's infrastructure. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. > > QoSFilterRule > The QosFilterRule format is derived from the OctetString AVP > Base Format. It uses the UTF-8 encoding and has the same > requirements as the UTF8String. Packets may be marked or > metered based on the following information that is associated > with it: > > Direction (in or out) > Source and destination IP address (possibly masked) > Protocol > Source and destination port (lists or ranges) > DSCP values (no mask or range) > > Rules for the appropriate direction are evaluated in order, > with the first matched rule terminating the evaluation. Each > packet is evaluated once. If no rule matches, the packet is > treated as best effort. > > QoSFilterRule filters MUST follow the format: > > action dir proto from src to dst [options] > > tag - Mark packet with a specific > DSCP [49]. > The DSCP option MUST be included. > meter - Meter traffic. The metering options > MUST be included. > > dir "in" is from the terminal, "out" is to the > terminal. > > proto An IP protocol specified by number. The "ip" > keyword means any protocol will match. > > src and dst
[ports] > > > > > Calhoun et al. expires December 2001 > [Page 37] > > > > > > Internet-Draft > June 2001 > > > The
may be specified as: > ipno An IPv4 or IPv6 number in dotted- > quad or canonical IPv6 form. Only > this exact IP number will > match the > rule. > ipno/bits An IP number as above with a mask > width of the form 1.2.3.4/24. In > this case all IP numbers from > 1.2.3.0 to 1.2.3.255 will match. > The bit width MUST be > valid for the > IP version and the IP number MUST > NOT have bits set beyond the mask. > > The sense of the match can be inverted by > preceding an address with the not modifier, > causing all other addresses to be matched > instead. This does not affect the > selection of > port numbers. > > The keyword "any" is 0.0.0.0/0 or the IPv6 > equivalent. The keyword "assigned" is the > address or set of addresses > assigned to the > terminal. The first rule SHOULD > be "deny in > ip !assigned". > > With the TCP, UDP and SCTP > protocols, optional > ports may be specified as: > > {port|port-port}[,port[,...]] > > The `-' notation specifies a range of ports > (including boundaries). > > options: > > DSCP > color values as defined in [49]. Exact matching > of DSCP values is required (no masks > or ranges). > the "deny" can replace the color_under or > color_over values in the meter action for rate- > dependent packet drop. > > > > > Calhoun et al. expires December 2001 > [Page 38] > > > > > > Internet-Draft > June 2001 > > > metering > The metering option provides Assured > Forwarding, > as defined in [50], and MUST be present if the > action is set to meter. The rate option is the > throughput, in bits per second, which > is used by > the access device to mark packets. > Traffic above > the rate is marked with the color_over > codepoint, > while traffic under the rate is marked with the > color_under codepoint. The color_under and > color_over options contain the drop > preferences, > and MUST conform to the recommended codepoint > keywords described in [50] (e.g. AF13). > > The metering option also supports the strict > limit on traffic required by Expedited > Forwarding, as defined in [51]. The color_over > option may contain the keyword "drop" > to prevent > forwarding of traffic that exceeds the rate > parameter. > > The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and the ipfw.c code may provide a useful base for > implementations. > From owner-aaa-wg@merit.edu Tue Sep 4 09:23: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 JAA14673 for ; Tue, 4 Sep 2001 09:23:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FEB991230; Tue, 4 Sep 2001 09:24:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5E0791232; Tue, 4 Sep 2001 09:24: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 8CE7B91230 for ; Tue, 4 Sep 2001 09:24:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7008F5DDE0; Tue, 4 Sep 2001 09:24:35 -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 659135DD8E for ; Tue, 4 Sep 2001 09:24:34 -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 f84DONK09558 for ; Tue, 4 Sep 2001 15:24:28 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA04699; Tue, 4 Sep 2001 15:24:19 +0200 (MET DST) Message-ID: <3B94D65F.2DD27B9A@rioja.ericsson.se> Date: Tue, 04 Sep 2001 15:25: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: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Destination-Host in PDSR Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-04 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html Document: CMS-02 Comment type: T Priority: 2 Section: 4.3 Rationale/Explanation of issue: The establishment of DSAs through evil proxies is usually a tricky task. As stated in our discussion about issue 136, two main scenarios are considered: - The access device does not have the cryptographic ability to handle the CMS functions locally, and therefore requests such services from the local agent, such an an aggregating relay or proxy agent. The NAS may have been configured to always issue a PDSR to its local agent for CMS services. In such cases, the agent MUST select the values for the DSA-TTL and provide the appropriate Local-CA-Info and the expected OCSP response from the DSA peer. - The access device has the cryptographic ability to perform the CMS functions, but a proxy agent is in the route towards the home server, and it returned a failure to the DSAR messages stating that it was not willing to allow the DSA to traverse through it. Such agents MAY attempt to re-use the values from the initial DSAR sent by the access device. The ABNF grammar of a PDSR AVP is: ::= < Diameter-Header: 305, REQ, PXY > { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } [ DSAR-Target-Domain ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] I'd like to focus in the second scenario. The agent has issued a DSAR including the Destination-Realm AVP (let's use abc.com). An evil proxy is in the route towards the home server, so that the evil proxy issues a DSAA including the Origin-Host and the Origin-Realm AVPs (and a DIAMETER_CAN_BE_A_COOL_CMS_PROXY result code). Following, the agent issues a PDSR. Well, it will include again abc.com (but as DSAR-Target-Domain) and the value of the Origin-Realm of the previous DSAA as Destination-Realm of the PDSR. However, it may happen that, once issued a PDSR with only a Destination-Realm, it will be routed to other proxy in the same realm. Maybe this proxy doesn't support CMS (so that it issues a DIAMETER_AINT_CMS_PROXY). Or maybe it supports CMS but, not being the same proxy it won't be able to reuse any of the previously sent parameters (parameters sent in the previous DSAR). I understand that, in this scenario, a Destination-Host AVP must be included in the PDSR. So that an optional Destination-Host AVP must be included in the ABNF grammar of PDSR. Requested change: a) Change the ABNF grammar of PDSR AVP including an optional field: [ Destination-Host ] b) Add explanatory text to 4.3 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Tue Sep 4 09:30: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 JAA15032 for ; Tue, 4 Sep 2001 09:30:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F037991232; Tue, 4 Sep 2001 09:30:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9D9491233; Tue, 4 Sep 2001 09:30: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 9158C91232 for ; Tue, 4 Sep 2001 09:30:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CEAF5DDF4; Tue, 4 Sep 2001 09:30:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 6211D5DD8E for ; Tue, 4 Sep 2001 09:30:19 -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 f84DUk317440 for ; Tue, 4 Sep 2001 16:30:46 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Sep 2001 16:30:16 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWDYSH>; Tue, 4 Sep 2001 16:29:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBAA2@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Expiration of AAA WG last call Date: Tue, 4 Sep 2001 16:29: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 Hi Bernard, Some folks have asked me what the plan is with regards to this document: http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt What will happen when the issues this document addresses are solved in the relevent Diameter spec? Is the intention to make this an Information RFC, Current Best Practices document, or will this just expire? thanks, John From owner-aaa-wg@merit.edu Tue Sep 4 09:53: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 JAA16170 for ; Tue, 4 Sep 2001 09:53:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50E8F91235; Tue, 4 Sep 2001 09:54:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1ABFA91238; Tue, 4 Sep 2001 09:54: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 0A5B891235 for ; Tue, 4 Sep 2001 09:54:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E59795DDF6; Tue, 4 Sep 2001 09:54:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 38BE05DDF5 for ; Tue, 4 Sep 2001 09:54:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA44769; Tue, 4 Sep 2001 06:45:39 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 4 Sep 2001 06:45:38 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Expiration of AAA WG last call In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBAA2@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 The document is slated for publication as an RFC, as a proposed standard. On Tue, 4 Sep 2001 john.loughney@nokia.com wrote: > Hi Bernard, > > Some folks have asked me what the plan is with regards to > this document: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt > > What will happen when the issues this document addresses are > solved in the relevent Diameter spec? Is the intention to > make this an Information RFC, Current Best Practices document, > or will this just expire? > > thanks, > John > > From owner-aaa-wg@merit.edu Tue Sep 4 10: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 KAA16912 for ; Tue, 4 Sep 2001 10:12:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB81691239; Tue, 4 Sep 2001 10:13:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C18F69123A; Tue, 4 Sep 2001 10:13: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 8074491239 for ; Tue, 4 Sep 2001 10:13:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 520C95DDFB; Tue, 4 Sep 2001 10:13:18 -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 E35515DDF8 for ; Tue, 4 Sep 2001 10:13:12 -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 f84EDBK17414 for ; Tue, 4 Sep 2001 16:13:11 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA08405; Tue, 4 Sep 2001 16:13:08 +0200 (MET DST) Message-ID: <3B94E1D0.10BA0A28@rioja.ericsson.se> Date: Tue, 04 Sep 2001 16:14:40 +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 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@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 Calhoun wrote: > > > there's no explicit mention of MIME encoding in 6.2 > > (CMS-Encrypted-Data AVP). My opinion is that such explicit mention to > > MIME should be included in 6.2 (at least if MIME encoding is > > necessary). > > ok, here's the scoop (as I understand it). 6.1 specifies how the > CMS-Signed-Data AVP is created. This is done by taking a bunch of AVPs, > putting them through the signing transform, and taking the result, which > is included in the AVP itself. However, the AVPs themselves are never encoded > in any MIME format when included in the message. Right. A CMS SignedData structure is created containing only the digest of the AVPs, not the whole bunch of AVPs. > 6.2, on the other hand, is completely different. The encrypted data is > included in the CMS-Encrypted-Data AVP. > > So, in 6.1 the process is different from 6.2. Really? In the sense that S/MIME isn't involved? Just pure CMS? > I believe that Stephen will need to help us out here with any additional > clarifications. I'm afraid I'm beginning to need it. Let's say that there are a encapsulation message syntax called CMS. It provides six content-types: data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data. This syntax evolves from PKCS#7 and makes use of ASN.1. Let's imagine that a messaging standard, S/MIME, takes just two of the content types (signed-data and enveloped-data) to provide secure messaging (as well as a particular singed-data message, certificates-only). Of course that some kind of MIME encoding is necessary. Finally, AAA-WG says that it will use CMS for providing end-to-end security. However, two significant things are also stated: that the secured AVPs will be CMS-Signed-Data, CMS-Encrypted-Data and CMS-Cert (which coincide with the different structures used by S/MIME) and that "This application was designed to allow for Diameter implementations to use existing S/MIME toolkits". My first impression is that S/MIME encoding was an intermediate step to get our secured AVP (that is the reason why I thought that S/MIME Security Application was a more proper name). However, it looks that, in order to get a CMS-Encrypted-Data AVP, no S/MIME processing is necessary. Now, I'm definitely confused (I admit that I'm not an S/MIME expert). But I'd like to know where S/MIME processing is used, where not (and how to encode several EnvelopedData values within a single CSM-Enveloped-Data AVP; is that an S/MIME method or not) > As far as the intro paragraph, I've come up with the following at the end > of section 1.0: > > This Diameter application makes use of Cryptographic Message > Syntax (CMS), which a method used to secure MIME (S/MIME) ^^^ | something missed? > messages. This application was designed to allow for Diameter > implementations to use existing S/MIME toolkits in order to > comply with this specification. > so, we're nearly there. Right :-)) From owner-aaa-wg@merit.edu Tue Sep 4 10:25: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 KAA17363 for ; Tue, 4 Sep 2001 10:25:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 500EC9123A; Tue, 4 Sep 2001 10:26:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E05B9123B; Tue, 4 Sep 2001 10:26: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 11B0C9123A for ; Tue, 4 Sep 2001 10:26:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D55FC5DDFE; Tue, 4 Sep 2001 10:26:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by segue.merit.edu (Postfix) with ESMTP id 55A2B5DDFB for ; Tue, 4 Sep 2001 10:26:40 -0400 (EDT) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-29.cisco.com [10.82.240.29]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA21888; Tue, 4 Sep 2001 07:26:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20010904100421.03404f08@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Sep 2001 10:25:53 -0400 To: jarno.rajahalme@nokia.com From: John Schnizlein Subject: RE: [AAA-WG]: Issue 87: Move filter-rule AVP to base Cc: pcalhoun@diameter.org, aaa-wg@merit.edu In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D4ED@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk Yes, it would be inappropriate. The meaning of flow labels was clearly not defined in Minneapolis (IETF 50). The draft minutes from London http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-aug2001.txt indicated some controversy remains, with a call for "Further discussion on mailing list." John At 09:04 AM 9/4/2001, jarno.rajahalme@nokia.com wrote: >Pat, > >Would it be inappropriate at this time to ask the QoSFilterRule to be >extended to include an optional IPv6 flow label value (20 bits) to be >matched by the filter? > > Jarno > >> -----Original Message----- >> From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] >>... >> QoSFilterRule >> The QosFilterRule format is derived from the OctetString AVP >> Base Format. It uses the UTF-8 encoding and has the same >> requirements as the UTF8String. Packets may be marked or >> metered based on the following information that is associated >> with it: >> >> Direction (in or out) >> Source and destination IP address (possibly masked) >> Protocol >> Source and destination port (lists or ranges) >> DSCP values (no mask or range) >> >> Rules for the appropriate direction are evaluated in order, >> with the first matched rule terminating the evaluation. Each >> packet is evaluated once. If no rule matches, the packet is >> treated as best effort. >> >> QoSFilterRule filters MUST follow the format: >> >> action dir proto from src to dst [options] >> >> tag - Mark packet with a specific >> DSCP [49]. >> The DSCP option MUST be included. >> meter - Meter traffic. The metering options >> MUST be included. >> >> dir "in" is from the terminal, "out" is to the >> terminal. >> >> proto An IP protocol specified by number. The "ip" >> keyword means any protocol will match. >> >> src and dst
[ports] >> >> The
may be specified as: >> ipno An IPv4 or IPv6 number in dotted- >> quad or canonical IPv6 form. Only >> this exact IP number will match >> the rule. >> ipno/bits An IP number as above with a mask >> width of the form 1.2.3.4/24. In >> this case all IP numbers from >> 1.2.3.0 to 1.2.3.255 will match. >> The bit width MUST be valid for the >> IP version and the IP number MUST >> NOT have bits set beyond the mask. >> >> The sense of the match can be inverted by >> preceding an address with the not modifier, >> causing all other addresses to be matched >> instead. This does not affect the selection >> of port numbers. >> >> The keyword "any" is 0.0.0.0/0 or the IPv6 >> equivalent. The keyword "assigned" is the >> address or set of addresses assigned >> >> to the terminal. The first rule SHOULD >> >> be "deny in ip !assigned". >> >> With the TCP, UDP and SCTP protocols, >> >> optional ports may be specified as: >> >> {port|port-port}[,port[,...]] >> >> The `-' notation specifies a range of ports >> (including boundaries). >> >> options: >> >> DSCP >> color values as defined in [49]. Exact matching >> of DSCP values is required (no masks or ranges). >> the "deny" can replace the color_under or >> color_over values in the meter action for rate- >> dependent packet drop. >> >> metering >> The metering option provides Assured Forwarding, >> as defined in [50], and MUST be present if the >> action is set to meter. The rate option is the >> throughput, in bits per second, which is used >> by the access device to mark packets. Traffic >> above the rate is marked with the color_over >> codepoint, >> while traffic under the rate is marked with the >> color_under codepoint. The color_under and >> color_over options contain the drop preferences, >> and MUST conform to the recommended codepoint >> keywords described in [50] (e.g. AF13). >> >> The metering option also supports the strict >> limit on traffic required by Expedited >> Forwarding, as defined in [51]. The color_over >> option may contain the keyword "drop" to prevent >> forwarding of traffic that exceeds the rate >> parameter. >> >> The rule syntax is a modified subset of ipfw(8) from FreeBSD, >> and the ipfw.c code may provide a useful base for >> implementations. >> From owner-aaa-wg@merit.edu Tue Sep 4 10:58: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 KAA18335 for ; Tue, 4 Sep 2001 10:58:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6F569123B; Tue, 4 Sep 2001 10:59:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94E399123D; Tue, 4 Sep 2001 10:59: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 462389123B for ; Tue, 4 Sep 2001 10:59:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18A675DDFE; Tue, 4 Sep 2001 10:59:14 -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 302C45DDFB for ; Tue, 4 Sep 2001 10:59:13 -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 f84Exe301536 for ; Tue, 4 Sep 2001 17:59:40 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Sep 2001 17:59:11 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWD6PD>; Tue, 4 Sep 2001 17:59:12 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB69@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 128: duplicate packet detection failure case Date: Tue, 4 Sep 2001 17:59:09 +0300 Importance: high X-Priority: 1 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 Pat, Sorry for the delay in responding - I have been quite busy - I have another document that just finished last call. I was a bit rushed when I submitted the issue for Diameter, it had actually 2 different parts that are easiest to consider separately: 1) Marking of the possibly duplicated messages. 2) Removal of duplicate messages. Step 1 is a minimal functionality for enabling the duplicate message checking to be efficient as possible. The Diameter client knows (after hearing no response) that it is sending the message a 2nd (or 3rd etc.) time (either to the original peer node or an alternate node). Enhancing the efficiency of checking is the main benefit but it may improve a bit the reliability too. It also improves the reliability somewhat since the Diameter client has in End-to-End Identifier only 12 low order bits of the local time when booting. That is 4096 seconds which is a bit over a hour. This means that with very bad luck, a Diameter client that goes down and wakes up after 4096 seconds MAY send a message with the same End-to-End Identifier, taking from non-volatile memory an earlier sent (but not yet answered) pending message and produces a duplicate. Unless, it has this capability to mark with 'D' bit that the pending message now resent may be a duplicate.) Step 2 is a solution where in addition to the minimal solution of marking the possibly duplicated packets, the duplicates are also removed form the network as quickly as possible, with minimal amount of double-checking. This mail presents only a simplified way of step 1, as it can be used also as a stand-alone feature (just an additional flag bit in the Diameter header). Please review the following description, it would help the Diameter Server to avoid the obligation to do a mandatory cross check every single received request message - which should save on processing. The needed small changes for the step 1) (marking of possibly duplicated packets) to the draft-ietf-aaa-diameter-07.txt are the following: 3.0 Diameter Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ would be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E D r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. r(eserved) - this flag bit is reserved for future use, and MUST be set to zero. would get one new flag bit 'D': E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. (possibly) D(uplicated) - If set, the message is possibly a duplicate, and must be later checked by a recipient node if it really is a duplicate. If sending a message for first time, this bit MUST be cleared. This bit MUST NOT be set if an answer message (about e.g. a protocol error) has been got for an earlier similar message, it is used only in cases where no answer has been got from the primary agent for a message and the message is sent again (e.g. due to failover, to an alternate agent). r(eserved) - this flag bit is reserved for future use, and MUST be set to zero. In: 5.5.4 Failover/Failback Procedures ... It is important to note that multiple identical request or answer MAY be received as a result of a failover. The End-to-End Identifier field in the Diameter header along with the Origin-Host AVP MUST be used to identify duplicate messages. the above paragraph would be amended as: It is important to note that multiple identical request or answer MAY be received as a result of a failover. The possibly-Duplicated flag MUST be set by the Diameter client node that performs failover, to mark those packets that it had sent with no answer message coming from the primary agent, and which it therefore forwards to an alternate node. The final destination node of a message MUST check those messages that have the 'D' bit set, if they can be identified as actually duplicated messages. The intermediate nodes MAY check the messages with the 'D' bit set, if they can be identified as duplicate messages. The End-to-End Identifier field in the Diameter header along with the Origin-Host AVP MUST be used to identify duplicate messages among the marked possibly duplicated messages. and in: 9.4 Fault Resilience ... Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. paragraph would get one sentence to its end: .... Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. The inspection MUST be performed at least for such records that arrived to the Diameter peer in messages having the 'D' bit set. br, John From owner-aaa-wg@merit.edu Tue Sep 4 15:08: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 PAA24759 for ; Tue, 4 Sep 2001 15:08:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 78F9991223; Tue, 4 Sep 2001 15:09:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42D1B91242; Tue, 4 Sep 2001 15:09: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 2850291223 for ; Tue, 4 Sep 2001 15:09:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D0995DDE0; Tue, 4 Sep 2001 15:09:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 5831E5DDB0 for ; Tue, 4 Sep 2001 15:09:00 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f84J4Pd19251; Tue, 4 Sep 2001 15:04:25 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from (mailman [172.21.24.8]) by ahab via smap (V2.1) id xma019246; Tue, 4 Sep 01 15:03:58 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f84J6mh16006; Tue, 4 Sep 2001 15:06:48 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma015918; Tue, 4 Sep 01 15:06:00 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Sep 2001 15:05:54 -0400 Message-ID: From: Yiwen Jiang To: "'aaa-wg@merit.edu'" Cc: "'pcalhoun@diameter.org'" Subject: [AAA-WG]: failover question Date: Tue, 4 Sep 2001 15:05:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, I have a question regarding how failover is handled based on -07. I went to the I-D, but couldn't find answer for this question. I understand that when a Diameter peer has detected that the connection with its remote peer has been lost via the watchdog timer, it will failover to an alternate host in its peer table. However, what happens when all the alternate hosts are down, and the Diameter cannot forward any messages to them? Or, if there is no other peers specified in the peer table? How would the base protocol notify its applications about this situation? Or, what would be your recommendation on how the application detects such situation, since the watchdog timers and such are all hidden from all Diameter applications? Thanks. Cheers, Yiwen --- Yiwen Jiang Mobile IP Networking Email: Yiwen.Jiang@tic.siemens.ca Phone: (613)271-7710 Telecom Innovation Centre 505 March Road Kanata, Ontario, Canada K2K 2M5 From owner-aaa-wg@merit.edu Wed Sep 5 03:01: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 DAA20919 for ; Wed, 5 Sep 2001 03:01:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B5E09120E; Wed, 5 Sep 2001 03:02:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6301291210; Wed, 5 Sep 2001 03: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 8DF949120E for ; Wed, 5 Sep 2001 03:02:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 598C25DDF8; Wed, 5 Sep 2001 03:02:36 -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 9492A5DDF5 for ; Wed, 5 Sep 2001 03:02:35 -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 f85731302081 for ; Wed, 5 Sep 2001 10:03:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Sep 2001 10:02:29 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSW1F9V>; Wed, 5 Sep 2001 10:02:29 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719800D@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: jschnizl@cisco.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, ipng@sunroof.eng.sun.com Subject: [AAA-WG]: IPv6 flow label support in the QoSFilterRule in Diameter (RE: [AA A-WG]: Issue 87: Move filter-rule AVP to base) Date: Wed, 5 Sep 2001 10:02: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 John, I'll come back with this when IPv6 WG consensus exists. I think we're pretty close now. Is there a hard deadline for any new issues for Diameter? Jarno jschnizl@cisco.com wrote: > > Yes, it would be inappropriate. The meaning of flow labels was clearly > not defined in Minneapolis (IETF 50). The draft minutes from London > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-a > ug2001.txt > indicated some controversy remains, with a call for > "Further discussion on mailing list." > > John > > At 09:04 AM 9/4/2001, jarno.rajahalme@nokia.com wrote: > >Pat, > > > >Would it be inappropriate at this time to ask the QoSFilterRule to be > >extended to include an optional IPv6 flow label value (20 bits) to be > >matched by the filter? > > > > Jarno > > > >> -----Original Message----- > >> From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > >>... > >> QoSFilterRule > >> The QosFilterRule format is derived from the > OctetString AVP > >> Base Format. It uses the UTF-8 encoding and has the same > >> requirements as the UTF8String. Packets may be marked or > >> metered based on the following information that > is associated > >> with it: > >> > >> Direction (in or out) > >> Source and destination IP address (possibly masked) > >> Protocol > >> Source and destination port (lists or ranges) > >> DSCP values (no mask or range) > >> > >> Rules for the appropriate direction are evaluated > in order, > >> with the first matched rule terminating the > evaluation. Each > >> packet is evaluated once. If no rule matches, the > packet is > >> treated as best effort. > >> > >> QoSFilterRule filters MUST follow the format: > >> > >> action dir proto from src to dst [options] > >> > >> tag - Mark packet with a specific > >> DSCP [49]. > >> The DSCP option MUST be included. > >> meter - Meter traffic. The > metering options > >> MUST be included. > >> > >> dir "in" is from the terminal, "out" is to the > >> terminal. > >> > >> proto An IP protocol specified by > number. The "ip" > >> keyword means any protocol will match. > >> > >> src and dst
[ports] > >> > >> The
may be specified as: > >> ipno An IPv4 or IPv6 number > in dotted- > >> quad or canonical IPv6 > form. Only > >> this exact IP number > will match > >> the rule. > >> ipno/bits An IP number as above > with a mask > >> width of the form > 1.2.3.4/24. In > >> this case all IP numbers from > >> 1.2.3.0 to 1.2.3.255 > will match. > >> The bit width MUST be > valid for the > >> IP version and the IP > number MUST > >> NOT have bits set > beyond the mask. > >> > >> The sense of the match can be inverted by > >> preceding an address with the not > modifier, > >> causing all other addresses to be matched > >> instead. This does not affect > the selection > >> of port numbers. > >> > >> The keyword "any" is 0.0.0.0/0 > or the IPv6 > >> equivalent. The keyword > "assigned" is the > >> address or set of addresses assigned > >> > >> to the terminal. The first > rule SHOULD > >> > >> be "deny in ip !assigned". > >> > >> With the TCP, UDP and SCTP protocols, > >> > >> optional ports may be specified as: > >> > >> {port|port-port}[,port[,...]] > >> > >> The `-' notation specifies a > range of ports > >> (including boundaries). > >> > >> options: > >> > >> DSCP > >> color values as defined in [49]. > Exact matching > >> of DSCP values is required (no > masks or ranges). > >> the "deny" can replace the color_under or > >> color_over values in the meter > action for rate- > >> dependent packet drop. > >> > >> metering > >> The metering option provides > Assured Forwarding, > >> as defined in [50], and MUST be > present if the > >> action is set to meter. The rate > option is the > >> throughput, in bits per second, > which is used > >> by the access device to mark > packets. Traffic > >> above the rate is marked with the > color_over > >> codepoint, > >> while traffic under the rate is > marked with the > >> color_under codepoint. The color_under and > >> color_over options contain the drop > preferences, > >> and MUST conform to the recommended > codepoint > >> keywords described in [50] (e.g. AF13). > >> > >> The metering option also supports the strict > >> limit on traffic required by Expedited > >> Forwarding, as defined in [51]. The > color_over > >> option may contain the keyword > "drop" to prevent > >> forwarding of traffic that exceeds the rate > >> parameter. > >> > >> The rule syntax is a modified subset of ipfw(8) > from FreeBSD, > >> and the ipfw.c code may provide a useful base for > >> implementations. > >> > From owner-aaa-wg@merit.edu Wed Sep 5 04:03: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 EAA21331 for ; Wed, 5 Sep 2001 04:03:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B59959121A; Wed, 5 Sep 2001 04:04:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7360A91276; Wed, 5 Sep 2001 04:04: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 52B4E9121A for ; Wed, 5 Sep 2001 04:04:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B7FB5DDF8; Wed, 5 Sep 2001 04:04:13 -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 6366F5DDF5 for ; Wed, 5 Sep 2001 04:04:12 -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 f8584d318184 for ; Wed, 5 Sep 2001 11:04:39 +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, 5 Sep 2001 11:04:11 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSW1JYN>; Wed, 5 Sep 2001 11:04:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB6C@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Question on Diameter behavior in Failure cases Date: Wed, 5 Sep 2001 11:04:07 +0300 Importance: high X-Priority: 1 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 Pat, As you can imagine, I've been doing some studying on the reliability aspects of Diameter. One question I have is what happens if a Diameter client goes down while sending messages, before getting a response to a pending message, when there is no secondary peer? The base protocol draft text says: 5.1 Peer Connections Although a Diameter node may have many possible peers that it is able to communicate with, it may not be economical to have an established connection to all of them. At a minimum, a Diameter node SHOULD have an established connection with a primary and secondary peer, and MAY have additional connections, if it is deemed necessary. Does that imply that a Diameter node may not ALWAYS have a secondary or additional connections available. In that case, if the Diameter client stops temporarily getting answer messages (and does not have an alternate agent to send the payload packet), the primary peer may recover (after a boot, for example). Then the following problem arises: Should the Diameter client re-send the pending payload message to its original (& now recovered) primary (& only) peer node, as the client does not know if the packet had been properly received went sent before the failure. It seems that this case a solution could be offered by the by marking the the packet 'possibly duplicated' (see my proposal sent yesterday for usage of a 'D' bit in the Diameter header) since the receiving primary (and only) peer node could a) check the 'D' marked packet against being a packet already received. b) forward the 'D' marked packet even towards the end system (Diameter Server), as the final destination node would anyway be responsible to verify that there are no duplicates and from the 'D' bit it would clearly note that it must check that packet (by comparing the End-to-End Identifiers of the marked packet(s)). This way we could get the one-peer-agent-only cases to work okay. Additionally it supports the case when the connection to the (only) recipient peer agent goes temporarily to the SUSPECT state (or the connection is temporarily closed) and is then again established in the OKAY state. Comments? John From owner-aaa-wg@merit.edu Wed Sep 5 05:54: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 FAA22264 for ; Wed, 5 Sep 2001 05:54:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 172359121F; Wed, 5 Sep 2001 05:55:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D733591276; Wed, 5 Sep 2001 05:55: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 A84DC9121F for ; Wed, 5 Sep 2001 05:55:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 686B35DDF5; Wed, 5 Sep 2001 05:55: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 8086F5DD8F for ; Wed, 5 Sep 2001 05:55:45 -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.10.1/WIREfire-1.3) with ESMTP id f859tgv02934 for ; Wed, 5 Sep 2001 11:55:43 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA11789; Wed, 5 Sep 2001 11:55:39 +0200 (MET DST) Message-ID: <3B95F6FD.AD1DB503@rioja.ericsson.se> Date: Wed, 05 Sep 2001 11:57:17 +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: [AAA-WG]: [issue] Authorisation rejected in CMS Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-05 Reference: Document: CMS-02 Comment type: T Priority: 1 Section: 1.5 Rationale/Explanation of issue: In CMS-02 (section 1.5), it's stated that: " one of participants of a DSA (specifically the one in the home network) MUST belong to the same realm as the user being authorized." May I suppose that otherwise, a DIAMETER_AUTHORIZATION_REJECTED result code is issued (or it should be a newly defined CMS-Sec specific error) Requested change: Include a specific mention to DIAMETER_AUTHORIZATION_REJECTED or defining a new result code. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Wed Sep 5 07: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 HAA25116 for ; Wed, 5 Sep 2001 07:45:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7F109124B; Wed, 5 Sep 2001 07:45:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DDDE91276; Wed, 5 Sep 2001 07:45: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 5B24B9124B for ; Wed, 5 Sep 2001 07:45:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 221165DD92; Wed, 5 Sep 2001 07:45:44 -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 284A55DDE2 for ; Wed, 5 Sep 2001 07:45:42 -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 f85Bk9322009 for ; Wed, 5 Sep 2001 14:46:09 +0300 (EET DST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Sep 2001 14:45:38 +0300 Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id ; Wed, 5 Sep 2001 14:45:38 +0300 Message-ID: From: Yanqun.Le@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: question about Diameter Date: Wed, 5 Sep 2001 14:35:44 +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, > > We are puzzled of the use of Disconnect-Peer-Request. It doesn't appear in > Peer FSM. Does the event of R-Peer-Disc appeared in Peer FSM have the same > meaning to it? > If a peer sends out DPR, which peer state should it change to? > I infer from draft 07, a receiver of DPR should not periodically attempt > to reconnect to the sender of DPR. Then only if the sender of DPR will > reconnect to another peer after it is going to do so? > > Best regards > Yanqun Le From owner-aaa-wg@merit.edu Wed Sep 5 10: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 KAA03730 for ; Wed, 5 Sep 2001 10:15:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00DE491254; Wed, 5 Sep 2001 10:16:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8DE391257; Wed, 5 Sep 2001 10:16: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 9E47491254 for ; Wed, 5 Sep 2001 10:16:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 742BF5DD97; Wed, 5 Sep 2001 10:16:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8A6A65DD92 for ; Wed, 5 Sep 2001 10:16:49 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA46362; Wed, 5 Sep 2001 07:08:11 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 5 Sep 2001 07:08:11 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question on Diameter behavior in Failure cases In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB6C@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 > One question I have is what happens if a Diameter client goes > down while sending messages, before getting a response to a > pending message, when there is no secondary peer? If the NAS goes down, you will have a AAA failure whether there are secondary servers or not. The way to handle that kind of failure is via clustering technology (some NASes already support this today) so that the connection can be migrated to another NAS. Diameter can't help with this. > Does that imply that a Diameter node may not ALWAYS have a > secondary or additional connections available. Failover protection is not mandatory. But if you want high availability it is a good idea. > In that case, if the Diameter client stops temporarily getting > answer messages (and does not have an alternate agent to send > the payload packet), the primary peer may recover (after a boot, > for example). Then the following problem arises: > I'm confused. You were initially talking about a *client* failure. Now you are talking about *server* failures. If the primary server fails and there is no alternate, then availability is compromised. Again, there isn't much that Diameter can do about that. > Should the Diameter client re-send the pending payload > message to its original (& now recovered) primary (& only) peer > node, as the client does not know if the packet had been > properly received went sent before the failure. > This points out that failure scenarios can result in duplicates, not only to different servers, but also to the same server. That is what the e2e session identifier was created to handle. In the case of accounting, this should be sufficient to deal with a duplicate accounting record. In the case of authentication/authorization, I'm not sure that there is a problem. You'll just get a new response. The only problem that could have arisen is if the server wrote something about the session to stable storage before responding, and *then* the connection failed (such as incrementing the simultaneous session count). In that case, when the server comes up again, it will have incorrect information in its database. The solution to this is for the server to *not* write session info to stable storage until it receives the equivalent of an application-layer ACK from the NAS. There is no app-layer ACK of an authentication response in Diameter, because the Accounting Request largely serves this function. > It seems that this case a solution could be offered by the > by marking the the packet 'possibly duplicated' (see my > proposal sent yesterday for usage of a 'D' bit in the Diameter > header) since the receiving primary (and only) peer node could I don't think that this is necessary, if the advice above is followed. Can you come up with a scenario in which a problem would be caused by receipt of a duplicate authentication packet? From owner-aaa-wg@merit.edu Wed Sep 5 11:27: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 LAA07610 for ; Wed, 5 Sep 2001 11:27:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59B9891275; Wed, 5 Sep 2001 11:28:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 298719127B; Wed, 5 Sep 2001 11:28: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 1D64C91275 for ; Wed, 5 Sep 2001 11:28:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE42D5DD9D; Wed, 5 Sep 2001 11:28:47 -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 3E07B5DD92 for ; Wed, 5 Sep 2001 11:28:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA46456; Wed, 5 Sep 2001 08:19:58 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 5 Sep 2001 08:19:58 -0700 (PDT) From: Bernard Aboba To: jarno.rajahalme@nokia.com Cc: jschnizl@cisco.com, pcalhoun@diameter.org, aaa-wg@merit.edu, ipng@sunroof.eng.sun.com Subject: Re: [AAA-WG]: IPv6 flow label support in the QoSFilterRule in Diameter (RE: [AA A-WG]: Issue 87: Move filter-rule AVP to base) In-Reply-To: <009CA59D1752DD448E07F8EB2F91175719800D@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 > Is there a hard deadline for any new issues for Diameter? We've just finished a WG last call, so the deadline is yesterday ;) So if there are issues with the specs, please get them in now. From owner-aaa-wg@merit.edu Wed Sep 5 12:12: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 MAA09625 for ; Wed, 5 Sep 2001 12:12:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75E2A91203; Wed, 5 Sep 2001 12:13:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DF1B9121C; Wed, 5 Sep 2001 12:13:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 336D591203 for ; Wed, 5 Sep 2001 12:13:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D5415DD9D; Wed, 5 Sep 2001 12:13:23 -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 2FC595DD99 for ; Wed, 5 Sep 2001 12:13:22 -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.10.1/WIREfire-1.3) with ESMTP id f85GDKv21519 for ; Wed, 5 Sep 2001 18:13:21 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA10582; Wed, 5 Sep 2001 18:13:17 +0200 (MET DST) Message-ID: <3B964F81.C0B28BB5@rioja.ericsson.se> Date: Wed, 05 Sep 2001 18:14:57 +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: [AAA-WG]: [issue] CMS Usage Scenario precisions Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-05 Reference: Document: CMS-02 Comment type: T Priority: 2 Section: 3.1 Rationale/Explanation of issue: a) In the list of elements that comprise a DSAA quoted in 3.1, it's listed the following: - a chain of CA certificates (possibly empty) Why this element (that I assume it's the CA-Chain AVP) is, possibly, empty? I understand that most of the times, the CA that has issued the certificates of the Home Realm are the same than the provided in the Local-CA-Info AVP, but saying that "possibly" it's empty is maybe too hard. b) On the other hand, in the list of elements that comprise a DSAR quoted in 3.1, it's listed the following: - the realm part of the user's NAI Is that really true? I mean, I understant this meaning when an authorisation or authentication operation is involved. But let's take an accounting operation. Which is the user's NAI? c) In the checks listing (according to conclusion in issue 126) the proposed text stated that: - the name in the certificate is consistent with the rules detailed in section 3.2. My concern is the following. Which certificates are we talking about? The included in the CMS-Cert AVP? The ones from AAA-Server-Certs? Both? BTW, I suppose that the certificate of the DSA receiver (the node issuing the DSAA) in included within the AAA-Server-Certs, so that no CMS-Cert would be necessary? d) The last paragraph of 3.1 talks (again, so that some paragraphs has been included at the beginning of the section) about certificate revocation checks: If certificate revocation is enabled, anytime a certificate is used from the local certificate cache, a revocation check MUST be performed. This paragraph contradicts Stephen's precissions about certificate revocation checks which approximately say that no revocation check is necessary until the "safe" period has ended. Requested change: a) Replace "(posibly empty)" with "(frequently empty since the CA that has issued the certificates for the Diameter servers in the realm are usually included within the CAs contained in the DSAR message). b) Clarify this item. c) Clarify this item (maybe with something like "the name in all the certificates included is consistent with the rules detailed in section 3.2.") d) Drop the quoted paragraph 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Wed Sep 5 12:18: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 MAA09866 for ; Wed, 5 Sep 2001 12:18:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8929E9121C; Wed, 5 Sep 2001 12:19:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D28A91229; Wed, 5 Sep 2001 12:19: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 776ED9121C for ; Wed, 5 Sep 2001 12:19:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58DAD5DD9D; Wed, 5 Sep 2001 12:19:12 -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 25A2E5DD99 for ; Wed, 5 Sep 2001 12:19:12 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15efOR-000FFj-00 for aaa-wg@merit.edu; Wed, 05 Sep 2001 09:19:11 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement Message-Id: Date: Wed, 05 Sep 2001 09:19:11 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Description of issue: Diameter -07 introduction needs improvement Submitter name: Randy Bush Submitter email address: randy@psg.com Date first submitted: 2001.09.03 Reference: Document: base Comment type: E Priority: S Section: 1.0, 1.1 Rationale/Explanation of issue: The Introduction (section 1.0) talks about the history and motivation for the development of Diameter. Section 1.1 talks about the basic building blocks of Diameter. Section 2 provides an overview of protocol concepts. What would be helpful is if a high-level introduction could be provided within section 1. The material currently in section 1.1 might be better moved to section 2. Requested change: To provide context, the following topics would be useful in the Introduction: a. An overview of the Diameter approach 1. Relationship of NASes, Servers and Intermediaries 2. Message routing concepts 3. Requests, Responses, Unsolicited messages b. Important ways that Diameter differs from RADIUS (Idea is to introduce the concepts, not go into depth, but make clear what the feature is attempting to achieve. Reference where details are provided.) 1. Peer-to-peer nature 2. Explicit support for intermediaries 3. Connection-oriented versus connectionless 4. Concept of extensions 5. Built-in failover support 6. Larger attribute space 7. Integrated accounting 8. Mandatory bit 9. Application-layer ACKs and error messages 10. Unsolicited server messages 11. Peer discovery 12. Capabilities negotiation (worth explaining why this isn't e2e here) c. Description of the Diameter document set and relationship between the documents. d. Approach to extensibility (this is in section 2.3, but might be better consolidated into the Introduction) From owner-aaa-wg@merit.edu Wed Sep 5 12:25: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 MAA10104 for ; Wed, 5 Sep 2001 12:25:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA71291229; Wed, 5 Sep 2001 12:26:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B259B9122B; Wed, 5 Sep 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 A80E591229 for ; Wed, 5 Sep 2001 12:26:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8745F5DD9D; Wed, 5 Sep 2001 12:26: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 02EB75DD99 for ; Wed, 5 Sep 2001 12:26:26 -0400 (EDT) Received: (qmail 10353 invoked by uid 500); 5 Sep 2001 16:13:35 -0000 Date: Wed, 5 Sep 2001 09:13:35 -0700 From: Pat Calhoun To: Randy Bush Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement Message-ID: <20010905091335.B10271@charizard.diameter.org> Mail-Followup-To: Randy Bush , 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 randy@psg.com on Wed, Sep 05, 2001 at 09:19:11AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for opening the issue. We'll take care of that. What I find interesting, though, is that most of this was in the framework document, which the WG decides to abandon some time ago. Now we need to pull some of the text from the framework into the base protocol. I do agree, though, that this is a good idea. PatC On Wed, Sep 05, 2001 at 09:19:11AM -0700, Randy Bush wrote: > Description of issue: Diameter -07 introduction needs improvement > > Submitter name: Randy Bush > Submitter email address: randy@psg.com > Date first submitted: 2001.09.03 > Reference: > Document: base > Comment type: E > Priority: S > Section: 1.0, 1.1 > Rationale/Explanation of issue: > > The Introduction (section 1.0) talks about the history and motivation for > the development of Diameter. Section 1.1 talks about the basic building > blocks of Diameter. Section 2 provides an overview of protocol > concepts. What would be helpful is if a high-level introduction could > be provided within section 1. The material currently in section 1.1 might > be better moved to section 2. > > Requested change: > > To provide context, the following topics would be useful in the > Introduction: > > a. An overview of the Diameter approach > 1. Relationship of NASes, Servers and Intermediaries > 2. Message routing concepts > 3. Requests, Responses, Unsolicited messages > > b. Important ways that Diameter differs from RADIUS > (Idea is to introduce the concepts, not go into > depth, but make clear what the feature is attempting > to achieve. Reference where details are provided.) > 1. Peer-to-peer nature > 2. Explicit support for intermediaries > 3. Connection-oriented versus connectionless > 4. Concept of extensions > 5. Built-in failover support > 6. Larger attribute space > 7. Integrated accounting > 8. Mandatory bit > 9. Application-layer ACKs and error messages > 10. Unsolicited server messages > 11. Peer discovery > 12. Capabilities negotiation (worth explaining why > this isn't e2e here) > > c. Description of the Diameter document set and relationship > between the documents. > > d. Approach to extensibility (this is in section 2.3, but might > be better consolidated into the Introduction) > From owner-aaa-wg@merit.edu Wed Sep 5 13:15:58 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 NAA11500 for ; Wed, 5 Sep 2001 13:15:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68BCB9122A; Wed, 5 Sep 2001 13:16:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CBAE9122B; Wed, 5 Sep 2001 13:16: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 19E869122A for ; Wed, 5 Sep 2001 13:16:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D45715DD9D; Wed, 5 Sep 2001 13:16:44 -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 C65785DD99 for ; Wed, 5 Sep 2001 13:16:43 -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 f85HGfK15540 for ; Wed, 5 Sep 2001 19:16:42 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA14177; Wed, 5 Sep 2001 19:16:38 +0200 (MET DST) Message-ID: <3B965E5A.42BEDC40@rioja.ericsson.se> Date: Wed, 05 Sep 2001 19:18:18 +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: [AAA-WG]: [issue] Error codes (recap) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-08-22 Reference: Document: CMS-02 Comment type: T|E Priority: S|1|2 Section: Rationale/Explanation of issue: Some errors and its result codes (not exhaustive): 1. A Diameter message with a CMS-Signed-Data AVP including a digital signature and no AVP with its 'P' bit set: DIAMETER_AVP_NOT_ALLOWED (existing in base draft) 2. A Diameter message without any CMS-Signed-Data AVP and some AVPs with its 'P' bit set: DIAMETER_MISSING_AVP (existing in base draft) 3. A Diameter message including CMS Security Application AVPs with no DSA established: DIAMETER_NO_DSA_ESTABLISHED (existing in CMS-03) 4. A Diameter node not being able to set up a DSA upon receiving a DSA-Request due to problems different from digital signature verification DIAMETER_NO_DSA_ESTABLISHED (existing in CMS-03) 5. A Diameter node not being able to set up a DSA upon receiving a DSA-Answer due to any problem DIAMETER_NO_DSA_ESTABLISHED (in subsequent Diameter messages if a CMS-related message is received) (existing in CMS-03) 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 finishing, a CMS-Signed-Data arrives without any certificate ?? 7. A Diameter message including CMS Security Application AVPs with the DSA expired (only if the Diameter node can "remember" past DSAs) DIAMETER_DSA_EXPIRED (existing in CMS-03) 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. ?? 9. A Diameter message containing a CMS-Signed-Data AVP that doesn't include any digital signature made by the node included in the Origin-Host AVP DIAMETER_CONTRADICTING_AVPS?? (existing in base draft) 10. A Diameter message containing a CMS-Signed-Data AVP. No appropriate digital certificate (regarding the identity included in the Origin-Host AVP) is available, neither included in the Diameter message as CMS-Cert AVP nor available in the local cache. DIAMETER_INVALID_AUTH?? (existing in CMS-03) 11. A Diameter message containing a CMS-Signed-Data AVP. The digital signature is invalid. DIAMETER_INVALID_AUTH (existing in CMS-03) 12. The DSA participant in the home network doesn't belong to the same realm as the user being authorized. DIAMETER_AUTHORIZATION_REJECTED?? (existing in base draft) 13. An OCSP response is requested. The Diameter server supports OCSP querying. However, the OCSP responder isn't available (the server gets a timeout) DIAMETER_OCSP_NOT_SUPPORTED?? (existing in CMS-03) 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. DIAMETER_NO_DSA_RECIPIENT?? 15. A Diameter message containing a CMS-Encrypted-Data AVP. An error occurs during decryption DIAMETER_DSA_DECRYPTION_FAILED?? Requested change: a) Decide if all the situations quoted in which no error code is mentioned needs a new error code (if so create them) b) Decide whether the suggested result codes are correct c) Once decided the result code for any situation, include a mention of such result code (or the section) in the proper place. d) Clarify what happens when a DSA can't be established because the initiator (once received the DSAA) fails to check the conditions listed in 3.1. Is is necessary to issue a NAK containing a DIAMETER_NO_DSA_ESTABLISHED? Or it sufficient to issue such result code only when another CMS-related AVP is inserted in subsequent messages? It's important to take into account that the following paragraph (from 6.1) states that a Diameter message must be issued after any failed verification of a digital signature: If the signature cannot be verified correctly, a response with the Result-Code AVP set to DIAMETER_INVALID_AUTH MUST be returned. e) Clarify the meaning of the following paragraph in 6.1 If a receiver detects that the contents of the CMS-Signed-Data AVP are invalid, it SHOULD return the new Result-Code AVP value defined in section 7.0. Which contents are we talking about (maybe 9 above)? Because, if it isn't the condition, a DIAMETER_INVALID... should be the appropriate result code. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Wed Sep 5 14:03: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 OAA13330 for ; Wed, 5 Sep 2001 14:03:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0808191205; Wed, 5 Sep 2001 14:04:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4CD99122B; Wed, 5 Sep 2001 14:04: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 BA68F91205 for ; Wed, 5 Sep 2001 14:04:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94B175DDA6; Wed, 5 Sep 2001 14:04:48 -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 C44955DD9D for ; Wed, 5 Sep 2001 14:04:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA46624; Wed, 5 Sep 2001 10:56:09 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 5 Sep 2001 10:56:09 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Randy Bush , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement In-Reply-To: <20010905091335.B10271@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > What I find interesting, though, is that most of this was in the framework document, > which the WG decides to abandon some time ago. Now we need to pull some of the > text from the framework into the base protocol. > We abandoned it with the understanding that the appropriate material would find its way into base. From owner-aaa-wg@merit.edu Wed Sep 5 14:18: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 OAA14112 for ; Wed, 5 Sep 2001 14:18:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8FC59122B; Wed, 5 Sep 2001 14:19:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74DCB9126C; Wed, 5 Sep 2001 14:19: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 6E94E9122B for ; Wed, 5 Sep 2001 14:19:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4ED475DD92; Wed, 5 Sep 2001 14:19:02 -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 A0FE95DDDA for ; Wed, 5 Sep 2001 14:19:01 -0400 (EDT) Received: from gwzpc (sjc-vpn2-318.cisco.com [10.21.113.62]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA22607; Wed, 5 Sep 2001 11:17:55 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Pat Calhoun" Cc: "Randy Bush" , Subject: RE: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement Date: Wed, 5 Sep 2001 11:16:38 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > What I find interesting, though, is that most of this was in > the framework document, > > which the WG decides to abandon some time ago. Now we need to > pull some of the > > text from the framework into the base protocol. > > > > We abandoned it with the understanding that the appropriate material would > find its way into base. The good news is that only one more author (Ping Pan) needs to be added to the base ;-) > > From owner-aaa-wg@merit.edu Wed Sep 5 14:23: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 OAA14520 for ; Wed, 5 Sep 2001 14:23:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3924B9126C; Wed, 5 Sep 2001 14:24:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00CC391277; Wed, 5 Sep 2001 14:24: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 DF2159126C for ; Wed, 5 Sep 2001 14:24:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B83965DDA6; Wed, 5 Sep 2001 14:24:54 -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 969285DD9D for ; Wed, 5 Sep 2001 14:24:54 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ehM0-0000yJ-00; Wed, 05 Sep 2001 11:24:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Glen Zorn" Cc: "Bernard Aboba" , "Pat Calhoun" , Subject: RE: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement References: Message-Id: Date: Wed, 05 Sep 2001 11:24:48 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The good news is that only one more author (Ping Pan) needs to be added to > the base ;-) imiho, it is time to have an editor on the front page and a section in the body for contributor credits. the iesg is starting to push back on the massive author list, which is especially prevalent in some sub-ip wgs. randy From owner-aaa-wg@merit.edu Wed Sep 5 14:35: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 OAA15704 for ; Wed, 5 Sep 2001 14:35:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F7D891277; Wed, 5 Sep 2001 14:36:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6152D91278; Wed, 5 Sep 2001 14:36: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 5B33791277 for ; Wed, 5 Sep 2001 14:36:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B7295DD9D; Wed, 5 Sep 2001 14:36:49 -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 871775DD97 for ; Wed, 5 Sep 2001 14:36:48 -0400 (EDT) Received: from gwzpc (sjc-vpn2-318.cisco.com [10.21.113.62]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA22922; Wed, 5 Sep 2001 11:35:43 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Randy Bush" Cc: "Bernard Aboba" , "Pat Calhoun" , Subject: RE: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement Date: Wed, 5 Sep 2001 11:34:04 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush [mailto:randy@psg.com] writes: > > The good news is that only one more author (Ping Pan) needs to > be added to > > the base ;-) > > imiho, it is time to have an editor on the front page and a section in the > body for contributor credits. the iesg is starting to push back on the > massive author list, which is especially prevalent in some sub-ip wgs. Well, this author list isn't all that massive. Just out of curiosity, though, doesn't the IESG have better things to do (say, reviewing technical content ;-) than worrying about the size of author lists? I'm not, by the way, referring to either of _our_ esteemed ADs; however, I personally know of at least one I-D which passed WG Last Call and languished for at least 4 months before the relevant AD even _looked_ at it... > > randy > From owner-aaa-wg@merit.edu Wed Sep 5 14:54: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 OAA17495 for ; Wed, 5 Sep 2001 14:54:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 014EA91278; Wed, 5 Sep 2001 14:55:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF2909127B; Wed, 5 Sep 2001 14: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 9898791278 for ; Wed, 5 Sep 2001 14:55:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D0405DDA8; Wed, 5 Sep 2001 14:55:15 -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 D35665DD97 for ; Wed, 5 Sep 2001 14:55:14 -0400 (EDT) Received: (qmail 10896 invoked by uid 500); 5 Sep 2001 18:42:22 -0000 Date: Wed, 5 Sep 2001 11:42:22 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , Randy Bush , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue]: Diameter -07 introduction needs improvement Message-ID: <20010905114221.A10877@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , Randy Bush , aaa-wg@merit.edu References: <20010905091335.B10271@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, Sep 05, 2001 at 10:56:09AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Sep 05, 2001 at 10:56:09AM -0700, Bernard Aboba wrote: > > What I find interesting, though, is that most of this was in the framework document, > > which the WG decides to abandon some time ago. Now we need to pull some of the > > text from the framework into the base protocol. > > > > We abandoned it with the understanding that the appropriate material would > find its way into base. So perhaps the issue was the "appropriate material" was never really defined. In any case, onto work... PatC From owner-aaa-wg@merit.edu Wed Sep 5 23:01: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 XAA29160 for ; Wed, 5 Sep 2001 23:01:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B077A9129E; Wed, 5 Sep 2001 23:02:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A16B9129F; Wed, 5 Sep 2001 23:02: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 7AD539129E for ; Wed, 5 Sep 2001 23:02:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77AC45DDBA; Wed, 5 Sep 2001 23:02:20 -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 B52B55DD92 for ; Wed, 5 Sep 2001 23:02:19 -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 f8630o911451 for ; Thu, 6 Sep 2001 06:00:50 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Sep 2001 06:02:18 +0300 Received: by esebh01nok.ntc.nokia.com with Internet Mail Service (5.5.2652.78) id ; Thu, 6 Sep 2001 06:02:18 +0300 Message-ID: From: Yanqun.Le@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] the use of Disconnect-Peer-Request Date: Thu, 6 Sep 2001 05:50: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 Submitter name: Yanqun Le Submitter email address: yanqun.e@nokia.com Date first submitted: 2001-09-06 Reference: Document: Base-07 Comment type: T Priority: 2 Section: 5.4 and 5.6 Rationale/Explanation of issue: 1) We are puzzled of the use of Disconnect-Peer-Request. It doesn't appear in Peer FSM. Does the event of R-Peer-Disc appeared in Peer FSM have the same meaning to it? 2) If a peer sends out DPR, which peer state should it change to? If it can't receive DPA, what shall it do? 3) I infer from draft 07, a receiver of DPR should not periodically attempt to reconnect to the sender of DPR. Then only if the sender of DPR will reconnect to another peer after it is going to do so? Best regards Yanqun Le From owner-aaa-wg@merit.edu Thu Sep 6 02:04: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 CAA15022 for ; Thu, 6 Sep 2001 02:04:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF1739121B; Thu, 6 Sep 2001 02:04:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76915912A6; Thu, 6 Sep 2001 02:04: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 29CEA9121B for ; Thu, 6 Sep 2001 02:04:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 056A75DDA1; Thu, 6 Sep 2001 02:04:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 3ACA25DD94 for ; Thu, 6 Sep 2001 02:04:34 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8668eG13424 for ; Thu, 6 Sep 2001 09:08:41 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Sep 2001 09:04:32 +0300 Received: by esebh01nok.ntc.nokia.com with Internet Mail Service (5.5.2652.78) id ; Thu, 6 Sep 2001 09:04:32 +0300 Message-ID: From: Yanqun.Le@nokia.com To: aaa-wg@merit.edu Cc: chunan.li@nokia.com, qing.roger.liu@nokia.com, Dongfeng.Jing@nokia.com Subject: [AAA-WG]: [issue] problems with Watch Dog Date: Thu, 6 Sep 2001 08:55:21 +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: Yanqun Le Submitter email address: yanqun.e@nokia.com Date first submitted: 2001-09-06 Reference: Document: Base-07 Comment type: T Priority: 2 Section: 5.5.3 and 5.1 Rationale/Explanation of issue: In section 5.1, it said: three watchdog messages are exchanged with accepted round trip times, and the connection to the peer is considered stablized. The Problem is: In SUSPECT state, if a DWA is received, which action should it take? 1) send another DWR, then which timer should it start? Tw or Tr/Tw? which state should it change to? Still remain in SUSPECT and waiting for sending another DWR or change to WAIT_DWA? 2) just change to OKAY? I think draft 07 doesn't state clearly on it. Looking forwad to your suggestions. Best regards Yanqun Le From owner-aaa-wg@merit.edu Thu Sep 6 04:41: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 EAA17703 for ; Thu, 6 Sep 2001 04:41:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6DFE912A9; Thu, 6 Sep 2001 04:42:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82862912AA; Thu, 6 Sep 2001 04:42: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 2E3A3912A9 for ; Thu, 6 Sep 2001 04:42:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8DC7D5DDA1; Thu, 6 Sep 2001 04:42:25 -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 730125DD92 for ; Thu, 6 Sep 2001 04:42:24 -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 f868gHK21306 for ; Thu, 6 Sep 2001 10:42:18 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA00202; Thu, 6 Sep 2001 10:42:10 +0200 (MET DST) Message-ID: <3B97374A.50488C44@rioja.ericsson.se> Date: Thu, 06 Sep 2001 10:43:54 +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: [AAA-WG]: [issue] Digital encryption + signature in CMS-Sec Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-06 Reference: Document: CMS-02 Comment type: T Priority: 1 Section: 6.1, 6.2 Rationale/Explanation of issue: When a set of AVPs is required also as encrypted and digitally signed, the draft states (according to S/MIME RFC) that the encryption must be done first. That's is coherent but can, in some occasions, be confused for an implementation. I'll try to explain it. Let's imagine that the Expected-Encrypted-AVP states that AVPs A and B must be encrypted. So does the Expected-Signed-AVP (including maybe another AVP, C). The implementation will first create a CMS-Encrypted-AVP containing A and B, that are subsequently dropped. When the signing process begin, there's no A and B AVPs, so that it might sign only C. In order to avoid this misbehaviour, I suggest stating explicitly that when encryption and digital signature are required, it has to be treated as an atomic operation, so that the implementation must "remember" that A and B AVPs are also inside an encrypted AVP. Requested change: Add some paragraphs after (6.1): When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first. The resulting CMS object MUST then be MIME encoded producing an application/pkcs7-mime MIME type which is then used as the content of the EnvelopedData. This means that signing is "outside" encryption. It might be something like the following: Implementations MUST treat this process as an atomic process, so that one encrypted the set of AVPs required as so, the implementation MUST use the CMS-Encrypted-Data AVP (as well as any additional AVP required as only signed) as the input to the signing process (even if the CMS-Encrypted-Data AVP was not required as digitally signed). Where an implementation wants to receive a set of AVPs both encrypted and signed it MIGHT use a work around consisting of requiring the set of AVPs as encrypted and CMS-Encrypted-Data AVP as digitally signed. Where there are more AVPs required as encrypted than digitally signed, a CMS-Encrypted-Data AVP MUST be created including only the AVPs that has also to be digitally signed. This AVP will be the input to the signing process. The rest of AVPs required as encrypted MUST be done as many as desired additional CMS-Encrypted-Data AVPs. Replace the next paragraph in 6.2: When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first. with When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first, according to the guidelines stated in 6.1. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Thu Sep 6 05:09: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 FAA18145 for ; Thu, 6 Sep 2001 05:09:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68AA79121E; Thu, 6 Sep 2001 05:11:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CC029127C; Thu, 6 Sep 2001 05:11: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 243F19121E for ; Thu, 6 Sep 2001 05:11:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA78B5DDA1; Thu, 6 Sep 2001 05:11:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ness.sophia.sema.fr (unknown [194.206.39.106]) by segue.merit.edu (Postfix) with ESMTP id 7467C5DD92 for ; Thu, 6 Sep 2001 05:11:06 -0400 (EDT) Received: from sopmes01.sophia.sema.fr (sopmes01.sophia.sema.fr) by ness.sophia.sema.fr (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Sep 2001 11:10:36 +0200 Received: from palmier.sema.fr (palmier.sophia.sema.fr [172.23.126.156]) by sopmes01.sophia.sema.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SJ9HXNYX; Thu, 6 Sep 2001 11:23:45 +0200 Message-Id: <5.1.0.14.0.20010906110719.00a74b90@mailserver> X-Sender: azh@mailserver X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Sep 2001 11:10:36 +0200 To: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente From: Alain Zahm Subject: Re: [AAA-WG]: [issue] Digital encryption + signature in CMS-Sec Cc: aaa-wg@merit.edu In-Reply-To: <3B97374A.50488C44@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA18145 Well what SMIME is stating on signed/encrypted content is given below (FromR FC2311) ----------------------------- 3.5 Signing and Encrypting To achieve signing and enveloping, any of the signed-only and encrypted-only formats may be nested. This is allowed because the above formats are all MIME entities, and because they all secure MIME entities.A n S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.I t is possible to either sign a message first, or to envelope the messagef irst. It is up to the implementor and the user to choose. When signing first, the signatories are then securely obscured by the enveloping. Whene nveloping first the signatories are exposed, but it is possible to verifys ignatures without removing the enveloping. This may be useful in an environment were automatic signature verification is desired, as no privatek ey material is required to verify a signature. ------------------------------- This being said it is better practice to sign then encrypt. What needs tob e authenticated is the given values not the encryption result. If you wantt o support non-repudiation, then you MUST sign first. Regards Alain Zahm At 10:43 06/09/01 +0200, Miguel Ángel Monjas Llorente wrote: >Submitter name: Miguel A. Monjas >Submitter email address: ecemaml@rioja.es.eu.ericsson.se >Date first submitted: 2001-09-06 >Reference: >Document: CMS-02 >Comment type: T >Priority: 1 >Section: 6.1, 6.2 >Rationale/Explanation of issue: > >When a set of AVPs is required also as encrypted and digitally signed, >the draft states (according to S/MIME RFC) that the encryption must be >done first. That's is coherent but can, in some occasions, be confused >for an implementation. > >I'll try to explain it. Let's imagine that the Expected-Encrypted-AVP >states that AVPs A and B must be encrypted. So does the >Expected-Signed-AVP (including maybe another AVP, C). The >implementation will first create a CMS-Encrypted-AVP containing A and >B, that are subsequently dropped. When the signing process begin, >there's no A and B AVPs, so that it might sign only C. In order to >avoid this misbehaviour, I suggest stating explicitly that when >encryption and digital signature are required, it has to be treated as >an atomic operation, so that the implementation must "remember" that A >and B AVPs are also inside an encrypted AVP. > >Requested change: > >Add some paragraphs after (6.1): > > When AVPs are to be both encrypted and signed, the >CMS-Encrypted-Data > AVP MUST be created first. The resulting CMS object MUST then be >MIME > encoded producing an application/pkcs7-mime MIME type which is then > used as the content of the EnvelopedData. This means that signing >is > "outside" encryption. > >It might be something like the following: > > Implementations MUST treat this process as an atomic process, so >that > one encrypted the set of AVPs required as so, the implementation >MUST > use the CMS-Encrypted-Data AVP (as well as any additional AVP >required > as only signed) as the input to the signing process (even if the > CMS-Encrypted-Data AVP was not required as digitally signed). > > Where an implementation wants to receive a set of AVPs both >encrypted > and signed it MIGHT use a work around consisting of requiring the >set > of AVPs as encrypted and CMS-Encrypted-Data AVP as digitally >signed. > > Where there are more AVPs required as encrypted than digitally >signed, > a CMS-Encrypted-Data AVP MUST be created including only the AVPs >that > has also to be digitally signed. This AVP will be the input to the > signing process. The rest of AVPs required as encrypted MUST be >done > as many as desired additional CMS-Encrypted-Data AVPs. > >Replace the next paragraph in 6.2: > > When AVPs are to be both encrypted and signed, the >CMS-Encrypted-Data > AVP MUST be created first. > >with > > When AVPs are to be both encrypted and signed, the >CMS-Encrypted-Data > AVP MUST be created first, according to the guidelines stated in >6.1. > > >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 > Retama 1, 4th. 28045 Madrid - SPAIN - ********************************************************************** This footnote confirms that this email message has been swept for the presence of computer viruses. SchlumbergerSema - Sophia Antipolis NetworkTeam.Sophia@sema.fr ********************************************************************** From owner-aaa-wg@merit.edu Thu Sep 6 06:39: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 GAA19245 for ; Thu, 6 Sep 2001 06:39:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95519912AC; Thu, 6 Sep 2001 06:40:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62F12912AE; Thu, 6 Sep 2001 06:40: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 244B5912AC for ; Thu, 6 Sep 2001 06:40:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F26CC5DD92; Thu, 6 Sep 2001 06:40:55 -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 0A4DF5DD8F for ; Thu, 6 Sep 2001 06:40:55 -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.10.1/WIREfire-1.3) with ESMTP id f86Aerv17446 for ; Thu, 6 Sep 2001 12:40:53 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA10034; Thu, 6 Sep 2001 12:40:50 +0200 (MET DST) Message-ID: <3B97531B.AD0560B6@rioja.ericsson.se> Date: Thu, 06 Sep 2001 12:42: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: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Digital encryption + signature in CMS-Sec References: <5.1.0.14.0.20010906110719.00a74b90@mailserver> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Alain Zahm wrote: > > Well what SMIME is stating on signed/encrypted content is given below (From > RFC2311) > > ----------------------------- > 3.5 Signing and Encrypting > To achieve signing and enveloping, any of the signed-only and > encrypted-only formats may be nested. This is allowed because the above > formats are all MIME entities, and because they all secure MIME entities. > An S/MIME implementation MUST be able to receive and process arbitrarily > nested S/MIME within reasonable resource limits of the recipient computer. > It is possible to either sign a message first, or to envelope the message > first. It is up to the implementor and the user to choose. When signing > first, the signatories are then securely obscured by the enveloping. When > enveloping first the signatories are exposed, but it is possible to verify > signatures without removing the enveloping. This may be useful in an > environment were automatic signature verification is desired, as no private > key material is required to verify a signature. > ------------------------------- > > This being said it is better practice to sign then encrypt. No, I don't think so. It's only said that one process may be useful in one environment. > What needs to > be authenticated is the given values not the encryption result. > If you want > to support non-repudiation, then you MUST sign first. Well, I see that a previous enveloping doesn't guarantee "direct" non-repudiation of the sender (it's necessary an extra step to decrypt the EnvelopedData object, but it doesn't matter so that the recipient of the message in on the list of receivers in the RecipientInfo of the CMS EnvelopedData, so it's able to decrypt the content). What I guess is that this mechanism is lighter, since the receiver must verify first that it's on the recipients list (by inspecting the CMS-Encrypted-Data AVP), next check the digital signature and finally decrypt the encrypted data. Otherwise, a previous decryption would be always necessary before verifying that the digital signature can be checked (certificates available, naming compliance and so on). Of course that this is just my interpretation. Maybe Stephen Farrell could enlighten us :-) Regards -- 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 Thu Sep 6 06:45: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 GAA19525 for ; Thu, 6 Sep 2001 06:45:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C08C8912AE; Thu, 6 Sep 2001 06:46:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C3B7912AF; Thu, 6 Sep 2001 06:46: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 8B327912AE for ; Thu, 6 Sep 2001 06:46:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A9A05DDA5; Thu, 6 Sep 2001 06:46:22 -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 7791A5DD9A for ; Thu, 6 Sep 2001 06:46:21 -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.10.1/WIREfire-1.3) with ESMTP id f86AkJv21814 for ; Thu, 6 Sep 2001 12:46:20 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA10585; Thu, 6 Sep 2001 12:46:17 +0200 (MET DST) Message-ID: <3B975462.747B101A@rioja.ericsson.se> Date: Thu, 06 Sep 2001 12:48:02 +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] Digital encryption + signature in CMS-Sec References: <3B97374A.50488C44@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 Just a clarification Miguel Ángel Monjas Llorente wrote: > > Submitter name: Miguel A. Monjas > Submitter email address: ecemaml@rioja.es.eu.ericsson.se > Date first submitted: 2001-09-06 > Reference: > Document: CMS-02 > Comment type: T > Priority: 1 > Section: 6.1, 6.2 > Rationale/Explanation of issue: > > When a set of AVPs is required also as encrypted and digitally signed, > the draft states (according to S/MIME RFC) that the encryption must be > done first. That's is coherent but can, in some occasions, be confused > for an implementation. > > I'll try to explain it. Let's imagine that the Expected-Encrypted-AVP > states that AVPs A and B must be encrypted. So does the > Expected-Signed-AVP (including maybe another AVP, C). The > implementation will first create a CMS-Encrypted-AVP containing A and > B, that are subsequently dropped. When the signing process begin, > there's no A and B AVPs, so that it might sign only C. In order to > avoid this misbehaviour, I suggest stating explicitly that when > encryption and digital signature are required, it has to be treated as > an atomic operation, so that the implementation must "remember" that A > and B AVPs are also inside an encrypted AVP. > > Requested change: > > Add some paragraphs after (6.1): > > When AVPs are to be both encrypted and signed, the > CMS-Encrypted-Data AVP MUST be created first. The resulting CMS > object MUST then be MIME encoded producing an > application/pkcs7-mime MIME type which is then used as the > content of the EnvelopedData. This means that signing is > "outside" encryption. > > It might be something like the following: > > Implementations MUST treat this process as an atomic process, so > that one encrypted the set of AVPs required as so, the > implementation MUST use the CMS-Encrypted-Data AVP (as well as > any additional AVP required as only signed) as the input to the > signing process (even if the CMS-Encrypted-Data AVP was not > required as digitally signed). Since the Diameter message will contain, at least, one CMS-Encrypted-Data AVP and a CMS-Signed-Data AVP with a digital signature on it, the convention about the 'P' bit MUST be followed. > Where an implementation wants to receive a set of AVPs both > encrypted and signed it MIGHT use a work around consisting of > requiring the set of AVPs as encrypted and CMS-Encrypted-Data > AVP as digitally signed. > > Where there are more AVPs required as encrypted than digitally > signed, a CMS-Encrypted-Data AVP MUST be created including only > the AVPs that has also to be digitally signed. This AVP will be > the input to the signing process. The rest of AVPs required as > encrypted MUST be done as many as desired additional > CMS-Encrypted-Data AVPs. > > Replace the next paragraph in 6.2: > > When AVPs are to be both encrypted and signed, the > CMS-Encrypted-Data > AVP MUST be created first. > > with > > When AVPs are to be both encrypted and signed, the > CMS-Encrypted-Data > AVP MUST be created first, according to the guidelines stated in > 6.1. -- 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 Thu Sep 6 08: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 IAA23527 for ; Thu, 6 Sep 2001 08:34:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79210912B2; Thu, 6 Sep 2001 08:35:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48D79912B3; Thu, 6 Sep 2001 08:35: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 1C64D912B2 for ; Thu, 6 Sep 2001 08:35:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E65185DDA6; Thu, 6 Sep 2001 08:35:38 -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 ADD9A5DDA1 for ; Thu, 6 Sep 2001 08:35:33 -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.10.1/WIREfire-1.3) with ESMTP id f86CZWv22354 for ; Thu, 6 Sep 2001 14:35:32 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA18508; Thu, 6 Sep 2001 14:35:29 +0200 (MET DST) Message-ID: <3B976DFB.51659365@rioja.ericsson.se> Date: Thu, 06 Sep 2001 14:37:15 +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: [AAA-WG]: [issue] Expiration of DSAs on behalf of a client Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-06 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00246.html Document: CMS-02 Comment type: T Priority: S Section: 1.2, 4.4, 6.14 Rationale/Explanation of issue: When a CMS proxy establishes a DSA on behalf of a client, it uses its own parameters (or maybe some of the provided by the client in a previous DSA attempt). Once established, it issues a PDSAA to inform the client about the status of the DSA. But, what happens once the DSA has expired? It may receive a message of the same client with AVPs that it (the proxy) would have protected while the DSA existed. Does it have to try to establish a new DSA (transparently for the client)? Or has to warn the client issuing a Diameter message with an appropriate Result-Code (so that the client issues a PDSAR again)? My idea is that the proxy should include the TTL of its established DSA in the PDSAA in order to inform the client when it has to reissue a PDSAR to make the proxy establish a new DSA. Requested change: Add the following text to the proposed text for issue 136: The PDSAA MUST contain the TTL setting agreed by the proxy agent for its DSA. This information will allow the access device to re-issue a PDSAR when the proxy's DSA has expired. Change the ABNF grammar of the PDSAA AVP (4.4), being the result: ::= < Diameter-Header: 305, PXY > { Result-Code } { Origin-Host } { Origin-Realm } { Auth-Application-Id } { DSA-TTL } [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] Add the followig text to the description of a DSA-TTL AVP in 6.14: A DSA-TTL AVP MUST also be included in the PDSAA in order to provide information about the lenght of the DSA established by the proxy on behalf of the access device. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Thu Sep 6 09:43: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 JAA26772 for ; Thu, 6 Sep 2001 09:43:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB5D5912B4; Thu, 6 Sep 2001 09:44:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6FF4912B5; Thu, 6 Sep 2001 09:44: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 929E7912B4 for ; Thu, 6 Sep 2001 09:44:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D78C5DDA8; Thu, 6 Sep 2001 09:44:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id C22B85DDA1 for ; Thu, 6 Sep 2001 09:44:08 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f86Df9g03760 for ; Thu, 6 Sep 2001 09:41:09 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from (mailman [172.21.24.8]) by ahab via smap (V2.1) id xma003758; Thu, 6 Sep 01 09:40:56 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f86Dhnf00238 for ; Thu, 6 Sep 2001 09:43:49 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma000148; Thu, 6 Sep 01 09:42:58 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Sep 2001 09:42:50 -0400 Message-ID: From: Yiwen Jiang To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: [issue] Ambiguity on Destination-Host AVP in Answer messages Date: Thu, 6 Sep 2001 09:42:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Dirk Poertner, Yiwen Jiang Submitter email address: Dirk.Poertner@icn.siemens.de, yiwen.jiang@tic.siemens.ca Date first submitted: 2001-9-6 Reference: Document: Base-07, MobileIP-07, NASREQ-07, CMS-02 Comment type: E Priority: 2 Section: Throughout Rationale/Explanation of issue: There are inconsistencies/ambiguities regarding Destination-Host AVP throughout the document. In older versions (< -05), it actually said that Destination-Host MUST be present in answers. Is this area missed in the cleanup process, or?? For example, in Base-07: In Section 6.1, " - a request that is not proxiable (such as CER) MUST NOT contain either Destination-Realm or Destination-Host AVPs." But the ABNF format of CER and CEA listed the Destination-Host as optional. In Section 6.2, " - The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message." But the ABNF formats of DPA and DWA listed the Destination-Host as mandatory. In the three application latest versions, Destination-Host AVP is included in various Answer messages. Requested change: Cleanup these areas to make it consistent. Cheers, Yiwen --- Yiwen Jiang Mobile IP Networking Email: Yiwen.Jiang@tic.siemens.ca Phone: (613)271-7710 Telecom Innovation Centre 505 March Road Kanata, Ontario, Canada K2K 2M5 From owner-aaa-wg@merit.edu Thu Sep 6 10:32: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 KAA28774 for ; Thu, 6 Sep 2001 10:32:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D639912B8; Thu, 6 Sep 2001 10:33:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED8E1912B9; Thu, 6 Sep 2001 10:33: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 041DD912B7 for ; Thu, 6 Sep 2001 10:32:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C67235DDB7; Thu, 6 Sep 2001 10:32:32 -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 4597F5DD95 for ; Thu, 6 Sep 2001 10:32:27 -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 f86EHEK19165 for ; Thu, 6 Sep 2001 16:17:15 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA26520; Thu, 6 Sep 2001 16:17:11 +0200 (MET DST) Message-ID: <3B9785D1.80F29D7@rioja.ericsson.se> Date: Thu, 06 Sep 2001 16:18:57 +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: [AAA-WG]: [issue] CMS-Cert in AVP occurrence table Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-06 Reference: Document: CMS-02 Comment type: E-T Priority: S Section: 8.0 Rationale/Explanation of issue: a) When issuing a DSA-Request, a digital signature (by means of a CMS-Signed-Data AVP) may be included. If so, an appropriate CMS-Cert must be included (unless the certificate is included within the SignedData estructure). b) In a DSA-Answer, I understand that the digital signature can be verified by means of the certificates in the AAA-Server-Certs, so that a CMS-Cert isn't necessary Requested change: a) Replace the row in the AVP occurrence table regarding CMS-Cert +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | DSAR| DSAA| PDSR| PDSA| ------------------------------|-----+-----+-----+-----+ CMS-Cert | 0-1 | 0 | 0 | 0 | b) Clarify if a CMS-Cert is necessary in a DSAA or if it's superseded by a certificate present in AAA-Server-Cert BTW, shouldn't be present Key-Hash AVP in the AVP occurrence table? 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Thu Sep 6 10:32: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 KAA28790 for ; Thu, 6 Sep 2001 10:32:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 80ED7912BA; Thu, 6 Sep 2001 10:33:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 365FF912B7; Thu, 6 Sep 2001 10:33: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 F285D912B8 for ; Thu, 6 Sep 2001 10:32:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C44AF5DDBA; Thu, 6 Sep 2001 10:32:57 -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 3B78C5DDB7 for ; Thu, 6 Sep 2001 10:32:52 -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.10.1/WIREfire-1.3) with ESMTP id f86EWav19509 for ; Thu, 6 Sep 2001 16:32:50 +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 f86EWab06283 for ; Thu, 6 Sep 2001 17:32:36 +0300 (EET DST) Message-ID: <3B978904.1975472A@lmf.ericsson.se> Date: Thu, 06 Sep 2001 17:32:36 +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: aaa-wg@merit.edu Subject: [AAA-WG]: Error replies to requests with no session id References: <3B964F81.C0B28BB5@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 Error replies to requests with no session id Submitter name: Jari Arkko Submitter email address: jari.arkko@ericsson.fi Date first submitted: September 6, 2001 Reference: - Document:base Comment type: T Priority: 1 Section: 7.2 Rationale/Explanation of issue: Diameter has a couple of messages such as Device-Watchdog- Request that do not include a session id in the request. Yet section 7.2 requires that error replies to request have the session id. How can we make an error reply to Device-Watchdog-Request, for instance? And section 6.2 then talks about answers, and says that Session-Id must be copied where it exists. Perhaps this is the right approach, but should the BNF in 7.2 be changed then? Other messages without Session-Id are Capabilities- Exchange-Req and Disconnect-Peer-Request. Requested change: Perhaps the BNF in 7.2 should be changed, or at least words added. I'm not sure how to change the BNF, given that we can't indicate a fixed position AVP that is optional... If added words is enough, then put in at the end of 7.2: "Note also that the Session-Id should be present if and only if the corresponding request contained it." From owner-aaa-wg@merit.edu Thu Sep 6 10:55: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 KAA29514 for ; Thu, 6 Sep 2001 10:55:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1CA1912B7; Thu, 6 Sep 2001 10:56:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1714912B9; Thu, 6 Sep 2001 10: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 8EDBD912B7 for ; Thu, 6 Sep 2001 10:56:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6613C5DD95; Thu, 6 Sep 2001 10:56: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 9970E5DD94 for ; Thu, 6 Sep 2001 10:56:09 -0400 (EDT) Received: (qmail 14386 invoked by uid 500); 6 Sep 2001 14:43:15 -0000 Date: Thu, 6 Sep 2001 07:43:15 -0700 From: Pat Calhoun To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 128: duplicate packet detection failure case Message-ID: <20010906074315.C14344@charizard.diameter.org> Mail-Followup-To: john.loughney@nokia.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB69@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: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB69@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Tue, Sep 04, 2001 at 05:59:09PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Sep 04, 2001 at 05:59:09PM +0300, john.loughney@nokia.com wrote: > Hi Pat, > > Sorry for the delay in responding - I have been quite > busy - I have another document that just finished > last call. I was a bit rushed when I submitted > the issue for Diameter, it had actually 2 different parts that > are easiest to consider separately: > > 1) Marking of the possibly duplicated messages. but what's the point? How do you know whether the first copy was received? What about the second copy when sending the third? In any case, duplicate checking beyond the 'D' bit is necessary. > 2) Removal of duplicate messages. > > Step 1 is a minimal functionality for enabling the > duplicate message checking to be efficient as possible. > The Diameter client knows (after hearing no response) > that it is sending the message a 2nd (or 3rd etc.) > time (either to the original peer node or an alternate node). > > Enhancing the efficiency of checking is the main > benefit but it may improve a bit the reliability too. > It also improves the reliability somewhat since the > Diameter client has in End-to-End Identifier only 12 > low order bits of the local time when booting. That is > 4096 seconds which is a bit over a hour. I'd argue that if a message takes a bit over an hour to make it to the server, then the response is moot (and something in the network is broken). > > This means that with very bad luck, a Diameter client > that goes down and wakes up after 4096 seconds MAY send > a message with the same End-to-End Identifier, taking from > non-volatile memory an earlier sent (but not yet answered) > pending message and produces a duplicate. Unless, it has > this capability to mark with 'D' bit that the pending message > now resent may be a duplicate.) right, but now you have the same problem, right? If a client reboots twice, exactly 4096 seconds apart, then the IDs will be similar, and the 'D' bit becomes irrelevant since once doesn't really know if it is for the first hour, the second hour, etc. So I am convinced that the protocol is fine as-is, and duplicate checks is a little more complicated than just setting a 'D' bit in a header. > > Step 2 is a solution where in addition to the minimal > solution of marking the possibly duplicated packets, the > duplicates are also removed form the network as quickly > as possible, with minimal amount of double-checking. > > This mail presents only a simplified way of step 1, as it > can be used also as a stand-alone feature (just an additional > flag bit in the Diameter header). Please review the following > description, it would help the Diameter Server to avoid > the obligation to do a mandatory cross check every single > received request message - which should save on processing. > > The needed small changes for the step 1) > (marking of possibly duplicated packets) to the > draft-ietf-aaa-diameter-07.txt are the following: > > > 3.0 Diameter Header > > ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E r r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > would be: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E D r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > and > > E(rror) - If set, the message contains a protocol error, > and the message will not conform to the ABNF > described for this command. Messages with the > 'E' bit set is commonly referred to as an error > message. This bit MUST NOT be set in request > messages. See section 7.2. > r(eserved) - this flag bit is reserved for future use, and > MUST be set to zero. > > would get one new flag bit 'D': > > E(rror) - If set, the message contains a protocol error, > and the message will not conform to the ABNF > described for this command. Messages with the > 'E' bit set is commonly referred to as an error > message. This bit MUST NOT be set in request > messages. See section 7.2. > (possibly) D(uplicated) > - If set, the message is possibly a duplicate, > and must be later checked by a recipient node > if it really is a duplicate. If sending a > message for first time, this bit MUST be cleared. > This bit MUST NOT be set if an answer message > (about e.g. a protocol error) has been got for > an earlier similar message, it is used only > in cases where no answer has been got from the > primary agent for a message and the message is > sent again (e.g. due to failover, to an > alternate agent). > r(eserved) - this flag bit is reserved for future use, and > MUST be set to zero. > > > In: > > 5.5.4 Failover/Failback Procedures > > ... > It is important to note that multiple identical request or answer MAY > be received as a result of a failover. The End-to-End Identifier > field in the Diameter header along with the Origin-Host AVP MUST be > used to identify duplicate messages. > > the above paragraph would be amended as: > > It is important to note that multiple identical request or answer MAY > be received as a result of a failover. The possibly-Duplicated flag > MUST be set by the Diameter client node that performs failover, to > mark those packets that it had sent with no answer message coming from > the primary agent, and which it therefore forwards to an alternate > node. The final destination node of a message MUST check those > messages that have the 'D' bit set, if they can be identified as > actually duplicated messages. The intermediate nodes MAY check > the messages with the 'D' bit set, if they can be identified > as duplicate messages. The End-to-End Identifier field in the > Diameter header along with the Origin-Host AVP MUST be used to > identify duplicate messages among the marked possibly duplicated > messages. > > and in: > > 9.4 Fault Resilience > > ... > Diameter peers acting as clients MUST implement the use of failover > to guard against server failures and certain network failures. > Diameter peers acting as agents or related off-line processing > systems MUST detect duplicate accounting records caused by the > sending of same record to several servers and duplication of messages > in transit. This detection MUST be based on the inspection of the > Session-Id and Accounting-Record-Number AVP pairs. > > paragraph would get one sentence to its end: > > .... > Diameter peers acting as clients MUST implement the use of failover > to guard against server failures and certain network failures. > Diameter peers acting as agents or related off-line processing > systems MUST detect duplicate accounting records caused by the > sending of same record to several servers and duplication of messages > in transit. This detection MUST be based on the inspection of the > Session-Id and Accounting-Record-Number AVP pairs. The inspection > MUST be performed at least for such records that arrived to the > Diameter peer in messages having the 'D' bit set. well, I don't have a particular issue with the above proposed text, but do question it's need. I'm willing to listen to the WG on this one. PatC From owner-aaa-wg@merit.edu Thu Sep 6 10:57: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 KAA29570 for ; Thu, 6 Sep 2001 10:57:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E88A912B9; Thu, 6 Sep 2001 10:58:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40304912BB; Thu, 6 Sep 2001 10:58: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 3A4C6912B9 for ; Thu, 6 Sep 2001 10:58:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1561E5DD95; Thu, 6 Sep 2001 10:58:36 -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 B51B15DD94 for ; Thu, 6 Sep 2001 10:58:35 -0400 (EDT) Received: (qmail 14409 invoked by uid 500); 6 Sep 2001 14:45:42 -0000 Date: Thu, 6 Sep 2001 07:45:42 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'aaa-wg@merit.edu'" , "'pcalhoun@diameter.org'" Subject: [AAA-WG]: Re: failover question Message-ID: <20010906074541.D14344@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , "'aaa-wg@merit.edu'" , "'pcalhoun@diameter.org'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Tue, Sep 04, 2001 at 03:05:53PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk great question. I informed Dave, the current API editor, about this problem, and I believe that we agreed that he would add a callback on the app side that would be called to notify it of a disconnect (either locally generated, or known via the ASR). I believe that Dave is waiting for -08 before releasing the new API spec (but I can't speak for Dave, of course). PatC On Tue, Sep 04, 2001 at 03:05:53PM -0400, Yiwen Jiang wrote: > Hi Pat, > > I have a question regarding how failover is handled based on -07. I went to > the I-D, but couldn't find answer for this question. > > I understand that when a Diameter peer has detected that the connection with > its remote peer has been lost via the watchdog timer, it will failover to an > alternate host in its peer table. However, what happens when all the > alternate hosts are down, and the Diameter cannot forward any messages to > them? Or, if there is no other peers specified in the peer table? > > How would the base protocol notify its applications about this situation? > Or, what would be your recommendation on how the application detects such > situation, since the watchdog timers and such are all hidden from all > Diameter applications? > > Thanks. > > Cheers, > Yiwen > --- > Yiwen Jiang > Mobile IP Networking > Email: Yiwen.Jiang@tic.siemens.ca > Phone: (613)271-7710 > > Telecom Innovation Centre > 505 March Road > Kanata, Ontario, Canada > K2K 2M5 From owner-aaa-wg@merit.edu Thu Sep 6 11:09: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 LAA29880 for ; Thu, 6 Sep 2001 11:09:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B3D6912BE; Thu, 6 Sep 2001 11:10:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56D54912BF; Thu, 6 Sep 2001 11:10: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 46C1E912BE for ; Thu, 6 Sep 2001 11:10:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 173705DD95; Thu, 6 Sep 2001 11:10: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 845E65DD94 for ; Thu, 6 Sep 2001 11:10:20 -0400 (EDT) Received: (qmail 14471 invoked by uid 500); 6 Sep 2001 14:57:26 -0000 Date: Thu, 6 Sep 2001 07:57:26 -0700 From: Pat Calhoun To: Yanqun.Le@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] the use of Disconnect-Peer-Request Message-ID: <20010906075726.F14344@charizard.diameter.org> Mail-Followup-To: Yanqun.Le@nokia.com, 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 Yanqun.Le@nokia.com on Thu, Sep 06, 2001 at 05:50:52AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Yanqun, I had received your request on the mailing list, but seem to be having some issues in keeping up with work :( Here's a snapshot of a portion of the state machine that will appear in -08. If you believe that it is still incorrect, please let me know: R-Open Send-Message R-Snd-Message R-Open R-Rcv-Message Process R-Open WatchDog-Timer R-Snd-DWR R-Open R-Rcv-DWR Process-DWR, R-Open R-Snd-DWA R-Rcv-DWA Process-DWA R-Open R-Conn-CER R-Snd-CEA R-Open R-Reject Stop R-Snd-DPR Closing R-Rcv-DPR R-Snd-DPA, Closed R-Disc R-Peer-Disc R-Disc Closed R-Rcv-CER Error Closed R-Rcv-CEA 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-Disc Closed I-Rcv-DPR I-Snd-DPA, Closed I-Disc I-Peer-Disc I-Snd-DPR Closing I-Rcv-CER Error Closed I-Rcv-CEA Error Closed Thanks, PatC On Thu, Sep 06, 2001 at 05:50:52AM +0300, Yanqun.Le@nokia.com wrote: > Submitter name: Yanqun Le > Submitter email address: yanqun.e@nokia.com > Date first submitted: 2001-09-06 > Reference: > Document: Base-07 > Comment type: T > Priority: 2 > Section: 5.4 and 5.6 > Rationale/Explanation of issue: > > 1) We are puzzled of the use of Disconnect-Peer-Request. It doesn't appear > in Peer FSM. Does the event of R-Peer-Disc appeared in Peer FSM have the > same meaning to it? > > 2) If a peer sends out DPR, which peer state should it change to? If it > can't receive DPA, what shall it do? > > 3) I infer from draft 07, a receiver of DPR should not periodically attempt > to reconnect to the sender of DPR. Then only if the sender of DPR will > reconnect to another peer after it is going to do so? > > Best regards > Yanqun Le > From owner-aaa-wg@merit.edu Thu Sep 6 13:14: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 NAA02987 for ; Thu, 6 Sep 2001 13:14:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0DC6912AD; Thu, 6 Sep 2001 13:15:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7106E912C9; Thu, 6 Sep 2001 13:15: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 B473F912AD for ; Thu, 6 Sep 2001 13:14:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 99B915DD9F; Thu, 6 Sep 2001 13:14:59 -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 BE6165DD94 for ; Thu, 6 Sep 2001 13:14:58 -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.10.1/WIREfire-1.3) with ESMTP id f86HEuv24622 for ; Thu, 6 Sep 2001 19:14:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA08094; Thu, 6 Sep 2001 19:14:52 +0200 (MET DST) Message-ID: <3B97AF77.5F7001A7@rioja.ericsson.se> Date: Thu, 06 Sep 2001 19:16:39 +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: [AAA-WG]: [issue] DIAMETER_NO_COMMON_TRUST error Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-06 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00300.html Document: CMS-02 Comment type: T Priority: 2 Section: 1.2 Rationale/Explanation of issue: DIAMETER_NO_COMMON_TRUST error is introduced in section 7.2 of CMS-Sec. However, no explicit mention to it is done in the text. The definition is as follows: This error code is returned when a receiver receives a PDSR for which it has no common trust with the sender, which is required to establish the DSA. What seems to suggest that when a proxy receives a PDSAR from a client when there no exist "common trust" between them. In which situations is considered that there's common trust? Requested change: Add clarifying text 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 7 05:51: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 FAA05121 for ; Fri, 7 Sep 2001 05:51:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD1AD912E9; Fri, 7 Sep 2001 05:52:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEECE912EA; Fri, 7 Sep 2001 05:52: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 90155912E9 for ; Fri, 7 Sep 2001 05:52:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A3BC5DDB8; Fri, 7 Sep 2001 05:52: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 494045DDB7 for ; Fri, 7 Sep 2001 05:52: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.10.1/WIREfire-1.3) with ESMTP id f879q9v14598 for ; Fri, 7 Sep 2001 11:52:10 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA03574; Fri, 7 Sep 2001 11:52:06 +0200 (MET DST) Message-ID: <3B9898F9.87AC0074@rioja.ericsson.se> Date: Fri, 07 Sep 2001 11:52:57 +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: [AAA-WG]: [issue] Result-code with 'P' bit erroneous Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-07 Reference: Document: Base-07|CMS-02 Comment type: T Priority: S Section: 7.1.5|7.2, CMS-02 2.0 Rationale/Explanation of issue: There's no defined error code for situations in which a node receives an AVP with its 'P' bit set not being authorised to have its 'P' bit set Requested change: Add in the appropriate place (7.1.5 in Base-07 or 7.2 in CMS-02) a new error code: DIAMETER_INVALID_AVP_P_BIT 50xx The request contained an AVP with an invalid value in its 'P' bit. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. Add at the end of the section 2.0 in CMS-02: Diameter implementations MUST check whether AVPs with its 'P' bit set are allowed to use it. If not, an appropriate error message MUST be issued containing DIAMETER_INVALID_AVP_P_BIT result code. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 7 06:23: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 GAA05381 for ; Fri, 7 Sep 2001 06:23:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3161912EA; Fri, 7 Sep 2001 06:24:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8969912EB; Fri, 7 Sep 2001 06:24: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 9E634912EA for ; Fri, 7 Sep 2001 06:24:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F7EC5DDB7; Fri, 7 Sep 2001 06:24:04 -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 93D0A5DDB3 for ; Fri, 7 Sep 2001 06:24:03 -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 f87AO1K08977 for ; Fri, 7 Sep 2001 12:24:02 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA06951; Fri, 7 Sep 2001 12:23:53 +0200 (MET DST) Message-ID: <3B98A06C.B8FF448@rioja.ericsson.se> Date: Fri, 07 Sep 2001 12:24:44 +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: [AAA-WG]: [issue] Erroneous protection expectations Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-07 Reference: Document: CMS-02 Comment type: T Priority: S Section: 3.1, 6.9, 6.10, 7.2 Rationale/Explanation of issue: A Diameter node can request protection on certain AVPs that are not allowed (i.e. requested as signed an AVP which can't set its 'P' bit or as encrypted an AVP which can't be encrypted). No check nor error code has been defined. Requested change: Add the following paragraph to 3.1 (after the list of components of the DSAR): The destination node MUST check that the provided elements of the DSAR are valid. It MUST check, at least, that: - Its local policy allows it to provide a TTL compatible with the value provided in the request. - One of the CAs provided is suitable of being the top of a CA certificate chain that will assure the certificates of the servers in the Home Domain. If these conditions can not be verified, the destination node MUST return a DSAA with the Result-Code AVP set to DIAMETER_NO_DSA_ESTABLISHED. The destination node MUST also verify that the protection expectations are valid. If it is requested as signed an AVP which may not set its 'P' bit or as encrypted an AVP which may not be encrypted, the destination node MUST return a DSAA with the Result-Code AVP set to DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS. In the event.... Add the following paragraph to 6.9: If the AVP code specified in the Expected-Signed-AVP is not valid (that it, that AVP is not allowed to set its 'P' bit), the implementation MUST issue an error message containing the DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code Add the following paragraph to 6.10: If the AVP code specified in the Expected-Encrypted-AVP is not valid (that it, that AVP is not allowed to be encrypted), the implementation MUST issue an error message containing the DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS result code Add the following error code to 7.2: DIAMETER_ERRONEOUS_PROTECTION_EXPECTATIONS 50xx The protection expectations stated in the Expected-Signed-AVP or Expected-Encrypted-AVP are invalid. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 7 09:30: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 JAA12560 for ; Fri, 7 Sep 2001 09:30:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE77B9120E; Fri, 7 Sep 2001 09:30:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8248D9126F; Fri, 7 Sep 2001 09:30: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 4F6C19120E for ; Fri, 7 Sep 2001 09:30:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E89B5DDBC; Fri, 7 Sep 2001 09:30: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 2441B5DDB3 for ; Fri, 7 Sep 2001 09:30:45 -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.10.1/WIREfire-1.3) with ESMTP id f87DUgv24962; Fri, 7 Sep 2001 15:30:43 +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 f87DUfb06514; Fri, 7 Sep 2001 16:30:41 +0300 (EET DST) Message-ID: <3B98CC01.CB8BBE2F@lmf.ericsson.se> Date: Fri, 07 Sep 2001 16:30:41 +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: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] DIAMETER_NO_COMMON_TRUST error References: <3B97AF77.5F7001A7@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 I have trouble understanding issue #168. Section 7.2 of cms-sec-02 does not include such an error. Also, the provided reference doesn't seem to be related to this issue. Perhaps this error was agreed in the context of some other issue? But searching 'issues.html' with 'trust' didn't reveal anything either. ... clarification would be appreciated (or maybe my web cache is just out of sync of the drafts?) Jari From owner-aaa-wg@merit.edu Fri Sep 7 09: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 JAA13005 for ; Fri, 7 Sep 2001 09:38:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B48791203; Fri, 7 Sep 2001 09:40:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B3949126F; Fri, 7 Sep 2001 09:40: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 14C1191203 for ; Fri, 7 Sep 2001 09:40:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6E0D5DDBC; Fri, 7 Sep 2001 09:40:00 -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 16AC35DDB3 for ; Fri, 7 Sep 2001 09:40: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.10.1/WIREfire-1.3) with ESMTP id f87Ddrv02304; Fri, 7 Sep 2001 15:39:53 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA25452; Fri, 7 Sep 2001 15:39:50 +0200 (MET DST) Message-ID: <3B98CE5A.51B62BD2@rioja.ericsson.se> Date: Fri, 07 Sep 2001 15:40:42 +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 Cc: Pat Calhoun , Jari Arkko Subject: Re: [AAA-WG]: [issue] DIAMETER_NO_COMMON_TRUST error References: <3B97AF77.5F7001A7@rioja.ericsson.se> <3B98CC01.CB8BBE2F@lmf.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 Jari Arkko wrote: > > I have trouble understanding issue #168. Section > 7.2 of cms-sec-02 does not include such an error. Right. It isn't still in the draft. I didn't checked that it wasn't actually in the CMS-02 but in the resolution of one of the issues (I don't remember which one). I'd better have talket to Pat off-line. Pat, please, could you drop this issue? (although I still need some clafirication on this point before adding it to the draft) Regards // M.A. From owner-aaa-wg@merit.edu Fri Sep 7 10:26: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 KAA15347 for ; Fri, 7 Sep 2001 10:26:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87C2C91271; Fri, 7 Sep 2001 10:27:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51811912DD; Fri, 7 Sep 2001 10:27: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 1CBCF91271 for ; Fri, 7 Sep 2001 10:27:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5EC55DDBD; Fri, 7 Sep 2001 10:27:31 -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 6660C5DDBC for ; Fri, 7 Sep 2001 10: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 f87ERLK08498 for ; Fri, 7 Sep 2001 16:27:21 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA28696; Fri, 7 Sep 2001 16:27:17 +0200 (MET DST) Message-ID: <3B98D97A.48CB66D0@rioja.ericsson.se> Date: Fri, 07 Sep 2001 16:28:10 +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] Expiration of DSAs on behalf of a client References: <3B976DFB.51659365@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: > > Submitter name: Miguel A. Monjas > Submitter email address: ecemaml@rioja.es.eu.ericsson.se > Date first submitted: 2001-09-06 > Reference: > http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00246.html > Document: CMS-02 > Comment type: T > Priority: S > Section: 1.2, 4.4, 6.14 > Rationale/Explanation of issue: > > Requested change: > > Add the following text to the proposed text for issue 136: > > The PDSAA MUST contain the TTL setting agreed by the proxy agent > for its DSA. This information will allow the access device to > re-issue a PDSAR when the proxy's DSA has expired. Well, the PDSAR may be used also (without DSA-Target-Realm) to inform the proxy that it must establish DSAs with all the realms it will be communicating with, so that maybe a MAY instead a MUST would be better. > Change the ABNF grammar of the PDSAA AVP (4.4), being the result: > > ::= < Diameter-Header: 305, PXY > > { Result-Code } > { Origin-Host } > { Origin-Realm } > { Auth-Application-Id } [ DSA-TTL ] > [ Origin-State-Id ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > Add the followig text to the description of a DSA-TTL AVP in 6.14: > > A DSA-TTL AVP MUST also be included in the PDSAA in order to > provide information about the lenght of the DSA established by > the proxy on behalf of the access device. Same comment 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 7 11:17: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 LAA16943 for ; Fri, 7 Sep 2001 11:17:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5EEE91236; Fri, 7 Sep 2001 11:19:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DEDA912EE; Fri, 7 Sep 2001 11:19: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 658EF91236 for ; Fri, 7 Sep 2001 11:19:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B3005DDBA; Fri, 7 Sep 2001 11:19: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 7E40C5DDA7 for ; Fri, 7 Sep 2001 11:19:04 -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 LAA25438 for ; Fri, 7 Sep 2001 11:17:25 -0400 (EDT) Date: Fri, 7 Sep 2001 11:19:28 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] missing realm protocol error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 2001-09-07 Reference: Document: Base-07 Comment type: T Priority: 1 Section: 7.1.3 Rationale/Explanation of issue: Section 6.1 states that - a request that needs to be sent to a specific home server among those serving a given realm, MUST contain both the Destination- Realm and Destination-Host AVPs. If there is a Destination-Host, but no Destination-Realm, there is no way to respond with a protocol error. MISSING_AVP is not a protocol error, so you must use the correct ABNF for the answer. This is not possible for a many proxy situations if the proxy is not aware of a certain Application (a simple relay agent for example). DIAMETER_UNABLE_TO_DELIVER is used when the realm known, but no hosts are available. DIAMETER_REALM_NOT_SERVED is used when the realm is available, but not served. Requested change: Either add a new DIAMETER_MISSING_DESTINATION_REALM protocol error, or reword DIAMETER_UNABLE_TO_DELIVER or DIAMETER_REALM_NOT_SERVED to include the above situation. -mark From owner-aaa-wg@merit.edu Fri Sep 7 11:54: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 LAA17978 for ; Fri, 7 Sep 2001 11:54:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B0DE912F1; Fri, 7 Sep 2001 11:54:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26818912F8; Fri, 7 Sep 2001 11:54: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 9CA2C912F1 for ; Fri, 7 Sep 2001 11:54:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81F415DDBC; Fri, 7 Sep 2001 11:54:22 -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 F16A65DDBA for ; Fri, 7 Sep 2001 11:54:21 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19543 for ; Fri, 7 Sep 2001 08:54:20 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA29387 for ; Fri, 7 Sep 2001 08:53:59 -0700 (PDT) Message-Id: <200109071553.IAA29387@heliopolis.eng.sun.com> Date: Fri, 7 Sep 2001 08:53:58 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: [AAA-WG]: JSR for Diameter Java API? To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BhuEGFBBhyrTTdVXVlUpxA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi folks, In the hopes that everybody is not so exhausted by the effort to finish up the protocol that they will ignore this :-), I'd like to bring up a proposal for the API. The proposal is to separate out the Java API and run it through the Java Community Process as a JSR in addition to or instead of doing it as part of the Informational RFC. In general, the IETF does not standardize APIs as everyone probably already knows. An Informational RFC does not have the same weight as a Standards Track RFC. The Java Community Process is designed to standardize Java APIs. An API that has gone through the JSR process and received approval has the same weight in the Java community as a Standards Track RFC does within the IETF. What is involved is the following: - Identify someone willing to act as a specification leader. The spec leader is responsible for writing the JSR and shepharding it through the process, and for seeing that the reference implementation and test suite are made available. - Identify a group of experts willing to review the specification. The experts must represent a wide group of interested parties in the industry. Having most or all of them from one company is not acceptable. - Identify someone willing to produce a reference implementation and test suite. I'm not entirely sure of the details on the license, but I believe it must be close or equivalent to open source, if not Open Source (capital O, capital S). As a point of reference, the Service Location Working Group chose, primarily through lack of interest, not to pursue this path two years ago, and now continued work outside the working group has resulted in considerable interest and a JSR has been developed. Is there any interest in pursuing a JSR for the Diameter API at this time? Note: if you reply affirmatively, please also indicate your level of interest and committment to playing one of the roles in the process mentioned above. jak From owner-aaa-wg@merit.edu Fri Sep 7 12:12: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 MAA18695 for ; Fri, 7 Sep 2001 12:12:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D947591205; Fri, 7 Sep 2001 12:13:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A11E19120A; Fri, 7 Sep 2001 12:13: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 7A60C91205 for ; Fri, 7 Sep 2001 12:13:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5DA5E5DDBE; Fri, 7 Sep 2001 12:13:38 -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 373B35DDBA for ; Fri, 7 Sep 2001 12:13:38 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA09795 for ; Fri, 7 Sep 2001 09:13:37 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA09480 for ; Fri, 7 Sep 2001 09:13:37 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 7 Sep 2001 11:13:37 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECFFA@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'James Kempf'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: JSR for Diameter Java API? Date: Fri, 7 Sep 2001 11:13:37 -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 > As a point of reference, the Service Location Working Group > chose, primarily > through lack of interest, not to pursue this path two years ago, and > now continued work outside the working group has resulted in > considerable > interest and a JSR has been developed. > > Is there any interest in pursuing a JSR for the Diameter API > at this time? Note: > if you reply affirmatively, please also indicate your level > of interest and > committment to playing one of the roles in the process > mentioned above. I'm definitely interested in pursuing this idea. I'm willing to serve as any/all roles mentioned. I haven't yet discussed it with any supervisors, but I would hope to be able to provide my implementation as a possible reference implementation. -Brian From owner-aaa-wg@merit.edu Fri Sep 7 13:24: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 NAA21210 for ; Fri, 7 Sep 2001 13:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1AA991208; Fri, 7 Sep 2001 13:25:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77BF79120A; Fri, 7 Sep 2001 13:25: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 655B691208 for ; Fri, 7 Sep 2001 13:25:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 431A65DDBF; Fri, 7 Sep 2001 13:25:26 -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 66AF35DDBE for ; Fri, 7 Sep 2001 13:25:25 -0400 (EDT) Received: from jariws1 ([212.54.16.229]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010907172523.TLBA15145.fep07-app.kolumbus.fi@jariws1>; Fri, 7 Sep 2001 20:25:23 +0300 Message-ID: <005f01c137c2$149867c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , References: <3B9898F9.87AC0074@rioja.ericsson.se> Subject: Re: [AAA-WG]: [issue] Result-code with 'P' bit erroneous Date: Fri, 7 Sep 2001 20:25:24 +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 agree with this issue as such. I would suggest however slightly more general error code, and it to be put to the base. This way we could handle any illegal bit-AVP combinations: DIAMETER_INVALID_AVP_BIT_COMBINATION 50xx The request contained an AVP with which is not allowed to have the given value in the AVP Flags field. A Diameter message indicating this error MUST include the offending AVPs within a Failed-AVP AVP. and then: Diameter implementations MUST check whether AVPs with its 'P' bit set are allowed to use it. If not, an appropriate error message MUST be issued containing DIAMETER_INVALID_AVP_BIT_COMBINATION result code. Jari From owner-aaa-wg@merit.edu Fri Sep 7 13:40: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 NAA21667 for ; Fri, 7 Sep 2001 13:40:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A86EE91212; Fri, 7 Sep 2001 13:41:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 725E491213; Fri, 7 Sep 2001 13:41: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 61FA391212 for ; Fri, 7 Sep 2001 13:41:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BD8B5DDBF; Fri, 7 Sep 2001 13:41:44 -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 7F4275DDBA for ; Fri, 7 Sep 2001 13:41:43 -0400 (EDT) Received: from jariws1 ([212.54.16.229]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010907174142.ULBD11276.fep01-app.kolumbus.fi@jariws1>; Fri, 7 Sep 2001 20:41:42 +0300 Message-ID: <006501c137c4$5bf539c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , References: <3B98A06C.B8FF448@rioja.ericsson.se> Subject: Re: [AAA-WG]: [issue] Erroneous protection expectations Date: Fri, 7 Sep 2001 20:41:43 +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 agree with the parts of this issue. However, I would suggest that instead of creating a new error code we could simply use DIAMETER_INVALID_AVP_VALUE. Otherwise we end up creating a special error code for all AVPs. Also, I would suggest we don't list all the checks explicitly because, essentially, the destination node must check ALL sent parameters according to the policies. I've reformulated the text slightly to be a bit more general in this respect. Edited change request below. Jari > Add the following paragraph to 3.1 (after the list of components of > the DSAR): > > The destination node MUST check that the provided elements of > the DSAR are valid. It MUST check, at least, that: > > - Its local policy allows the given TTL, realm, AVP protection > expectations, certification status, and other parameters. > - A common "top" of the certificate chain can be found between > the home and foreign domains. > > If these conditions can not be verified, the destination node MUST > return a DSAA with the Result-Code AVP set to > DIAMETER_NO_DSA_ESTABLISHED. > > The destination node MUST also verify that the protection > expectations are valid. If it is requested as signed an AVP > which may not set its 'P' bit or as encrypted an AVP which may > not be encrypted, the destination node MUST return a DSAA with the > Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE. > > > In the event.... > > Add the following paragraph to 6.9: > > If the AVP code specified in the Expected-Signed-AVP is not > valid (that it, that AVP is not allowed to set its 'P' bit), the > implementation MUST issue an error message containing the > DIAMETER_INVALID_AVP_VALUE result code > > Add the following paragraph to 6.10: > > If the AVP code specified in the Expected-Encrypted-AVP is not > valid (that it, that AVP is not allowed to be encrypted), the > implementation MUST issue an error message containing the > DIAMETER_INVALID_AVP_VALUE result code From owner-aaa-wg@merit.edu Fri Sep 7 13:53: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 NAA22086 for ; Fri, 7 Sep 2001 13:53:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B061E91213; Fri, 7 Sep 2001 13:54:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8050E9121B; Fri, 7 Sep 2001 13:54: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 6BEEA91213 for ; Fri, 7 Sep 2001 13:54:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53AD25DDBE; Fri, 7 Sep 2001 13:54:51 -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 761A15DDBA for ; Fri, 7 Sep 2001 13:54:50 -0400 (EDT) Received: from jariws1 ([212.54.16.229]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010907175449.UMHU11276.fep01-app.kolumbus.fi@jariws1>; Fri, 7 Sep 2001 20:54:49 +0300 Message-ID: <008501c137c6$314a74e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Mark Eklund" , References: Subject: Re: [AAA-WG]: [issue] missing realm protocol error Date: Fri, 7 Sep 2001 20:54:51 +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 > Either add a new DIAMETER_MISSING_DESTINATION_REALM protocol > error, or reword DIAMETER_UNABLE_TO_DELIVER or > DIAMETER_REALM_NOT_SERVED to include the above situation. Perhaps we should avoid again the explosion of new error codes, and pick the second option. Here's a an attempt at the rewording: DIAMETER_UNABLE_TO_DELIVER 3003 This error is given when Diameter can not deliver the message to the destination, either because no host within the realm was available to process the request, or because Destination-Host AVP was given without the associated Destination-Realm AVP. From owner-aaa-wg@merit.edu Fri Sep 7 14:15:41 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 OAA22704 for ; Fri, 7 Sep 2001 14:15:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A36789121E; Fri, 7 Sep 2001 14:16:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B905D91221; Fri, 7 Sep 2001 14:16: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 923569121E for ; Fri, 7 Sep 2001 14:16:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 668775DDBA; Fri, 7 Sep 2001 14:16:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 873205DDA7 for ; Fri, 7 Sep 2001 14:16:02 -0400 (EDT) Received: from jariws1 ([212.54.16.229]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010907181601.UFLM1085.fep06-app.kolumbus.fi@jariws1>; Fri, 7 Sep 2001 21:16:01 +0300 Message-ID: <00a501c137c9$27933ec0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , References: <3B976DFB.51659365@rioja.ericsson.se> <3B98D97A.48CB66D0@rioja.ericsson.se> Subject: Re: [AAA-WG]: [issue] CMS-Cert in AVP occurrence table Date: Fri, 7 Sep 2001 21:16:03 +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 >a) When issuing a DSA-Request, a digital signature (by means of a >CMS-Signed-Data AVP) may be included. If so, an appropriate CMS-Cert >must be included (unless the certificate is included within the >SignedData estructure). Section 5.0 states that the CMS-Cert may be present in DSAR and DSAA. For the return message, it's the home server's cert. But as far as I can see, the CMS-Cert MUST be present and can't be avoided. (Unless we want to optimize the case where we already have the cert? No, I think it is too messy) So, the correct new line is: CMS-Cert | 1 | 1 | 0 | 0 | >b) Clarify if a CMS-Cert is necessary in a DSAA or if it's superseded >by a certificate present in AAA-Server-Cert I can't find AAA-Server-Cert from the cms-sec-02 version. >BTW, shouldn't be present Key-Hash AVP in the AVP occurrence table? No, because it's a subpart of Local-CA-Info AVP which you can find from the table already. In conclusion I think we should change the AVP occurrence line for CMS-Cert, but nothing else. Jari From owner-aaa-wg@merit.edu Fri Sep 7 14:40: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 OAA23618 for ; Fri, 7 Sep 2001 14:40:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41F4991224; Fri, 7 Sep 2001 14:41:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11F5091228; Fri, 7 Sep 2001 14:41: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 07A5291224 for ; Fri, 7 Sep 2001 14:41:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DFB845DDC3; Fri, 7 Sep 2001 14:41: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 1EAFE5DDC2 for ; Fri, 7 Sep 2001 14:41:57 -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 OAA02554; Fri, 7 Sep 2001 14:40:16 -0400 (EDT) Date: Fri, 7 Sep 2001 14:42:18 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] missing realm protocol error In-Reply-To: <008501c137c6$314a74e0$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I have no problem with that resolution. -mark On Fri, 7 Sep 2001, Jari Arkko wrote: > > Either add a new DIAMETER_MISSING_DESTINATION_REALM protocol > > error, or reword DIAMETER_UNABLE_TO_DELIVER or > > DIAMETER_REALM_NOT_SERVED to include the above situation. > > Perhaps we should avoid again the explosion of new error > codes, and pick the second option. Here's a an attempt at the > rewording: > > DIAMETER_UNABLE_TO_DELIVER 3003 > This error is given when Diameter can not deliver > the message to the destination, either because > no host within the realm was available to process > the request, or because Destination-Host AVP was > given without the associated Destination-Realm AVP. > > > > > From owner-aaa-wg@merit.edu Mon Sep 10 03:09: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 DAA06490 for ; Mon, 10 Sep 2001 03:09:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A52691217; Mon, 10 Sep 2001 03:10:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4EF691248; Mon, 10 Sep 2001 03:10: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 420D991217 for ; Mon, 10 Sep 2001 03:10:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADE485DDD1; Mon, 10 Sep 2001 03:10:15 -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 904825DD8E for ; Mon, 10 Sep 2001 03:10:14 -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.10.1/WIREfire-1.3) with ESMTP id f8A7ABv21948 for ; Mon, 10 Sep 2001 09:10:12 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA25068; Mon, 10 Sep 2001 09:10:04 +0200 (MET DST) Message-ID: <3B9C6793.FB8336BC@rioja.ericsson.se> Date: Mon, 10 Sep 2001 09:11:15 +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] Result-code with 'P' bit erroneous References: <3B9898F9.87AC0074@rioja.ericsson.se> <005f01c137c2$149867c0$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 Jari Arkko wrote: > > I agree with this issue as such. I would suggest however slightly > more general error code, and it to be put to the base. This > way we could handle any illegal bit-AVP combinations: > > DIAMETER_INVALID_AVP_BIT_COMBINATION 50xx > The request contained an AVP with which is not allowed > to have the given value in the AVP Flags field. A Diameter message > indicating this error MUST include the offending AVPs > within a Failed-AVP AVP. > > and then: > > Diameter implementations MUST check whether AVPs with its 'P' bit > set are allowed to use it. If not, an appropriate error message > MUST be issued containing DIAMETER_INVALID_AVP_BIT_COMBINATION > result code. I agree with Jari's resolution. If Pat's also agrees on it... Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 10 03:14: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 DAA06546 for ; Mon, 10 Sep 2001 03:14:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5EA291248; Mon, 10 Sep 2001 03:14:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F40B91249; Mon, 10 Sep 2001 03:14: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 76CFD91248 for ; Mon, 10 Sep 2001 03:14:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 601F85DDD1; Mon, 10 Sep 2001 03:14:56 -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 A9FBC5DD8E for ; Mon, 10 Sep 2001 03:14:55 -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.10.1/WIREfire-1.3) with ESMTP id f8A7Esv27038; Mon, 10 Sep 2001 09:14:54 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA25505; Mon, 10 Sep 2001 09:14:51 +0200 (MET DST) Message-ID: <3B9C68B2.8CC3C9C9@rioja.ericsson.se> Date: Mon, 10 Sep 2001 09:16:02 +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: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Erroneous protection expectations References: <3B98A06C.B8FF448@rioja.ericsson.se> <006501c137c4$5bf539c0$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 Jari Arkko wrote: > > I agree with the parts of this issue. However, I would > suggest that instead of creating a new error code we > could simply use DIAMETER_INVALID_AVP_VALUE. > Otherwise we end up creating a special error code for > all AVPs. You're right. Maybe I'd better point only error situations and not result codes. > Also, I would suggest we don't list all the checks explicitly > because, essentially, the destination node must check > ALL sent parameters according to the policies. I've reformulated > the text slightly to be a bit more general in this respect. > > Edited change request below. I agree on Jari's re-replacements. > > Add the following paragraph to 3.1 (after the list of components of > > the DSAR): > > > > The destination node MUST check that the provided elements of > > the DSAR are valid. It MUST check, at least, that: > > > > - Its local policy allows the given TTL, realm, AVP protection > > expectations, certification status, and other parameters. > > - A common "top" of the certificate chain can be found between > > the home and foreign domains. > > > > If these conditions can not be verified, the destination node MUST > > return a DSAA with the Result-Code AVP set to > > DIAMETER_NO_DSA_ESTABLISHED. > > > > The destination node MUST also verify that the protection > > expectations are valid. If it is requested as signed an AVP > > which may not set its 'P' bit or as encrypted an AVP which may > > not be encrypted, the destination node MUST return a DSAA with the > > Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE. > > > > > > In the event.... > > > > Add the following paragraph to 6.9: > > > > If the AVP code specified in the Expected-Signed-AVP is not > > valid (that it, that AVP is not allowed to set its 'P' bit), the > > implementation MUST issue an error message containing the > > DIAMETER_INVALID_AVP_VALUE result code > > > > Add the following paragraph to 6.10: > > > > If the AVP code specified in the Expected-Encrypted-AVP is not > > valid (that it, that AVP is not allowed to be encrypted), the > > implementation MUST issue an error message containing the > > DIAMETER_INVALID_AVP_VALUE result code Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 10 03: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 DAA06685 for ; Mon, 10 Sep 2001 03:25:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C05991249; Mon, 10 Sep 2001 03:26:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51C3B9124A; Mon, 10 Sep 2001 03:26: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 18D4F91249 for ; Mon, 10 Sep 2001 03:26:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF4A15DDD2; Mon, 10 Sep 2001 03:26:32 -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 1E55D5DD8E for ; Mon, 10 Sep 2001 03:26:32 -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 f8A7QTK27918; Mon, 10 Sep 2001 09:26:30 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA26282; Mon, 10 Sep 2001 09:26:25 +0200 (MET DST) Message-ID: <3B9C6B68.BBBECA12@rioja.ericsson.se> Date: Mon, 10 Sep 2001 09:27:36 +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: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] CMS-Cert in AVP occurrence table References: <3B976DFB.51659365@rioja.ericsson.se> <3B98D97A.48CB66D0@rioja.ericsson.se> <00a501c137c9$27933ec0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Jari Arkko wrote: > > >a) When issuing a DSA-Request, a digital signature (by means of a > >CMS-Signed-Data AVP) may be included. If so, an appropriate CMS-Cert > >must be included (unless the certificate is included within the > >SignedData estructure). > > Section 5.0 states that the CMS-Cert may be present in DSAR > and DSAA. For the return message, it's the home server's cert. > But as far as I can see, the CMS-Cert MUST be present and can't > be avoided. (Unless we want to optimize the case where we already > have the cert? No, I think it is too messy) I've seen it, but being only an example, I'd rather want to know the right answer. > So, the correct new line is: > > CMS-Cert | 1 | 1 | 0 | 0 | Assuming that a CMS-Cert MUST always go with a digital signature, it's OK. > >b) Clarify if a CMS-Cert is necessary in a DSAA or if it's superseded > >by a certificate present in AAA-Server-Cert > > I can't find AAA-Server-Cert from the cms-sec-02 version. Sorry by the typo. It's AAA-Server-Certs and it's described in section 6.6. As far as I understand, the destination node of the DSA is one of the AAA servers of the domain, so that the digital signature included in the DSAA can be verified by means of one of such certificates. Can't it? > >BTW, shouldn't be present Key-Hash AVP in the AVP occurrence table? > > No, because it's a subpart of Local-CA-Info AVP which you can find > from the table already. Yes. I thought the same. But I also noticed that the other subpart of Local-CA-Info AVP (CA-Name AVP) is actually listed. As far as I understand both o none of them must be listed. > In conclusion I think we should change the AVP occurrence line > for CMS-Cert, but nothing else. You're assuming that: - No optimization would be employed (what looks right). - The digital certificate of the destination DSA participant isn't included in AAA-Server-Certs (what I'd like to be confirmed). Comments? // 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 Mon Sep 10 09:29: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 JAA14574 for ; Mon, 10 Sep 2001 09:29:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1C4F99125C; Mon, 10 Sep 2001 09:30:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E8079125D; Mon, 10 Sep 2001 09:30: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 6044E9125C for ; Mon, 10 Sep 2001 09:30:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3B5D5DDCC; Mon, 10 Sep 2001 09:30:01 -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 A097C5DD8E for ; Mon, 10 Sep 2001 09:30:00 -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 f8ADTxK27034; Mon, 10 Sep 2001 15:29:59 +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 f8ADTwb01547; Mon, 10 Sep 2001 16:29:59 +0300 (EET DST) Message-ID: <3B9CC057.52B20C3C@lmf.ericsson.se> Date: Mon, 10 Sep 2001 16:29:59 +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: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: Jari Arkko , aaa-wg@merit.edu Subject: [AAA-WG]: AAA-Server-Certs vs. CMS-Cert [was: CMS-Cert in AVP occurrence table] References: <3B976DFB.51659365@rioja.ericsson.se> <3B98D97A.48CB66D0@rioja.ericsson.se> <00a501c137c9$27933ec0$8a1b6e0a@arenanet.fi> <3B9C6B68.BBBECA12@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: > Yes. I thought the same. But I also noticed that the other subpart of > Local-CA-Info AVP (CA-Name AVP) is actually listed. As far as I > understand both o none of them must be listed. Right. Take both away then. > > In conclusion I think we should change the AVP occurrence line > > for CMS-Cert, but nothing else. > > You're assuming that: > > - No optimization would be employed (what looks right). > - The digital certificate of the destination DSA participant isn't > included in AAA-Server-Certs (what I'd like to be confirmed). I have actually managed to get now confused on the AAA-Server-Certs and CMS-Cert. Which one is what, and why doesn't AAA-Server-Certs specify the format of the contents, like CMS-Cert does? Jari From owner-aaa-wg@merit.edu Mon Sep 10 09:50: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 JAA15455 for ; Mon, 10 Sep 2001 09:50:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 036519125F; Mon, 10 Sep 2001 09:51:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C347891260; Mon, 10 Sep 2001 09:51: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 9CBDC9125F for ; Mon, 10 Sep 2001 09:51:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 763A65DDD1; Mon, 10 Sep 2001 09:51:39 -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 97B5F5DDCC for ; Mon, 10 Sep 2001 09:51:38 -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 f8ADpaK16502 for ; Mon, 10 Sep 2001 15:51:37 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA00073; Mon, 10 Sep 2001 15:51:32 +0200 (MET DST) Message-ID: <3B9CC5AE.1CEC9023@rioja.ericsson.se> Date: Mon, 10 Sep 2001 15:52:46 +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 Cc: Jari Arkko Subject: [AAA-WG]: Re: AAA-Server-Certs vs. CMS-Cert [was: CMS-Cert in AVP occurrence table] References: <3B976DFB.51659365@rioja.ericsson.se> <3B98D97A.48CB66D0@rioja.ericsson.se> <00a501c137c9$27933ec0$8a1b6e0a@arenanet.fi> <3B9C6B68.BBBECA12@rioja.ericsson.se> <3B9CC057.52B20C3C@lmf.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 Jari Arkko wrote: > > Miguel Ángel Monjas Llorente wrote: > > > Yes. I thought the same. But I also noticed that the other subpart of > > Local-CA-Info AVP (CA-Name AVP) is actually listed. As far as I > > understand both o none of them must be listed. > > Right. Take both away then. It is the more coherent option... > > - The digital certificate of the destination DSA participant isn't > > included in AAA-Server-Certs (what I'd like to be confirmed). > > I have actually managed to get now confused on the AAA-Server-Certs > and CMS-Cert. Which one is what, and why doesn't AAA-Server-Certs > specify the format of the contents, like CMS-Cert does? Good question. Maybe Pat or Stephen could answer this question... (the only mention of this AVP was in the discussion about the obligation of including a digital signature in the DSA-Answer; this AVP MUST have its 'P' bit set) Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 10 11:58: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 LAA19638 for ; Mon, 10 Sep 2001 11:58:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0A5B191253; Mon, 10 Sep 2001 11:59:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C844F91257; Mon, 10 Sep 2001 11:59: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 ADD2C91253 for ; Mon, 10 Sep 2001 11:59:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8DE495DDD6; Mon, 10 Sep 2001 11:59: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 4B6B25DDD5 for ; Mon, 10 Sep 2001 11:59:38 -0400 (EDT) Received: (qmail 18752 invoked by uid 500); 10 Sep 2001 15:46:31 -0000 Date: Mon, 10 Sep 2001 08:46:31 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Result-code with 'P' bit erroneous Message-ID: <20010910084631.B18734@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B9898F9.87AC0074@rioja.ericsson.se> <005f01c137c2$149867c0$8a1b6e0a@arenanet.fi> <3B9C6793.FB8336BC@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3B9C6793.FB8336BC@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 10, 2001 at 09:11:15AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Sounds good to me. PatC On Mon, Sep 10, 2001 at 09:11:15AM +0200, Miguel Ángel Monjas Llorente wrote: > Jari Arkko wrote: > > > > I agree with this issue as such. I would suggest however slightly > > more general error code, and it to be put to the base. This > > way we could handle any illegal bit-AVP combinations: > > > > DIAMETER_INVALID_AVP_BIT_COMBINATION 50xx > > The request contained an AVP with which is not allowed > > to have the given value in the AVP Flags field. A Diameter message > > indicating this error MUST include the offending AVPs > > within a Failed-AVP AVP. > > > > and then: > > > > Diameter implementations MUST check whether AVPs with its 'P' bit > > set are allowed to use it. If not, an appropriate error message > > MUST be issued containing DIAMETER_INVALID_AVP_BIT_COMBINATION > > result code. > > I agree with Jari's resolution. If Pat's also agrees on it... > > Regards > > // M.A. From owner-aaa-wg@merit.edu Mon Sep 10 17:16: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 RAA02027 for ; Mon, 10 Sep 2001 17:16:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B1DD91279; Mon, 10 Sep 2001 17:16:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FBFE9127A; Mon, 10 Sep 2001 17:16: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 840FA91279 for ; Mon, 10 Sep 2001 17:16:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6284C5DD97; Mon, 10 Sep 2001 17:16:20 -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 288FB5DD8D for ; Mon, 10 Sep 2001 17:16:20 -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 f8ALGJp14897 for ; Mon, 10 Sep 2001 16:16:19 -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 f8ALGJW16377 for ; Mon, 10 Sep 2001 16:16: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 QAA28735 for ; Mon, 10 Sep 2001 16:16:18 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA21932 for ; Mon, 10 Sep 2001 16:16:17 -0500 (CDT) Message-ID: <3B9D2BB9.9010805@ericsson.com> Date: Mon, 10 Sep 2001 14:08:09 -0700 From: Tony Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] The need for Float128 ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: 2001-09-10 Reference: Document: Base-07 Comment type: T Priority: 1 Section: 4.3 Rationale/Explanation of issue: Float128 is specified in the Base specification, but not int128 and u_int128. Is there a particular need for Float128?. Furthermore, is Float128 even supported in most OSs? Requested change: Remove Float128 from the Base, unless somebody can tell that float128 is really needed and can be supported be the majority of known OSs. From owner-aaa-wg@merit.edu Mon Sep 10 17:32: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 RAA02434 for ; Mon, 10 Sep 2001 17:32:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E7609127B; Mon, 10 Sep 2001 17:33:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1429B9127F; Mon, 10 Sep 2001 17:33: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 1F7499127B for ; Mon, 10 Sep 2001 17:32:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF7535DD8D; Mon, 10 Sep 2001 17:32:45 -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 31E385DDCA for ; Mon, 10 Sep 2001 17:32:45 -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 f8ALWi525940 for ; Mon, 10 Sep 2001 16:32:44 -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 f8ALWhW20722 for ; Mon, 10 Sep 2001 16:32: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 QAA29633 for ; Mon, 10 Sep 2001 16:32:43 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA22193 for ; Mon, 10 Sep 2001 16:32:41 -0500 (CDT) Message-ID: <3B9D2F94.6060308@ericsson.com> Date: Mon, 10 Sep 2001 14:24:36 -0700 From: Tony Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Reminder to the Diameter interop testing event (bake off) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I just want to remind every one that the last date to register for the interop testing event is this Friday (10/14/01), please find further info how register at the url below. http://standards.ericsson.net/diameter-bake-off/ Regards, /Tony From owner-aaa-wg@merit.edu Mon Sep 10 17:56: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 RAA02897 for ; Mon, 10 Sep 2001 17:56:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8D8791227; Mon, 10 Sep 2001 17:57:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76BFA9127E; Mon, 10 Sep 2001 17:57: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 6253691227 for ; Mon, 10 Sep 2001 17:57:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36CCE5DD9D; Mon, 10 Sep 2001 17:57:25 -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 0196C5DD8D for ; Mon, 10 Sep 2001 17:57:24 -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 f8ALvOp02672 for ; Mon, 10 Sep 2001 16:57:24 -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 f8ALvOU22056 for ; Mon, 10 Sep 2001 16:57:24 -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 QAA00776 for ; Mon, 10 Sep 2001 16:57:23 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA22514 for ; Mon, 10 Sep 2001 16:57:22 -0500 (CDT) Message-ID: <3B9D355E.1070701@ericsson.com> Date: Mon, 10 Sep 2001 14:49:18 -0700 From: Tony Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Reminder to the Diameter interop testing event (bake off) References: <3B9D2F94.6060308@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry I meant 14th of September as last date to register. Thus, this Friday. Regards, /Tony Tony Johansson wrote: > All, > > I just want to remind every one that the last date to register for the > interop testing event is this Friday (10/14/01), please find further > info how register at the url below. > > http://standards.ericsson.net/diameter-bake-off/ > > Regards, > > /Tony From owner-aaa-wg@merit.edu Tue Sep 11 13:37: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 NAA14251 for ; Tue, 11 Sep 2001 13:37:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB1D891480; Tue, 11 Sep 2001 12:56:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56718914AF; Tue, 11 Sep 2001 12:39: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 A35C991417 for ; Tue, 11 Sep 2001 11:39:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 820765DD8F; Tue, 11 Sep 2001 11:39:53 -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 D404D5DD8E for ; Tue, 11 Sep 2001 11:39:52 -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 f8BFdpK12531 for ; Tue, 11 Sep 2001 17:39:51 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA04781; Tue, 11 Sep 2001 17:39:48 +0200 (MET DST) Message-ID: <3B9E304B.4729227D@rioja.ericsson.se> Date: Tue, 11 Sep 2001 17:39:55 +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: [AAA-WG]: List of error situations Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, I've compiled a comprehensive list of error situations I've found when dealing wiht the CMS draft. Most of them has been listed in previous list but I think that a full list will be interesting. After each error I've included four items: Error code issued: the result code issued in every situation. Definition of the error: where the definition of the error is stated. Included in CMS-02 draft: whether it has been considered in CMS-02 Included in CMS-03 draft: whether it has been considered in CMS-02 Status: what I consider that should be done. ==================================================================== 1 PROTECTION MISMATCH 1. A Diameter message arrives containing a CMS-Signed-Data AVP and no AVPs with its 'P' bit set. Error code issued: DIAMETER_AVP_NOT_ALLOWED Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: not necessary to add any information to the drafts. 2. A Diameter message arrives containing some AVPs with its 'P' bit set and without any CMS-Signed-Data AVP. Error code issued: DIAMETER_MISSING_AVP Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: not necessary to add any information to the drafts. 3. A Diameter message arrives containing AVPs with its 'P' bit set without being authorised for being protected. Error code issued: DIAMETER_INVALID_AVP_BIT_COMBINATION Definition of the error: suggested in base (7.1.5) (resolution of issue 169) Included in CMS-02 draft: No Included in CMS-03 draft: Yes (suggested at the end of section 2.0) Status: agreed on WG (issue 169). 4. A Diameter message arrives containing AVPs with its 'P' set when it was not agreed on the DSA establishment that they should be protected: Error code issued: DIAMETER_INVALID_AVP_BIT_COMBINATION Definition of the error: suggested in base (7.1.5) (resolution of issue 169) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. 5. A Diameter message arrives containing AVPs which were agreed on the DSA establishment as being encrypted (that is, they should not be present in plain in the message): Error code issued: DIAMETER_AVP_NOT_ALLOWED Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. 6. A CMS-Encrypted-Data AVP arrives within a Diameter message containing AVPs that are not authorised to be encrypted: Error code issued: DIAMETER_INVALID_AVP_VALUE Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. 7. A CMS-Encrypted-Data AVP arrives within a Diameter message containing AVPs that were not agreed on the DSA establishment as encryptable: Error code issued: DIAMETER_INVALID_AVP_VALUE Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. 8. A CMS-Signed-Data AVP arrives within a Diameter message containing a digital signature on a set of AVPs different from the AVPs with its 'P' bit set: Error code issued: DIAMETER_INVALID_AVP_VALUE Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. 2 NO DSA AVAILABLE 9. A Diameter message arrives including some Diameter CMS Security Application AVPs (CMS-Signed-Data, CMS-Encrypted-Data or CMS-Cert) with no DSA established. Error code issued: DIAMETER_NO_DSA_ESTABLISHED Definition of the error: CMS-03 (7.2) Included in CMS-02 draft: No Included in CMS-03 draft: Just as result code definition (resolution of issue 169 proposes its explicit mention but regarding error situation 11) Status: confirmation needed. 10. A Diameter message arrives including some Diameter CMS Security Application AVPs (CMS-Signed-Data, CMS-Encrypted-Data or CMS-Cert) with an expired DSA (if the implementation is able to detect that the AVPs come from a node with which a former DSA was established). Error code issued: DIAMETER_DSA_EXPIRED Definition of the error: CMS-03 (7.2) Included in CMS-02 draft: No Included in CMS-03 draft: Just as result code definition. Status: confirmation needed. 3 ERRORS IN DSA ESTABLISHMENT 11. A Diameter server can not set up a DSA upon receiving a DSA-Request since it is not able to construct a DSA-Answer according to the rules listed in section 3.1: Error code issued: DIAMETER_NO_DSA_ESTABLISHED Definition of the error: CMS-03 (7.2) Included in CMS-02 draft: No Included in CMS-03 draft: Yes Status: agreed on WG (issue 156). 12. A Diameter proxy or client can not set up a DSA upon receiving a DSA-Answer since it is not able to verify all the conditions listed in section 3.1: Error code issued: DIAMETER_NO_DSA_ESTABLISHED Definition of the error: CMS-03 (7.2) Included in CMS-02 draft: No Included in CMS-03 draft: Just as result code definition. Status: discussion on the WG (issue 170, still not approved). 13. A Diameter node can not set up a DSA upon receiving a DSA-Request or a DSA-Answer because the requested protection on certain AVPs is not allowed (that is, requesting as signed an AVP which may not set its 'P' bit or as encrypted an AVP which may not be encrypted). Error code issued: DIAMETER_INVALID_AVP_VALUE Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: Yes (section 3.1). Status: discussion on the WG (issue 170, still not approved). 4 ERRORS REGARDING CRYPTOGRAPHIC AVPS VERIFICATION 14. A Diameter message arrives containing a CMS-Signed-Data AVP that does not include any digital signature made by the node included in the Origin-Host AVP. Error code issued: DIAMETER_INVALID_AUTH Definition of the error: CMS-03 (7.1) Included in CMS-02 draft: No Included in CMS-03 draft: No. Status: confirmation needed. 15. A Diameter message arrives containing a CMS-Signed-Data AVP. No appropriate digital certificate (regarding the identity included in the Origin-Host AVP) is available, neither included in the Diameter message as a CMS-Cert AVP nor available in the local cache. Error code issued: DIAMETER_INVALID_AUTH Definition of the error: CMS-03 (7.1) Included in CMS-02 draft: No Included in CMS-03 draft: No. Status: confirmation needed. 16. A Diameter message arrives containing a CMS-Signed-Data AVP. The digital signature is invalid. Error code issued: DIAMETER_INVALID_AUTH Definition of the error: CMS-03 (7.1) Included in CMS-02 draft: No Included in CMS-03 draft: No. Status: agreed on WG (issue 156). 17. A Diameter message arrives containing a CMS-Encrypted-Data AVP. The recipient is not on the list of recipients specified in the RecipientInfos of the CMS EnvelopedData object and the node decides to indicate an error. Error code issued: Definition of the error: Included in CMS-02 draft: No Included in CMS-03 draft: Status: proposal needed. 18. A Diameter message arrives containing a CMS-Encrypted-Data AVP and does not have the required shared secret: Error code issued: DIAMETER_KEY_UNKNOWN Definition of the error: CMS-02 (7.1) Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 19. A Diameter message arrives containing a CMS-Encrypted-Data AVP and an error occurs during decryption. Error code issued: Definition of the error: Included in CMS-02 draft: No Included in CMS-03 draft: Status: proposal needed. 20. A Diameter message arrives containing a CMS-Signed-Data AVP with an invalid ContentInfo object. Error code issued: DIAMETER_INVALID_CMS_DATA Definition of the error: CMS-02 (7.1) Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 21. A Diameter message arrives containing a CMS-Encrypted-Data AVP with an invalid ContentInfo object. Error code issued: DIAMETER_INVALID_CMS_DATA Definition of the error: CMS-02 (7.1) Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 22. A Diameter message arrives containing a CMS-Cert AVP with an invalid ContentInfo object. Error code issued: DIAMETER_INVALID_CMS_DATA Definition of the error: CMS-02 (7.1) Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 5 REVALIDATION ERRORS 23. A Diameter node that does not support certificate revocation checks has calculated a safe period based on the expiration dates of the certificates. Once this safe period has finishing, a Diameter message including a CMS-Signed-Data AVP arrives without any certificate: Error code issued: Definition of the error: Included in CMS-02 draft: No Included in CMS-03 draft: Status: proposal needed. 6 OCPS SUPPORT 24. OCSP responses for every certificate are requested by means of the OCSP-Request-Flags AVP. The Diameter server supports OCSP querying but the OCSP responder is not available (the server gets a timeout, for instance). Error code issued: DIAMETER_OCSP_NOT_SUPPORTED Definition of the error: CMS-02 Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: confirmation needed. 25. OCSP responses for every certificate are requested by means of the OCSP-Request-Flags AVP. The Diameter server does not support OCSP querying. Error code issued: DIAMETER_OCSP_NOT_SUPPORTED Definition of the error: CMS-02 Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 7 CMS PROXY MODE 26. A Diameter proxy receives a DSAR. The protection levels are not compatible with the local policy. Error code issued: DIAMETER_NO_CMS_THROUGH_PROXY Definition of the error: CMS-02 Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 27. A Diameter proxy receives a DSAR. The protection levels are compatible with the local policy. Error code issued: DIAMETER_CAN_ACT_AS_CMS_PROXY Definition of the error: CMS-02 Included in CMS-02 draft: Yes Included in CMS-03 draft: Yes Status: no discussion needed. 28. A Diameter proxy receives a PDSR for which it has no common trust with the sender, which is required to establish the DSA. Error code issued: DIAMETER_NO_COMMON_TRUST Definition of the error: CMS-03 (7.2) Included in CMS-02 draft: No Included in CMS-03 draft: Yes Status: clarification needed. 8 MISCELLANEOUS 29. The DSA participant in the home network does not belong to the same realm as the user being authorized. Error code issued: DIAMETER_AUTHORIZATION_REJECTED Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. 30. No more than one CMS-Signed-Data AVP must be present in any given Diameter message: DIAMETER_AVP_NOT_ALLOWED Error code issued: DIAMETER_AVP_NOT_ALLOWED Definition of the error: base (7.1.5) Included in CMS-02 draft: No Included in CMS-03 draft: No Status: confirmation needed. ==================================================================== The different status mean the following: - Confirmation needed (4, 5, 6, 7, 8, 9, 10, 14, 15, 24, 29 and 30). I've supposed that a determinate result code must be used but I'd need a explicit confirmation about it. If my suppositions are correct, some text on the draft might be added to make it clearer. - Proposal needed (17, 19 and 23). No idea about which result code must be used (I suspect that a newly defined result code should be used) - Clarification needed (28). It regards issue 168. As I understand that this can be a tedious task, I offer my help to Pat to add the suggested clarification text to the draft once the confirmations have been issued. Regards -- 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Wed Sep 12 07:45: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 HAA18178 for ; Wed, 12 Sep 2001 07:45:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 538FE912C9; Wed, 12 Sep 2001 07:41:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90497912C8; Wed, 12 Sep 2001 07:39: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 7E851912C3 for ; Wed, 12 Sep 2001 07:39:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 669C75DDB5; Wed, 12 Sep 2001 07:39:19 -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 AD3E15DD93 for ; Wed, 12 Sep 2001 07:39:18 -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 f8CBdl327191 for ; Wed, 12 Sep 2001 14:39:47 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Sep 2001 14:39:16 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWKQ4D>; Wed, 12 Sep 2001 14:39:17 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBB52@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question on Diameter behavior in Failure cases (VER SION 1.2) Date: Wed, 12 Sep 2001 14:39:06 +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 Bernard, my comments are embedded in the text below. Br, John > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > One question I have is what happens if a Diameter client goes > > down while sending messages, before getting a response to a > > pending message, when there is no secondary peer? > > If the NAS goes down, you will have a AAA failure whether there > are secondary servers or not. The way to handle that kind of failure > is via clustering technology (some NASes already support this today) > so that the connection can be migrated to another NAS. > Diameter can't help > with this. Yes, clustering is an option if costs are not really relevant. But the Diameter could be defined so that it is reliable and robust. On the other hand, it would be a quite expesive requirement if every Diameter node would have to be clustered (if the Diameter could not itself be made reliable). > > Does that imply that a Diameter node may not ALWAYS have a > > secondary or additional connections available. > > Failover protection is not mandatory. But if you want high > availability it is a good idea. Ok. As you stated (and I understood from the draft), Diameter node is thus intended to work in both cases: a) with additional connections available b) as a node permanently without additional connections. Additionally there may be the case c) the additional connection(s) is/are temporarily out of order. > > In that case, if the Diameter client stops temporarily getting > > answer messages (and does not have an alternate agent to send > > the payload packet), the primary peer may recover (after a boot, > > for example). Then the following problem arises: > > > > I'm confused. You were initially talking about a *client* > failure. Now you > are talking about *server* failures. If the primary server > fails and there > is no alternate, then availability is compromised. Again, there isn't > much that Diameter can do about that. Sorry if my wording was not clear. I meant that this email thread discusses _several_ failure cases, as indicated in the email Subject. The words were there just as intended: "The Diameter client stops temporarily _getting_ messages" meant that the primary peer (Diameter Agent) is down (or the link to it). So I was (as intended) talking in the referred text about a Diameter agent failure instead of Diameter client failure. To the second part of the above comment it could be answered that Diameter _could_ really do something about the situation, even if there are no Diameter agents temporarily available. The Diameter client certainly has at least some RAM memory available and it may have non-volatile memory too. (It is already defined in the chapter 8.8 and 9.4 that there may be non-volatile memory available and that the Diameter node can keep count of the restarts and even communicate the number outwards if needed, using the Session-Id AVP.) These memory resources allow (as long as they last) the Diameter client to put all the pending messages in buffers, waiting for a peer node/link to come up. => The Diameter client that gets the communication working again to the awakening peer node, may indeed be in position to overcome a temporary state of isolation. It may be able to deliver all the locally (volatile/non-volatile memory) buffered pending messages. So, the Diameter client could well try for more than abandon all its packets pending to be sent, if temporarily there is no working link to a peer node. It could resend the before link failure not yet unacknowledged messages (minimum amount: 0, max amount: the protocol window size) again. But to "warn" the Diameter server, the 'D' bit would be set for the one (or very few) yet unacknowledged messages. This would tell the Diameter server that it should check them (with the E2E Identifier pairs & the Origin-Host AVP pairs), as they (only) need the detail level check. > > > Should the Diameter client re-send the pending payload > > message to its original (& now recovered) primary (& only) peer > > node, as the client does not know if the packet had been > > properly received went sent before the failure. > > > > This points out that failure scenarios can result in > duplicates, not only > to different servers, but also to the same server. That is what the > e2e session identifier was created to handle. But, comparisons of the the End-to-End Identifier pairs together with the Origin-Host AVP pairs for every packet (including the non-duplicated majority) would be far less efficient if the possible duplicates would not be marked by the Diameter client node that is the only node knowing when it sends possible duplicates. Since the ratio of duplicate messages is less than one to a billion normal messages, and since the checking of a single bit is faster than searching and decoding AVP pairs and checking e.g. 70 octets one by one, the checking of just one bit would be a most useful method. This does not mean that the E2E Identifier pairs and Origin-Hot AVP pairs would not be used, but that they would be mandatorily used only for the (marked) possible duplicates. > In the case of accounting, > this should be sufficient to deal with a duplicate accounting record. In the case of accounting, a very similar big difference in the efficiency appears: Either to robotically search every single message for the Session-Id AVP and for the Accounting-Record-Number AVP and after that check their contents, octet by octet. It would mean some decades more uniqueness checking work at the Diameter server if we would not have the 'D' bit in a constant offset place in the Diameter header (allowing the Diameter server to limit the (mandatory) uniqueness checks only to those very few potential messages for which the detailed processing (= E2E Identifier & Origin-Host AVP checking) is useful. > > In the case of authentication/authorization, I'm not sure > that there is a problem. You'll just get a new response. In a commercial, country wide operator network a Diameter server could be serving a huge number of Diameter clients and message uniqueness checking efficiency at the Diameter server would look as a very useful thing. If only the 'D' bit existence is checked most of the time (and the E2E Identifier pairs and the Origin-Host AVPs pairs compared only in less cases than e.g. one in a billion), then Diameter would work better, even _if_ the "application purpose" (e.g. authentication) would allow occasional failures in message handlings. Anyway, it would look a safe way if unpredictable and abnormal situations are avoided as carefully as possible, not relying on e.g. that it does not matter usually or so. And since there may be yet unseen Diameter extensions in the future, it would be far most simplest to have the already the Diameter Base protocol as a reliable message handler. > The only problem that could have > arisen is if the server wrote something about the session to stable > storage before responding, and *then* the connection failed (such as > incrementing the simultaneous session count). In that case, when the > server comes up again, it will have incorrect information in > its database. > > The solution to this is for the server to *not* write session info to > stable storage until it receives the equivalent of an > application-layer > ACK from the NAS. There is no app-layer ACK of an > authentication response > in Diameter, because the Accounting Request largely serves > this function. (May I first correct the last line of my paragraph which was intended to be: "> > properly received before the failure.") Yes, session info is not looking so useful to be written to stable storage before the ACK. > > It seems that this case a solution could be offered by the > > by marking the the packet 'possibly duplicated' (see my > > proposal sent yesterday for usage of a 'D' bit in the Diameter > > header) since the receiving primary (and only) peer node could > > I don't think that this is necessary, if the advice above is > followed. Can > you come up with a scenario in which a problem would be > caused by receipt of a duplicate authentication packet? The main benefit is an quite big (e.g. 2 decades) efficiency boost in the message uniqueness checkings in the Diameter server. I have not yet investigated all the possible authentication messaging scenarios and what problems the allowing of duplicated messages could cause but it would be easiest just to mark the potential duplicates. The need for the (slower) detail uniqueness checking arises only very seldom and the sending node can mark those cases. (Less than one message in a billion would typically be a duplicated message, typically caused to an travelling message by a broken link). Summary: It would be a simple solution to just prevent the duplicates to appear in an uncontrolled manner. This would be achieved by the most simple way that is used in these cases, by setting one ('D') bit by any Diameter message sending node (not the Siameter server). By marking the possible duplicates and checking thorougly at the Diameter server only the marked messages. The marked possibly duplicates messages form an extremely small minority of the whole message traffic of a network. Therefore the uniqueness checking processor load at the Diameter server would decrease to almost zero for the total traffic. Therefore I would recommend that approach in the first place, especially as we do not yet even know what future applications and extensions could be requiring from the Diameter Base protocol reliability. The bottom line is therefore that it would be risky to allow duplicates, but beneficial to do that with almost zero processor effort per packet in average at the Diameter Server. The currently existing Diameter message uniqueness checking could be used, but mandatorily only for those few packets, which possibly actually could be duplicates. John From owner-aaa-wg@merit.edu Wed Sep 12 08:00: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 IAA18650 for ; Wed, 12 Sep 2001 08:00:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23609912A5; Wed, 12 Sep 2001 07:59:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5200912A7; Wed, 12 Sep 2001 07:59: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 CCFBD912A5 for ; Wed, 12 Sep 2001 07:59:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC5595DDB5; Wed, 12 Sep 2001 07:59:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 9F7765DD93 for ; Wed, 12 Sep 2001 07:59:50 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8CC45G17836 for ; Wed, 12 Sep 2001 15:04:06 +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 ; Wed, 12 Sep 2001 14:59:49 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWKR7H>; Wed, 12 Sep 2001 14:59:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB87@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 128: duplicate packet detection failure case Date: Wed, 12 Sep 2001 14:59: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 Pat, Some comments & also answers embedded. Summary: ======== 0) May I clarify a bit the description of different steps in an uniqueness checking process. The 'D' bit usage is not a new, "competing" uniqueness _checking_ method (for the E2E Identifier pair & Origin-Host AVP pair checkings), but a marker enabling _efficiency_ boost and working in combination with e.g. the E2E Identifier & Origin-Host-AVP pair checking method. So there were 3 basic operations that could be used even in combination, to prevent message multiplication: 1.- mark the few potential duplicated messages (at Diameter message sending nodes) This was the minimal step 1 of Issue 128. We could have that even if we would not take the step 2 of Issue 128. Then we would keep the messaging mechanism just as is, and only in some very rare cases need to set one single bit ('D') at a message sending Diameter node, and save for nearly all messages the otherwise mandatory uniqueness checking work in the Diameter server. 2.- check the uniqueness of the marked ones (at Diameter server, by E2E Id & Origin-Host AVP pairs) 3.- remove the found duplicates (either by Diameter server, or if the issue 128 step 2, i.e. automatic duplicate removal by Diameter client - agent cooperation, before forwarding to Diameter server would be enough small feature). For this step 2) I understood that it would be considered affecting the actual protocol and therefore "too much" for at least some parties. But we can do without that, keep the existing messaging method (protocol), and do only the initial step 1 (marking of possible duplicates) and we still get an exceptionally big performance boost for a feature: even 2 decades checking speed improvement is well possible. 1) The usage of the 'D' bit in by Diameter client when needed enables e.g. 2 decades faster uniqueness checkings in the Diameter Server, as there would be typically e.g. 100 times less processor commands needed at the Diameter server to check message uniqueness. 2) The Server would mandatorily compare only then the received message with the slower (E2E Identifier pair & Origin-Host AVP pair) procedure when the 'D' bit is set (which would typically happen in less than one message in a billion (as links are most of the time ok, and the message sending is stopped after the link failure, until the link is again ok. 3) In accounting the duplicate message prevention is an important must. The big commercial operators are at least in some major countries audited by independent auditors who will demand the operator to *prove* that its accounting system will not produce any doubled accounting records. Failure in the audit means that the operator loses its network service license until it can prove that the unreliability has been corrected. > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 06 September, 2001 17:43 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 128: duplicate packet detection failure > case > > > On Tue, Sep 04, 2001 at 05:59:09PM +0300, > john.loughney@nokia.com wrote: > > Hi Pat, > > > > Sorry for the delay in responding - I have been quite > > busy - I have another document that just finished > > last call. I was a bit rushed when I submitted > > the issue for Diameter, it had actually 2 different parts that > > are easiest to consider separately: > > > > 1) Marking of the possibly duplicated messages. > > but what's the point? How do you know whether the first copy > was received? What about the second copy when sending the third? The point is that the sender knows which packets are sent a 2nd/3rd/4th... time and should therefore be the potential duplicates. The sender does not know which of the possible duplicates are real duplicates. The receiving node (Diameter Server as the last possible place) on the other hand has the visibility to all the material it got via the agents from the Diameter. But here is the difference: a) Either the Diameter Server has to check every packet and searches and decodes and checks quite a lot of octets, belonging to the Origin-Host string of type DiameterIdentity (octet string of e.g. 70 octets like aaa://host.abcdefghij-klmnopq.com:6666;transport=tcp;protocol=diameter) and the End-to-End Identifier (4 octets) by comparing two value pairs to other ones, or b) The Diameter Server checks just 1 single bit in 99.9999...% of the cases and only in one case in over a billion, AVP searchings, decodings and finally the comparisons of the long Origin-Host string AVP pairs and the End-to-End Identifier AVPs could be made, by checking them, octet by octet. > In any case, duplicate checking beyond the 'D' bit is necessary. Yes of course. But, since it is only necessary to check the _possible_ duplicates (marked with the 'D' bit), instead of having to process every Diameter packet contents in more detail, 99.999...% of the record detail checking work (for uniqueness) is saved. > > > 2) Removal of duplicate messages. > > > > Step 1 is a minimal functionality for enabling the > > duplicate message checking to be efficient as possible. > > The Diameter client knows (after hearing no response) > > that it is sending the message a 2nd (or 3rd etc.) > > time (either to the original peer node or an alternate node). > > > > Enhancing the efficiency of checking is the main > > benefit but it may improve a bit the reliability too. > > It also improves the reliability somewhat since the > > Diameter client has in End-to-End Identifier only 12 > > low order bits of the local time when booting. That is > > 4096 seconds which is a bit over a hour. > > I'd argue that if a message takes a bit over an hour to make it to the > server, then the response is moot (and something in the > network is broken). Since the Diameter Base protocol is a basic module that can be in future extended in ways that are today even not seen, the Base protocol should be made as reliable as possible. It could not now easily be assumed that e.g. message duplication could be less than maximally prevented. Also, it could likely be somewhat premature for us to assume that now and also in future, any delayed responses are moot. It would look like a very simple solution if the 'D' bit would always be set when the message is a potential duplicate. Here I was not concerned in first place about a response but about the sending. Here was a case of sending party being down. My issue here was about: 1) effectiveness (number) of comparisons per one message and 2) amount of comparisons done in total for all the messages transferred to the Diameter server and 3) reliability if the sending node goes down for 4092 seconds or for a multiple of that time. With the 'D' bit usage for the pending packets that the Diameter client may have in its non-volatile memory, and packet contents comparison for the 'D'-marked packet at the receiving end, a duplicate packet would be identified and found efficiently, also in the case that the sending Diameter client was down 4092 seconds (or its multiple). The End-to-End Identifier (and Origin-Host AVP) pairs could not do alone this as it is typically changed after every boot for the next packets to be sent. (Or otherwise the Diameter should have some other kind of protocol logic than it currently has.) Since the 'D' bit would be set only to the possible duplicates but not to the original, the 'D' bit provides additional information that the E2E Identifier does not alone offer: The original (first) message is differentiated from it duplicates. This gives useful information about where and when the duplicates were generated. When using the E2EIdentifier, the duplicated messages look all the same, also the original message. Therefore it is likely a bit more difficult to track the event that triggered the duplicates, to improve the network against message duplication tendency. (Actually, it would even seem that the way to do most reliably the duplicate markings and later removal, the sending Diameter client should use 'D' bit for marking, and the Diameter Server should compare more than the Origin-Host & End-to-End Identifier pairs of a suspected duplicate packet. Even the whole packet contents of 'D'-marked packet should be checked, as the job is done extremely seldom and End-to-End Identifier is usually different every time after a Diameter client boot-up after e.g. a Diameter client node failure.) > > > > > This means that with very bad luck, a Diameter client > > that goes down and wakes up after 4096 seconds MAY send > > a message with the same End-to-End Identifier, taking from > > non-volatile memory an earlier sent (but not yet answered) > > pending message and produces a duplicate. Unless, it has > > this capability to mark with 'D' bit that the pending message > > now resent may be a duplicate.) > > right, but now you have the same problem, right? If a client > reboots twice, > exactly 4096 seconds apart, then the IDs will be similar, and > the 'D' bit > becomes irrelevant since once doesn't really know if it is > for the first hour, > the second hour, etc. I may overlook something, but it seems that there is a difference: The first message is not marked with a 'D' bit so that is different (=unique) if that exists. If the 'D' marked set of duplicates do not have a one unduplicated "master" message, then they may look the same after 4092 seconds, as with E2E Identifier. But, there is a major (e.g. 2 decades) difference in the uniqueness checking work at the Diameter server end, since the 'D' bit is so much more efficient to test (to see whether the slower E2E Identifier & Origin-Host AVP pairs' search&decoding&string comparisons are needed at all. Most of the time, there would be no 'D' bit and no need to do the slower checks therefore. A Diameter server may have to serve a very big number of Diameter clients (which have thus different high order 12 bits in the E2E Identifier => A lot of slower comparisons needed at Diameter server unless the 'D' bit is used to help the identification of possible duplicates. > So I am convinced that the protocol is fine as-is, and > duplicate checks is > a little more complicated than just setting a 'D' bit in a header. Please consider the 2 decades efficiency boost at the Diameter server, too. Can anyone state a more efficient (or even equally efficient way here? 'D' bit would be an indicator for 2 decades efficiency boost, not even intended to cover the whole uniqueness checking alone. > > > > Step 2 is a solution where in addition to the minimal > > solution of marking the possibly duplicated packets, the > > duplicates are also removed form the network as quickly > > as possible, with minimal amount of double-checking. > > > > This mail presents only a simplified way of step 1, as it > > can be used also as a stand-alone feature (just an additional > > flag bit in the Diameter header). Please review the following > > description, it would help the Diameter Server to avoid > > the obligation to do a mandatory cross check every single > > received request message - which should save on processing. > > > > The needed small changes for the step 1) > > (marking of possibly duplicated packets) to the > > draft-ietf-aaa-diameter-07.txt are the following: > > > > > > 3.0 Diameter Header > > > > ... > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E r r r r r| Command-Code > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > would be: > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E D r r r r| Command-Code > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > and > > > > E(rror) - If set, the message contains a > protocol error, > > and the message will not conform to the ABNF > > described for this command. > Messages with the > > 'E' bit set is commonly referred to > as an error > > message. This bit MUST NOT be set in request > > messages. See section 7.2. > > r(eserved) - this flag bit is reserved for future use, and > > MUST be set to zero. > > > > would get one new flag bit 'D': > > > > E(rror) - If set, the message contains a > protocol error, > > and the message will not conform to the ABNF > > described for this command. > Messages with the > > 'E' bit set is commonly referred to > as an error > > message. This bit MUST NOT be set in request > > messages. See section 7.2. > > (possibly) D(uplicated) > > - If set, the message is possibly a duplicate, > > and must be later checked by a recipient node > > if it really is a duplicate. If sending a > > message for first time, this bit > MUST be cleared. > > This bit MUST NOT be set if an answer message > > (about e.g. a protocol error) has > been got for > > an earlier similar message, it is used only > > in cases where no answer has been > got from the > > primary agent for a message and the > message is > > sent again (e.g. due to failover, to an > > alternate agent). > > r(eserved) - this flag bit is reserved for future use, and > > MUST be set to zero. > > > > > > In: > > > > 5.5.4 Failover/Failback Procedures > > > > ... > > It is important to note that multiple identical request > or answer MAY > > be received as a result of a failover. The End-to-End Identifier > > field in the Diameter header along with the Origin-Host > AVP MUST be > > used to identify duplicate messages. > > > > the above paragraph would be amended as: > > > > It is important to note that multiple identical request > or answer MAY > > be received as a result of a failover. The > possibly-Duplicated flag > > MUST be set by the Diameter client node that performs > failover, to > > mark those packets that it had sent with no answer > message coming from > > the primary agent, and which it therefore forwards to an > alternate > > node. The final destination node of a message MUST check those > > messages that have the 'D' bit set, if they can be identified as > > actually duplicated messages. The intermediate nodes MAY check > > the messages with the 'D' bit set, if they can be identified > > as duplicate messages. The End-to-End Identifier field in the > > Diameter header along with the Origin-Host AVP MUST be used to > > identify duplicate messages among the marked possibly duplicated > > messages. > > > > and in: > > > > 9.4 Fault Resilience > > > > ... > > Diameter peers acting as clients MUST implement the use > of failover > > to guard against server failures and certain network failures. > > Diameter peers acting as agents or related off-line processing > > systems MUST detect duplicate accounting records caused by the > > sending of same record to several servers and > duplication of messages > > in transit. This detection MUST be based on the inspection of the > > Session-Id and Accounting-Record-Number AVP pairs. > > > > paragraph would get one sentence to its end: > > > > .... > > Diameter peers acting as clients MUST implement the use > of failover > > to guard against server failures and certain network failures. > > Diameter peers acting as agents or related off-line processing > > systems MUST detect duplicate accounting records caused by the > > sending of same record to several servers and > duplication of messages > > in transit. This detection MUST be based on the inspection of the > > Session-Id and Accounting-Record-Number AVP pairs. The inspection > > MUST be performed at least for such records that arrived to the > > Diameter peer in messages having the 'D' bit set. > > well, I don't have a particular issue with the above proposed > text, but do question it's need. Since it is only necessary to check the _possible_ duplicates (marked with the 'D' bit) that form an extremely small minority of all the packets transferred, instead of having to process every Diameter packet contents in more detail, 99.999...% of the accounting record detail checking work (for uniqueness) is saved. If the two Session-Id (AVP 263) and Accounting-Record-Number (AVP 485) pairs would be needed to be mandatorily checked also for every non-duplicated packet (=nearly all of the packets) mandatorily, it would mean unnecessary work for nearly every packet as link failures could be expected to occur much less often than for one packet in a billion. If the Diameter client sending packets is booted due to a temporary failure, and there is only one working link to an Diameter agent or Server, then as defined in chapter 9.4, there are possibilities to still continue: "Diameter clients MAY have non-volatile memory for the safe storage of accounting records over reboots or extended network failures, network partitions, and server failures. If such memory is available the client SHOULD store new accounting records there as soon as the records are created and until a positive acknowledgement of their reception from the Diameter Server has been received." And after a reboot, the client MUST starting sending the records in the non-volatile memory to the accounting server. Now, the resending of a packet to the Diameter agent or Server would be possible (also in the one link available only -case) if only the duplicates could be indicated. Anyhow, as defined in chapter 3.0 about the End-to-End Identifier, its high order 12 bits are initiated to contain the low order 12 bits of current (boot) time, while the low order 20 bits is set to a random value. Thus, the End-to-End Identifier is (usually) different after every boot in the Diameter logic. This means that e.g. the End-to-End Identifier would not be usable for the accounting record duplicate checking. Anyhow, the 'D' bit would be still possible to mark a possible duplicate and 'D' bit checking per packet is much faster than checking every Session-Id (and UTF8String) and Accounting-Record-Number AVP pair against the other pair(s), as 99.9999...% of the time no more than one ('D') bit only needs to be compared. The sender of a packet always knows if it resends a packet (to any link that it has or will establish). Therefore it knows that in the 2nd, 3rd, etc. sending, the packet might appear as a duplicate in a end system, and should therefore get the 'D' bit set as to request the cross-checking for that particular packet. > I'm willing to listen to the WG on this one. > > PatC > John From owner-aaa-wg@merit.edu Wed Sep 12 10:24: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 KAA22721 for ; Wed, 12 Sep 2001 10:24:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F00C0912C0; Wed, 12 Sep 2001 10:22:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1154912CE; Wed, 12 Sep 2001 10:22: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 E0107912C0 for ; Wed, 12 Sep 2001 10:22:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDC015DDA5; Wed, 12 Sep 2001 10:22:01 -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 E8F9B5DD93 for ; Wed, 12 Sep 2001 10:22:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA58993; Wed, 12 Sep 2001 07:12:47 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 12 Sep 2001 07:12:47 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Question on Diameter behavior in Failure cases (VER SION 1.2) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBB52@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 > The Diameter client certainly has at least some RAM > memory available and it may have non-volatile memory too. Yes. Diameter clients can be designed to store requests in NVRAM, and retry indefinitely, either to the same agent or a failover agent. > These memory resources allow (as long as they > last) the Diameter client to put all the pending > messages in buffers, waiting for a peer node/link to come > up. Actually, as described in RFC 2975, it is often desirable to utilize non-volatile storage so that requests can survive a client failure. So there is no need to lose data just because memory resources have run out. > => The Diameter client that gets the communication > working again to the awakening peer node, may indeed > be in position to overcome a temporary state of > isolation. Yes, this is how the protocol should behave. > It may be able to deliver all the locally > (volatile/non-volatile memory) buffered pending > messages. So, the Diameter client could > well try for more than abandon all its packets > pending to be sent, if temporarily there is no > working link to a peer node. In general, a Diameter node MUST NOT abandon "all packets" waiting to be sent, just because a connection is closed. If NVRAM exists, then unacknowledged requests can be stored there to protect against a client failure. They should only be deleted there when an app-layer ack is received (accounting) or when the client connection drops (authentication). If there is no NVRAM, but memory resources are available, then the packets should be stored awaiting delivery to an alternate peer, or recovery of the primary peer. Since loss of data is one of the major flaws of RADIUS, I hope that the Diameter specification is clear about the expected behavior. If the behavior you describe is not clearly indicated in the spec, then it should be. If not, please file an issue on this. > This would tell the Diameter server that it should check > them (with the E2E Identifier pairs & the Origin-Host > AVP pairs), as they (only) need the detail level check. The problem is that in these failover situations, there are no ordering guarantees between packets sent on different connections. If the packets are sent within the "time wait" interval of each other, then it is conceivable that the request with the 'D' bit set could arrive *before* the initial request. So it's not clear to me that having a 'D' bit removes the need to check for dupes on packets without the 'D' bit set. In that case, what good does the 'D' bit do? Also, if we have a 'D' bit, we need to be clear about the obligations of a Diameter server receiving a request with a 'D' bit set. In failover scenarios, duplicate checking may not necessarily be feasible at the Diameter Server. For example, in accounting, the record may be stored with the E2E identifier, and then the billing engine may remove the duplicates later. In authentication, if the request is idempotent, there is no need for the server to take any action based on the 'D' bit -- the server can just send another response. However, if simultaneous usage is being tracked, then it would make sense to check for duplicates. However, it's important to understand that ordering is not guaranteed -- so the request with the 'D' bit could arrive *before* the other request that does *not* have the 'D' bit set. So it seems to me that where we have non-idempotent requests, duplicate detection *always* needs to be carried out. > But, comparisons of the the End-to-End Identifier pairs > together with the Origin-Host AVP pairs for every packet > (including the non-duplicated majority) would be far less efficient > if the possible duplicates would not be marked by the Diameter > client node that is the only node knowing when it sends possible > duplicates. The problem is that the 'D' bit provides a false sense of security. I think that you can still have duplicates in packets without the 'D' bit set. I presume that the 'D' bit is being set for all requests that were pending an application layer ack when the connection went down, whether they are resent on a connection to the same peer or an alternate peer. > In the case of accounting, a very similar big difference in > the efficiency appears: Either to robotically search every > single message for the Session-Id AVP and for the > Accounting-Record-Number AVP and after that check their contents, > octet by octet. In practice, I don't think you'll do this -- won't you just write the accounting record to stable storage, and do the dupe checking down the line, unless simultaneous usage is being monitored? From owner-aaa-wg@merit.edu Thu Sep 13 01:03: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 BAA12787 for ; Thu, 13 Sep 2001 01:03:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A62CF915CD; Thu, 13 Sep 2001 00:59:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49743917EC; Thu, 13 Sep 2001 00:46: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 C5B1891912 for ; Thu, 13 Sep 2001 00:42:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA9025DD91; Thu, 13 Sep 2001 00:42:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by segue.merit.edu (Postfix) with ESMTP id E14CE5DDD7 for ; Thu, 13 Sep 2001 00:42:46 -0400 (EDT) Received: from lobbi (lobbi.etri.re.kr [129.254.12.168]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZ7PXK63; Thu, 13 Sep 2001 13:39:02 +0900 Message-ID: <019801c13c0e$855ae5a0$a80cfe81@lobbi> From: "Sangkeun Yoo" To: Subject: [AAA-WG]: Question about routing request and answer Date: Thu, 13 Sep 2001 13:42:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA12787 Hi all, First, I want to say I'm sorry if this was discussed before. In the Diameter Base Protocol(07.txt), 6.1.8 Relaying and Proxying Requests A relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from. As above discription, Route-Record AVP contains the peer's information the request was received from. But in the "Figure 5:Routing of Diameter messages" in the section 6.1.8, it contains its own information in the Route-Record AVP in the request from DRL to HMS. And in the 6.8.1, 6.8.1 Route-Record AVP The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one sent in the Origin-Host of the Capabilities-Exchange-Request message. As above discription, Route-Record AVP contains its own information. Which is correct? One more question, In the 6.2.2, 6.2.2 Relaying and Proxying Answers ....................... The agent MUST then send the answer to the host which it received the original request from. Does Route-Record AVP must appear in answer message or not? I wonder how the agent can know the host that the original request was received from. Is it from Route-Record AVP or saved source of the reqeust including the IP address, port and protocol discribed in section 6.1.8? If from Route-Record AVP, in the Figure 5 there is no Route-Record AVP in the answer message from HMS to DRL. I think that HMS can know the host it has to send answer message to from Route-Record(drl.mno.net) it received, right? But even if Route-Record AVP from HMS to DRL is omitted by editorial error, how can DRL know the host it has to relay answer message to, while Route-Record indicates its own information? Regards, Sangkeun Yoo. -------------- Email: lobbi@etri.re.kr AAA Information Security Research Team Electronics and Telecommunications Research Institute(ETRI) From owner-aaa-wg@merit.edu Thu Sep 13 03:48: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 DAA28580 for ; Thu, 13 Sep 2001 03:48:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B06D791239; Thu, 13 Sep 2001 03:46:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77BF191275; Thu, 13 Sep 2001 03:46: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 44F3B91239 for ; Thu, 13 Sep 2001 03:46:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2AB705DDF5; Thu, 13 Sep 2001 03:46:28 -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 627215DDDC for ; Thu, 13 Sep 2001 03:46:27 -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 f8D7kQK06814 for ; Thu, 13 Sep 2001 09:46:26 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Sep 13 09:46:19 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Sep 2001 09:46:25 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C00B06@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'aaa-wg@merit.edu'" Cc: "Yolanda Garcia-Serrano (ECE)" Subject: [AAA-WG]: Question about Capabilities-Exchange Date: Thu, 13 Sep 2001 09:45:52 +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 have a question about the contents of Capabilities-Exchange messages: In chapter 5.3.1, 5.3.2 as well as in 10.1 (AVP Table), Auth-Application-Id and Acct-Application-Id AVPs do not appear as mandatory for CER and CEA messages. MUST Auth-Application-Id or Acct-Application-Id (at least one of both) be mandatory in CER/CEA messages? Otherwise, I found confusing following statements in the draft: * Section 2.5 ... all other Diameter nodes MUST advertise locally supported applications. Does not the "MUST" imply the sending of Auth-Application-Id or Acct-Application-Id in the CER, CEA messages= * Section 5.3 (Capabilities Exchange) .. A receiver of a Capabilities-Exchange-Req (CER) message which does not have any applications in common with the sender MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection. How can a receiver of a CER message detect whether it has any application in common with the sender if the message does not contain either Auth-Application-Id or Acct-Application-Id ? *6.9 Auth-Application-Id AVP The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of the Authentication and Authorization portion of an application (see Section 2.5). The Auth- Application-Id MUST also be present in all Authentication and/or Authorization messages that are defined in a separate Diameter specification and have an Application ID assigned. Advertising support of the authen & autho portion of an application means include this AVP in the CER/CEA messages, isn't it? Sumarizing, I think the ABNR of CER and CEA messages, as well as the AVP table has to be updated to include at least 1 Auth-Application-Id and 1 Acct-Application-Id. If so, could this be clarified in the draft ? Thanks, and best regards /Yolanda Garcia From owner-aaa-wg@merit.edu Thu Sep 13 10:51: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 KAA05007 for ; Thu, 13 Sep 2001 10:51:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9EB1912F5; Thu, 13 Sep 2001 10:50:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB5B1912F7; Thu, 13 Sep 2001 10:50: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 A367C912F5 for ; Thu, 13 Sep 2001 10:50:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 899375DDA7; Thu, 13 Sep 2001 10:50: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 043495DDA3 for ; Thu, 13 Sep 2001 10:50:40 -0400 (EDT) Received: (qmail 332 invoked by uid 500); 13 Sep 2001 14:37:23 -0000 Date: Thu, 13 Sep 2001 07:37:23 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Question about Capabilities-Exchange Message-ID: <20010913073723.F32724@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA02C00B06@eestqnt104.es.eu.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: <577066326047D41180AC00508B955DDA02C00B06@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Thu, Sep 13, 2001 at 09:45:52AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk The ABNF doesn't have a way to state that either one or another AVP MUST be present. So, the supporting text is the best we can do, and so far it hasn't hampered any of the interopoerability tests we've had. PatC On Thu, Sep 13, 2001 at 09:45:52AM +0200, Yolanda Garcia-Serrano (ECE) wrote: > Hi, > > I have a question about the contents of Capabilities-Exchange messages: > > In chapter 5.3.1, 5.3.2 as well as in 10.1 (AVP Table), Auth-Application-Id and > Acct-Application-Id AVPs do not appear as mandatory for CER and CEA messages. > MUST Auth-Application-Id or Acct-Application-Id (at least one of both) be > mandatory in CER/CEA messages? > Otherwise, I found confusing following statements in the draft: > > * Section 2.5 > ... all other Diameter nodes MUST advertise locally supported applications. > > Does not the "MUST" imply the sending of Auth-Application-Id or Acct-Application-Id in > the CER, CEA messages= > > * Section 5.3 (Capabilities Exchange) > .. A receiver of a Capabilities-Exchange-Req (CER) message which does > not have any applications in common with the sender MUST return a > Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to > DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport > layer connection. > > How can a receiver of a CER message detect whether it has any application in common with the sender > if the message does not contain either Auth-Application-Id or Acct-Application-Id ? > > *6.9 Auth-Application-Id AVP > The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and > is used in order to advertise support of the Authentication and > Authorization portion of an application (see Section 2.5). The Auth- > Application-Id MUST also be present in all Authentication and/or > Authorization messages that are defined in a separate Diameter > specification and have an Application ID assigned. > > Advertising support of the authen & autho portion of an application means include this > AVP in the CER/CEA messages, isn't it? > > Sumarizing, I think the ABNR of CER and CEA messages, as well as the AVP table has to be updated > to include at least 1 Auth-Application-Id and 1 Acct-Application-Id. If so, could this be > clarified in the draft ? > > Thanks, and best regards > /Yolanda Garcia From owner-aaa-wg@merit.edu Thu Sep 13 12:09:58 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 MAA06979 for ; Thu, 13 Sep 2001 12:09:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 063899133D; Thu, 13 Sep 2001 12:05:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C599B91337; Thu, 13 Sep 2001 12:05: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 5541591205 for ; Thu, 13 Sep 2001 12:03:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C9F55DDFD; Thu, 13 Sep 2001 12:03: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 849A45DDF4 for ; Thu, 13 Sep 2001 12:03:55 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA01289; Thu, 13 Sep 2001 08:56:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 13 Sep 2001 08:56:59 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Cc: mankin@isi.edu Subject: [AAA-WG]: [Issue]: Transport failure algorithm differs between drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/13/01 Document: base-07, transport-04 Comment type: Technical Priority: Must fix Section: 5.5.3 (base), 3.2 (transport) Explanation of issue: The transport failure algorithms described in the two drafts differ substantially. For example, the transport draft describes an algorithm that depends on a single timer, while the base drafts algorithm includes multiple timers. Requested change: The drafts need to be aligned so that they describe the same transport failure algorithm. From owner-aaa-wg@merit.edu Thu Sep 13 12:24:25 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 MAA07785 for ; Thu, 13 Sep 2001 12:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BC9B913CB; Thu, 13 Sep 2001 12:21:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EF5F91394; Thu, 13 Sep 2001 12:20: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 9EB86913BE for ; Thu, 13 Sep 2001 12:19:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73A2E5DDF5; Thu, 13 Sep 2001 12:19: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 E373E5DDF4 for ; Thu, 13 Sep 2001 12:19:21 -0400 (EDT) Received: (qmail 1301 invoked by uid 500); 13 Sep 2001 16:06:04 -0000 Date: Thu, 13 Sep 2001 09:06:04 -0700 From: Pat Calhoun To: Bernard Aboba Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: Re: [AAA-WG]: [Issue]: Transport failure algorithm differs between drafts Message-ID: <20010913090604.B1275@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , aaa-wg@merit.edu, mankin@isi.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 aboba@internaut.com on Thu, Sep 13, 2001 at 08:56:59AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk ok, so since the base protocol has been through significant review, can we assume that the transport draft is the one that needs to change? PatC On Thu, Sep 13, 2001 at 08:56:59AM -0700, Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: 9/13/01 > Document: base-07, transport-04 > Comment type: Technical > Priority: Must fix > Section: 5.5.3 (base), 3.2 (transport) > Explanation of issue: The transport failure algorithms described in the > two drafts differ substantially. For example, the transport draft > describes an algorithm that depends on a single timer, while the base > drafts algorithm includes multiple timers. > Requested change: > The drafts need to be aligned so that they describe the same transport > failure algorithm. > From owner-aaa-wg@merit.edu Thu Sep 13 14:21: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 OAA12298 for ; Thu, 13 Sep 2001 14:21:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FBD591386; Thu, 13 Sep 2001 14:17:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91AF09134C; Thu, 13 Sep 2001 14:17: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 A98A491347 for ; Thu, 13 Sep 2001 14:17:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BF995DDF4; Thu, 13 Sep 2001 14:17:15 -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 BDAEB5DDBA for ; Thu, 13 Sep 2001 14:17:14 -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 OAA16332 for ; Thu, 13 Sep 2001 14:15:29 -0400 (EDT) Date: Thu, 13 Sep 2001 14:17:39 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue]: Missing text in float definitions. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 9/13/01 Document: base-07 Comment type: Editorial Priority: Should fix Section: 4.3 Explanation of issue: The definitions of Float32, Float64, and Float128 in the base draft all are missing the sentence fragment "if the 'V' big is enabled)". Requested change: Add the text to the end of the four lines. From owner-aaa-wg@merit.edu Fri Sep 14 02:39: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 CAA10723 for ; Fri, 14 Sep 2001 02:39:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2EC6C913DC; Fri, 14 Sep 2001 02:38:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBA7B913E1; Fri, 14 Sep 2001 02:38: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 D65DC913DC for ; Fri, 14 Sep 2001 02:38:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A46B55DDE4; Fri, 14 Sep 2001 02:38:32 -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 04F795DDC1 for ; Fri, 14 Sep 2001 02:38:32 -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.10.1/WIREfire-1.3) with SMTP id f8E6cUv05683 for ; Fri, 14 Sep 2001 08:38:30 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Sep 14 08:38:30 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 08:38:30 +0200 Message-ID: <577066326047D41180AC00508B955DDA02C00B09@eestqnt104.es.eu.ericsson.se> From: "Yolanda Garcia-Serrano (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: [issue] Date: Fri, 14 Sep 2001 08:38: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 Submitter name: Yolanda Garcia Submitter email address: Yolanda.Garcia-Serrano@ece.ericsson.se Date first submitted: 2001-09-14 Reference: Document: Base-07 Comment type: T Priority: S Section: 2.5, 5.3, 6.9, 6.10 Rationale/Explanation of issue: Diameter Nodes MUST advertise locally supported applications. This must be done including at least an Auth-Application-Id AVP or an Acct-Application-Id AVPs in CER and CEA messages, otherwise there is no way a receiver of a CER message detect whether it has any application in common with the sender. Requested change: Add clariying text at least in sections 5.3.1 and 5.3.2 From owner-aaa-wg@merit.edu Fri Sep 14 04: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 EAA13467 for ; Fri, 14 Sep 2001 04:53:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02075913F0; Fri, 14 Sep 2001 04:52:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6BEB913F2; Fri, 14 Sep 2001 04:52: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 6EB07913F0 for ; Fri, 14 Sep 2001 04:52:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4487F5DE0B; Fri, 14 Sep 2001 04:52:44 -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 5BCCF5DE07 for ; Fri, 14 Sep 2001 04:52:43 -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.10.1/WIREfire-1.3) with ESMTP id f8E8qfv12642 for ; Fri, 14 Sep 2001 10:52:41 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA23974; Fri, 14 Sep 2001 10:52:31 +0200 (MET DST) Message-ID: <3BA1C568.347C5635@rioja.ericsson.se> Date: Fri, 14 Sep 2001 10:52:56 +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: [AAA-WG]: [issue] CMS proxy scenarios Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-14 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00229.html Document: CMS-02 Comment type: T Priority: 2 Section: 1.2, 4.3 Rationale/Explanation of issue: As agreed in the discussion of issue 136, the description of two scenarios regarding CMS proxies was introduced in the draft. These scenarios are just examples, so that additional scenarios might be considered. I've noticed that there might exist another scenario. Let's consider a local AAA server that has to forward authentication request from user that don't belong to its realm. It seems reasonable that the AAA server establishes DSAs with other realms automatically (that is, without any PDSA request from the clients). The local AAA server would decide, accoding to its policies, with which realms it must establish a DSA. This scenario seems reasonable since it puts the intelligence of the system in the Diameter node and not in the client. As a consecuence, at least three scenarios could be described. The two escenarios also covered by the draft (as agreed on issue 136's discussion): - The access device does not have the cryptographic ability to handle the CMS functions locally, and therefore requests such services from the local agent, such an an aggregating relay or proxy agent. The NAS may have been configured to always issue a PDSR to its local agent for CMS services. In such cases, the agent MUST select the values for the DSA-TTL and provide the appropriate Local-CA-Info and the expected OCSP response from the DSA peer. - The access device has the cryptographic ability to perform the CMS functions, but a proxy agent is in the route towards the home server, and it returned a failure to the DSAR messages stating that it was not willing to allow the DSA to traverse through it. Such agents MAY attempt to re-use the values from the initial DSAR sent by the access device. And an additional scenario (which IMHO could be even more common): - The access device does not have the cryptographic ability to handle the CMS functions locally but does not request such services from the local agent. Instead, the local agent has been configured to establish DSAs with certain realms in an automatic way, so that the existence of DSAs is transparent for the access device. Requested change: Add such scenario to the draft. However, as this new scenario doesn't requires a previous PDSA request, it looks like that this scenario shouldn't be added to section 4.3 but to section 1.2. And that's a problem, since Pat already stated that in order to add the scenarios to section 1.2 a major "surgery taks" might be necessary. If Pat and the rest of the WG agrees on adding this issue, I'll be able to carry out this task. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 14 06:19: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 GAA14055 for ; Fri, 14 Sep 2001 06:19:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0731A9140B; Fri, 14 Sep 2001 06:18:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2FF9913FC; Fri, 14 Sep 2001 06:18: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 A63DE913F8 for ; Fri, 14 Sep 2001 06:18:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 887565DE04; Fri, 14 Sep 2001 06:18:00 -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 AE8685DD93 for ; Fri, 14 Sep 2001 06:17:59 -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 f8EAHvK16366 for ; Fri, 14 Sep 2001 12:17:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA04523; Fri, 14 Sep 2001 12:17:54 +0200 (MET DST) Message-ID: <3BA1D96C.112F348E@rioja.ericsson.se> Date: Fri, 14 Sep 2001 12:18:20 +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: [AAA-WG]: [issue] Partial support of CMS Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-14 Reference: Document: CMS-02. ¿base? Comment type: T Priority: S Section: Rationale/Explanation of issue: One of the scenarios described in section 4.3 introduces the concept of a client without cryptographic abilities but able to send a PDSA request (and process a PDSA answer). My concern is the following: does this client actually support CMS (that is, can it include a value of '2' in the capabilities exchange?) I don't think so. However, it must support the messages that are needed to request a proxy a DSA on its behalf. Requested change: A clarifying text about it such clients can advertise that they support CMS when they can't actually do it? As a consecuence, maybe it would be more reasonable to move PDSAR and PDSAA to the base specification, so that a base support would include such messages (I don't really like this proposal, but IMHO it's the more coherent). 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 14 06:41: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 GAA14272 for ; Fri, 14 Sep 2001 06:41:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19314913F6; Fri, 14 Sep 2001 06:41:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D208F913F8; Fri, 14 Sep 2001 06:41: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 AA779913F6 for ; Fri, 14 Sep 2001 06:41:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C6A75DE0A; Fri, 14 Sep 2001 06:41:12 -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 A08415DD93 for ; Fri, 14 Sep 2001 06:41:11 -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 f8EAf9K03992 for ; Fri, 14 Sep 2001 12:41:09 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA07303; Fri, 14 Sep 2001 12:41:05 +0200 (MET DST) Message-ID: <3BA1DEDB.CBA03B66@rioja.ericsson.se> Date: Fri, 14 Sep 2001 12:41:31 +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: [AAA-WG]: [issue] AAA-Server-Certs References: <3B976DFB.51659365@rioja.ericsson.se> <3B98D97A.48CB66D0@rioja.ericsson.se> <00a501c137c9$27933ec0$8a1b6e0a@arenanet.fi> <3B9C6B68.BBBECA12@rioja.ericsson.se> <3B9CC057.52B20C3C@lmf.ericsson.se> <3B9CC5AE.1CEC9023@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 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. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 14 08:40: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 IAA16741 for ; Fri, 14 Sep 2001 08:40:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B010913FA; Fri, 14 Sep 2001 08:40:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07C6C9140A; Fri, 14 Sep 2001 08:40: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 E2997913FA for ; Fri, 14 Sep 2001 08:40:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6D275DE08; Fri, 14 Sep 2001 08:40:02 -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 E93365DE07 for ; Fri, 14 Sep 2001 08:40:01 -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.10.1/WIREfire-1.3) with ESMTP id f8ECdtv14693 for ; Fri, 14 Sep 2001 14:39:56 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA20194; Fri, 14 Sep 2001 14:39:51 +0200 (MET DST) Message-ID: <3BA1FAB2.21379235@rioja.ericsson.se> Date: Fri, 14 Sep 2001 14:40:18 +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: [AAA-WG]: CMS Decryption Error References: <3B9E304B.4729227D@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 Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-14 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02095.html Document: CMS-02 Comment type: T Priority: 2 Section: 6.2 Rationale/Explanation of issue: In the list of errors provided in the reference message, the error situation 19 states no error code: > 19. A Diameter message arrives containing a CMS-Encrypted-Data AVP and > an error occurs during decryption. > Error code issued: > Definition of the error: > Included in CMS-02 draft: No > Included in CMS-03 draft: > Status: proposal needed. After some reflexion time, I've noticed that there is no way to distinguish between an error decryption and an error in the AVPs extracted. As far as I know, the extracted AVPs are just a bit stream that has to be parsed. If the CMS-Encrypted-Data AVP has been modified, the only result is that the bit stream would be parsed since the extracted AVPs would be invalid. My proposal is that only a DIAMENTER_INVALID_AVP_VALUE would be issued, including the CMS-Encrypted-Data AVP as Failed-AVP AVP. Requested change: Replace the following sentence in 6.2: ...and an error occurs during decryption, then the recipient MUST indicate an error. with the following: ...and an error occurs during decryption, then the recipient MUST indicate an error by means of the DIAMETER_INVALID_AVP_VALUE result code and including the CMS-Encrypted-Data AVP as Failed-AVP AVP. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Fri Sep 14 10:05: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 KAA18140 for ; Fri, 14 Sep 2001 10:05:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7F639121E; Fri, 14 Sep 2001 10:04:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75E4991418; Fri, 14 Sep 2001 10:04: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 450D29121E for ; Fri, 14 Sep 2001 10:04:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29CEF5DDBA; Fri, 14 Sep 2001 10:04:45 -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 7E31F5DD8C for ; Fri, 14 Sep 2001 10:04:44 -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 f8EE4hK11007 for ; Fri, 14 Sep 2001 16:04:43 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA28782; Fri, 14 Sep 2001 16:04:40 +0200 (MET DST) Message-ID: <3BA20E93.9BC670E0@rioja.ericsson.se> Date: Fri, 14 Sep 2001 16:05:07 +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: [AAA-WG]: [issue] PDSA-Request without DSA-Target-Realm Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit 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: 1 Section: 1.2 Rationale/Explanation of issue: The possibility of issueing a PDSA request without a DSA-Target-Realm has been suggested as an optimized approach that allows to avoid a explicit PDSA with any desired realm. However, there are some points that remain unclear (IMHO): - When does the proxy establish a DSA? As an initial establishment with all the realms isn't possible, I suppose that every time the client request an authorisation operation regarding a user, the proxy must detect the operation and establish a DSA before forwarding the authorisation message. - Does the proxy has to establish a DSA with any realm? I don't think so, since it may not be allowed by the proxy's local policies. - What happens when one of such DSA fails? Or whether the proxy doesn't support a DSA with the required realm? Or even whether there is a another proxy on the route that issues a NOT_CMS_THROUGH_PROXY result code? Do the proxy have to indicate it to the client, issuing an appropriate answer with a given result-code (maybe DIAMETER_NO_DSA_ESTABLISHED)? Or it must forward the message without warning the client? - Are all the clients equal? I mean, does the proxy have to record on behalf of which client it is establishing a DSA (what might involve several DSAs with the same realm on behalf of different clients)? - What happens when the DSA expires? Does the proxy have to re-establish it without any indication from the client. If so, the third model suggested in one of my previous issues would be better (no explicit PDSAR to begin a DSA but just local policies of the proxy). Requested change: a) Replace the following paragraph: An optimized approach also allows the PDSR to be sent by the access device without the DSAR-Target-Realm AVP. This message is used to inform the proxy that it MUST establish a Diameter security association for all realms it will be communicating with on behalf of the access device. with something like the following: An optimized approach also allows the PDSAR to be sent by the access device without the DSAR-Target-Realm AVP. This message is used to inform the proxy that it MUST establish a Diameter security association for all realms it will be communicating with on behalf of the access device. Such DSA MUST be established only first time a message must be routed to a given realm. It may happen that this DSA can not be established. For example, the proxy might be configured not to establish DSAs with the required realm, the DSA setup migh fail or there is a proxy agent in the route towards the home server, and it returned a failure to the DSAR messages stating that it was not willing to allow the DSA to traverse through it. In such situations, the proxy MUST reject the message, but set the Result-Code AVP to DIAMETER_NO_DSA_ESTABLISHED. If several access device send a PDSAR without the DSAR-Target-Realm AVP, only one DSA per realm MUST be established. b) Add clarifying text regarding what happens when the DSA expires. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Sat Sep 15 10: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 KAA20565 for ; Sat, 15 Sep 2001 10:46:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A519491251; Sat, 15 Sep 2001 10:45:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B1BC91253; Sat, 15 Sep 2001 10:45: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 5476E91251 for ; Sat, 15 Sep 2001 10:45:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40B955DDD1; Sat, 15 Sep 2001 10:45: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 ADFED5DDB1 for ; Sat, 15 Sep 2001 10:45:29 -0400 (EDT) Received: (qmail 14219 invoked by uid 500); 15 Sep 2001 14:32:03 -0000 Date: Sat, 15 Sep 2001 07:32:03 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 160: Destination-Host in PDSR Message-ID: <20010915073203.B14171@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 agree with this issue, and propose adding the last sentence: - The access device has the cryptographic ability to perform the CMS functions, but a proxy agent is in the route towards the home server, and it returned a failure to the DSAR messages stating that it was not willing to allow the DSA to traverse through it. Such agents MAY attempt to re-use the values from the initial DSAR sent by the access device. In such cases,the PDSR initiator SHOULD include the Destination-Host AVP to ensure that the PDSR is received by the same proxy agent. Of course, the ABNF is also modified to include the Destination-Host AVP as an optional AVP. PatC From owner-aaa-wg@merit.edu Sat Sep 15 10:49: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 KAA20597 for ; Sat, 15 Sep 2001 10:49:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7222D91253; Sat, 15 Sep 2001 10:49:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4816491255; Sat, 15 Sep 2001 10:49: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 2996791253 for ; Sat, 15 Sep 2001 10:49:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E61C5DDD1; Sat, 15 Sep 2001 10:49: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 C23625DDB1 for ; Sat, 15 Sep 2001 10:49:29 -0400 (EDT) Received: (qmail 14238 invoked by uid 500); 15 Sep 2001 14:36:03 -0000 Date: Sat, 15 Sep 2001 07:36:03 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 162: Error replies to requests with no session id Message-ID: <20010915073603.C14171@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 Interesting issue. How about we define the following in the ABNF: ( AVP ) Where () means that if present, the location is fixed? That seems like the best fix, IMHO. PatC From owner-aaa-wg@merit.edu Sat Sep 15 10:52: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 KAA20634 for ; Sat, 15 Sep 2001 10:52:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A668691255; Sat, 15 Sep 2001 10:52:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7226291258; Sat, 15 Sep 2001 10: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 57C5291255 for ; Sat, 15 Sep 2001 10:52:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4433E5DDD1; Sat, 15 Sep 2001 10:52: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 F0E125DDB1 for ; Sat, 15 Sep 2001 10:52:21 -0400 (EDT) Received: (qmail 14255 invoked by uid 500); 15 Sep 2001 14:38:55 -0000 Date: Sat, 15 Sep 2001 07:38:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 166: Ambiquity on Destination-Host AVP in Answer messages Message-ID: <20010915073855.D14171@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 was fixed quite some time ago via another issue. I have already addressed all of the drafts, so I will close this issue. PatC From owner-aaa-wg@merit.edu Sat Sep 15 11:03: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 LAA20689 for ; Sat, 15 Sep 2001 11:03:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00DEA91259; Sat, 15 Sep 2001 11:03:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2C749125C; Sat, 15 Sep 2001 11:03: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 A048891259 for ; Sat, 15 Sep 2001 11:03:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E2745DDD1; Sat, 15 Sep 2001 11:03: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 0D5B15DDB1 for ; Sat, 15 Sep 2001 11:03:35 -0400 (EDT) Received: (qmail 14274 invoked by uid 500); 15 Sep 2001 14:50:08 -0000 Date: Sat, 15 Sep 2001 07:50:07 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 158: DSA error codes (III) Message-ID: <20010915075007.E14171@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've made the following changes to the text to address this issue: When a conforming implementation receives a Diameter message which contains encrypted AVPs within a CMS EnvelopedData, 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 return an answer with the Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST answer with the Result-Code set to DIAMETER_DSA_DECRYPTION_FAILED. and added the error codes: DIAMETER_DSA_DECRYPTION_FAILED 5023 A Diameter message was received with encrypted data, and the decryption process was unsuccessful. DIAMETER_NO_DSA_RECIPIENT 5024 A Diameter message was received with encrypted data, and the local Diameter node is not a potential recipient of the EnvelopedData. Thanks, PatC From owner-aaa-wg@merit.edu Sat Sep 15 11:15:28 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 LAA20770 for ; Sat, 15 Sep 2001 11:15:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 62FB29125C; Sat, 15 Sep 2001 11:14:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EB1B9125D; Sat, 15 Sep 2001 11:14: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 0820A9125C for ; Sat, 15 Sep 2001 11:14:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF80B5DDD3; Sat, 15 Sep 2001 11:14:50 -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 9BEE65DDB1 for ; Sat, 15 Sep 2001 11:14:50 -0400 (EDT) Received: (qmail 14309 invoked by uid 500); 15 Sep 2001 15:01:24 -0000 Date: Sat, 15 Sep 2001 08:01:24 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 164: problems with Watch Dog Message-ID: <20010915080124.F14171@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 authors of the issue are correct that the pseudo-code doesn't reflect the text in 5.1. So, I propose adding the following field to the PCB in 5.5.3: wdRecoveryCount - This field contains the number of DWAs received from a peer once the PCB's state is in the SUSPECT state. Then changes are made to the pseudo-code to handle this case: /* * OnReceiveDWA() is called whenever a DWA is received * from the peer. */ OnReceiveDWA(pcb) { if pcb->Status == SUSPECT if pcb->wdRecoveryCount == 3 pcb->wdRecoveryCount = 0 pcb->Status = OKAY else pcb->wdRecoveryCount++ else if pcb->Status != INACTIVE if pcb->Pending T = Tr else T = Ti } /* * OnTimerElapsed() is called by some timer services * whenever T reaches zero (0). */ 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->wdRecoveryCount == 3 StopConnection(pcb) FailoverProcedures(pcb) else SendWatchdog(pcb) } I believe this resolves the issue. Comments? PatC From owner-aaa-wg@merit.edu Sat Sep 15 11:25: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 LAA20846 for ; Sat, 15 Sep 2001 11:25:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 588559125D; Sat, 15 Sep 2001 11:25:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 203C59125F; Sat, 15 Sep 2001 11:25: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 A33BD9125D for ; Sat, 15 Sep 2001 11:25:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F3F55DDD3; Sat, 15 Sep 2001 11:25: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 3EA0D5DDB1 for ; Sat, 15 Sep 2001 11:25:24 -0400 (EDT) Received: (qmail 14329 invoked by uid 500); 15 Sep 2001 15:11:58 -0000 Date: Sat, 15 Sep 2001 08:11:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 165: Expiration of DSAs on behalf of a client Message-ID: <20010915081158.G14171@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 accept this issue, and have made the appropriate changes as requested in the CMS document. PatC From owner-aaa-wg@merit.edu Sat Sep 15 11:27: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 LAA20871 for ; Sat, 15 Sep 2001 11:27:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3B979125F; Sat, 15 Sep 2001 11:26:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7796C91260; Sat, 15 Sep 2001 11:26: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 530F39125F for ; Sat, 15 Sep 2001 11:26:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A4605DDD3; Sat, 15 Sep 2001 11:26: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 DA9295DDB1 for ; Sat, 15 Sep 2001 11:26:56 -0400 (EDT) Received: (qmail 14346 invoked by uid 500); 15 Sep 2001 15:13:30 -0000 Date: Sat, 15 Sep 2001 08:13:30 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 172: The need for Float128? Message-ID: <20010915081330.H14171@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 AVP type was added by the data type folks since it exists in other protocols, and we were attempting to simply reuse what is already defined out there. If the WG agrees to delete this type, I'm ok with it, but I really hate to re-open the whole data type can of worms :( PatC From owner-aaa-wg@merit.edu Sun Sep 16 10:51: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 KAA12460 for ; Sun, 16 Sep 2001 10:51:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B8D091362; Sun, 16 Sep 2001 10:49:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A8891334; Sun, 16 Sep 2001 10:49: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 5BF619129D for ; Sun, 16 Sep 2001 10:49:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50DAE5DE27; Sun, 16 Sep 2001 10:49: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 C3C365DDE6 for ; Sun, 16 Sep 2001 10:49:46 -0400 (EDT) Received: (qmail 21180 invoked by uid 500); 16 Sep 2001 14:36:13 -0000 Date: Sun, 16 Sep 2001 07:36:13 -0700 From: Pat Calhoun To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue]: Missing text in float definitions. Message-ID: <20010916073613.G14511@charizard.diameter.org> Mail-Followup-To: Mark Eklund , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from meklund@cisco.com on Thu, Sep 13, 2001 at 02:17:39PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk I have addressed this nroff bug, and closed this issue. PatC On Thu, Sep 13, 2001 at 02:17:39PM -0400, Mark Eklund wrote: > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 9/13/01 > Document: base-07 > Comment type: Editorial > Priority: Should fix > Section: 4.3 > Explanation of issue: > > The definitions of Float32, Float64, and Float128 in the base > draft all are missing the sentence fragment "if the 'V' big is > enabled)". > > Requested change: > > Add the text to the end of the four lines. > > > From owner-aaa-wg@merit.edu Sun Sep 16 10:52: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 KAA12485 for ; Sun, 16 Sep 2001 10:52:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DF1891285; Sun, 16 Sep 2001 10:52:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 893049128F; Sun, 16 Sep 2001 10:52: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 4E76E91289 for ; Sun, 16 Sep 2001 10:51:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 471095DE49; Sun, 16 Sep 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 EEB885DE33 for ; Sun, 16 Sep 2001 10:51:28 -0400 (EDT) Received: (qmail 21188 invoked by uid 500); 16 Sep 2001 14:37:41 -0000 Date: Sun, 16 Sep 2001 07:37:41 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Decryption Error Message-ID: <20010916073741.H14511@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B9E304B.4729227D@rioja.ericsson.se> <3BA1FAB2.21379235@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BA1FAB2.21379235@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Fri, Sep 14, 2001 at 02:40:18PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit I have addressed this issue, which conflicted with another issue by Miguel. I assume that this issue overrides a portion of issue 158, to which I posted proposed text at http://www.merit.edu/mail.archives/aaa-wg/msg02114.html. PatC On Fri, Sep 14, 2001 at 02:40:18PM +0200, Miguel Ángel Monjas Llorente wrote: > Submitter name: Miguel A. Monjas > Submitter email address: ecemaml@rioja.es.eu.ericsson.se > Date first submitted: 2001-09-14 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02095.html > Document: CMS-02 > Comment type: T > Priority: 2 > Section: 6.2 > Rationale/Explanation of issue: > > In the list of errors provided in the reference message, the error > situation 19 states no error code: > > > 19. A Diameter message arrives containing a CMS-Encrypted-Data AVP and > > an error occurs during decryption. > > Error code issued: > > Definition of the error: > > Included in CMS-02 draft: No > > Included in CMS-03 draft: > > Status: proposal needed. > > After some reflexion time, I've noticed that there is no way to > distinguish between an error decryption and an error in the AVPs > extracted. As far as I know, the extracted AVPs are just a bit stream > that has to be parsed. If the CMS-Encrypted-Data AVP has been > modified, the only result is that the bit stream would be parsed since > the extracted AVPs would be invalid. > > My proposal is that only a DIAMENTER_INVALID_AVP_VALUE would be > issued, including the CMS-Encrypted-Data AVP as Failed-AVP AVP. > > Requested change: > > Replace the following sentence in 6.2: > > ...and an error occurs during decryption, then the > recipient MUST indicate an error. > > with the following: > > ...and an error occurs during decryption, then the > recipient MUST indicate an error by means of the > DIAMETER_INVALID_AVP_VALUE result code and including > the CMS-Encrypted-Data AVP as Failed-AVP AVP. > > 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 > Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Sun Sep 16 10:55: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 KAA12511 for ; Sun, 16 Sep 2001 10:55:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87F7291281; Sun, 16 Sep 2001 10:54:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55A5E91289; Sun, 16 Sep 2001 10:54: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 E461F91281 for ; Sun, 16 Sep 2001 10:54:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D912F5DE27; Sun, 16 Sep 2001 10:54: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 963975DDE6 for ; Sun, 16 Sep 2001 10:54:49 -0400 (EDT) Received: (qmail 21208 invoked by uid 500); 16 Sep 2001 14:41:16 -0000 Date: Sun, 16 Sep 2001 07:41:16 -0700 From: Pat Calhoun To: "Yolanda Garcia-Serrano (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: [issue] Message-ID: <20010916074116.I14511@charizard.diameter.org> Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA02C00B09@eestqnt104.es.eu.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: <577066326047D41180AC00508B955DDA02C00B09@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Fri, Sep 14, 2001 at 08:38:21AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk May I inquire why the supporting text in section 5.3 is not sufficient? Can we not simply assume that the reader will read 5.3 before 5.3.1 and 5.3.2, and make the connection? PatC On Fri, Sep 14, 2001 at 08:38:21AM +0200, Yolanda Garcia-Serrano (ECE) wrote: > Submitter name: Yolanda Garcia > Submitter email address: Yolanda.Garcia-Serrano@ece.ericsson.se > Date first submitted: 2001-09-14 > Reference: > Document: Base-07 > Comment type: T > Priority: S > Section: 2.5, 5.3, 6.9, 6.10 > Rationale/Explanation of issue: > > Diameter Nodes MUST advertise locally supported applications. This must be done > including at least an Auth-Application-Id AVP or an Acct-Application-Id AVPs in > CER and CEA messages, otherwise there is no way a receiver of a CER message detect > whether it has any application in common with the sender. > > Requested change: > > Add clariying text at least in sections 5.3.1 and 5.3.2 From owner-aaa-wg@merit.edu Sun Sep 16 11:41: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 LAA13050 for ; Sun, 16 Sep 2001 11:41:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BC6A91299; Sun, 16 Sep 2001 11:40:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B927191367; Sun, 16 Sep 2001 11:40: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 E560791299 for ; Sun, 16 Sep 2001 11:40:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF6D05DE27; Sun, 16 Sep 2001 11:40: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 276FD5DDE6 for ; Sun, 16 Sep 2001 11:40:35 -0400 (EDT) Received: (qmail 21276 invoked by uid 500); 16 Sep 2001 15:27:02 -0000 Date: Sun, 16 Sep 2001 08:27:02 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] CMS proxy scenarios Message-ID: <20010916082702.J14511@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3BA1C568.347C5635@rioja.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: <3BA1C568.347C5635@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Fri, Sep 14, 2001 at 10:52:56AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Although I tried hard to avoid re-writing this section, after reading 1.2 some more, I found some inconsistencies, so a re-write was probably in the best interest of the WG :( So, I've followed Miguel's proposed approach, and propose the following text (of course, I removed the scenarios from section 4.3): 1.2 Establishing Security Relationship through proxy agents As previously discussed, proxy agents typically modify Diameter messages to implement policy enforcement. An example of a proxy server would be an aggregating server, which typically sits one Diameter hop away from the access device, and enforces policy in order to protect the access device from receiving AVPs that could cause harm (e.g. excessive number of filters, unsupported tunneling protocol). Although in theory such checks could be performed on the access device, these devices are typically embedded systems, and not easily configurable. The proxy agent's behavior, on the other hand, is typically under control of the network operator. Diameter messages between two participants of a DSA would fail verification if a proxy agent were to modify any protected AVPs. Therefore proxy agents either MUST NOT modify protected AVPs or else MUST NOT allow the DSA to be established. In this section, we discuss the capabilities provided by this Diameter application which allow proxy agents to secure AVPs on behalf of an access device. The following scenarios are envisioned: - The access device does not have the cryptographic ability to handle the CMS functions locally, and therefore requests such services from the local agent, such an an aggregating relay or proxy agent. The NAS may have been configured to always issue a PDSR to its local agent for CMS services. In such cases, the agent MUST select the values for the DSA-TTL and provide the appropriate Local-CA-Info and the expected OCSP response from - The access device has the cryptographic ability to perform the CMS functions, but a proxy agent is in the route towards the home server, and it returned a failure to the DSAR messages stating that it was not willing to allow the DSA to traverse through it. Such agents MAY attempt to re-use the values from the initial DSAR sent by the access device. In such cases,the PDSR initiator SHOULD include the Destination-Host AVP to ensure that the PDSR is received by the same proxy agent. - The access device MAY have the cryptographic ability to perform CMS functions locally, but does not request a DSAR to request a DSA. The local agent, however, has been configured to establish DSAs with certain realms automatically, hiding the existence of the DSAs from the access device. In the above scenarios, the first two occur at the explicit request of the access device, while the last one occurs without any messaging from the access device. In the latter case, the proxy agent acts as an access device of sorts and the rules in section 1.1 should be used instead. When a local agent receives a DSAR, it has the following options: - The local agent rejects all DSARs by sending a DSAA message whose Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY. The DSAA SHOULD include the CMS-Signed-Data AVP, signed by the proxy agent, and include its certificate to allow the access device to validate the originator of the DSAA. The access device can then determine whether it is willing to provide service, based on its local policy. - The local agent rejects all DSARs by sending a DSAA message whose Result-Code AVP is set to DIAMETER_CAN_ACT_AS_CMS_PROXY, informing the access device that the agent is willing to establish the DSA on its behalf. The DSAA MUST include the CMS- Signed-Data AVP, signed by the proxy agent, and include its certificate to allow the access device to validate the originator of the DSAA. If the access device is willing to use the agent's services, which it could be configured to only accept such DSAA messages from agents within its realm, it issues a Proxy-Diameter-Security-Association-Request (PDSR) which MUST contain the target realm. The local agent MAY use any of the parameters provided by the access device in the previous DSAR attempt when establishing the DSA. Once the DSA is established, the agent MUST issue a Proxy-Diameter-Security- Association-Answer (PDSA). The PDSA MUST contain the TTL setting agreed by the proxy agent for its DSA. This information will allow the access device to re-issue a PDSR prior to the proxy's DSA if it needs the DSA to remain active. Note that an access device MAY be configured to always issue a PDSR to its aggregating proxy, reducing the number of round trips. Similarly, an aggregating proxy MAY be configured to initiate an DSAR regardless of whether a PDSR was sent by the access device. mno.net mno.net xyz.net abc.com +------+ +------+ +------+ +------+ | | |Proxy | |Relay | | Home | | NAS | | | | | | | | | |Agent | |Agent | |Server| +------+ +------+ +------+ +------+ -------------> (DSAR) Destination-Realm = abc.com <------------- (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY -------------> (PDSR) DSAR-Target-Domain = abc.com ----------------------------> (DSAR) Destination-Realm = abc.com <---------------------------- (DSAA) Result-Code = DIAMETER_SUCCESS <------------- (PDSA) Result-Code = DIAMETER_SUCCESS Figure 3: Establishing Security through Proxy Agent An optimized approach also allows the PDSR to be sent by the access device without the DSAR-Target-Domain AVP. This message is used to inform the proxy that it MUST establish a Diameter security association for all realms it will be communicating with on behalf of the access device. Allowing the first hop agent to be used to establish the DSA with the home server MAY reduce the current concerns that the cryptographic operations resulting from this specification MAY overburden embedded access devices. Comments appreciated, PatC From owner-aaa-wg@merit.edu Sun Sep 16 11:47: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 LAA13107 for ; Sun, 16 Sep 2001 11:47:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 000E89128C; Sun, 16 Sep 2001 11:46:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8456D9128D; Sun, 16 Sep 2001 11:46: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 4BB149128C for ; Sun, 16 Sep 2001 11:46:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E62F5DE27; Sun, 16 Sep 2001 11:46: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 ECE015DDE6 for ; Sun, 16 Sep 2001 11:46:33 -0400 (EDT) Received: (qmail 21292 invoked by uid 500); 16 Sep 2001 15:33:00 -0000 Date: Sun, 16 Sep 2001 08:33:00 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: WG Consensus check: Re: [AAA-WG]: [issue] Partial support of CMS Message-ID: <20010916083300.K14511@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3BA1D96C.112F348E@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BA1D96C.112F348E@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Fri, Sep 14, 2001 at 12:18:20PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Folks, my inclination is to not make this change, but I think that it deserves input from the WG. We have a couple of options here: 1. Move the PDSR to the base protocol spec, as suggested below. 2. Add clarifying text to the CMS spec stating that a compliant node MAY only need to support the PDSR/PDSA messages. 3. Split the CMS spec into two (my least favorite) 4. Have the CMS spec include a two application-Id (this would be broken, btw) so I don't believe we should take this approach. 5. leave it as is. my preference is #2 above. Comments from the WG please. PatC On Fri, Sep 14, 2001 at 12:18:20PM +0200, Miguel Ángel Monjas Llorente wrote: > Submitter name: Miguel A. Monjas > Submitter email address: ecemaml@rioja.es.eu.ericsson.se > Date first submitted: 2001-09-14 > Reference: > Document: CMS-02. ¿base? > Comment type: T > Priority: S > Section: > Rationale/Explanation of issue: > > One of the scenarios described in section 4.3 introduces the concept > of a client without cryptographic abilities but able to send a PDSA > request (and process a PDSA answer). > > My concern is the following: does this client actually support CMS > (that is, can it include a value of '2' in the capabilities exchange?) > I don't think so. However, it must support the messages that are > needed to request a proxy a DSA on its behalf. > > Requested change: > > A clarifying text about it such clients can advertise that they > support CMS when they can't actually do it? As a consecuence, maybe it > would be more reasonable to move PDSAR and PDSAA to the base > specification, so that a base support would include such messages (I > don't really like this proposal, but IMHO it's the more coherent). > > 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 > Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Sun Sep 16 11:58: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 LAA13234 for ; Sun, 16 Sep 2001 11:58:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46BA49128B; Sun, 16 Sep 2001 11:58:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C3C99128D; Sun, 16 Sep 2001 11:58: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 EE40B9128B for ; Sun, 16 Sep 2001 11:58:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E289D5DE31; Sun, 16 Sep 2001 11:58: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 5AAFD5DDE6 for ; Sun, 16 Sep 2001 11:58:42 -0400 (EDT) Received: (qmail 21319 invoked by uid 500); 16 Sep 2001 15:45:09 -0000 Date: Sun, 16 Sep 2001 08:45:09 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] PDSA-Request without DSA-Target-Realm Message-ID: <20010916084509.L14511@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3BA20E93.9BC670E0@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BA20E93.9BC670E0@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Fri, Sep 14, 2001 at 04:05:07PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit How about the following text instead (which is a variant of the text sent by Miguel): An optimized approach also allows the PDSR to be sent by the access device without the DSAR-Target-Realm AVP. This message is used to inform the proxy that it MUST establish a Diameter security association for all realms it will be communicating with on behalf of the access device. DSAs are typically established once the first request for a given realm has been recelived by the proxy agent, but it MAY establish certain DSAs with known realm in advance. If a DSA for a given realm cannot be established, the proxy agent MUST reject the access device's request, and set the Result-Code AVP to DIAMETER_NO_DSA_ESTABLISHED. Although the proxy agent MAY receive many PDSRs from access devices, only one DSA per realm MUST be established. Furthermore, the PDSR is responsible for re-establishing the DSA prior to expiration without any involvement by the access device. PatC On Fri, Sep 14, 2001 at 04:05:07PM +0200, Miguel Ángel Monjas Llorente wrote: > 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: 1 > Section: 1.2 > Rationale/Explanation of issue: > > The possibility of issueing a PDSA request without a DSA-Target-Realm > has been suggested as an optimized approach that allows to avoid a > explicit PDSA with any desired realm. > > However, there are some points that remain unclear (IMHO): > > - When does the proxy establish a DSA? As an initial establishment > with all the realms isn't possible, I suppose that every time the > client request an authorisation operation regarding a user, the proxy > must detect the operation and establish a DSA before forwarding the > authorisation message. > > - Does the proxy has to establish a DSA with any realm? I don't think > so, since it may not be allowed by the proxy's local policies. > > - What happens when one of such DSA fails? Or whether the proxy > doesn't support a DSA with the required realm? Or even whether there > is a another proxy on the route that issues a NOT_CMS_THROUGH_PROXY > result code? Do the proxy have to indicate it to the client, issuing > an appropriate answer with a given result-code (maybe > DIAMETER_NO_DSA_ESTABLISHED)? Or it must forward the message without > warning the client? > > - Are all the clients equal? I mean, does the proxy have to record on > behalf of which client it is establishing a DSA (what might involve > several DSAs with the same realm on behalf of different clients)? > > - What happens when the DSA expires? Does the proxy have to > re-establish it without any indication from the client. If so, the > third model suggested in one of my previous issues would be better (no > explicit PDSAR to begin a DSA but just local policies of the proxy). > > Requested change: > > a) Replace the following paragraph: > > An optimized approach also allows the PDSR to be sent by the access > device without the DSAR-Target-Realm AVP. This message is used to > inform the proxy that it MUST establish a Diameter security > association for all realms it will be communicating with on behalf > of the access device. > > with something like the following: > > An optimized approach also allows the PDSAR to be sent by the > access > device without the DSAR-Target-Realm AVP. This message is used to > inform the proxy that it MUST establish a Diameter security > association for all realms it will be communicating with on behalf > of the access device. Such DSA MUST be established only first time > a message must be routed to a given realm. > > It may happen that this DSA can not be established. For example, > the proxy might be configured not to establish DSAs with the > required > realm, the DSA setup migh fail or there is a proxy agent in the > route towards the home server, and it returned a failure to the > DSAR messages stating that it was not willing to allow the DSA to > traverse through it. In such situations, the proxy MUST reject the > message, but set the Result-Code AVP to > DIAMETER_NO_DSA_ESTABLISHED. > > If several access device send a PDSAR without the DSAR-Target-Realm > AVP, only one DSA per realm MUST be established. > > b) Add clarifying text regarding what happens when the DSA expires. > > 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 > Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Sun Sep 16 16:44: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 QAA14974 for ; Sun, 16 Sep 2001 16:44:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F83D91291; Sun, 16 Sep 2001 14:15:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 512929130F; Sun, 16 Sep 2001 14:15: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 2C2E491291 for ; Sun, 16 Sep 2001 14:15:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC3B25DD92; Sun, 16 Sep 2001 14:15:24 -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 183CC5DD8F for ; Sun, 16 Sep 2001 14:15:24 -0400 (EDT) Received: from jariws1 ([62.248.155.144]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010916181515.YQFM26796.fep02-app.kolumbus.fi@jariws1>; Sun, 16 Sep 2001 21:15:15 +0300 Message-ID: <04c401c13edb$992ce220$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: References: <3BA1D96C.112F348E@rioja.ericsson.se> <20010916083300.K14511@charizard.diameter.org> Subject: Re: WG Consensus check: Re: [AAA-WG]: [issue] Partial support of CMS Date: Sun, 16 Sep 2001 21:15:42 +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 > 1. Move the PDSR to the base protocol spec, as suggested below. > 2. Add clarifying text to the CMS spec stating that a compliant node > MAY only need to support the PDSR/PDSA messages. > 3. Split the CMS spec into two (my least favorite) > 4. Have the CMS spec include a two application-Id (this would be broken, btw) > so I don't believe we should take this approach. > 5. leave it as is. My preference is also #2. Jari From owner-aaa-wg@merit.edu Mon Sep 17 04:24: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 EAA06304 for ; Mon, 17 Sep 2001 04:24:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE78791282; Mon, 17 Sep 2001 04:23:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6007912DC; Mon, 17 Sep 2001 04:23: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 9FDEC91282 for ; Mon, 17 Sep 2001 04:23:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9402D5DD99; Mon, 17 Sep 2001 04:23:55 -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 CFDC45DD95 for ; Mon, 17 Sep 2001 04:23:53 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA04924; Mon, 17 Sep 2001 10:24:08 +0200 From: "Fredrik Johansson" To: "Jari Arkko" , "Pat Calhoun" , =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: Subject: RE: WG Consensus check: Re: [AAA-WG]: [issue] Partial support of CMS Date: Mon, 17 Sep 2001 10:24:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <04c401c13edb$992ce220$8a1b6e0a@arenanet.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit I would prefer #2 /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Jari Arkko >Sent: den 16 september 2001 20:16 >To: Pat Calhoun; Miguel Ángel Monjas Llorente >Cc: aaa-wg@merit.edu >Subject: Re: WG Consensus check: Re: [AAA-WG]: [issue] Partial support >of CMS > > > >> 1. Move the PDSR to the base protocol spec, as suggested below. >> 2. Add clarifying text to the CMS spec stating that a compliant node >> MAY only need to support the PDSR/PDSA messages. >> 3. Split the CMS spec into two (my least favorite) >> 4. Have the CMS spec include a two application-Id (this would be >broken, btw) >> so I don't believe we should take this approach. >> 5. leave it as is. > >My preference is also #2. > >Jari > > From owner-aaa-wg@merit.edu Mon Sep 17 04:55: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 EAA06611 for ; Mon, 17 Sep 2001 04:55:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD10A912DC; Mon, 17 Sep 2001 04:54:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 746429133C; Mon, 17 Sep 2001 04:54: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 5867A912DC for ; Mon, 17 Sep 2001 04:54:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 528155DD95; Mon, 17 Sep 2001 04:54:21 -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 A67C35DD8E for ; Mon, 17 Sep 2001 04:54:20 -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.10.1/WIREfire-1.3) with ESMTP id f8H8s9v14614 for ; Mon, 17 Sep 2001 10:54:09 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA22097; Mon, 17 Sep 2001 10:52:14 +0200 (MET DST) Message-ID: <3BA5B9E4.E1885ADC@rioja.ericsson.se> Date: Mon, 17 Sep 2001 10:52:52 +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: WG Consensus check: Re: [AAA-WG]: [issue] Partial support of CMS References: <3BA1D96C.112F348E@rioja.ericsson.se> <20010916083300.K14511@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 Calhoun wrote: > > Folks, my inclination is to not make this change, but I think that it deserves > input from the WG. We have a couple of options here: > > 1. Move the PDSR to the base protocol spec, as suggested below. > 2. Add clarifying text to the CMS spec stating that a compliant node > MAY only need to support the PDSR/PDSA messages. > 3. Split the CMS spec into two (my least favorite) > 4. Have the CMS spec include a two application-Id (this would be broken, btw) > so I don't believe we should take this approach. > 5. leave it as is. > > my preference is #2 above. Proposal #2 means that a node announcing -1 may have no real CMS support (just PDSR/PDSA messages). Since I think that this option might be very risky, I'd modify #2 proposal to say that ONLY Diameter clients (that is, NASes) may support only PDSA messages while not supporting the whole application. Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 17 05:18: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 FAA06809 for ; Mon, 17 Sep 2001 05:18:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1821191333; Mon, 17 Sep 2001 05:16:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D78139133C; Mon, 17 Sep 2001 05:16: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 AB61E91333 for ; Mon, 17 Sep 2001 05:16:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96B8C5DD99; Mon, 17 Sep 2001 05:16:48 -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 E6DA35DD95 for ; Mon, 17 Sep 2001 05:16:47 -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 f8H9GaK09289; Mon, 17 Sep 2001 11:16:37 +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 f8H9GZb17218; Mon, 17 Sep 2001 12:16:35 +0300 (EET DST) Message-ID: <3BA5BF73.3B6F4044@lmf.ericsson.se> Date: Mon, 17 Sep 2001 12:16:35 +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: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: aaa-wg@merit.edu Subject: Re: WG Consensus check: Re: [AAA-WG]: [issue] Partial support of CMS References: <3BA1D96C.112F348E@rioja.ericsson.se> <20010916083300.K14511@charizard.diameter.org> <3BA5B9E4.E1885ADC@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 >Since I think that this option might be very risky, I'd modify #2 >proposal to say that ONLY Diameter clients (that is, NASes) may >support only PDSA messages while not supporting the whole application. Well... not sure I agree about the risky part here. CMS is an extension, and certain rules dictate how an implementation is conformant to it. Base protocol spec 2.0 gives these rules (which contain more text than just excusing the clients, by the way). I am happy with the current spec in this respect. One way of implementing the option #2 that is under discussion is to copy also the relevant excerpt from base 2.0 to cms. Jari From owner-aaa-wg@merit.edu Mon Sep 17 06:30:59 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 GAA07454 for ; Mon, 17 Sep 2001 06:30:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1EE1691288; Mon, 17 Sep 2001 06:29:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D67C891340; Mon, 17 Sep 2001 06:29: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 C674E91288 for ; Mon, 17 Sep 2001 06:29:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A8DCA5DDA1; Mon, 17 Sep 2001 06:29: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 359865DD9A for ; Mon, 17 Sep 2001 06:29:42 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA08661; Mon, 17 Sep 2001 12:29:59 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Issue 164: problems with Watch Dog Date: Mon, 17 Sep 2001 12:30:32 +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: <20010915080124.F14171@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 Probably just a small miss when setting the counters in the pseudo code According to section 5.1 the status should be set to OKAY when 3 watchdog messages are exchanged withing accepted round trip times. However, I believe that the pseudo code below require 4 DWAs to be received before Status is set to OKAY? Considering the wdRecoveryCount starts at 0 and OKAY is not set when wdRecoveryCount reaches 3 but the next time a DWA is received. i.e. the 4th DWA. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 15 september 2001 17:01 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 164: problems with Watch Dog > > >The authors of the issue are correct that the pseudo-code doesn't reflect >the text in 5.1. So, I propose adding the following field to the PCB >in 5.5.3: > >wdRecoveryCount - This field contains the number of DWAs received > from a peer once the PCB's state is in the SUSPECT state. > >Then changes are made to the pseudo-code to handle this case: > >/* > * OnReceiveDWA() is called whenever a DWA is received > * from the peer. > */ >OnReceiveDWA(pcb) >{ > if pcb->Status == SUSPECT > if pcb->wdRecoveryCount == 3 > pcb->wdRecoveryCount = 0 > pcb->Status = OKAY > else pcb->wdRecoveryCount++ > else if pcb->Status != INACTIVE > if pcb->Pending > T = Tr > else > T = Ti >} > >/* > * OnTimerElapsed() is called by some timer services > * whenever T reaches zero (0). > */ >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->wdRecoveryCount == 3 > StopConnection(pcb) > FailoverProcedures(pcb) > else SendWatchdog(pcb) >} > > >I believe this resolves the issue. Comments? > >PatC From owner-aaa-wg@merit.edu Mon Sep 17 07:08: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 HAA07976 for ; Mon, 17 Sep 2001 07:08:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 268B891298; Mon, 17 Sep 2001 07:07:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC5BF9129A; Mon, 17 Sep 2001 07:07: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 C7FDA91298 for ; Mon, 17 Sep 2001 07:07:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1A9E5DDA6; Mon, 17 Sep 2001 07:07:49 -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 007F45DDA1 for ; Mon, 17 Sep 2001 07:07:48 -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.10.1/WIREfire-1.3) with ESMTP id f8HB7bv02993 for ; Mon, 17 Sep 2001 13:07:38 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id NAA07266; Mon, 17 Sep 2001 13:07:34 +0200 (MET DST) Message-ID: <3BA5D9A5.2C4C3D34@rioja.ericsson.se> Date: Mon, 17 Sep 2001 13:08: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: aaa-wg@merit.edu Subject: Re: WG Consensus check: Re: [AAA-WG]: [issue] Partial support of CMS References: <3BA1D96C.112F348E@rioja.ericsson.se> <20010916083300.K14511@charizard.diameter.org> <3BA5B9E4.E1885ADC@rioja.ericsson.se> <3BA5BF73.3B6F4044@lmf.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 Jari Arkko wrote: > > >Since I think that this option might be very risky, I'd modify #2 > >proposal to say that ONLY Diameter clients (that is, NASes) may > >support only PDSA messages while not supporting the whole application. > > Well... not sure I agree about the risky part here. > CMS is an extension, and certain rules dictate > how an implementation is conformant to it. > > Base protocol spec 2.0 gives these rules (which contain > more text than just excusing the clients, by the way). > I am happy with the current spec in this respect. Yes. I browsed that section a long time ago and I didn't remember the exact details. After reading, the conclusion is clear: - Diameter servers: MUST support DSA messages; MAY support PDSA messages - Proxy agents: MUST support DSA messages; MUST support PDSA messages - Diameter clients: SHOULD support DSA messages; MUST support PDSA messages - Relay agents: MAY support DSA messages; MAY support PDSA messages - Redirector agents: MAY support DSA messages; MAY support PDSA messages What looks fine (except that Diameter clients SHOULD support DSA messages; wouldn't it be more realistic to weaken this requirement (since the proper CMS draft states some scenarios with NASes without cryptographic abilities)?) > One way of implementing the option #2 that is under > discussion is to copy also the relevant excerpt from > base 2.0 to cms. Yes, I think that including a paragraph stating what the announcement for each type of diameter nodes means would be convenient. Regards -- 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 Mon Sep 17 07:12: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 HAA08076 for ; Mon, 17 Sep 2001 07:12:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA3A99129A; Mon, 17 Sep 2001 07:11:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73CAD91340; Mon, 17 Sep 2001 07:11: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 5792D9129A for ; Mon, 17 Sep 2001 07:11:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 429465DDA1; Mon, 17 Sep 2001 07:11:28 -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 91E945DD99 for ; Mon, 17 Sep 2001 07:11:27 -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.10.1/WIREfire-1.3) with ESMTP id f8HBBGv06124 for ; Mon, 17 Sep 2001 13:11:16 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id NAA07586; Mon, 17 Sep 2001 13:11:13 +0200 (MET DST) Message-ID: <3BA5DA81.171A4CBB@rioja.ericsson.se> Date: Mon, 17 Sep 2001 13:12:01 +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 160: Destination-Host in PDSR References: <20010915073203.B14171@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 Calhoun wrote: > > All, > > I agree with this issue, and propose adding the last sentence: > > - The access device has the cryptographic ability to perform the > CMS functions, but a proxy agent is in the route towards the > home server, and it returned a failure to the DSAR messages > stating that it was not willing to allow the DSA to traverse > through it. Such agents MAY attempt to re-use the values from > the initial DSAR sent by the access device. In such cases,the > PDSR initiator SHOULD include the Destination-Host AVP to > ensure that the PDSR is received by the same proxy agent. > > Of course, the ABNF is also modified to include the Destination-Host AVP > as an optional AVP. OK, I've seen it's been moved to section 1.2 as part of issue #177's resolution Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 17 07:36: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 HAA08809 for ; Mon, 17 Sep 2001 07:36:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5835D91306; Mon, 17 Sep 2001 07:35:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 257A491340; Mon, 17 Sep 2001 07:35: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 E353291306 for ; Mon, 17 Sep 2001 07:35:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4B7F5DDA1; Mon, 17 Sep 2001 07:35:56 -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 058C05DD99 for ; Mon, 17 Sep 2001 07:35:56 -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.10.1/WIREfire-1.3) with ESMTP id f8HBZiv26110 for ; Mon, 17 Sep 2001 13:35:45 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id NAA09267; Mon, 17 Sep 2001 13:35:37 +0200 (MET DST) Message-ID: <3BA5E039.70E424A0@rioja.ericsson.se> Date: Mon, 17 Sep 2001 13:36:25 +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] CMS proxy scenarios References: <3BA1C568.347C5635@rioja.ericsson.se> <20010916082702.J14511@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 Calhoun wrote: > > Although I tried hard to avoid re-writing this section, after reading 1.2 > some more, I found some inconsistencies, so a re-write was probably in the > best interest of the WG :( > > So, I've followed Miguel's proposed approach, and propose the following text > (of course, I removed the scenarios from section 4.3): > > 1.2 Establishing Security Relationship through proxy agents > > As previously discussed, proxy agents typically modify Diameter > messages to implement policy enforcement. An example of a proxy > server would be an aggregating server, which typically sits one > Diameter hop away from the access device, and enforces policy in > order to protect the access device from receiving AVPs that could > cause harm (e.g. excessive number of filters, unsupported tunneling > protocol). Although in theory such checks could be performed on the > access device, these devices are typically embedded systems, and not > easily configurable. The proxy agent's behavior, on the other hand, > is typically under control of the network operator. > > Diameter messages between two participants of a DSA would fail > verification if a proxy agent were to modify any protected AVPs. > Therefore proxy agents either MUST NOT modify protected AVPs or else > MUST NOT allow the DSA to be established. In this section, we discuss > the capabilities provided by this Diameter application which allow > proxy agents to secure AVPs on behalf of an access device. The > following scenarios are envisioned: > > - The access device does not have the cryptographic ability to > handle the CMS functions locally, and therefore requests such ^^^^^^^^^^^^^ As discussed in issue #178 a more specific name would be used (maybe "security CMS functions") > services from the local agent, such an an aggregating relay or > proxy agent. The NAS may have been configured to always issue a > PDSR to its local agent for CMS services. In such cases, the > agent MUST select the values for the DSA-TTL and provide the > appropriate Local-CA-Info and the expected OCSP response from the DSA peer. > - The access device has the cryptographic ability to perform the > CMS functions, but a proxy agent is in the route towards the ^^^^^^^^^^^^^ > home server, and it returned a failure to the DSAR messages > stating that it was not willing to allow the DSA to traverse > through it. Such agents MAY attempt to re-use the values from > the initial DSAR sent by the access device. In such cases,the > PDSR initiator SHOULD include the Destination-Host AVP to ensure > that the PDSR is received by the same proxy agent. > - The access device MAY have the cryptographic ability to perform ^^^ This isn't a requirement (just a statement) so that maybe capital letters aren't necessary. > CMS functions locally, but does not request a DSAR to request a ^^^^^^^^^^^^^ > DSA. The local agent, however, has been configured to establish > DSAs with certain realms automatically, hiding the existence of > the DSAs from the access device. > > In the above scenarios, the first two occur at the explicit request > of the access device, while the last one occurs without any messaging > from the access device. In the latter case, the proxy agent acts as > an access device of sorts and the rules in section 1.1 should be used > instead. > > When a local agent receives a DSAR, it has the following options: > - The local agent rejects all DSARs by sending a DSAA message > whose Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY. > The DSAA SHOULD include the CMS-Signed-Data AVP, signed by the > proxy agent, and include its certificate to allow the access > device to validate the originator of the DSAA. The access device > can then determine whether it is willing to provide service, > based on its local policy. > - The local agent rejects all DSARs by sending a DSAA message > whose Result-Code AVP is set to DIAMETER_CAN_ACT_AS_CMS_PROXY, > informing the access device that the agent is willing to > establish the DSA on its behalf. The DSAA MUST include the CMS- > Signed-Data AVP, signed by the proxy agent, and include its > certificate to allow the access device to validate the > originator of the DSAA. If the access device is willing to use > the agent's services, which it could be configured to only > accept such DSAA messages from agents within its realm, it > issues a Proxy-Diameter-Security-Association-Request (PDSR) > which MUST contain the target realm. The local agent MAY use any > of the parameters provided by the access device in the previous > DSAR attempt when establishing the DSA. Once the DSA is > established, the agent MUST issue a Proxy-Diameter-Security- > Association-Answer (PDSA). The PDSA MUST contain the TTL setting > agreed by the proxy agent for its DSA. This information will > allow the access device to re-issue a PDSR prior to the proxy's > DSA if it needs the DSA to remain active. > > Note that an access device MAY be configured to always issue a PDSR > to its aggregating proxy, reducing the number of round trips. > Similarly, an aggregating proxy MAY be configured to initiate an DSAR > regardless of whether a PDSR was sent by the access device. > > mno.net mno.net xyz.net abc.com > +------+ +------+ +------+ +------+ > | | |Proxy | |Relay | | Home | > | NAS | | | | | | | > | | |Agent | |Agent | |Server| > +------+ +------+ +------+ +------+ > -------------> > (DSAR) Destination-Realm = abc.com > > <------------- > (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY > > -------------> > (PDSR) DSAR-Target-Domain = abc.com > > ----------------------------> > (DSAR) Destination-Realm = abc.com > > <---------------------------- > (DSAA) Result-Code = DIAMETER_SUCCESS > > <------------- > (PDSA) Result-Code = DIAMETER_SUCCESS > > Figure 3: Establishing Security through Proxy Agent > > An optimized approach also allows the PDSR to be sent by the access > device without the DSAR-Target-Domain AVP. This message is used to > inform the proxy that it MUST establish a Diameter security > association for all realms it will be communicating with on behalf of > the access device. > > Allowing the first hop agent to be used to establish the DSA with the > home server MAY reduce the current concerns that the cryptographic > operations resulting from this specification MAY overburden embedded > access devices. No more comments Regards // M.A. From owner-aaa-wg@merit.edu Mon Sep 17 07:37: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 HAA08864 for ; Mon, 17 Sep 2001 07:37:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EE4891340; Mon, 17 Sep 2001 07:36:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39F3791344; Mon, 17 Sep 2001 07:36: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 2862C91340 for ; Mon, 17 Sep 2001 07:36:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1DDB15DDA1; Mon, 17 Sep 2001 07:36:53 -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 439605DD99 for ; Mon, 17 Sep 2001 07:36:52 -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.10.1/WIREfire-1.3) with ESMTP id f8HBafv26771 for ; Mon, 17 Sep 2001 13:36:41 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id NAA09323; Mon, 17 Sep 2001 13:36:39 +0200 (MET DST) Message-ID: <3BA5E076.4BFDAFA9@rioja.ericsson.se> Date: Mon, 17 Sep 2001 13:37:26 +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] PDSA-Request without DSA-Target-Realm References: <3BA20E93.9BC670E0@rioja.ericsson.se> <20010916084509.L14511@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: > > How about the following text instead (which is a variant of the text > sent by Miguel): > > An optimized approach also allows the PDSR to be sent by the > access device without the DSAR-Target-Realm AVP. This message is used to > inform the proxy that it MUST establish a Diameter security > association for all realms it will be communicating with on behalf > of the access device. DSAs are typically established once the first request > for a given realm has been recelived by the proxy agent, but it MAY > establish certain DSAs with known realm in advance. > > If a DSA for a given realm cannot be established, the proxy agent > MUST reject the access device's request, and set the Result-Code AVP > to DIAMETER_NO_DSA_ESTABLISHED. Although the proxy agent MAY receive > many PDSRs from access devices, only one DSA per realm MUST be > established. Furthermore, the PDSR is responsible for re-establishing ^^^^ proxy? > the DSA prior to expiration without any involvement by the access device. 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 Mon Sep 17 08: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 IAA09647 for ; Mon, 17 Sep 2001 08:06:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C085791295; Mon, 17 Sep 2001 08:05:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A657912A1; Mon, 17 Sep 2001 08:05: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 20AAF91295 for ; Mon, 17 Sep 2001 08:05:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 196FC5DDA1; Mon, 17 Sep 2001 08:05:11 -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 3F86D5DD99 for ; Mon, 17 Sep 2001 08:05:10 -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 f8HC4wK24261 for ; Mon, 17 Sep 2001 14:04:59 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA11315; Mon, 17 Sep 2001 14:04:55 +0200 (MET DST) Message-ID: <3BA5E717.67E7A0CA@rioja.ericsson.se> Date: Mon, 17 Sep 2001 14:05:43 +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]: CMS Decryption Error References: <3B9E304B.4729227D@rioja.ericsson.se> <3BA1FAB2.21379235@rioja.ericsson.se> <20010916073741.H14511@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: > > I have addressed this issue, which conflicted with another issue by Miguel. > I assume that this issue overrides a portion of issue 158, to which I posted > proposed text at http://www.merit.edu/mail.archives/aaa-wg/msg02114.html. Yes. The proposed resolution of issue 158 looks fine, but as stated in the previous mail, the key point is that I don't know if we've got the possibility of deciding whether a given CMS-Encrypted-AVP has been modified or not. If we've got a CMS-Encrypted-Data AVP encrypting an only AVP, once we decrypt and parse we find that the AVP doesn't match any defined AVP. We can deduce that the AVP has been modified (but actually there's no way to decide if it's a question of modification, bad encryption or bad encoding or the original AVP). Of course that if we find two or more supposed AVPs that don't match any defined AVP, it quite probable that some modification has been suffered. My proposal is to keep the DIAMETER_DSA_DECRYPTION_FAILED as proposed by Pat, but taking into account that probably CMS implementations wouldn't be able to distiguish between a failed decryption and other type of errors related to decryption. 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 Mon Sep 17 11:18:48 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 LAA13788 for ; Mon, 17 Sep 2001 11:18:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43563912B1; Mon, 17 Sep 2001 11:17:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11EFC912B5; Mon, 17 Sep 2001 11:17: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 E645E912B1 for ; Mon, 17 Sep 2001 11:17:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDE9B5DDA1; Mon, 17 Sep 2001 11:17: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 54F265DD99 for ; Mon, 17 Sep 2001 11:17:31 -0400 (EDT) Received: (qmail 26161 invoked by uid 500); 17 Sep 2001 15:03:51 -0000 Date: Mon, 17 Sep 2001 08:03:51 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 164: problems with Watch Dog Message-ID: <20010917080351.D26055@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , aaa-wg@merit.edu References: <20010915080124.F14171@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, Sep 17, 2001 at 12:30:32PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk ooops... you are correct. Will change 3 to 2, since 0 is the starting point. Thanks, PatC On Mon, Sep 17, 2001 at 12:30:32PM +0200, Fredrik Johansson wrote: > Probably just a small miss when setting the counters in the pseudo code > > According to section 5.1 the status should be set to OKAY when 3 watchdog > messages are exchanged withing accepted round trip times. However, I believe > that the pseudo code below require 4 DWAs to be received before Status is > set to OKAY? Considering the wdRecoveryCount starts at 0 and OKAY is not set > when wdRecoveryCount reaches 3 but the next time a DWA is received. i.e. the > 4th DWA. > > /Fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Pat Calhoun > >Sent: den 15 september 2001 17:01 > >To: aaa-wg@merit.edu > >Subject: [AAA-WG]: Issue 164: problems with Watch Dog > > > > > >The authors of the issue are correct that the pseudo-code doesn't reflect > >the text in 5.1. So, I propose adding the following field to the PCB > >in 5.5.3: > > > >wdRecoveryCount - This field contains the number of DWAs received > > from a peer once the PCB's state is in the SUSPECT state. > > > >Then changes are made to the pseudo-code to handle this case: > > > >/* > > * OnReceiveDWA() is called whenever a DWA is received > > * from the peer. > > */ > >OnReceiveDWA(pcb) > >{ > > if pcb->Status == SUSPECT > > if pcb->wdRecoveryCount == 3 > > pcb->wdRecoveryCount = 0 > > pcb->Status = OKAY > > else pcb->wdRecoveryCount++ > > else if pcb->Status != INACTIVE > > if pcb->Pending > > T = Tr > > else > > T = Ti > >} > > > >/* > > * OnTimerElapsed() is called by some timer services > > * whenever T reaches zero (0). > > */ > >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->wdRecoveryCount == 3 > > StopConnection(pcb) > > FailoverProcedures(pcb) > > else SendWatchdog(pcb) > >} > > > > > >I believe this resolves the issue. Comments? > > > >PatC > From owner-aaa-wg@merit.edu Mon Sep 17 13:23: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 NAA16729 for ; Mon, 17 Sep 2001 13:23:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DA1E912B6; Mon, 17 Sep 2001 13:22:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF5CC912BB; Mon, 17 Sep 2001 13:22: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 B1215912B6 for ; Mon, 17 Sep 2001 13:22:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A58435DDAC; Mon, 17 Sep 2001 13:22: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 5ED2C5DDA1 for ; Mon, 17 Sep 2001 13:22:45 -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.10.1/WIREfire-1.3) with ESMTP id f8HHMWv21516; Mon, 17 Sep 2001 19:22:33 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA08230; Mon, 17 Sep 2001 19:22:28 +0200 (MET DST) Message-ID: <3BA63156.55540223@rioja.ericsson.se> Date: Mon, 17 Sep 2001 19:22:30 +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] CMS proxy scenarios References: <3BA1C568.347C5635@rioja.ericsson.se> <20010916082702.J14511@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 An additional point: a Diameter proxy can deny a DSA setup attempt through it by two reasons: - Because it would modify any of the AVPs requested as protected, so that the participants of the DSA would detect modifications in some of the AVPs of the message. - Because the proxy has been configured to act as a CMS proxy only when the target of the DSA is within an allowed set. This last condition hasn't been included. I would include a clarifying text Pat Calhoun wrote: > > 1.2 Establishing Security Relationship through proxy agents > > When a local agent receives a DSAR, it has the following options: > - The local agent rejects all DSARs by sending a DSAA message > whose Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY. This rejection can be due to the fact that the proxy would modify some of the AVPs requested as protected or because, even not modifying any AVP, it has been configured not to allow a subsequent DSA with the given domain. > The DSAA SHOULD include the CMS-Signed-Data AVP, signed by the > proxy agent, and include its certificate to allow the access > device to validate the originator of the DSAA. The access device > can then determine whether it is willing to provide service, > based on its local policy. 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 Mon Sep 17 22:38: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 WAA29022 for ; Mon, 17 Sep 2001 22:38:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AA49912DF; Mon, 17 Sep 2001 22:37:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D418C91214; Mon, 17 Sep 2001 22:37: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 EBD90912DF for ; Mon, 17 Sep 2001 22:37:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE9D45DDBC; Mon, 17 Sep 2001 22:37:19 -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 5EBEC5DDB6 for ; Mon, 17 Sep 2001 22:37:19 -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 f8I2b7Q20535 for ; Mon, 17 Sep 2001 21:37:07 -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 f8I2b6604865 for ; Mon, 17 Sep 2001 21:37:06 -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 VAA26344 for ; Mon, 17 Sep 2001 21:37:06 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA19534 for ; Mon, 17 Sep 2001 21:37:04 -0500 (CDT) Message-ID: <3BA6B166.6070906@ericsson.com> Date: Mon, 17 Sep 2001 19:28:54 -0700 From: Tony Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: The 3rd diameter bake-off is postpone with three weeks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Due to the recent terrorist attacks in the US, many of the companies that will participate in the Diameter interop event have a company-wide ban on non-essential travel for an indefinate period of time. So, we have therefore agreed to postpone the event with three weeks. Thus, the new date for the event are 22nd of October to the 26th of October. 10 vendors / organizations have register before the deadline, which was set to the 14th of September. We believe the we can host one or two more vendors, so if you want to participate please let us know asap, at the latest Thursday this week. http://standards.ericsson.net/diameter-bake-off/ Regards, /Tony From owner-aaa-wg@merit.edu Tue Sep 18 14:23: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 OAA28387 for ; Tue, 18 Sep 2001 14:23:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3FA2915EA; Tue, 18 Sep 2001 14:08:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E99791594; Tue, 18 Sep 2001 13:54: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 3C9D6915BE for ; Tue, 18 Sep 2001 13:52:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3302F5DDE2; Tue, 18 Sep 2001 13:52:14 -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 E52AE5DDE1 for ; Tue, 18 Sep 2001 13:52:10 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id SAA26259 for ; Tue, 18 Sep 2001 18:51:52 +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 ; Tue, 18 Sep 2001 18:48:44 +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 SAA07266; Tue, 18 Sep 2001 18:54:41 +0100 Message-ID: <3BA789B5.A2D27EC6@baltimore.ie> Date: Tue, 18 Sep 2001 18:51:49 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: aaa-wg@merit.edu, Pat Calhoun , xme Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> Content-Type: multipart/mixed; boundary="------------FFCA5C1DED0F106076D405A3" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------FFCA5C1DED0F106076D405A3 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id SAA07266 Content-Transfer-Encoding: quoted-printable Miguel, I've spoken to Pat about this (and though it seemed clear=20 enough to me it really wasn't:-). I also checked with the=20 S/MIME WG to make sure we're doing the "right" thing with MIME encodings so that we can more easily re-use existing toolkits in our context. First the background then the suggested text to include: - CMS is a generic cryptographic message format, that makes no reference to MIME. We're using a small subset of the options available in CMS. - The S/MIME v3 message specification tells you how MIME and CMS can be used together to do secure email. There are many toolkits which implement this specification, and some of=20 the older ones don't really handle the "bare" CMS cases very well (they assume you want MIME encoding). For these reasons the current draft uses the following scheme for the CMS-Encrypted-Data AVP (similar considerations apply for the CMS-Signed-Data AVP): - Marshall up (catenate) the set of to-be-encrypted AVPs - Encode those using MIME encoding and use the id-data object identifier (another place where the older toolkits=20 go wrong, some only handle id-data and insist on=20 MIME en/de-coding the to-be-encrypted data) - Wrap that using CMS EnvelopedData - Put the result into a CMS-Encrypted-Data AVP 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=20 problems than otherwise. (I personally don't mind whether we omit the MIME encoding or not.) The attached re-wording of sections 6.1/6.2 should hopefully clarify this. Regards, Stephen. Miguel =C1ngel Monjas Llorente wrote: >=20 > Pat Calhoun wrote: > > > > > there's no explicit mention of MIME encoding in 6.2 > > > (CMS-Encrypted-Data AVP). My opinion is that such explicit mention = to > > > MIME should be included in 6.2 (at least if MIME encoding is > > > necessary). > > > > ok, here's the scoop (as I understand it). 6.1 specifies how the > > CMS-Signed-Data AVP is created. This is done by taking a bunch of AVP= s, > > putting them through the signing transform, and taking the result, wh= ich > > is included in the AVP itself. However, the AVPs themselves are never= encoded > > in any MIME format when included in the message. >=20 > Right. A CMS SignedData structure is created containing only the > digest of the AVPs, not the whole bunch of AVPs. >=20 > > 6.2, on the other hand, is completely different. The encrypted data i= s > > included in the CMS-Encrypted-Data AVP. > > > > So, in 6.1 the process is different from 6.2. >=20 > Really? In the sense that S/MIME isn't involved? Just pure CMS? >=20 > > I believe that Stephen will need to help us out here with any additio= nal > > clarifications. >=20 > I'm afraid I'm beginning to need it. >=20 > Let's say that there are a encapsulation message syntax called CMS. It > provides six content-types: data, signed-data, enveloped-data, > digested-data, encrypted-data, and authenticated-data. This syntax > evolves from PKCS#7 and makes use of ASN.1. >=20 > Let's imagine that a messaging standard, S/MIME, takes just two of the > content types (signed-data and enveloped-data) to provide secure > messaging (as well as a particular singed-data message, > certificates-only). Of course that some kind of MIME encoding is > necessary. >=20 > Finally, AAA-WG says that it will use CMS for providing end-to-end > security. However, two significant things are also stated: that the > secured AVPs will be CMS-Signed-Data, CMS-Encrypted-Data and CMS-Cert > (which coincide with the different structures used by S/MIME) and that > "This application was designed to allow for Diameter implementations > to use existing S/MIME toolkits". >=20 > My first impression is that S/MIME encoding was an intermediate step > to get our secured AVP (that is the reason why I thought that S/MIME > Security Application was a more proper name). However, it looks that, > in order to get a CMS-Encrypted-Data AVP, no S/MIME processing is > necessary. >=20 > Now, I'm definitely confused (I admit that I'm not an S/MIME expert). > But I'd like to know where S/MIME processing is used, where not (and > how to encode several EnvelopedData values within a single > CSM-Enveloped-Data AVP; is that an S/MIME method or not) >=20 > > As far as the intro paragraph, I've come up with the following at the= end > > of section 1.0: > > > > This Diameter application makes use of Cryptographic Message > > Syntax (CMS), which a method used to secure MIME (S/MIME) > ^^^ > | something missed? >=20 > > messages. This application was designed to allow for Diameter > > implementations to use existing S/MIME toolkits in order to > > comply with this specification. >=20 > > so, we're nearly there. >=20 > Right :-)) --=20 ____________________________________________________________ Stephen Farrell =20 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 --------------FFCA5C1DED0F106076D405A3 Content-Type: text/plain; charset=us-ascii; name="61-61-with-mime.txt" Content-Disposition: inline; filename="61-61-with-mime.txt" Content-Transfer-Encoding: 7bit Insert into section 6.0: The profile of CMS algorithm and structure usage is conformant to that specified in the S/MIME v3 message specification [11]. This makes is simpler to base an implementation of this specification upon an existing S/MIME toolkit. All MIME encoded data in this specification MUST use the "application/pkcs7-mime" MIME type. 6.1 CMS-Signed-Data AVP The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. This means that where a set of AVPs is to be signed, the set of AVPs with the 'P' bit set MUST first be catenated together in the order in which they occur in the Diameter message and MUST then be encoded according to MIME encoding rules specified in [16,17]. The result of this encoding is used as input into the signing process. Note that the AVPs themselves are not encapsulated within the CMS-Signed-Data AVP. Instead, the digest value of the AVPs produced in the signature process MUST be included in the CMS-Signed- Data AVP, as a message-digest attribute (defined in section 11.2 of [3]) in the SignerInfo value. Multiple Diameter entities MAY add their signatures to an existing CMS-Signed-Data AVP. Multiple signatures are added within the countersignature attribute (defined in section 11.4 of [3]) and not as additional SignerInfo values. The countersignature attribute requires that the signatures occur sequentially, meaning that each signature covers the existing signatures in the CMS object. The initial signature, and any additional countersignatures, MUST cover the exact same set of AVPs, in the order they are present in the message. Note that the CMS-Signed-Data AVP itself MUST NOT be used in the generation of the signature, and therefore MUST NOT have its 'P' bit set. The eContent field of the EncapsulatedContentInfo structure MUST be absent since the digital signature covers data outside of the object. The signature is computed over all AVPs with the 'P' bit enabled. The order of the AVPs MUST be preserved and the computation begins with the first AVP immediately following the Diameter header. If a receiver detects that the contents of the CMS-Signed-Data AVP are invalid, it SHOULD return the DIAMETER_INVALID_AUTH Result-Code AVP value defined in section 7.1. When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first. This AVP MUST then have the 'P' bit set and be one of the inputs to the signing process as described above. (Any other processing resulting in the same output can be used.) This means that signing is "outside" encryption. No more than one CMS-Signed-Data AVP MUST be present in any given Diameter message. 6.2 CMS-Encrypted-Data AVP The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. All AVPs to be encrypted are concatenated. This value is then MIME encoded (according to the rules specified in [16,17]) and then encrypted according to normal CMS rules, and then used as the value of the EncryptedContent field within EnvelopedData. The contentType of the EncryptedContentInfo value MUST be id-data [11]. A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. Where one or more AVP would be encrypted within separate EnvelopedData structures, then separate CMS-Encrypted-Data AVPs MUST be used. Thus, implementations MUST be able to support the presence of multiple CMS-Encrypted-Data AVPs and MUST be able to decrypt any EnvelopedData for which it is a recipient, as indicated in the EnvelopedData's RecipientInfos field [3]. 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. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST answer with the Result-Code set to DIAMETER_INVALID_AVP_VALUE. Diameter nodes SHOULD implement content encryption key reuse (see section 3.4 above). If a receiver detects that the contents of the CMS-Encrypted-Data AVP is invalid, it SHOULD answer with the Result-Code set to DIAMETER_INVALID_AVP_VALUE. Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter message. 6.x Example encodings In order to clarify contents of and the relationships between CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following example of how these AVPs are calculated. First, some short-hand: - MIME(x) represents the MIME encoding of x - EnvelopedData-fnc(x,y) represents the EnvelopedData produced as output of a function with x as the to-be-encrypted-data and y as the parameters (e.g. recipient information). - SignedData (y) represents the SignedData produced as output of a function with the catenation of the 'P is set' AVPS as the to-be-digested-data (which is not part of the output!) and y as the parameters (e.g. signer information). The scenario calls for a message containing 7 AVPs s,t,e,p,h,e and n to meet the following: AVPs s,t and e are to be encrypted for recipient P. AVPs e,p and h are to be encrypted for recipient A. AVPs s,e (2nd time:-) and n are to be signed by originator T. The resulting message will look like: AVP1='P is set', EnvelopedData-fnc(MIME(s,t,e),P) AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) AVP3='P is set', e AVP4='P is clear', n AVP5='P is clear', SignedData(T) The result of this is that AVPs t,e(1st time), p and h are actually signed even though that wasn't required. However, this is no harm. --------------FFCA5C1DED0F106076D405A3-- From owner-aaa-wg@merit.edu Tue Sep 18 17:59: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 RAA03289 for ; Tue, 18 Sep 2001 17:59:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F32AC9134F; Tue, 18 Sep 2001 17:58:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B47F5912B4; Tue, 18 Sep 2001 17:58: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 728089134F for ; Tue, 18 Sep 2001 17:58:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 696AB5DDE9; Tue, 18 Sep 2001 17:58:29 -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 4DB725DDBF for ; Tue, 18 Sep 2001 17:58:29 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 5E9AE7A for ; Tue, 18 Sep 2001 17:58:17 -0400 (EDT) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] Retain RADIUS attribute types for attributes 0-255 Date: Tue, 18 Sep 2001 17:56:00 -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 Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: September 18, 2001 Reference: None Document: draft-ietf-aaa-diameter-mobileip-07 Comment type: T Priority: 1 Section: 7.1, 7.2, 7.4, 7.5 Rationale/Explanation of issue: The first 256 AVP numbers are reserved for compatibility with RADIUS. However, the type of four of them has been changed in the Diameter draft. Accounting-Input-Octets, Accounting-Output-Octets, Accounting-Input-Packets, and Accounting-Output-Packets are AVPs in the RADIUS attribute space, but are 32-bit integers in RADIUS and 64-bit integers in Diameter. This makes the dictionary implementation more difficult in servers that support both RADIUS and Diameter. For the first 256 attributes, we should retain full RADIUS compatibility and retain the original RADIUS type. If Diameter applications want 64-bit integer counters, then create Diameter-specific AVPs for them. Requested change: (The AVP names are only a suggestion) Rename Accounting-Input-Octets as Accounting-Input-Extended-Octets, rename Accounting-Output-Octets as Accounting-Output-Extended-Octets, rename Accounting-Input-Packets as Accounting-Input-Extended-Packets, rename Accounting-Output-Packets as Accounting-Output-Extended-Packets, let their values be 64-bit integers, and assign them Diameter AVP numbers greater than 255. From owner-aaa-wg@merit.edu Tue Sep 18 18:38: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 SAA04177 for ; Tue, 18 Sep 2001 18:38:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4AF9912EA; Tue, 18 Sep 2001 18:34:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E889D91351; Tue, 18 Sep 2001 18:30: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 5500B9135C for ; Tue, 18 Sep 2001 18:21:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B3C15DDA5; Tue, 18 Sep 2001 18:21:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (unknown [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 1B4C25DDA0 for ; Tue, 18 Sep 2001 18:21:44 -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 f8IMLPQ21841 for ; Tue, 18 Sep 2001 17:21:25 -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 f8IMLPG02105 for ; Tue, 18 Sep 2001 17:21:25 -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 RAA21695 for ; Tue, 18 Sep 2001 17:21:24 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id RAA03230 for ; Tue, 18 Sep 2001 17:21:22 -0500 (CDT) Message-ID: <003b01c14090$40019b80$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "aaa-wg" References: Subject: Re: [AAA-WG]: [issue] Retain RADIUS attribute types for attributes 0-255 Date: Tue, 18 Sep 2001 15:21:19 -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 Related to this issue, a similar problem exists in the nasreq-07 spec. However, while sections 8.1-8.5 indicate that the AVPs in question should be Unsigned64, the table in section 2.2 indicates that they are in fact Unsigned32. Kev > > Submitter name: Bob Kopacz > Submitter email address: BKopacz@InterlinkNetworks.com > Date first submitted: September 18, 2001 > Reference: None > Document: draft-ietf-aaa-diameter-mobileip-07 > Comment type: T > Priority: 1 > Section: 7.1, 7.2, 7.4, 7.5 > Rationale/Explanation of issue: > > The first 256 AVP numbers are reserved for compatibility with > RADIUS. > > However, the type of four of them has been changed in the Diameter > draft. Accounting-Input-Octets, Accounting-Output-Octets, > Accounting-Input-Packets, and Accounting-Output-Packets are AVPs in > the RADIUS attribute space, but are 32-bit integers in RADIUS and > 64-bit integers in Diameter. > > This makes the dictionary implementation more difficult in servers > that support both RADIUS and Diameter. > > For the first 256 attributes, we should retain full RADIUS > compatibility and retain the original RADIUS type. If Diameter > applications want 64-bit integer counters, then create > Diameter-specific AVPs for them. > > Requested change: > > (The AVP names are only a suggestion) > > Rename Accounting-Input-Octets as Accounting-Input-Extended-Octets, > rename Accounting-Output-Octets as Accounting-Output-Extended-Octets, > rename Accounting-Input-Packets as Accounting-Input-Extended-Packets, > rename Accounting-Output-Packets as Accounting-Output-Extended-Packets, > let their values be 64-bit integers, > and assign them Diameter AVP numbers greater than 255. > From owner-aaa-wg@merit.edu Thu Sep 20 05:36: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 FAA04320 for ; Thu, 20 Sep 2001 05:36:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 746D391216; Thu, 20 Sep 2001 05:35:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A7259121E; Thu, 20 Sep 2001 05:35: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 F156691216 for ; Thu, 20 Sep 2001 05:35:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D1D235DDD7; Thu, 20 Sep 2001 05:35:53 -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 2BCCA5DDC6 for ; Thu, 20 Sep 2001 05:35:53 -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 f8K9Z3K19517; Thu, 20 Sep 2001 11:35:03 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA06400; Thu, 20 Sep 2001 11:34:58 +0200 (MET DST) Message-ID: <3BA9B856.E97DCA3C@rioja.ericsson.se> Date: Thu, 20 Sep 2001 11:35:18 +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 Cc: stephen.farrell@baltimore.ie, Pat Calhoun Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Stephen Farrell wrote: > > Miguel, > > I've spoken to Pat about this (and though it seemed clear > enough to me it really wasn't:-). I also checked with the > S/MIME WG to make sure we're doing the "right" thing with > MIME encodings so that we can more easily re-use existing > toolkits in our context. > > First the background then the suggested text to include: > > - CMS is a generic cryptographic message format, that makes > no reference to MIME. We're using a small subset of the > options available in CMS. > - The S/MIME v3 message specification tells you how MIME and > CMS can be used together to do secure email. There are many > toolkits which implement this specification, and some of > the older ones don't really handle the "bare" CMS cases > very well (they assume you want MIME encoding). > > For these reasons the current draft uses the following scheme > for the CMS-Encrypted-Data AVP (similar considerations apply > for the CMS-Signed-Data AVP): > > - Marshall up (catenate) the set of to-be-encrypted AVPs > - Encode those using MIME encoding and use the id-data > object identifier (another place where the older toolkits > go wrong, some only handle id-data and insist on > MIME en/de-coding the to-be-encrypted data) > - Wrap that using CMS EnvelopedData > - Put the result into a CMS-Encrypted-Data AVP > > 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.) > > The attached re-wording of sections 6.1/6.2 should > hopefully clarify this. ---------------------------------------------------------------------- Just some comments: > Insert into section 6.0: > > The profile of CMS algorithm and structure usage is conformant to > that specified in the S/MIME v3 message specification [11]. This > makes is simpler to base an implementation of this specification > upon an existing S/MIME toolkit. > > All MIME encoded data in this specification MUST use the > "application/pkcs7-mime" MIME type. > > 6.1 CMS-Signed-Data AVP > > The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and > contains the Basic Encoding Rules (BER) encoding of a CMS object [3] > of type ContentInfo. This means that where a set of AVPs is to be > signed, the set of AVPs with the 'P' bit set MUST first be catenated > together in the order in which they occur in the Diameter message > and MUST then be encoded according to MIME encoding rules specified > in [16,17]. The result of this encoding is used as input into the > signing process. I assume that references 16 and 17 has been added. Could you post such references? > Note that the AVPs themselves are not encapsulated within the > CMS-Signed-Data AVP. Instead, the digest value of the AVPs > produced in the signature process MUST be included in the CMS-Signed- > Data AVP, as a message-digest attribute (defined in section 11.2 of > [3]) in the SignerInfo value. > > Multiple Diameter entities MAY add their signatures to an existing > CMS-Signed-Data AVP. Multiple signatures are added within the > countersignature attribute (defined in section 11.4 of [3]) and not > as additional SignerInfo values. The countersignature attribute > requires that the signatures occur sequentially, meaning that each > signature covers the existing signatures in the CMS object. > > The initial signature, and any additional countersignatures, MUST > cover the exact same set of AVPs, in the order they are present in > the message. > > Note that the CMS-Signed-Data AVP itself MUST NOT be used in the > generation of the signature, and therefore MUST NOT have its 'P' bit set. > > The eContent field of the EncapsulatedContentInfo structure MUST be > absent since the digital signature covers data outside of the object. > The signature is computed over all AVPs with the 'P' bit enabled. The > order of the AVPs MUST be preserved and the computation begins with > the first AVP immediately following the Diameter header. > > If a receiver detects that the contents of the CMS-Signed-Data AVP > are invalid, it SHOULD return the DIAMETER_INVALID_AUTH Result-Code AVP > value defined in section 7.1. Well, here I'd suggest leaving something more similar to the old text. Something like: If a receiver cannot verify correctly the signature carried by the CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH Result-Code AVP value defined in section 7.1. Just because there can be some confusion between the following existing errors: DIAMETER_INVALID_CMS_DATA 5019 This error code is returned when a CMS-Data AVP is received with an invalid ContentInfo object. and DIAMETER_INVALID_AUTH 4012 The signature in the CMS-Signed-Data AVP is invalid. > When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data > AVP MUST be created first. This AVP MUST then have the 'P' bit set > and be one of the inputs to the signing process as described above. > (Any other processing resulting in the same output can be used.) This > means that signing is "outside" encryption. > > No more than one CMS-Signed-Data AVP MUST be present in any given > Diameter message. > > 6.2 CMS-Encrypted-Data AVP > > The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and > contains the Basic Encoding Rules (BER) encoding of a CMS object [3] > of type ContentInfo. > > All AVPs to be encrypted are concatenated. This value is then MIME > encoded (according to the rules specified in [16,17]) and then encrypted > according to normal CMS rules, and then used as the value of the ^^^^^^^^ maybe too many "and then" > EncryptedContent field within EnvelopedData. The contentType of the > EncryptedContentInfo value MUST be id-data [11]. > > A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. Where one or > more AVP would be encrypted within separate EnvelopedData structures, then > separate CMS-Encrypted-Data AVPs MUST be used. Well, it has been stated above that all AVPs to be encrypted are concatenated, encoded, encrypted and used as the Encrypted Content of EnvelopedData. Maybe the second paragraph should be rephrased to say "All AVPs to be encrypted in a given AVP are concatenated" > Thus, implementations MUST be able to support the presence of multiple > CMS-Encrypted-Data AVPs and MUST be able to decrypt any EnvelopedData > for which it is a recipient, as indicated in the EnvelopedData's > RecipientInfos field [3]. > > 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. If the recipient is in the > RecipientInfos and an error occurs during decryption, then the > recipient MUST answer with the Result-Code set to > DIAMETER_INVALID_AVP_VALUE. This solves issue 174. > Diameter nodes SHOULD implement content encryption key reuse (see > section 3.4 above). > > If a receiver detects that the contents of the CMS-Encrypted-Data AVP > is invalid, it SHOULD answer with the Result-Code set to ^^^ are > DIAMETER_INVALID_AVP_VALUE. Shouldn't they be DIAMETER_INVALID_CMS_DATA? > Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter > message. > > 6.x Example encodings > > In order to clarify contents of and the relationships between > CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following > example of how these AVPs are calculated. > > First, some short-hand: > > - MIME(x) represents the MIME encoding of x > - EnvelopedData-fnc(x,y) represents the EnvelopedData produced > as output of a function with x as the to-be-encrypted-data > and y as the parameters (e.g. recipient information). > - SignedData (y) represents the SignedData produced > as output of a function with the catenation of the 'P is set' > AVPS as the to-be-digested-data (which is not part of the > output!) and y as the parameters (e.g. signer information). > > The scenario calls for a message containing 7 AVPs s,t,e,p,h,e and n > to meet the following: > AVPs s,t and e are to be encrypted for recipient P. > AVPs e,p and h are to be encrypted for recipient A. > AVPs s,e (2nd time:-) and n are to be signed by originator T. I'd use subindexes: The scenario calls for a message containing 7 AVPs s,t,e1,p,h,e2 and n to meet the following: AVPs s,t and e1 are to be encrypted for recipient P. AVPs e1,p and h are to be encrypted for recipient A. AVPs s,e2 and n are to be signed by originator T. Additionally, I think that information about who has requested a digital signature should be added. > The resulting message will look like: > > AVP1='P is set', EnvelopedData-fnc(MIME(s,t,e),P) > AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) > AVP3='P is set', e > AVP4='P is clear', n > AVP5='P is clear', SignedData(T) AVP1='P is set', EnvelopedData-fnc(MIME(s,t,e1),P) AVP2='P is clear', EnvelopedData-fnc(MIME(e1,p,h),A) AVP3='P is set', e2 AVP4='P is clear', n AVP5='P is clear', SignedData(T) In this example, P would get s,t,e1,e2 and n with a digital signature (either direct or indirect) on only s,t,e1 and e2 (although there is a digital signature on p and h, P isn't able to decrypt AVP2, so that it won't get p and h). In turn, A would get e1,p,h,e2 and n with a digital signature on e2 (A is not able to decrypt AVP1) > The result of this is that AVPs t,e(1st time), p and h are actually > signed even though that wasn't required. However, this is no harm. As a conclusion, I'd add information about who is the receiver of the digital signature, would change the protection bit of AVP4 (n) and would rephrase the last paragraph in order to add such informations... Regards -- 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 Thu Sep 20 06:00: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 GAA04572 for ; Thu, 20 Sep 2001 06:00:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 40FA79121E; Thu, 20 Sep 2001 05:59:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FEA091227; Thu, 20 Sep 2001 05:59: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 C1E4C9121E for ; Thu, 20 Sep 2001 05:59:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AEF575DDE9; Thu, 20 Sep 2001 05:59:43 -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 12FF95DDC6 for ; Thu, 20 Sep 2001 05:59:43 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id KAA12853 for ; Thu, 20 Sep 2001 10:59: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 ; Thu, 20 Sep 2001 10:56:15 +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 LAA00703; Thu, 20 Sep 2001 11:02:23 +0100 Message-ID: <3BA9BDFC.153944F@baltimore.ie> Date: Thu, 20 Sep 2001 10:59:25 +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 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> Content-Type: multipart/mixed; boundary="------------61BFDD4994ED42673E4B6DDC" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------61BFDD4994ED42673E4B6DDC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Miguel, I've no problem with your edits (new text attached), except: > I assume that references 16 and 17 has been added. Could you post such > references? Sorry they were from Pat's working copy: .IP [16] N. Freed, N. Borenstein, " MIME Part 1: Format of Internet Message Bodies", RFC 2045, November 1996. .IP [17] N. Freed, N. Borenstein, " MIME Part 2: Media Types", RFC 2046, November 1996. > > A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. Where one or > > more AVP would be encrypted within separate EnvelopedData structures, then > > separate CMS-Encrypted-Data AVPs MUST be used. > > Well, it has been stated above that all AVPs to be encrypted are > concatenated, encoded, encrypted and used as the Encrypted Content of > EnvelopedData. Maybe the second paragraph should be rephrased to say > "All AVPs to be encrypted in a given AVP are concatenated" I prefer the existing text here. > > 6.x Example encodings I fixed some errors here, not quite the way you asked. > As a conclusion, I'd add information about who is the receiver of the > digital signature, would change the protection bit of AVP4 (n) and > would rephrase the last paragraph in order to add such informations... There's no concept of the "receiver" of a digital signature. Anyone can verify a signature. It is true that sometimes that encrypting and signing will mean that some stuff that was signed isn't visible to some verifiers, but that's presumably the correct situation. Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com --------------61BFDD4994ED42673E4B6DDC Content-Type: text/plain; charset=us-ascii; name="6.1again.txt" Content-Disposition: inline; filename="6.1again.txt" Content-Transfer-Encoding: 7bit Insert into section 6.0: The profile of CMS algorithm and structure usage is conformant to that specified in the S/MIME v3 message specification [11]. This makes is simpler to base an implementation of this specification upon an existing S/MIME toolkit. All MIME encoded data in this specification MUST use the "application/pkcs7-mime" MIME type. 6.1 CMS-Signed-Data AVP The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. This means that where a set of AVPs is to be signed, the set of AVPs with the 'P' bit set MUST first be catenated together in the order in which they occur in the Diameter message and MUST then be encoded according to MIME encoding rules specified in [16,17]. The result of this encoding is used as input into the signing process. Note that the AVPs themselves are not encapsulated within the CMS-Signed-Data AVP. Instead, the digest value of the AVPs produced in the signature process MUST be included in the CMS-Signed- Data AVP, as a message-digest attribute (defined in section 11.2 of [3]) in the SignerInfo value. Multiple Diameter entities MAY add their signatures to an existing CMS-Signed-Data AVP. Multiple signatures are added within the countersignature attribute (defined in section 11.4 of [3]) and not as additional SignerInfo values. The countersignature attribute requires that the signatures occur sequentially, meaning that each signature covers the existing signatures in the CMS object. The initial signature, and any additional countersignatures, MUST cover the exact same set of AVPs, in the order they are present in the message. Note that the CMS-Signed-Data AVP itself MUST NOT be used in the generation of the signature, and therefore MUST NOT have its 'P' bit set. The eContent field of the EncapsulatedContentInfo structure MUST be absent since the digital signature covers data outside of the object. The signature is computed over all AVPs with the 'P' bit enabled. The order of the AVPs MUST be preserved and the computation begins with the first AVP immediately following the Diameter header. If a receiver cannot verify correctly the signature carried by the CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH Result-Code AVP value defined in section 7.1. When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first. This AVP MUST then have the 'P' bit set and be one of the inputs to the signing process as described above. (Any other processing resulting in the same output can be used.) This means that signing is "outside" encryption. No more than one CMS-Signed-Data AVP MUST be present in any given Diameter message. 6.2 CMS-Encrypted-Data AVP The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. All AVPs to be encrypted are concatenated. This value is then: - MIME encoded (according to the rules specified in [16,17]), - encrypted according to normal CMS rules, - used as the value of the EncryptedContent field within EnvelopedData. The contentType of the EncryptedContentInfo value MUST be id-data [11]. A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. Where one or more AVP would be encrypted within separate EnvelopedData structures, then separate CMS-Encrypted-Data AVPs MUST be used. Thus, implementations MUST be able to support the presence of multiple CMS-Encrypted-Data AVPs and MUST be able to decrypt any EnvelopedData for which it is a recipient, as indicated in the EnvelopedData's RecipientInfos field [3]. 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. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST answer with the Result-Code set to DIAMETER_INVALID_AVP_VALUE. Diameter nodes SHOULD implement content encryption key reuse (see section 3.4 above). If a receiver detects that the contents of the CMS-Encrypted-Data AVP are invalid, it SHOULD answer with the Result-Code set to DIAMETER_INVALID_CMS_DATA. Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter message. 6.x Example encodings In order to clarify contents of and the relationships between CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following example of how these AVPs are calculated. First, some short-hand: - MIME(x) represents the MIME encoding of x - EnvelopedData-fnc(x,y) represents the EnvelopedData produced as output of a function with x as the to-be-encrypted-data and y as the parameters (e.g. recipient information). - SignedData (y) represents the SignedData produced as output of a function with the catenation of the 'P is set' AVPs as the to-be-digested-data (which is not part of the output!) and y as the parameters (e.g. signer information). The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n to meet the following: AVPs s, t and e are to be encrypted for recipient P. AVPs e, p and h are to be encrypted for recipient A. AVPs s, e' and n are to be signed by originator T. The resulting message will look like: AVP1='P is set', EnvelopedData-fnc(MIME(s,t,e),P) AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) AVP3='P is set', e' AVP4='P is set', n AVP5='P is clear', SignedData(T) The result of this is that AVPs s,t,e,e' and n are actually signed even though signing of t and e wasn't required. However, this is no harm. --------------61BFDD4994ED42673E4B6DDC-- From owner-aaa-wg@merit.edu Thu Sep 20 09:27: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 JAA09272 for ; Thu, 20 Sep 2001 09:27:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17AEB91227; Thu, 20 Sep 2001 09:26:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFD8E91244; Thu, 20 Sep 2001 09:26: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 8E86991227 for ; Thu, 20 Sep 2001 09:26:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 798315DDD4; Thu, 20 Sep 2001 09:26:17 -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 D14245DDC6 for ; Thu, 20 Sep 2001 09:26:16 -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 f8KDPZK22184; Thu, 20 Sep 2001 15:25:39 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA26181; Thu, 20 Sep 2001 15:25:28 +0200 (MET DST) Message-ID: <3BA9EE00.AF3925BE@rioja.ericsson.se> Date: Thu, 20 Sep 2001 15:24:16 +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 Cc: stephen.farrell@baltimore.ie, Pat Calhoun Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Stephen Farrell wrote: > > Miguel, > > > > 6.x Example encodings > > I fixed some errors here, not quite the way you asked. > > > As a conclusion, I'd add information about who is the receiver of the > > digital signature, would change the protection bit of AVP4 (n) and > > would rephrase the last paragraph in order to add such informations... > > There's no concept of the "receiver" of a digital signature. Anyone can > verify a signature. It is true that sometimes that encrypting and > signing will mean that some stuff that was signed isn't visible to > some verifiers, but that's presumably the correct situation. OK. This is right in a wide sense but it's necessary to take into account that Diameter CMS Security employs widely DSAs. The two participants usually request some kind of protection (AVPs to be protected and means to get the protection). In such a scenario, there is a "receiver" of the digital signature (the participant that has requested it). Let's take your example: > The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n > to meet the following: > AVPs s, t and e are to be encrypted for recipient P. > AVPs e, p and h are to be encrypted for recipient A. > AVPs s, e' and n are to be signed by originator T. > > The resulting message will look like: > > AVP1='P is set', EnvelopedData-fnc(MIME(s,t,e),P) > AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) > AVP3='P is set', e' > AVP4='P is set', n > AVP5='P is clear', SignedData(T) Let's imagine that this scenario happens withing a DSA established between T and P. P has requested a digital signature on s, e' and n and encryption on s, t and e. The resulting message will comply with the requests: - Encryption of s, t and e (AVP1) - Digital signature on s, t, e, e' and n. What about if the DSA has been established between T and A. A has requested a digital signature on s, e' and n and encryption on e, p and h. The resulting message won't comply with the requests: - Encryption of e, p and h. - Digital signature on e' and n. But NOT on s .It can be argued that s has been signed since the digital signature has been applied on AVP1, AVP3 and AVP4. But it isn't actually true. A can't decrypt s since it's visible. My conclusion is that, when assembling Diameter messages, the participant must be very careful with the way in which it encrypts and signs the AVPs (that was the purpose of issue 181) depending on the parameter of the DSA. For instance, in your example, if the receiver of the message is A and not P, the resulting message must look like: --->>> AVP1='P is clear', EnvelopedData-fnc(MIME(s,t,e),P) (*) AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) AVP3='P is set', e' AVP4='P is set', n AVP5='P is clear', SignedData(T) --->>> AVP6='P is set', s (*) If no internal policy states that P also requests digital signature on its encrypted AVPs. It isn't important to note that, although there's no receiver of a digital signature, there is actually a receiver of a Diameter message secured with Diameter CMS Security. 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 Thu Sep 20 09: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 JAA09894 for ; Thu, 20 Sep 2001 09:42:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B67BC91245; Thu, 20 Sep 2001 09:41:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8441591246; Thu, 20 Sep 2001 09:41: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 434CF91245 for ; Thu, 20 Sep 2001 09:41:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 298F15DDC6; Thu, 20 Sep 2001 09:41:50 -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 7F18B5DD98 for ; Thu, 20 Sep 2001 09:41:49 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id OAA15473 for ; Thu, 20 Sep 2001 14:41:28 +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, 20 Sep 2001 14:38:21 +0100 Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA00635; Thu, 20 Sep 2001 15:46:28 +0100 Message-ID: <3BA9F20B.60BD212E@baltimore.ie> Date: Thu, 20 Sep 2001 14:41: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 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@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, I think it would be an error to start complicating the concept of the DSA to include ideas about signing only being allowed between nodes that share a DSA, and only for some AVPs and only on Mondays and only if the sky's clear etc.. Signing is effectively independent of DSAs. Unnecessary signatures are no harm to anyone. Insisting on things not being signed when you don't care seems worse than useless to me. > OK. This is right in a wide sense but it's necessary to take into > account that Diameter CMS Security employs widely DSAs. Nope. Signing with RSA doesn't ever require a concept of a receiver. End of story. > The two > participants usually request some kind of protection (AVPs to be > protected and means to get the protection). In such a scenario, there > is a "receiver" of the digital signature (the participant that has > requested it). Irrelevant. If someone wants to do extra work signing then that's fine. If someone needs a signature they insist on it. There's no need to complicate things so lets not. (Or else reference the requjirement/use-case that shows that there is). > What about if the DSA has been established between T and A. A has > requested a digital signature on s, e' and n and encryption on e, p > and h. So A gets more stuff signed than he needs, big deal. > The resulting message won't comply with the requests: > --->>> AVP1='P is clear', EnvelopedData-fnc(MIME(s,t,e),P) (*) > AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) > AVP3='P is set', e' > AVP4='P is set', n > AVP5='P is clear', SignedData(T) > --->>> AVP6='P is set', s I think it is clearly wrong to suggest (as you seem to be doing) that AVP 's' be sent both encrypted (AVP1) and in clear (AVP6). How could that ever be a good idea? > It isn't important to note that, although there's no receiver of a > digital signature, there is actually a receiver of a Diameter message > secured with Diameter CMS Security. That sentence doesn't pass my parser:-) 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 Sep 20 10:13: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 KAA11034 for ; Thu, 20 Sep 2001 10:13:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD30C9123D; Thu, 20 Sep 2001 10:12:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B135F91248; Thu, 20 Sep 2001 10:12: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 51AD39123D for ; Thu, 20 Sep 2001 10:12:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36FC35DDD4; Thu, 20 Sep 2001 10:12:20 -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 675B85DD98 for ; Thu, 20 Sep 2001 10:12:19 -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.10.1/WIREfire-1.3) with ESMTP id f8KEBWv09153; Thu, 20 Sep 2001 16:11:32 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA01837; Thu, 20 Sep 2001 16:11:26 +0200 (MET DST) Message-ID: <3BA9F923.2ABB834@rioja.ericsson.se> Date: Thu, 20 Sep 2001 16:11:47 +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 Cc: stephen.farrell@baltimore.ie, Pat Calhoun Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@rioja.ericsson.se> <3BA9F20B.60BD212E@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: > > > What about if the DSA has been established between T and A. A has > > requested a digital signature on s, e' and n and encryption on e, p > > and h. > > So A gets more stuff signed than he needs, big deal. I think that is the key point of this discussion. I've got no problem with extra signatures. Just more stuff as you say. But if encryption is involved isn't so easy. > > The resulting message won't comply with the requests: > > --->>> AVP1='P is clear', EnvelopedData-fnc(MIME(s,t,e),P) (*) > > AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) > > AVP3='P is set', e' > > AVP4='P is set', n > > AVP5='P is clear', SignedData(T) > > --->>> AVP6='P is set', s > > I think it is clearly wrong to suggest (as you seem to be doing) that > AVP 's' be sent both encrypted (AVP1) and in clear (AVP6). How could > that ever be a good idea? What I suggest is that if A wants encryption of e, p and h and digital signature on e', n and s its irrelevant that e is actually present in the message since it isn't visible for A. So that, if T want to fulfil the requirements of P (the other participant of the DSA). If you don't like my proposal about the message, what about this? AVP1='P is anything', 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 set', n AVP5='P is clear', SignedData(T) Anyway, AVP 's' has to be sent in a way that the requester (A, the other participant of the DSA) can recover it. It means that it has to be included twice because of the internal policy of T (that requires an additional encryption for P). This is the end of story, isn't it? A message encrypted for P is invisible for A. My only purpose is pointing that a careful technique must be implemented in a node when combining digital signature and encryption (specially if several encryption receivers are involved). According to this, I think that it's important to point that the message you're using as example will depend on the previously established DSA. > > It isn't important to note that, although there's no receiver of a > > digital signature, there is actually a receiver of a Diameter message > > secured with Diameter CMS Security. > > That sentence doesn't pass my parser:-) May I suggest upgrading to a new version ;-)) Regards // M.A. From owner-aaa-wg@merit.edu Thu Sep 20 10:15:27 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 KAA11092 for ; Thu, 20 Sep 2001 10:15:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F03191248; Thu, 20 Sep 2001 10:14:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CC8D91249; Thu, 20 Sep 2001 10:14: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 EFBA191248 for ; Thu, 20 Sep 2001 10:14:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D27415DDD4; Thu, 20 Sep 2001 10:14:28 -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 42D7D5DDC6 for ; Thu, 20 Sep 2001 10:14:28 -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 f8KEDnK13367; Thu, 20 Sep 2001 16:13:49 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA02078; Thu, 20 Sep 2001 16:13:46 +0200 (MET DST) Message-ID: <3BA9F9B0.B1B1FD0@rioja.ericsson.se> Date: Thu, 20 Sep 2001 16:14:08 +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 Cc: stephen.farrell@baltimore.ie, Pat Calhoun Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@rioja.ericsson.se> <3BA9F20B.60BD212E@baltimore.ie> <3BA9F923.2ABB834@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: > > > > > What about if the DSA has been established between T and A. A has > > > requested a digital signature on s, e' and n and encryption on e, p > > > and h. > > > > So A gets more stuff signed than he needs, big deal. > > I think that is the key point of this discussion. I've got no problem > with extra signatures. Just more stuff as you say. But if encryption > is involved isn't so easy. > > > > The resulting message won't comply with the requests: > > > --->>> AVP1='P is clear', EnvelopedData-fnc(MIME(s,t,e),P) (*) > > > AVP2='P is clear', EnvelopedData-fnc(MIME(e,p,h),A) > > > AVP3='P is set', e' > > > AVP4='P is set', n > > > AVP5='P is clear', SignedData(T) > > > --->>> AVP6='P is set', s > > > > I think it is clearly wrong to suggest (as you seem to be doing) that > > AVP 's' be sent both encrypted (AVP1) and in clear (AVP6). How could > > that ever be a good idea? > > What I suggest is that if A wants encryption of e, p and h and digital > signature on e', n and s its irrelevant that e is actually present in > the message since it isn't visible for A. So that, if T want to fulfil > the requirements of P (the other participant of the DSA). If you don't ^ it has to include the AVP twoice > like my proposal about the message, what about this? > > AVP1='P is anything', 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 set', n > AVP5='P is clear', SignedData(T) > > Anyway, AVP 's' has to be sent in a way that the requester (A, the > other participant of the DSA) can recover it. It means that it has to > be included twice because of the internal policy of T (that requires > an additional encryption for P). This is the end of story, isn't it? A > message encrypted for P is invisible for A. > > My only purpose is pointing that a careful technique must be > implemented in a node when combining digital signature and encryption > (specially if several encryption receivers are involved). According to > this, I think that it's important to point that the message you're > using as example will depend on the previously established DSA. > > > > It isn't important to note that, although there's no receiver of a > > > digital signature, there is actually a receiver of a Diameter message > > > secured with Diameter CMS Security. > > > > That sentence doesn't pass my parser:-) > > May I suggest upgrading to a new version ;-)) > > 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 Thu Sep 20 10: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 KAA11708 for ; Thu, 20 Sep 2001 10:32:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B8C291249; Thu, 20 Sep 2001 10:31:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2167B9124A; Thu, 20 Sep 2001 10:31: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 D49D791249 for ; Thu, 20 Sep 2001 10:31:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B60525DDC6; Thu, 20 Sep 2001 10:31:19 -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 5F4505DD98 for ; Thu, 20 Sep 2001 10:31:18 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id PAA28291 for ; Thu, 20 Sep 2001 15:30:56 +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, 20 Sep 2001 15:27:49 +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 QAA12224; Thu, 20 Sep 2001 16:35:55 +0100 Message-ID: <3BA9FDA1.AD56705D@baltimore.ie> Date: Thu, 20 Sep 2001 15:30:57 +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 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@rioja.ericsson.se> <3BA9F20B.60BD212E@baltimore.ie> <3BA9F923.2ABB834@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, The original scenario in the example was: The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n to meet the following: AVPs s, t and e are to be encrypted for recipient P. AVPs e, p and h are to be encrypted for recipient A. AVPs s, e' and n are to be signed by originator T. The set of AVPs I described meet this requirement. In your mails you've added a new requirement "that s be sent to A", which I did not include. (Indeed by saying that s had to be encrypted for P, I was implicitly stating that "s not be visible to A".) If your additional requirement were added to the list then the AVP set below is almost ok: > AVP1='P is anything', 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 set', n > AVP5='P is clear', SignedData(T) The problem with it is that 'P is anything' is not allowed. P is either set (in which case the AVP is input to signing) or is clear (in which case it isn't). That means that the set of AVPs below meets the combination of the original requirements and your new one ("that s be sent to A"). 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 set', n AVP5='P is clear', SignedData(T) Those AVPs can be sent to either P or A and will meet the requirements. So, are you suggesting that I change the scenario to include the additional requirement? If that's all: we're done, no problem, I'll include it. (I guess it does show up a rule: don't send the same AVP encrypted and in clear; which is probably worth stating though it should be obvious:-) If you're after something else, then I don't know what it is, nor where the requirement is coming from. 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 Sep 20 10:54: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 KAA12522 for ; Thu, 20 Sep 2001 10:54:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A970B9124A; Thu, 20 Sep 2001 10:53:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F5379124C; Thu, 20 Sep 2001 10:53: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 2A1729124A for ; Thu, 20 Sep 2001 10:53:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 072D85DDC6; Thu, 20 Sep 2001 10:53:29 -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 2ECA25DD98 for ; Thu, 20 Sep 2001 10:53:28 -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 f8KEqfK12903; Thu, 20 Sep 2001 16:52:41 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA07703; Thu, 20 Sep 2001 16:52:35 +0200 (MET DST) Message-ID: <3BAA02C8.B7A5A231@rioja.ericsson.se> Date: Thu, 20 Sep 2001 16:52:56 +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 Cc: stephen.farrell@baltimore.ie, Pat Calhoun Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@rioja.ericsson.se> <3BA9F20B.60BD212E@baltimore.ie> <3BA9F923.2ABB834@rioja.ericsson.se> <3BA9FDA1.AD56705D@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Stephen Farrell wrote: > > Miguel, > > The original scenario in the example was: > > The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n > to meet the following: > AVPs s, t and e are to be encrypted for recipient P. > AVPs e, p and h are to be encrypted for recipient A. > AVPs s, e' and n are to be signed by originator T. > > The set of AVPs I described meet this requirement. Yes, it did. > In your mails you've added a new requirement "that s be sent > to A", which I did not include. (Indeed by saying that s had to > be encrypted for P, I was implicitly stating that "s not be > visible to A".) Well, the new requirement only wanted to note that usually such scenarios exist within a DSA. Just that. > If your additional requirement were added to the list then > the AVP set below is almost ok: > > > AVP1='P is anything', 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 set', n > > AVP5='P is clear', SignedData(T) > > The problem with it is that 'P is anything' is not allowed. P is > either set (in which case the AVP is input to signing) or is > clear (in which case it isn't). Right. I just wanted to say that, in a DSA between T and A, the actual protection flag of AVP1 is irrelevant (if no protection status has been stated for P). > That means that the set of AVPs below meets the combination of > the original requirements and your new one ("that s be sent to A"). > > 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 set', n > AVP5='P is clear', SignedData(T) > > Those AVPs can be sent to either P or A and will meet the > requirements. Yes. > So, are you suggesting that I change the scenario to include the > additional requirement? If that's all: we're done, no problem, > I'll include it. That's all. Just saying that when encrypting and signing, the "receiver" (of the message, not of the digital signature, so that this character doesn't play this movie) has to be taken into account. > (I guess it does show up a rule: don't send the > same AVP encrypted and in clear; which is probably worth stating > though it should be obvious:-) Yes, it should have been obvious :-)) > If you're after something else, then I don't know what it is, > nor where the requirement is coming from. Nothing else. Regards -- 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 Thu Sep 20 11: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 LAA12791 for ; Thu, 20 Sep 2001 11:02:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 029C49124C; Thu, 20 Sep 2001 11:01:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C895691295; Thu, 20 Sep 2001 11:01: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 3EDC19124C for ; Thu, 20 Sep 2001 11:01:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2530B5DDC6; Thu, 20 Sep 2001 11:01:39 -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 7C3095DD98 for ; Thu, 20 Sep 2001 11:01:38 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id QAA29269 for ; Thu, 20 Sep 2001 16:01: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 ; Thu, 20 Sep 2001 15:58:07 +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 RAA01236; Thu, 20 Sep 2001 17:06:15 +0100 Message-ID: <3BAA04BD.2AF9430C@baltimore.ie> Date: Thu, 20 Sep 2001 16:01: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: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@rioja.ericsson.se> <3BA9F20B.60BD212E@baltimore.ie> <3BA9F923.2ABB834@rioja.ericsson.se> <3BA9FDA1.AD56705D@baltimore.ie> <3BAA02C8.B7A5A231@rioja.ericsson.se> Content-Type: multipart/mixed; boundary="------------B05DBAC723B0073872DE96CF" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------B05DBAC723B0073872DE96CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Latest and greatest 6.1/6.2 text attached and we're done (I hope:-) 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 --------------B05DBAC723B0073872DE96CF Content-Type: text/plain; charset=us-ascii; name="6.1again.txt" Content-Disposition: inline; filename="6.1again.txt" Content-Transfer-Encoding: 7bit Insert into section 6.0: The profile of CMS algorithm and structure usage is conformant to that specified in the S/MIME v3 message specification [11]. This makes is simpler to base an implementation of this specification upon an existing S/MIME toolkit. All MIME encoded data in this specification MUST use the "application/pkcs7-mime" MIME type. 6.1 CMS-Signed-Data AVP The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. This means that where a set of AVPs is to be signed, the set of AVPs with the 'P' bit set MUST first be catenated together in the order in which they occur in the Diameter message and MUST then be encoded according to MIME encoding rules specified in [16,17]. The result of this encoding is used as input into the signing process. Note that the AVPs themselves are not encapsulated within the CMS-Signed-Data AVP. Instead, the digest value of the AVPs produced in the signature process MUST be included in the CMS-Signed- Data AVP, as a message-digest attribute (defined in section 11.2 of [3]) in the SignerInfo value. Multiple Diameter entities MAY add their signatures to an existing CMS-Signed-Data AVP. Multiple signatures are added within the countersignature attribute (defined in section 11.4 of [3]) and not as additional SignerInfo values. The countersignature attribute requires that the signatures occur sequentially, meaning that each signature covers the existing signatures in the CMS object. The initial signature, and any additional countersignatures, MUST cover the exact same set of AVPs, in the order they are present in the message. Note that the CMS-Signed-Data AVP itself MUST NOT be used in the generation of the signature, and therefore MUST NOT have its 'P' bit set. The eContent field of the EncapsulatedContentInfo structure MUST be absent since the digital signature covers data outside of the object. The signature is computed over all AVPs with the 'P' bit enabled. The order of the AVPs MUST be preserved and the computation begins with the first AVP immediately following the Diameter header. If a receiver cannot verify correctly the signature carried by the CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH Result-Code AVP value defined in section 7.1. When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data AVP MUST be created first. This AVP MUST then have the 'P' bit set and be one of the inputs to the signing process as described above. (Any other processing resulting in the same output can be used.) This means that signing is "outside" encryption. No more than one CMS-Signed-Data AVP MUST be present in any given Diameter message. 6.2 CMS-Encrypted-Data AVP The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and contains the Basic Encoding Rules (BER) encoding of a CMS object [3] of type ContentInfo. All AVPs to be encrypted are concatenated. This value is then: - MIME encoded (according to the rules specified in [16,17]), - encrypted according to normal CMS rules, - used as the value of the EncryptedContent field within EnvelopedData. The contentType of the EncryptedContentInfo value MUST be id-data [11]. A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. Where one or more AVP would be encrypted within separate EnvelopedData structures, then separate CMS-Encrypted-Data AVPs MUST be used. Thus, implementations MUST be able to support the presence of multiple CMS-Encrypted-Data AVPs and MUST be able to decrypt any EnvelopedData for which it is a recipient, as indicated in the EnvelopedData's RecipientInfos field [3]. 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. If the recipient is in the RecipientInfos and an error occurs during decryption, then the recipient MUST answer with the Result-Code set to DIAMETER_INVALID_AVP_VALUE. Diameter nodes SHOULD implement content encryption key reuse (see section 3.4 above). If a receiver detects that the contents of the CMS-Encrypted-Data AVP are invalid, it SHOULD answer with the Result-Code set to DIAMETER_INVALID_CMS_DATA. Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter message. 6.x Example encodings In order to clarify the contents of and the relationships between CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following example of how these AVPs are calculated. First, some short-hand: - MIME(x) represents the MIME encoding of x - EnvelopedData-fnc(x,y) represents the EnvelopedData produced as output of a function with x as the to-be-encrypted-data and y as the parameters (e.g. recipient information). - SignedData (y) represents the SignedData produced as output of a function with the catenation of the 'P is set' AVPs as the to-be-digested-data (which is not part of the output!) and y as the parameters (e.g. signer information). The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n to meet the following: AVPs s, t and e are to be encrypted for recipient P. AVPs e, p and h are to be encrypted for recipient A. AVPs s, and e' are to be signed by originator T. AVP s is to be sent to recipient A. AVP n needs neither signing nor encryption. Note that though there is no explicit requirement that AVP s be encrypted for A, since it will be encrypted for P, we also have to encrypt it for A. Implementations SHOULD NOT send the same AVP both encrypted and in clear. 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) The result of this is that all AVPs excapt n are actually signed even though signing of t and e wasn't explicitly required. However, this is no harm. --------------B05DBAC723B0073872DE96CF-- From owner-aaa-wg@merit.edu Thu Sep 20 11:10: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 LAA13008 for ; Thu, 20 Sep 2001 11:10:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E929291295; Thu, 20 Sep 2001 11:10:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2A9B91310; Thu, 20 Sep 2001 11:10: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 8222991295 for ; Thu, 20 Sep 2001 11:10:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E9D95DDC6; Thu, 20 Sep 2001 11:10:10 -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 949E25DD98 for ; Thu, 20 Sep 2001 11:10:09 -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.10.1/WIREfire-1.3) with ESMTP id f8KF9Xv21317; Thu, 20 Sep 2001 17:09:33 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA10795; Thu, 20 Sep 2001 17:09:27 +0200 (MET DST) Message-ID: <3BAA06BD.6C073FA6@rioja.ericsson.se> Date: Thu, 20 Sep 2001 17:09:49 +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 Cc: stephen.farrell@baltimore.ie Subject: Re: [AAA-WG]: Issue 150: S/MIME precisions References: <20010830104633.B8794@charizard.diameter.org> <3B8F3DC2.B94F6A49@rioja.ericsson.se> <20010903111122.D19656@charizard.diameter.org> <3B94E1D0.10BA0A28@rioja.ericsson.se> <3BA789B5.A2D27EC6@baltimore.ie> <3BA9B856.E97DCA3C@rioja.ericsson.se> <3BA9BDFC.153944F@baltimore.ie> <3BA9EE00.AF3925BE@rioja.ericsson.se> <3BA9F20B.60BD212E@baltimore.ie> <3BA9F923.2ABB834@rioja.ericsson.se> <3BA9FDA1.AD56705D@baltimore.ie> <3BAA02C8.B7A5A231@rioja.ericsson.se> <3BAA04BD.2AF9430C@baltimore.ie> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Stephen Farrell wrote: > > Latest and greatest 6.1/6.2 text attached and we're done > (I hope:-) Perfect!!! :-))) 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 Thu Sep 20 11:23: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 LAA13348 for ; Thu, 20 Sep 2001 11:23:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0E0191310; Thu, 20 Sep 2001 11:23:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8451691314; Thu, 20 Sep 2001 11:23: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 49E3791310 for ; Thu, 20 Sep 2001 11:23:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25BD05DDC6; Thu, 20 Sep 2001 11:23: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 8268F5DD98 for ; Thu, 20 Sep 2001 11:23: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.10.1/WIREfire-1.3) with ESMTP id f8KFMmv28560 for ; Thu, 20 Sep 2001 17:22:49 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA11753; Thu, 20 Sep 2001 17:22:44 +0200 (MET DST) Message-ID: <3BAA09DA.208A2530@rioja.ericsson.se> Date: Thu, 20 Sep 2001 17:23:06 +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] Digital encryption + signature in CMS-Sec References: <3B97374A.50488C44@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 Hi all, according to the discusion on issue 150, this issue may be removed. A little bit of digital signature doesn't harm any AVP :-))) Regards // M.A. PS: maybe a fragment of the proposed text: > Where an implementation wants to receive a set of AVPs both > encrypted and signed it MIGHT use a work around consisting of > requiring such a set of AVPs as encrypted (using as many as > needed Expected-Encrypted-AVP AVPs) and CMS-Encrypted-Data > AVP as digitally signed (using an only Expected-Signed-AVP > AVP). could be added at the end of 6.10 -- 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 Thu Sep 20 18:52: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 SAA25922 for ; Thu, 20 Sep 2001 18:52:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 267399124C; Thu, 20 Sep 2001 18:51:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E868191268; Thu, 20 Sep 2001 18:51: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 B7A149124C for ; Thu, 20 Sep 2001 18:51:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5DF15DDE7; Thu, 20 Sep 2001 18:51:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 51B435DDB7 for ; Thu, 20 Sep 2001 18:51:21 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA07049 for ; Thu, 20 Sep 2001 15:50:44 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA20892 for ; Thu, 20 Sep 2001 15:50:43 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 20 Sep 2001 17:50:43 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter MIPv4 questions Date: Thu, 20 Sep 2001 17:50:42 -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 Pat, In a MIPv4 scenario, the Auth-Lifetime value MUST be communicated to the MN, so that it knows when to re-register. How is this done? Is it via the registration lifetime (Lifetime field in the Registration Reply header), or via the registration keys' lifetime (Lifetime field in the "Unsolicited MN-FA/HA Key Material From AAA" subtype)? Also, is the absence/presence of the MN-AAA Authentication subtype, the trigger at the FA to decide if the message should go directly to HA or via the AAA infrastructure? Thanks, -Panos From owner-aaa-wg@merit.edu Fri Sep 21 03:53: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 DAA17343 for ; Fri, 21 Sep 2001 03:53:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2884A91267; Fri, 21 Sep 2001 03:52:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D62C491269; Fri, 21 Sep 2001 03:52: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 7AF6191267 for ; Fri, 21 Sep 2001 03:52:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A02A5DD96; Fri, 21 Sep 2001 03:52:38 -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 6BCBC5DD8D for ; Fri, 21 Sep 2001 03:52:37 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f8L7qCK27925 for ; Fri, 21 Sep 2001 09:52:13 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Sep 21 09:52:02 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 09:52:02 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA03441C86@efijont102> From: "Harri Hakala (LMF)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Acct-Application-Id Date: Fri, 21 Sep 2001 09:42:56 +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 would like to know is it possible to use Diameter Accounting commands without any application specified by Diameter Base protocol. I just would like to add a few vendor specific AVPs and use the standard Diameter accounting commands. Or should I create a new vendor specific diameter application to be able to specify the Acct-Application-Id ? Regards...Harri Hakala From owner-aaa-wg@merit.edu Fri Sep 21 06:17: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 GAA18407 for ; Fri, 21 Sep 2001 06:17:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DE559124F; Fri, 21 Sep 2001 06:16:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F4AE91251; Fri, 21 Sep 2001 06:16: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 DA0E49124F for ; Fri, 21 Sep 2001 06:16:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1A995DDCA; Fri, 21 Sep 2001 06:16:09 -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 20D4F5DDB1 for ; Fri, 21 Sep 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 f8LAFhK07967 for ; Fri, 21 Sep 2001 12:15:43 +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 f8LAFfb27483; Fri, 21 Sep 2001 13:15:41 +0300 (EET DST) Message-ID: <3BAB134D.2699204B@lmf.ericsson.se> Date: Fri, 21 Sep 2001 13:15:41 +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]: Acct-Application-Id References: <0154633DAF7BD4119C360002A513AA03441C86@efijont102> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I would like to know is it possible to use Diameter >Accounting commands without any application specified >by Diameter Base protocol. You can define either standard or private application identifiers, as described in section 11.3. A private application identifier would belong either to a vendor, or possibly another standards organization. So, you can do this and use Diameter to transport accounting data without an application RFC. Having said that, it might be a good idea anyway to have e.g. an Informational RFC that describes your application. The advantage of this would be that then you'd be able to say what extra/special AVPs are necessary in your case etc. Jari From owner-aaa-wg@merit.edu Fri Sep 21 09:54: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 JAA25351 for ; Fri, 21 Sep 2001 09:54:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E99A89125C; Fri, 21 Sep 2001 09:53:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD50E9125D; Fri, 21 Sep 2001 09:53:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A10E39125C for ; Fri, 21 Sep 2001 09:53:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89B585DDED; Fri, 21 Sep 2001 09:53:47 -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 791545DDE9 for ; Fri, 21 Sep 2001 09:53:46 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA26760; Fri, 21 Sep 2001 15:53:49 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , , "Tony Johansson" Subject: RE: [AAA-WG]: Issue 172: The need for Float128? Date: Fri, 21 Sep 2001 15:54:18 +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: <20010915081330.H14171@charizard.diameter.org> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree that we should not re-open the whole data type discussion again, but I'm still in favor for removing float 128 since it's not supported by many of the common hardware platforms and compilators. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 15 september 2001 17:14 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Issue 172: The need for Float128? > > >This AVP type was added by the data type folks since it exists in other >protocols, and we were attempting to simply reuse what is already defined >out there. If the WG agrees to delete this type, I'm ok with it, but I >really hate to re-open the whole data type can of worms :( > >PatC From owner-aaa-wg@merit.edu Fri Sep 21 11:02: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 LAA27768 for ; Fri, 21 Sep 2001 11:02:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3FC229125C; Fri, 21 Sep 2001 11:02:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 035E99125F; Fri, 21 Sep 2001 11:02: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 DD21E9125C for ; Fri, 21 Sep 2001 11:02:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C51985DDE9; Fri, 21 Sep 2001 11:02: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 43CC75DDDE for ; Fri, 21 Sep 2001 11:02:05 -0400 (EDT) Received: (qmail 27946 invoked by uid 500); 21 Sep 2001 14:47:58 -0000 Date: Fri, 21 Sep 2001 07:47:58 -0700 From: Pat Calhoun To: "Harri Hakala (LMF)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Acct-Application-Id Message-ID: <20010921074758.D27874@charizard.diameter.org> Mail-Followup-To: "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" References: <0154633DAF7BD4119C360002A513AA03441C86@efijont102> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0154633DAF7BD4119C360002A513AA03441C86@efijont102>; from Harri.Hakala@lmf.ericsson.se on Fri, Sep 21, 2001 at 09:42:56AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk vendor specific acct-appl-id is required. PatC On Fri, Sep 21, 2001 at 09:42:56AM +0200, Harri Hakala (LMF) wrote: > Hi, > > I would like to know is it possible to use Diameter Accounting commands > without any application specified by Diameter Base protocol. > > I just would like to add a few vendor specific AVPs and use the standard > Diameter accounting commands. > Or should I create a new vendor specific diameter application to be able to > specify the Acct-Application-Id ? > > Regards...Harri Hakala From owner-aaa-wg@merit.edu Fri Sep 21 11:36: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 LAA28844 for ; Fri, 21 Sep 2001 11:36:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7FD6591267; Fri, 21 Sep 2001 11:35:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E415991269; Fri, 21 Sep 2001 11:35: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 D5E8C91267 for ; Fri, 21 Sep 2001 11:35:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC3995DDE9; Fri, 21 Sep 2001 11:35: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 364435DDDE for ; Fri, 21 Sep 2001 11:35:38 -0400 (EDT) Received: (qmail 28784 invoked by uid 500); 21 Sep 2001 15:21:31 -0000 Date: Fri, 21 Sep 2001 08:21:31 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter MIPv4 questions Message-ID: <20010921082131.Q27874@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 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 panos.thomas@motorola.com on Thu, Sep 20, 2001 at 05:50:42PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk > In a MIPv4 scenario, the Auth-Lifetime value MUST be communicated to > the MN, so that it knows when to re-register. How is this done? > Is it via the registration lifetime (Lifetime field in the > Registration Reply header), or via the registration keys' lifetime > (Lifetime field in the "Unsolicited MN-FA/HA Key Material From AAA" > subtype)? reg lifetime in reg reply. > Also, is the absence/presence of the MN-AAA Authentication subtype, > the trigger at the FA to decide if the message should go directly > to HA or via the AAA infrastructure? correct, and the FA has the option to reject the reg req if the MN-AAA is missing, and it believes it needs to be present. The mobile would then have to re-issue a reg req. PatC From owner-aaa-wg@merit.edu Fri Sep 21 11:53: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 LAA29248 for ; Fri, 21 Sep 2001 11:53:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A193791269; Fri, 21 Sep 2001 11:52:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7777D9126A; Fri, 21 Sep 2001 11:52: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 42B1D91269 for ; Fri, 21 Sep 2001 11:52:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CCCD5DDED; Fri, 21 Sep 2001 11:52:39 -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 734B35DDDE for ; Fri, 21 Sep 2001 11:52:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA15947 for ; Fri, 21 Sep 2001 08:44:37 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 21 Sep 2001 08:44:37 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue]: Diameter hop-by-hop security Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 9/19/01 Document: base-07 Comment type: Technical Priority: Must fix Section: 2.2 Securing Diameter Messages Explanation of issue: There is a mismatch between security support required on the client and on the server. Diameter clients MUST support IPsec, and MAY support TLS. Yet, Diameter Servers MUST support TLS, and MAY support IPsec. Thus, compliant Diameter clients & servers won't necessarily interoperate. Requested change: Change text to: Diameter Servers MUST support TLS and IPsec. From owner-aaa-wg@merit.edu Mon Sep 24 09:01: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 JAA01245 for ; Mon, 24 Sep 2001 09:01:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4687191254; Mon, 24 Sep 2001 08:08:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1851491256; Mon, 24 Sep 2001 08:08: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 0618791254 for ; Mon, 24 Sep 2001 08:08:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5F525DD97; Mon, 24 Sep 2001 08:08: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 93FB65DD91 for ; Mon, 24 Sep 2001 08:08:28 -0400 (EDT) Received: (qmail 14725 invoked by uid 500); 24 Sep 2001 11:54:02 -0000 Date: Mon, 24 Sep 2001 04:54:02 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 180: AAA-Server-Certs Message-ID: <20010924045402.F13756@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 AAA-Server-Cert allows more than one node to be the target of a DSA, which is needed for various redundancy and PKI naming schemes. This is quite clear from the spec already, so I would propose rejecting this issue. PatC From owner-aaa-wg@merit.edu Mon Sep 24 09:01: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 JAA01288 for ; Mon, 24 Sep 2001 09:01:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A0F79120D; Mon, 24 Sep 2001 06:29:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D813E9120E; Mon, 24 Sep 2001 06:29: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 9D17B9120D for ; Mon, 24 Sep 2001 06:29:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7197B5DD9F; Mon, 24 Sep 2001 06:29:24 -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 AF26D5DD91 for ; Mon, 24 Sep 2001 06:29:23 -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 f8OASlK17633 for ; Mon, 24 Sep 2001 12:28:48 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA10790; Mon, 24 Sep 2001 12:28:43 +0200 (MET DST) Message-ID: <3BAF0AF1.DDBE5ED3@rioja.ericsson.se> Date: Mon, 24 Sep 2001 12:29:05 +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: [AAA-WG]: [issue] CMS-protected AVPs outside a DSA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit 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. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Mon Sep 24 09:01: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 JAA01280 for ; Mon, 24 Sep 2001 09:01:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 36CF191213; Mon, 24 Sep 2001 08:30:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04D2591258; Mon, 24 Sep 2001 08:30: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 C1E8891213 for ; Mon, 24 Sep 2001 08:30:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F0915DD9F; Mon, 24 Sep 2001 08:30: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 ACA685DD91 for ; Mon, 24 Sep 2001 08:30:49 -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.10.1/WIREfire-1.3) with ESMTP id f8OCUDv16852 for ; Mon, 24 Sep 2001 14:30:14 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA20189; Mon, 24 Sep 2001 14:30:10 +0200 (MET DST) Message-ID: <3BAF2769.5AF38EA0@rioja.ericsson.se> Date: Mon, 24 Sep 2001 14:30:33 +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 167: CMS-Cert in AVP Occurence Table References: <20010924044055.D13756@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, > > THere are cases where a certificate could be omitted from a DSAR (e.g. > if two nodes frequently setup DSAs and are under the same > jurisdiction). This issue now mandates that the DSA-Request includes > this AVP Really? My original proposal was changing the current row (which is the following): +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | DSAR| DSAA| PDSR| PDSA| ------------------------------|-----+-----+-----+-----+ CMS-Cert | 0 | 0 | 0 | 0 | with this one CMS-Cert | 0-1 | 0 | 0 | 0 | After some discussion, it was described that, if a certificate was always needed in the DSAR, the row must be: CMS-Cert | 1 | 0 | 0 | 0 | But, once Stephen and you has made a decision ("There are cases where a certificate could be omitted from a DSAR"), my original proposal must be included (that is, the issue must not be rejected, but taken in its original way). 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 Mon Sep 24 09: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 JAA04738 for ; Mon, 24 Sep 2001 09:14:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 62C0391207; Mon, 24 Sep 2001 05:23:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CA7291208; Mon, 24 Sep 2001 05:23: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 E1B8291207 for ; Mon, 24 Sep 2001 05:23:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B0E0B5DDB0; Mon, 24 Sep 2001 05:23:11 -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 AE4AD5DDA0 for ; Mon, 24 Sep 2001 05:23:10 -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.10.1/WIREfire-1.3) with ESMTP id f8O9MRv14103 for ; Mon, 24 Sep 2001 11:22:28 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA05720; Mon, 24 Sep 2001 11:22:25 +0200 (MET DST) Message-ID: <3BAEFB66.BDAA1C48@rioja.ericsson.se> Date: Mon, 24 Sep 2001 11:22:46 +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: [AAA-WG]: [issue] CMS-Data AVPs in base protocol Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-09-24 Reference: Document: Base Comment type: T Priority: S Section: 9.5, 9.7.1 Rationale/Explanation of issue: In base specification 9.5 it's quoted the term CMS-Data AVP: In all accounting records the Session-Id and User-Name AVPs MUST be present. If end-to-end authentication is required, as described in [11], the CMS-Data AVP may be used to authenticate the Accounting Data and Service Specific AVPs. It is not typically necessary, nor recommended, that the end-to-end authentication cover any additional AVPs since the Data and Service Specific AVP, and associated CMS-Data, MAY need to be submitted to a third party. Also in 9.7.1: When the Accounting-Request is being submitted to a third party (e.g. settlement service), and includes the CMS-Data AVP [11], the CMS-Data AVP MUST be signed by both the local and home Diameter server using the countersignature procedures described in [11]. However, this CMS-Data AVP doesn't actually exist. Requested change: Changing that term in both paragraphs. In the first paragraph, CMS-Data should be changed by CMS-Signed-Data since it's authentication the security service involved. However, in the last sentence, the phrase "It is [...] not recommended that the end-to-end authentication cover any additional AVPs..." looks wrong. As stated in the discussion of issue 150, too much digital signature doesn't harm and there's no problem if the signature covers other AVPs. The result could be something like the following: In all accounting records the Session-Id and User-Name AVPs MUST be present. If end-to-end authentication 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, although nor harmful, that the digital signature carried by the CMS-Signed-Data AVP covers any additional AVPs, even if the since the Data and Service Specific AVP, and associated CMS-Signed-Data, MAY need to be submitted to a third party. In the second one, it also looks like CMS-Signed-Data is the right option. When the Accounting-Request is being submitted to a third party (e.g. settlement service), and includes the CMS-Signed-Data AVP [11], the CMS-Signed-Data AVP MUST be include digital signatures by both the local and home Diameter server using the countersignature procedures described in [11]. 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 Retama 1, 4th. 28045 Madrid - SPAIN - From owner-aaa-wg@merit.edu Mon Sep 24 09:14: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 JAA04758 for ; Mon, 24 Sep 2001 09:14:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 646CC91208; Mon, 24 Sep 2001 05:47:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC0459120D; Mon, 24 Sep 2001 05:47: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 3753491208 for ; Mon, 24 Sep 2001 05:47:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 090235DD99; Mon, 24 Sep 2001 05:47:28 -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 182895DD97 for ; Mon, 24 Sep 2001 05:47:27 -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 f8O9kpK02240 for ; Mon, 24 Sep 2001 11:46:51 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA07559; Mon, 24 Sep 2001 11:46:48 +0200 (MET DST) Message-ID: <3BAF011E.A37CDF84@rioja.ericsson.se> Date: Mon, 24 Sep 2001 11:47:10 +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] CMS-Data AVPs in base protocol References: <3BAEFB66.BDAA1C48@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 Problems with the cut&paste Miguel Ángel Monjas Llorente wrote: > > Submitter name: Miguel A. Monjas > Submitter email address: ecemaml@rioja.es.eu.ericsson.se > Date first submitted: 2001-09-24 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 9.5, 9.7.1 > Rationale/Explanation of issue: > > Requested change: > The result could be something like the following: > > In all accounting records the Session-Id and User-Name AVPs MUST > be present. If end-to-end authentication 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, although nor harmful, that the digital signature carried > by the CMS-Signed-Data AVP covers any additional AVPs, even if the > the Data and Service Specific AVP, and associated ^^^^^ "since" dropped > CMS-Signed-Data, MAY need to be submitted to a third party. 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 Mon Sep 24 09:15: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 JAA04877 for ; Mon, 24 Sep 2001 09:15:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DE8791212; Mon, 24 Sep 2001 07:27:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5D5E9124B; Mon, 24 Sep 2001 07: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 AB4F891212 for ; Mon, 24 Sep 2001 07:26:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B20A5DD9F; Mon, 24 Sep 2001 07:26: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 F0B475DD91 for ; Mon, 24 Sep 2001 07:26:58 -0400 (EDT) Received: (qmail 13894 invoked by uid 500); 24 Sep 2001 11:12:32 -0000 Date: Mon, 24 Sep 2001 04:12:32 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: passive access device in CMS case Message-ID: <20010924041232.B13756@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, My co-author and I have recently been chatting about the progression of CMS (or lack thereof :(, and had a concern about one of the recent examples that was added to the CMS draft: "- The access device may have the cryptographic ability to perform CMS functions locally, but does not request a DSAR to request a DSA. The local agent, however, has been configured to establish DSAs with certain realms automatically, hiding the existence of the DSAs from the access device." His concern is simply that the above scenario requires no additional signaling, and in such cases the proxy is no different from an access device. So he would prefer to see this example removed. Comments, PatC From owner-aaa-wg@merit.edu Mon Sep 24 09:57: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 JAA01282 for ; Mon, 24 Sep 2001 09:01:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB9179124B; Mon, 24 Sep 2001 07:55:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD6E59124E; Mon, 24 Sep 2001 07:55: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 A557E9124B for ; Mon, 24 Sep 2001 07:55:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85AA75DD97; Mon, 24 Sep 2001 07:55: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 46ED35DD91 for ; Mon, 24 Sep 2001 07:55:21 -0400 (EDT) Received: (qmail 14009 invoked by uid 500); 24 Sep 2001 11:40:55 -0000 Date: Mon, 24 Sep 2001 04:40:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 167: CMS-Cert in AVP Occurence Table Message-ID: <20010924044055.D13756@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, THere are cases where a certificate could be omitted from a DSAR (e.g. if two nodes frequently setup DSAs and are under the same jurisdiction). This issue now mandates that the DSA-Request includes this AVP, and Stephen and I believe this should be rejected. PatC From owner-aaa-wg@merit.edu Mon Sep 24 09:57: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 JAA01275 for ; Mon, 24 Sep 2001 09:01:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD90291258; Mon, 24 Sep 2001 08:50:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B37469126C; Mon, 24 Sep 2001 08: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 9F2CD91258 for ; Mon, 24 Sep 2001 08:50:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CB025DDA0; Mon, 24 Sep 2001 08:50:21 -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 A53FA5DD91 for ; Mon, 24 Sep 2001 08:50:20 -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.10.1/WIREfire-1.3) with ESMTP id f8OCnCv05040; Mon, 24 Sep 2001 14:49:24 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA21582; Mon, 24 Sep 2001 14:48:23 +0200 (MET DST) Message-ID: <3BAF2BA7.8D661900@rioja.ericsson.se> Date: Mon, 24 Sep 2001 14:48:39 +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 Cc: Pat Calhoun Subject: Re: [AAA-WG]: passive access device in CMS case References: <20010924041232.B13756@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, > > My co-author and I have recently been chatting about the progression > of CMS (or lack thereof :(, I'm sorry that you think there's no progression of CMS. IMHO a great task of clarification and improvement was being made so that I regret you both don't think the same... > and had a concern about one of the recent > examples that was added to the CMS draft: > > "- The access device may have the cryptographic ability to perform > CMS functions locally, but does not request a DSAR to request a DSA. > The local agent, however, has been configured to establish DSAs with > certain realms automatically, hiding the existence of the DSAs from > the access device." > > His concern is simply that the above scenario requires no additional > signaling, and in such cases the proxy is no different from an access > device. > > So he would prefer to see this example removed. Well, I'm the proponent of such an scenario and I'd like to explain the reason I had to suggest it: although it doesn't require any additional signalling it is a very likely scenario. Maybe you may think that this is only an specification of a Diameter application, so that only syntax must be described and that anything that isn't forbidden is allowed, but I think that some kind of guidance doesn't harm anyone. But it's up to you deciding what must be inside the specification. However, and according to Stephen's comments, maybe the scenario could be changed: - The local agent has been configured to establish DSAs with certain realms automatically, hiding the existence of the DSAs from the access device. This scenario requires no additional signaling, and in such cases the proxy is no different from an access device. 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 Mon Sep 24 10:38: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 KAA14182 for ; Mon, 24 Sep 2001 10:38:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEB619120C; Mon, 24 Sep 2001 10:38:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACAD59127A; Mon, 24 Sep 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 901639120C for ; Mon, 24 Sep 2001 10:38:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 66BFC5DDA9; Mon, 24 Sep 2001 10:38:31 -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 860565DDA3 for ; Mon, 24 Sep 2001 10:38:30 -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.10.1/WIREfire-1.3) with ESMTP id f8OEalv08064; Mon, 24 Sep 2001 16:36:48 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA29976; Mon, 24 Sep 2001 16:36:43 +0200 (MET DST) Message-ID: <3BAF4512.DE765D3C@rioja.ericsson.se> Date: Mon, 24 Sep 2001 16:37:06 +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 Cc: Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs References: <20010924045402.F13756@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, > > The AAA-Server-Cert allows more than one node to be the target of > a DSA, which is needed for various redundancy and PKI naming schemes. > This is quite clear from the spec already, so I would propose rejecting > this issue. Well, what is quite clear is the alleged necessity of this AVP. What isn't so clear is the implications of this fact. First of all, the DSAs aren't actually established between two nodes but between a node and a realm. This fact will make more complex a Diameter server: - The DSA destination node will have to forward the certificate of the originator to the AAA server that would process subsequent requests (or maybe this secondary AAA server would have to fetch the certificate of the originator once it receives a request from it; or maybe the originator has to include its certificate in all its messages when they include a digital signature). - When encrypting AVPs, the originator node will have to maintain a register of the actual AAA server with which it is communicating, since it has to choose a specific certificate (or maybe include all the possible receivers in the ReceiptInfo values). According to the draft, all the AAA servers may have the same key ("For multiple Diameter servers within a realm that share a public key" in section 3.2), but that's only a possibility. BTW, if there's an only AAA server in the realm, its certificate should be the one included in a CMS-Cert AVP, so that the following row in section 8.0 is wrong: AAA-Server-Certs | 0 | 1+ | 0 | 0 | And should be replaced by AAA-Server-Certs | 0 | 0+ | 0 | 0 | // 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 Mon Sep 24 10:39: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 KAA14324 for ; Mon, 24 Sep 2001 10:39:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBB8A9127A; Mon, 24 Sep 2001 10:40:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 897E89127D; Mon, 24 Sep 2001 10:40: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 773FD9127A for ; Mon, 24 Sep 2001 10:40:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EB5A5DDA3; Mon, 24 Sep 2001 10:40:25 -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 991BA5DD91 for ; Mon, 24 Sep 2001 10:40:24 -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.10.1/WIREfire-1.3) with ESMTP id f8OEdmv10088 for ; Mon, 24 Sep 2001 16:39:48 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA00218; Mon, 24 Sep 2001 16:39:45 +0200 (MET DST) Message-ID: <3BAF45C9.3E08CCA@rioja.ericsson.se> Date: Mon, 24 Sep 2001 16:40:09 +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] CMS-protected AVPs outside a DSA References: <3BAF0AF1.DDBE5ED3@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: > > 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: > 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) BTW, if it's allowed to include additional "out-of-DSA" signatures, it will supposed that an appropriate digital signature must be include and that (it the destination node supports validation checks) the certificate must be validated (since no TTL is available). // 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 Mon Sep 24 10:41: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 KAA14460 for ; Mon, 24 Sep 2001 10:41:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7809591281; Mon, 24 Sep 2001 10:41:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51F4D9127D; Mon, 24 Sep 2001 10:41: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 F347291281 for ; Mon, 24 Sep 2001 10:41:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEE8E5DDA3; Mon, 24 Sep 2001 10:41: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 8AACB5DD91 for ; Mon, 24 Sep 2001 10:41:37 -0400 (EDT) Received: (qmail 15059 invoked by uid 500); 24 Sep 2001 14:27:10 -0000 Date: Mon, 24 Sep 2001 07:27:10 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: passive access device in CMS case Message-ID: <20010924072710.A15045@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu, Pat Calhoun References: <20010924041232.B13756@charizard.diameter.org> <3BAF2BA7.8D661900@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BAF2BA7.8D661900@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 24, 2001 at 02:48:39PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Sep 24, 2001 at 02:48:39PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > All, > > > > My co-author and I have recently been chatting about the progression > > of CMS (or lack thereof :(, > > I'm sorry that you think there's no progression of CMS. IMHO a great > task of clarification and improvement was being made so that I regret > you both don't think the same... Sorry... I should have qualified the progression of getting a spec out, not the increase in quality :( > > > and had a concern about one of the recent > > examples that was added to the CMS draft: > > > > "- The access device may have the cryptographic ability to perform > > CMS functions locally, but does not request a DSAR to request a DSA. > > The local agent, however, has been configured to establish DSAs with > > certain realms automatically, hiding the existence of the DSAs from > > the access device." > > > > His concern is simply that the above scenario requires no additional > > signaling, and in such cases the proxy is no different from an access > > device. > > > > So he would prefer to see this example removed. > > Well, I'm the proponent of such an scenario and I'd like to explain > the reason I had to suggest it: although it doesn't require any > additional signalling it is a very likely scenario. Maybe you may > think that this is only an specification of a Diameter application, so > that only syntax must be described and that anything that isn't > forbidden is allowed, but I think that some kind of guidance doesn't > harm anyone. But it's up to you deciding what must be inside the > specification. > > However, and according to Stephen's comments, maybe the scenario could > be changed: > > - The local agent has been configured to establish DSAs with > certain realms automatically, hiding the existence of the DSAs from > the access device. This scenario requires no additional signaling, > and in such cases the proxy is no different from an access device. Stephen? PatC From owner-aaa-wg@merit.edu Mon Sep 24 10:42: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 KAA14653 for ; Mon, 24 Sep 2001 10:42:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF4459127D; Mon, 24 Sep 2001 10:42:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8728991283; Mon, 24 Sep 2001 10:42: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 7B0739127D for ; Mon, 24 Sep 2001 10:42:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E7335DDA3; Mon, 24 Sep 2001 10:42: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 0B9D75DD91 for ; Mon, 24 Sep 2001 10:42:52 -0400 (EDT) Received: (qmail 15075 invoked by uid 500); 24 Sep 2001 14:28:25 -0000 Date: Mon, 24 Sep 2001 07:28:25 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 167: CMS-Cert in AVP Occurence Table Message-ID: <20010924072825.B15045@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010924044055.D13756@charizard.diameter.org> <3BAF2769.5AF38EA0@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BAF2769.5AF38EA0@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 24, 2001 at 02:30:33PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Sep 24, 2001 at 02:30:33PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > All, > > > > THere are cases where a certificate could be omitted from a DSAR (e.g. > > if two nodes frequently setup DSAs and are under the same > > jurisdiction). This issue now mandates that the DSA-Request includes > > this AVP > > Really? > > My original proposal was changing the current row (which is the > following): > > +-----------------------+ > | Command-Code | > |-----+-----+-----+-----+ > Attribute Name | DSAR| DSAA| PDSR| PDSA| > ------------------------------|-----+-----+-----+-----+ > CMS-Cert | 0 | 0 | 0 | 0 | > > with this one > > CMS-Cert | 0-1 | 0 | 0 | 0 | yes, this one is fine. > > After some discussion, it was described that, if a certificate was > always needed in the DSAR, the row must be: > > CMS-Cert | 1 | 0 | 0 | 0 | This one is a problem > > But, once Stephen and you has made a decision ("There are cases where > a certificate could be omitted from a DSAR"), my original proposal > must be included (that is, the issue must not be rejected, but taken > in its original way). correct... thanks for the recap. I think we lost the original proposal. PatC From owner-aaa-wg@merit.edu Mon Sep 24 10:53: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 KAA15557 for ; Mon, 24 Sep 2001 10:53:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCB5391283; Mon, 24 Sep 2001 10:53:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9845E91285; Mon, 24 Sep 2001 10:53: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 822BF91283 for ; Mon, 24 Sep 2001 10:53:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 574295DDA9; Mon, 24 Sep 2001 10:53: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 A2EC45DD91 for ; Mon, 24 Sep 2001 10:53:36 -0400 (EDT) Received: (qmail 15388 invoked by uid 500); 24 Sep 2001 14:39:09 -0000 Date: Mon, 24 Sep 2001 07:39:09 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu, Pat Calhoun Subject: Re: [AAA-WG]: Issue 180: AAA-Server-Certs Message-ID: <20010924073909.C15045@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu, Pat Calhoun References: <20010924045402.F13756@charizard.diameter.org> <3BAF4512.DE765D3C@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BAF4512.DE765D3C@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 24, 2001 at 04:37:06PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Sep 24, 2001 at 04:37:06PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > All, > > > > The AAA-Server-Cert allows more than one node to be the target of > > a DSA, which is needed for various redundancy and PKI naming schemes. > > This is quite clear from the spec already, so I would propose rejecting > > this issue. > > Well, what is quite clear is the alleged necessity of this AVP. What > isn't so clear is the implications of this fact. ok > > First of all, the DSAs aren't actually established between two nodes > but between a node and a realm. This fact will make more complex a > Diameter server: > > - The DSA destination node will have to forward the certificate of the > originator to the AAA server that would process subsequent requests > (or maybe this secondary AAA server would have to fetch the > certificate of the originator once it receives a request from it; or > maybe the originator has to include its certificate in all its > messages when they include a digital signature). correct. The server in the dest realm can return the certs of all AAA servers in its network. > - When encrypting AVPs, the originator node will have to maintain a > register of the actual AAA server with which it is communicating, > since it has to choose a specific certificate (or maybe include all > the possible receivers in the ReceiptInfo values). According to the > draft, all the AAA servers may have the same key ("For multiple > Diameter servers within a realm that share a public key" in section > 3.2), but that's only a possibility. sure, but it can maintain a cache of all servers, with the associated cert. > BTW, if there's an only AAA server in the realm, its certificate > should be the one included in a CMS-Cert AVP, so that the following > row in section 8.0 is wrong: no, my understanding is that it would be in the AAA-Server-Cert. > AAA-Server-Certs | 0 | 1+ | 0 | 0 | > > And should be replaced by > > AAA-Server-Certs | 0 | 0+ | 0 | 0 | Stephen? PatC From owner-aaa-wg@merit.edu Mon Sep 24 12:33: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 MAA22234 for ; Mon, 24 Sep 2001 12:33:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1504391296; Mon, 24 Sep 2001 12:33:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6C6691297; Mon, 24 Sep 2001 12:33: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 A83FF91296 for ; Mon, 24 Sep 2001 12:33:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8DBDF5DD9F; Mon, 24 Sep 2001 12:33:57 -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 639AA5DD91 for ; Mon, 24 Sep 2001 12:33:56 -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.10.1/WIREfire-1.3) with ESMTP id f8OGXJv05043; Mon, 24 Sep 2001 18:33:19 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA08192; Mon, 24 Sep 2001 18:33:15 +0200 (MET DST) Message-ID: <3BAF6064.6B0AE52B@rioja.ericsson.se> Date: Mon, 24 Sep 2001 18:33:40 +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 180: AAA-Server-Certs References: <20010924045402.F13756@charizard.diameter.org> <3BAF4512.DE765D3C@rioja.ericsson.se> <20010924073909.C15045@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 DSA destination node will have to forward the certificate of the > > originator to the AAA server that would process subsequent requests > > (or maybe this secondary AAA server would have to fetch the > > certificate of the originator once it receives a request from it; or > > maybe the originator has to include its certificate in all its > > messages when they include a digital signature). > > correct. The server in the dest realm can return the certs of all AAA servers > in its network. Well, I'm not actually talking about the destination server sending the certificates of the AAA servers (using the AAA-Server-Certs AVP) but about the way in which the destination node of the DSA forwards the certificate of the originator. As far as I understand, a DSA is established with one of the AAA servers of the destination realm. This server includes its certificate (and the certificates of the rest of AAA servers in the realm) in a AAA-Server-Certs AVP. As the DSAR coming from the DSA originator may include its certificate, this one would be available only for the destination node of the DSA (but not for the rest of AAA servers of the realm). Unless this certificate is available for such servers, the DSA originator will always have to include its certificate any Diameter message that contains a digital signature. Otherwise, the protocol itself will have to specify that the actual destination node of the DSA must "publish" this certificate in a repository or forward this certificate to the rest of AAA servers of the realm (acording to the specification itself, it's not allowed to push certificates without establishing a DSA). Besides, the destination node has to forward also the agreed TTL to inform the rest of AAA servers about when they would have to re-validate the certificates, hasn't it? (as well as the information regarding the AVPs that must be signed or encrypted). Some kind of proxy? Unless I'm missing anything, I reckon that the way in which AAA-Server-Cerst is intended to work is a little bit difficult to implement. I'd like some clarification about this point. > > - When encrypting AVPs, the originator node will have to maintain a > > register of the actual AAA server with which it is communicating, > > since it has to choose a specific certificate (or maybe include all > > the possible receivers in the ReceiptInfo values). According to the > > draft, all the AAA servers may have the same key ("For multiple > > Diameter servers within a realm that share a public key" in section > > 3.2), but that's only a possibility. > > sure, but it can maintain a cache of all servers, with the associated > cert. Yes, of course, but as determinating with which AAA server it is actually communicating can be a hard task, it will always encrypt the CEK of a CMS-Encrypted-Data APV for ALL the AAA servers of the realm (whose certs it's got, of course) > > BTW, if there's an only AAA server in the realm, its certificate > > should be the one included in a CMS-Cert AVP, so that the following > > row in section 8.0 is wrong: > > no, my understanding is that it would be in the AAA-Server-Cert. OK. I've checked it again and you're right. My fault... 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 Mon Sep 24 13:21: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 NAA24719 for ; Mon, 24 Sep 2001 13:21:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EBD49129E; Mon, 24 Sep 2001 13:21:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 447C0912A0; Mon, 24 Sep 2001 13:21: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 2225E9129E for ; Mon, 24 Sep 2001 13:21:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EAC975DD93; Mon, 24 Sep 2001 13:21:39 -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 8AD215DD91 for ; Mon, 24 Sep 2001 13:21:38 -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.10.1/WIREfire-1.3) with ESMTP id f8OHL0v15405; Mon, 24 Sep 2001 19:21:01 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA10804; Mon, 24 Sep 2001 19:20:55 +0200 (MET DST) Message-ID: <3BAF6B90.59835F0E@rioja.ericsson.se> Date: Mon, 24 Sep 2001 19:21:20 +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 167: CMS-Cert in AVP Occurence Table References: <20010924044055.D13756@charizard.diameter.org> <3BAF2769.5AF38EA0@rioja.ericsson.se> <20010924072825.B15045@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: > > > CMS-Cert | 0-1 | 0 | 0 | 0 | > > yes, this one is fine. Sorry, but now I'm not certain of this suggestion. In one of the answers to issue 180, you've said (when I was suggesting that it may happen that AAA-Server-Certs wouldn't be present in a DSAA) that you thought that AAA-Server-Certs would include the certificate of the AAA server signing the DSAA, so that no CMS-Cert is needed here. Which is the right answer to this problem? 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 Mon Sep 24 18:02: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 SAA02265 for ; Mon, 24 Sep 2001 18:02:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A93891282; Mon, 24 Sep 2001 18:02:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4618912B5; Mon, 24 Sep 2001 18:02: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 88FD691282 for ; Mon, 24 Sep 2001 18:02:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EB5D5DDA5; Mon, 24 Sep 2001 18:02:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (adsl-64-217-217-113.dsl.rcsntx.swbell.net [64.217.217.113]) by segue.merit.edu (Postfix) with SMTP id 307535DDA3 for ; Mon, 24 Sep 2001 18:02:20 -0400 (EDT) Received: (qmail 17331 invoked by uid 500); 24 Sep 2001 22:14:39 -0000 Date: Mon, 24 Sep 2001 17:14:39 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Section 5.6.3 Message-ID: <20010924171439.Y13945@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 Is there a difference between the actions Reject and Disc? -Dave From owner-aaa-wg@merit.edu Mon Sep 24 18:23: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 SAA02502 for ; Mon, 24 Sep 2001 18:23:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18984912B6; Mon, 24 Sep 2001 18:23:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0406912B7; Mon, 24 Sep 2001 18:23: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 ECEB4912B6 for ; Mon, 24 Sep 2001 18:23:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 764D55DDA5; Mon, 24 Sep 2001 18:23:27 -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 D58A85DDAC for ; Mon, 24 Sep 2001 18:23:25 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA18006 for ; Mon, 24 Sep 2001 15:22:49 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA25894 for ; Mon, 24 Sep 2001 15:22:49 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 24 Sep 2001 17:22:49 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ED01E@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'David Frascone'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Section 5.6.3 Date: Mon, 24 Sep 2001 17:22:48 -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 My understanding is that Reject is only used on incoming connections after checking the CER. However, it seems that in practice the implementations of both actions would be identical/very similar. It's probable that you might not yet be keeping state when you Reject a connection, though (so there would be less resource-freeing involved). -Brian > -----Original Message----- > From: David Frascone [mailto:dave@frascone.com] > Sent: Monday, September 24, 2001 5:15 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Section 5.6.3 > > > Is there a difference between the actions Reject and Disc? > > > -Dave From owner-aaa-wg@merit.edu Mon Sep 24 20:02: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 UAA04006 for ; Mon, 24 Sep 2001 20:02:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46D34912C2; Mon, 24 Sep 2001 20:03:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 144D0912C3; Mon, 24 Sep 2001 20:03: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 DE25D912C2 for ; Mon, 24 Sep 2001 20:03:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C13305DDAA; Mon, 24 Sep 2001 20:03:02 -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 3DB425DDA3 for ; Mon, 24 Sep 2001 20:03:02 -0400 (EDT) Received: (qmail 18437 invoked by uid 500); 24 Sep 2001 23:48:32 -0000 Date: Mon, 24 Sep 2001 16:48:32 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'David Frascone'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Section 5.6.3 Message-ID: <20010924164832.A18419@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'David Frascone' , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ED01E@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ED01E@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Mon, Sep 24, 2001 at 05:22:48PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Also, it provides you with additional logging information, since the reason for a reject is different from a simple disc. PatC On Mon, Sep 24, 2001 at 05:22:48PM -0500, Cain Brian-BCAIN1 wrote: > My understanding is that Reject is only used on incoming connections after checking the CER. However, it seems that in practice the implementations of both actions would be identical/very similar. It's probable that you might not yet be keeping state when you Reject a connection, though (so there would be less resource-freeing involved). > > -Brian > > > -----Original Message----- > > From: David Frascone [mailto:dave@frascone.com] > > Sent: Monday, September 24, 2001 5:15 PM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Section 5.6.3 > > > > > > Is there a difference between the actions Reject and Disc? > > > > > > -Dave From owner-aaa-wg@merit.edu Mon Sep 24 20:15: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 UAA04128 for ; Mon, 24 Sep 2001 20:15:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0ABBE912C7; Mon, 24 Sep 2001 20:15:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA449912D8; Mon, 24 Sep 2001 20:15: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 882EC912C7 for ; Mon, 24 Sep 2001 20:15:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65ADB5DDAA; Mon, 24 Sep 2001 20:15:30 -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 C3AC85DDA3 for ; Mon, 24 Sep 2001 20:15:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA23238 for ; Mon, 24 Sep 2001 17:06:58 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 24 Sep 2001 17:06:58 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed resolution of issue #173 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id UAA04128 This issue related to differences in the failover algorithm between diameter-07 and transport-04. The proposed solution is to include failover text in only one place, the transport draft. Diameter base will reference that text. Of course, there is then the issue of what the text should be. A proposal for the next text of section 3.2 of transport -05 is included below. This proposal contains a single timer, Tw. Please send comments to the list. ------------------------------------------------------------------ 3.2 Application layer watchdog In order to enable AAA implementations to more quickly detect transport and application-layer failures, AAA proto­ cols MUST support an application layer watchdog message. The application layer watchdog message enables failover from a server that has failed either because it is unreachable or because its applications functions have failed. This is dis­ tinct from the purpose of the SCTP heartbeat, which is to enable failover between interfaces. The SCTP heartbeat may enable a failover to another path to reach the same server, but does not adress the situation where the server system or the application service has failed. Therefore both mecha­ nisms MAY be used together. The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection. It operates on all open connections and is used to suspend and eventually close connections that are experiencing difficul­ ties. The watchdog is also used to re-open and validate con­ nections that have returned to health. The watchdog may be utilized either within primary/secondary or load balancing configurations. However, it is not intended as a cluster heartbeat mechanism comparable to that proposed in [31]. 3.2.1. Algorithm overview The watchdog behavior is controlled by an algorithm defined in this section. Implementations SHOULD implement this algorithm, which operates as follows: [1] Watchdog behavior is controlled by a single timer (Tw). The default value of Tw is 30 seconds. This value was selected because it minimizes the probability that failover will be initiated due to a routing flap, as noted in [Paxson]. While Tw MAY be set as low as 6 seconds (not including jitter), it MUST NOT set lower than this. Note that setting such a low value of the watchdog timer is likely to result in an increased probability of duplicates, as well as an increase in spurious failover and failback attempts. In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, each time the watchdog interval is calculated with a jitter by using the Tw value and randomly adding a value drawn between -2 and 2 seconds. Alternative calculations to create jitter MAY be used. These MUST be pseudo-random and not cyclic. [2] When a response is received, Tw is reset. Receiving a watchdog from a peer constitutes activity, and Tw should be reset. On sending a message, if the send queue is empty, then Tw is reset. If the watchdog timer expires and the send queue is empty, then a watchdog packet is sent. Watchdog packets are not retransmitted by the AAA protocol, since AAA protocols run over reli­ able transports that will handle all retransmissions internally. If the watchdog timer expires and the send queue is not empty, then failover is initiated. The AAA client MAY resend the request to an alternate server, reusing the end-to-end identifier so as to permit duplicate detec­ tion. However, the client MUST NOT close the primary connection until the primary's watchdog timer has expired twice without a response (note that the watch­ dog is not sent a second time, however). Once the pri­ mary connection has failed, subsequent requests are sent to the alternate server until the watchdog timer on the primary connection is reset. Suspension of the primary connection prevents flapping between primary and alternate connections, and ensures that failover behavior remains consistent. The appli­ cation may not receive a response to the watchdog mes­ sage due to a connectivity problem, in which case a transport layer ACK will not have been received, or the lack of response may be due to an application problem. Without transport layer visibility, the application is unable to tell the difference, and must behave conser­ vatively. In situations where no transport layer ACK is received on the primary connection after multiple re-transmis­ sions, the RTO will be exponentially backed off. Due to Karn's algorithm as implemented SCTP and TCP, the RTO estimator will not be reset until another ACK is received in response to a non-re-transmitted request. Thus, in cases where the problem occurs at the trans­ port layer, after the client fails over to the alter­ nate server, the RTO of the primary will remain at a high value unless an ACK is received on the primary connection. In the case where the problem occurs at the transport layer, subsequent requests sent on the primary connec­ tion will not receive the same service as was origi­ nally provided. For example, instead of failover occur­ ing after 3 retransmissions, failover might occur with­ out even a single retransmission if RTO has been suffi­ ciently backed off. Of course, if the lack of a watch­ dog response was due to an application layer problem, then RTO will not have been backed off. However, with­ out transport layer visibility, there is no way for the application to know this. Suspending use of the primary connection until a response is received to a watchdog message guarantees that the RTO timer will have been reset before the pri­ mary connection is reused. If no response is received after the second Tw expiration, then the primary con­ nection is closed and so the suspension becomes perma­ nent. [3] After the the expiration of two watchdog timers without a response, the AAA client SHOULD cause a transport reset or close to be done on the connection. While the connection is in the closed state, the AAA client MUST NOT attempt to send further watchdog messages on the connection. However, after the connection is closed, the AAA client continues to periodically attempt to re- open the connection. The AAA client SHOULD wait for the transport layer to report connection failure before attempting again, but MAY choose to bound this wait time by the watchdog interval, Tw. If the connection is successfully opened, then the watchdog message is sent. Once three watchdog messages have been sent and responded to, the connection is returned to service, and transactions are once again sent over it. Connec­ tion validation via receipt of multiple watchdogs is not required when a connection is initially brought up -- in this case, the connection can immediately be put into service. When using SCTP as a transport, it is not necessary to disable SCTP's transport-layer heartbeats. However If AAA implementations have access to SCTP's heartbeat parameters, they MAY chose to ensure that SCTP's heart­ beat interval is longer than the AAA protocol's watch­ dog interval, Tw. This will ensure both that alternate paths are still probed by SCTP, while the primary path has a minumum of heartbeat redundancy. In the event that a transport failure is detected with a peer, it is necessary for all pending request messages to be forwarded to an alternate agent, if possible. This is com­ monly referred to as failover. In order for a AAA client or agent to perform failover pro­ cedures, it is necessary to maintain a pending message queue for a given peer. When an answer message is received, the corresponding request is removed from the queue. The Hop-by- Hop Identifier field MAY be used to match the answer with the queued request. When a transport failure is detected, all messages in the queue are sent to an alternate agent, if possible. Multiple identical requests or answers MAY be received as a result of a failover. The combination of an end-to-end identifier and the origin host MUST be used to identify duplicate messages. 3.2.2. Detailed algorithm description In this section, we will refer to a memory control structure that contains all information regarding a specific peer as a Peer Control Block, or PCB. For the purposes of illustrating the algorithm, each PCB contains the following fields: Status - This field represents the level of confidence in the algorithm. The following values are defined: OKAY: The connection is up SUSPECT: Failover has been initiated on the connection. DOWN: Connection has been closed. REOPEN: Attempting to reopen a connection Pending - This boolean field is set to TRUE when there are no outstanding unanswered requests. T is the watchdog timer, measured in seconds. Every second, T is decremented. When it reaches 0, the OnTimerElapsed event (see below) is invoked. Pseudo-code for the algorithm is as follows: /* Here is the Failover state machine: States: OKAY: The connection is up SUSPECT: Failover has been initiated on the connection. DOWN: Connection has been closed. REOPEN: Attempting to reopen a closed connection Pending: Set to TRUE if there are outstanding unanswered requests T: Watchdog timer value STATE Event New State Actions ===== ===== ========= ======= OKAY Send & OKAY SetWatchDog() !Pending OKAY Send & Pending OKAY SUSPECT Send ERROR Error() DOWN Send ERROR Error() OKAY Receive OKAY SetWatchDog() SUSPECT Receive OKAY Failback() SetWatchDog() DOWN Receive DOWN Throwaway() OKAY Timer expires & OKAY SendWatchdog() !Pending OKAY Timer expires & SUSPECT FailOver() Pending SetWatchdog() SUSPECT Timer expires DOWN Close Connection SetWatchdog() DOWN Timer expires REOPEN AttemptOpen() SetWatchdog() REOPEN Timer expires REOPEN SetWatchdog() REOPEN Connection up SUSPECT SendWatchdog() OKAY Connection down DOWN SetWatchdog() SUSPECT Connection down DOWN SetWatchdog() REOPEN Connection down DOWN SetWatchdog() DOWN Connection down ERROR Error() */ /* SetWatchdog() is called in order to set the Watchdog timer, measured in seconds. The default value of TWINIT is 30 seconds. A random value between -2 and 2 seconds is added to the timer to provide jitter. */ SetWatchdog() { return (TWINIT -2.0 + 4.0 * random()) ; } /* OnReceive() is called whenever a message is received from the peer. This message MAY be a request or an answer, and can include DWR and DWA messages. */ OnReceive(pcb) { switch (pcb->Status){ case OKAY: T = SetWatchdog(); break; case SUSPECT: pcb->Status = OKAY; T = SetWatchdog(); Failback(); break; case REOPEN: pcb->Status = SUSPECT; T = SetWatchdog(); break; case DOWN: Throwaway(received packet); break; default: Error("Shouldn't be here!"); break; } } /* OnSendRequest() is called after a request is sent to the peer. [Issue: Should this be called whenever any message is sent to the peer?] */ OnSendRequest(pcb) { switch (pcb->Status){ case OKAY: if (!Pending) T = SetWatchdog(); break; default: error("Shouldn't be here!"); break; } } /* OnTimerElapsed() is called whenever T reaches zero (0). */ OnTimerElapsed(pcb) { switch (pcb->status){ case OKAY: if (!Pending) { SendWatchdog(pbc); break; } pcb->status = SUSPECT; FailOver(pcb); break ; case SUSPECT: pcb->status = DOWN; CloseConnection(pcb); OpenAttempt = FALSE; T = SetWatchdog(); break; case DOWN: if (!OpenAttempt) { OpenAttempt = TRUE; AttemptOpen(pcb); break; } break; default: error("Shouldn't be here!); break; } } /* OnConnectionUp() is called whenever a connection comes up */ OnConnectionUp(pcb) { switch (pcb->status){ case DOWN pcb->status = REOPEN; SendWatchdog(); break; default: error("Shouldn't be here!); break; } } /* OnConnectionDown() is called whenever a connection goes down */ OnConnectionDown(pcb) { switch (pcb->status){ case OK: pcb->status = DOWN; T=SetWatchdog(); break; case SUSPECT: pcb->status = DOWN; T=SetWatchdog(); break; case REOPEN: pcb->status = DOWN; T=SetWatchdog(); break; default: error("Shouldn't be here!); break; } } From owner-aaa-wg@merit.edu Mon Sep 24 20:33: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 UAA04334 for ; Mon, 24 Sep 2001 20:33:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3AF5912C8; Mon, 24 Sep 2001 20:33:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 752369128C; Mon, 24 Sep 2001 20:33: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 17211912C8 for ; Mon, 24 Sep 2001 20:33:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E55515DDAA; Mon, 24 Sep 2001 20:33: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 9F55F5DDA3 for ; Mon, 24 Sep 2001 20:33:09 -0400 (EDT) Received: (qmail 18790 invoked by uid 500); 25 Sep 2001 00:18:39 -0000 Date: Mon, 24 Sep 2001 17:18:39 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 167: CMS-Cert in AVP Occurence Table Message-ID: <20010924171839.D18419@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , Pat Calhoun , aaa-wg@merit.edu References: <20010924044055.D13756@charizard.diameter.org> <3BAF2769.5AF38EA0@rioja.ericsson.se> <20010924072825.B15045@charizard.diameter.org> <3BAF6B90.59835F0E@rioja.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <3BAF6B90.59835F0E@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Sep 24, 2001 at 07:21:20PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Sep 24, 2001 at 07:21:20PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > > CMS-Cert | 0-1 | 0 | 0 | 0 | > > > > yes, this one is fine. > > Sorry, but now I'm not certain of this suggestion. In one of the > answers to issue 180, you've said (when I was suggesting that it may > happen that AAA-Server-Certs wouldn't be present in a DSAA) that you > thought that AAA-Server-Certs would include the certificate of the AAA > server signing the DSAA, so that no CMS-Cert is needed here. Which is > the right answer to this problem? The AVP isn't required to send AAA server certs, but you may want to send other certs (e.g. top level CA cert). PatC From owner-aaa-wg@merit.edu Mon Sep 24 22:22: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 WAA06203 for ; Mon, 24 Sep 2001 22:22:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D810D91238; Mon, 24 Sep 2001 22:21:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95968912CF; Mon, 24 Sep 2001 22:21: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 D21DA91238 for ; Mon, 24 Sep 2001 22:21:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B67775DDAD; Mon, 24 Sep 2001 22:21:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (adsl-64-217-217-113.dsl.rcsntx.swbell.net [64.217.217.113]) by segue.merit.edu (Postfix) with SMTP id 16C855DDA3 for ; Mon, 24 Sep 2001 22:21:13 -0400 (EDT) Received: (qmail 17899 invoked by uid 500); 25 Sep 2001 02:33:34 -0000 Date: Mon, 24 Sep 2001 21:33:34 -0500 From: David Frascone To: Cain Brian-BCAIN1 , "'David Frascone'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Section 5.6.3 Message-ID: <20010924213334.A13945@newman.frascone.com> Mail-Followup-To: Cain Brian-BCAIN1 , 'David Frascone' , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ED01E@IL27EXM10.cig.mot.com> <20010924164832.A18419@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: <20010924164832.A18419@charizard.diameter.org>; from pcalhoun@diameter.org on Mon, Sep 24, 2001 at 04:48:32PM -0700 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Gotcha. Thanks. -Dave On Mon, Sep 24, 2001 at 04:48:32PM -0700, Pat Calhoun wrote: > Also, it provides you with additional logging information, since the reason for > a reject is different from a simple disc. > > PatC > > On Mon, Sep 24, 2001 at 05:22:48PM -0500, Cain Brian-BCAIN1 wrote: > > My understanding is that Reject is only used on incoming connections after checking the CER. However, it seems that in practice the implementations of both actions would be identical/very similar. It's probable that you might not yet be keeping state when you Reject a connection, though (so there would be less resource-freeing involved). > > > > -Brian > > > > > -----Original Message----- > > > From: David Frascone [mailto:dave@frascone.com] > > > Sent: Monday, September 24, 2001 5:15 PM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: Section 5.6.3 > > > > > > > > > Is there a difference between the actions Reject and Disc? > > > > > > > > > -Dave > From owner-aaa-wg@merit.edu Tue Sep 25 03:50: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 DAA25183 for ; Tue, 25 Sep 2001 03:50:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 197FF91209; Tue, 25 Sep 2001 03:50:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4F0591242; Tue, 25 Sep 2001 03:50: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 535E491209 for ; Tue, 25 Sep 2001 03:50:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2671B5DDC7; Tue, 25 Sep 2001 03:50:25 -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 1BA4A5DDC3 for ; Tue, 25 Sep 2001 03:50:24 -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 f8P7njK19555 for ; Tue, 25 Sep 2001 09:49:45 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA11542; Tue, 25 Sep 2001 09:49:42 +0200 (MET DST) Message-ID: <3BB03733.DE2AE877@rioja.ericsson.se> Date: Tue, 25 Sep 2001 09:50:11 +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 167: CMS-Cert in AVP Occurence Table References: <20010924044055.D13756@charizard.diameter.org> <3BAF2769.5AF38EA0@rioja.ericsson.se> <20010924072825.B15045@charizard.diameter.org> <3BAF6B90.59835F0E@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: > > Pat Calhoun wrote: > > > > > CMS-Cert | 0-1 | 0 | 0 | 0 | > > > > yes, this one is fine. > > Sorry, but now I'm not certain of this suggestion. In one of the > answers to issue 180, you've said (when I was suggesting that it may > happen that AAA-Server-Certs wouldn't be present in a DSAA) that you > thought that AAA-Server-Certs would include the certificate of the AAA > server signing the DSAA, so that no CMS-Cert is needed here. Which is > the right answer to this problem? Well, sometimes I'm not the most clever man.... I've rethinking the anwser above and is quite wrong. This issue was intended to fix an alleged error in DSA-R (not in DSA-A in which AAA-Server-Certs must be placed). Please drop this mail... Regards // M.A. From owner-aaa-wg@merit.edu Tue Sep 25 10:03: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 KAA04089 for ; Tue, 25 Sep 2001 10:03:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6603391244; Tue, 25 Sep 2001 10:03:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 238CC91246; Tue, 25 Sep 2001 10:03: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 092C991244 for ; Tue, 25 Sep 2001 10:03:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E23515DDE2; Tue, 25 Sep 2001 10:03:44 -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 ECFE45DDB9 for ; Tue, 25 Sep 2001 10:03:43 -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.10.1/WIREfire-1.3) with ESMTP id f8PE2vv12792; Tue, 25 Sep 2001 16:02:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA09863; Tue, 25 Sep 2001 16:02:27 +0200 (MET DST) Message-ID: <3BB08E89.E8787B0C@rioja.ericsson.se> Date: Tue, 25 Sep 2001 16:02:49 +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 167: CMS-Cert in AVP Occurence Table References: <20010924044055.D13756@charizard.diameter.org> <3BAF2769.5AF38EA0@rioja.ericsson.se> <20010924072825.B15045@charizard.diameter.org> <3BAF6B90.59835F0E@rioja.ericsson.se> <20010924171839.D18419@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: > > On Mon, Sep 24, 2001 at 07:21:20PM +0200, Miguel Ángel Monjas Llorente wrote: > > Pat Calhoun wrote: > > > > > > > CMS-Cert | 0-1 | 0 | 0 | 0 | > > > > > > yes, this one is fine. > > > > Sorry, but now I'm not certain of this suggestion. In one of the > > answers to issue 180, you've said (when I was suggesting that it may > > happen that AAA-Server-Certs wouldn't be present in a DSAA) that you > > thought that AAA-Server-Certs would include the certificate of the AAA > > server signing the DSAA, so that no CMS-Cert is needed here. Which is > > the right answer to this problem? > > The AVP isn't required to send AAA server certs, but you may want to send > other certs (e.g. top level CA cert). You needn't do that. The top level CA certificate should be one of the "direct trust" certificates that the originator of the DSA listed in the DSA-Request (Local-CA-Info) so that no top level certificate is needed in the DSA-Answer but only the certificates included in AAA-Server-Certs and the ones of the CA-Chain. 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 Sep 25 12:42: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 MAA08985 for ; Tue, 25 Sep 2001 12:42:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 144119121E; Tue, 25 Sep 2001 12:42:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D43EE912D7; Tue, 25 Sep 2001 12:42: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 CBFB89121E for ; Tue, 25 Sep 2001 12:42:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B8AC25DDE1; Tue, 25 Sep 2001 12:42:50 -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 98C475DDCB for ; Tue, 25 Sep 2001 12:42:50 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA22729 for ; Tue, 25 Sep 2001 09:42:06 -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 JAA22847 for ; Tue, 25 Sep 2001 09:42:06 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 25 Sep 2001 11:42:06 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: [Issue] Decouple authorization and key generation Date: Tue, 25 Sep 2001 11:42:05 -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: 9/25/01 Reference: N/A Document: draft-ietf-aaa-diameter-mobileip-07.txt Comment type: T Priority: 2 Section: 5.0 Rationale/Explanation of issue: 3rd paragraph in Section 5.0: "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)." Tying the Authorization-Lifetime and the key lifetimes couples authorization and key generation. It may be desirable to allow AAAH to set key lifetimes to any value (e.g. to a multiple of the Authorization-Lifetime), so that it doesn't have to generate new keys every time it re-authorizes the user. Requested change: Remove the 3rd paragraph in Section 5.0 and add a MIP-Lifetime AVP to the MIP-XX-to-XX-Key AVPs in Sections 6.1 - 6.6. -Panos From owner-aaa-wg@merit.edu Tue Sep 25 16:17: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 QAA13917 for ; Tue, 25 Sep 2001 16:17:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AE53912E1; Tue, 25 Sep 2001 16:17:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4023E91321; Tue, 25 Sep 2001 16:17: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 76EEA912E1 for ; Tue, 25 Sep 2001 16:17:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CB645DDB9; Tue, 25 Sep 2001 16:17:13 -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 B13CE5DD91 for ; Tue, 25 Sep 2001 16:17:11 -0400 (EDT) Received: from fredrikj (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id WAA13471; Tue, 25 Sep 2001 22:16:47 +0200 From: "Fredrik Johansson" To: "Bernard Aboba" , Subject: RE: [AAA-WG]: Proposed resolution of issue #173 Date: Tue, 25 Sep 2001 22:17:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: 8bit do we really need a new draft that we'll be dependent on? We already have three drafts as it is today. Why not make the transport draft an informational draft and keep all necessary information about diameter specific transport mechanisms in the base draft my 2c /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Bernard Aboba >Sent: den 25 september 2001 02:07 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Proposed resolution of issue #173 > > >This issue related to differences in the failover algorithm between >diameter-07 and transport-04. > >The proposed solution is to include failover text in only one place, the >transport draft. Diameter base will reference that text. > >Of course, there is then the issue of what the text should be. A proposal >for the next text of section 3.2 of transport -05 is included below. This >proposal contains a single timer, Tw. > >Please send comments to the list. > >------------------------------------------------------------------ > >3.2 Application layer watchdog > >In order to enable AAA implementations to more quickly >detect transport and application-layer failures, AAA proto­ >cols MUST support an application layer watchdog message. > >The application layer watchdog message enables failover from >a server that has failed either because it is unreachable or >because its applications functions have failed. This is dis­ >tinct from the purpose of the SCTP heartbeat, which is to >enable failover between interfaces. The SCTP heartbeat may >enable a failover to another path to reach the same server, >but does not adress the situation where the server system or >the application service has failed. Therefore both mecha­ >nisms MAY be used together. > >The watchdog is used in order to enable a AAA client or >agent to determine when to resend on another connection. It >operates on all open connections and is used to suspend and >eventually close connections that are experiencing difficul­ >ties. The watchdog is also used to re-open and validate con­ >nections that have returned to health. The watchdog may be >utilized either within primary/secondary or load balancing >configurations. However, it is not intended as a cluster >heartbeat mechanism comparable to that proposed in [31]. > >3.2.1. Algorithm overview > >The watchdog behavior is controlled by an algorithm defined >in this section. Implementations SHOULD implement this >algorithm, which operates as follows: > >[1] Watchdog behavior is controlled by a single timer (Tw). > The default value of Tw is 30 seconds. This value was > selected because it minimizes the probability that > failover will be initiated due to a routing flap, > as noted in [Paxson]. > > While Tw MAY be set as low as 6 seconds (not including > jitter), it MUST NOT set lower than this. Note that > setting such a low value of the watchdog timer is > likely to result in an increased probability of > duplicates, as well as an increase in spurious > failover and failback attempts. > > In order to avoid synchronization behaviors that can > occur with fixed timers among distributed systems, each > time the watchdog interval is calculated with a jitter > by using the Tw value and randomly adding a value drawn > between -2 and 2 seconds. Alternative calculations to > create jitter MAY be used. These MUST be pseudo-random > and not cyclic. > >[2] When a response is received, Tw is reset. Receiving a > watchdog from a peer constitutes activity, and Tw > should be reset. On sending a message, if the send > queue is empty, then Tw is reset. If the watchdog timer > expires and the send queue is empty, then a watchdog > packet is sent. Watchdog packets are not retransmitted > by the AAA protocol, since AAA protocols run over reli­ > able transports that will handle all retransmissions > internally. > > If the watchdog timer expires and the send queue is not > empty, then failover is initiated. The AAA client MAY > resend the request to an alternate server, reusing the > end-to-end identifier so as to permit duplicate detec­ > tion. However, the client MUST NOT close the primary > connection until the primary's watchdog timer has > expired twice without a response (note that the watch­ > dog is not sent a second time, however). Once the pri­ > mary connection has failed, subsequent requests are > sent to the alternate server until the watchdog timer > on the primary connection is reset. > > Suspension of the primary connection prevents flapping > between primary and alternate connections, and ensures > that failover behavior remains consistent. The appli­ > cation may not receive a response to the watchdog mes­ > sage due to a connectivity problem, in which case a > transport layer ACK will not have been received, or the > lack of response may be due to an application problem. > Without transport layer visibility, the application is > unable to tell the difference, and must behave conser­ > vatively. > > In situations where no transport layer ACK is received > on the primary connection after multiple re-transmis­ > sions, the RTO will be exponentially backed off. Due to > Karn's algorithm as implemented SCTP and TCP, the RTO > estimator will not be reset until another ACK is > received in response to a non-re-transmitted request. > Thus, in cases where the problem occurs at the trans­ > port layer, after the client fails over to the alter­ > nate server, the RTO of the primary will remain at a > high value unless an ACK is received on the primary > connection. > > In the case where the problem occurs at the transport > layer, subsequent requests sent on the primary connec­ > tion will not receive the same service as was origi­ > nally provided. For example, instead of failover occur­ > ing after 3 retransmissions, failover might occur with­ > out even a single retransmission if RTO has been suffi­ > ciently backed off. Of course, if the lack of a watch­ > dog response was due to an application layer problem, > then RTO will not have been backed off. However, with­ > out transport layer visibility, there is no way for the > application to know this. > > Suspending use of the primary connection until a > response is received to a watchdog message guarantees > that the RTO timer will have been reset before the pri­ > mary connection is reused. If no response is received > after the second Tw expiration, then the primary con­ > nection is closed and so the suspension becomes perma­ > nent. > > >[3] After the the expiration of two watchdog timers without > a response, the AAA client SHOULD cause a transport > reset or close to be done on the connection. While the > connection is in the closed state, the AAA client MUST > NOT attempt to send further watchdog messages on the > connection. However, after the connection is closed, > the AAA client continues to periodically attempt to re- > open the connection. The AAA client SHOULD wait for > the transport layer to report connection failure before > attempting again, but MAY choose to bound this wait > time by the watchdog interval, Tw. If the connection is > successfully opened, then the watchdog message is sent. > Once three watchdog messages have been sent and > responded to, the connection is returned to service, > and transactions are once again sent over it. Connec­ > tion validation via receipt of multiple watchdogs is > not required when a connection is initially brought up > -- in this case, the connection can immediately be put > into service. > > When using SCTP as a transport, it is not necessary to > disable SCTP's transport-layer heartbeats. However If > AAA implementations have access to SCTP's heartbeat > parameters, they MAY chose to ensure that SCTP's heart­ > beat interval is longer than the AAA protocol's watch­ > dog interval, Tw. This will ensure both that alternate > paths are still probed by SCTP, while the primary path > has a minumum of heartbeat redundancy. > >In the event that a transport failure is detected with a >peer, it is necessary for all pending request messages to be >forwarded to an alternate agent, if possible. This is com­ >monly referred to as failover. > >In order for a AAA client or agent to perform failover pro­ >cedures, it is necessary to maintain a pending message queue >for a given peer. When an answer message is received, the >corresponding request is removed from the queue. The Hop-by- >Hop Identifier field MAY be used to match the answer with >the queued request. > >When a transport failure is detected, all messages in the >queue are sent to an alternate agent, if possible. Multiple >identical requests or answers MAY be received as a result of >a failover. The combination of an end-to-end identifier and >the origin host MUST be used to identify duplicate messages. > >3.2.2. Detailed algorithm description > >In this section, we will refer to a memory control structure >that contains all information regarding a specific peer as a >Peer Control Block, or PCB. > >For the purposes of illustrating the algorithm, each PCB >contains the following fields: > > Status - This field represents the level of confidence in the > algorithm. The following values are defined: > > OKAY: The connection is up > SUSPECT: Failover has been initiated on the >connection. > DOWN: Connection has been closed. > REOPEN: Attempting to reopen a connection > > Pending - This boolean field is set to TRUE when there are no > outstanding unanswered requests. > >T is the watchdog timer, measured in seconds. Every second, >T is decremented. When it reaches 0, the OnTimerElapsed >event (see below) is invoked. > >Pseudo-code for the algorithm is as follows: > >/* > >Here is the Failover state machine: > >States: > OKAY: The connection is up > SUSPECT: Failover has been initiated on the connection. > DOWN: Connection has been closed. > REOPEN: Attempting to reopen a closed connection > Pending: Set to TRUE if there are outstanding unanswered requests > T: Watchdog timer value > >STATE Event New State Actions >===== ===== ========= ======= >OKAY Send & OKAY SetWatchDog() > !Pending >OKAY Send & > Pending OKAY >SUSPECT Send ERROR Error() >DOWN Send ERROR Error() >OKAY Receive OKAY SetWatchDog() >SUSPECT Receive OKAY Failback() > SetWatchDog() >DOWN Receive DOWN Throwaway() >OKAY Timer expires & OKAY SendWatchdog() > !Pending >OKAY Timer expires & SUSPECT FailOver() > Pending SetWatchdog() >SUSPECT Timer expires DOWN Close Connection > SetWatchdog() >DOWN Timer expires REOPEN AttemptOpen() > SetWatchdog() >REOPEN Timer expires REOPEN SetWatchdog() >REOPEN Connection up SUSPECT SendWatchdog() >OKAY Connection down DOWN SetWatchdog() >SUSPECT Connection down DOWN SetWatchdog() >REOPEN Connection down DOWN SetWatchdog() >DOWN Connection down ERROR Error() >*/ > > >/* SetWatchdog() is called in order to set the Watchdog > timer, measured in seconds. The default value of > TWINIT is 30 seconds. A random value between > -2 and 2 seconds is added to the timer to provide jitter. >*/ > >SetWatchdog() >{ > return (TWINIT -2.0 + 4.0 * random()) ; >} > > >/* > OnReceive() is called whenever a message > is received from the peer. This message MAY > be a request or an answer, and can include > DWR and DWA messages. >*/ >OnReceive(pcb) >{ > switch (pcb->Status){ > case OKAY: > T = SetWatchdog(); > break; > case SUSPECT: > pcb->Status = OKAY; > T = SetWatchdog(); > Failback(); > break; > case REOPEN: > pcb->Status = SUSPECT; > T = SetWatchdog(); > break; > case DOWN: > Throwaway(received packet); > break; > default: > Error("Shouldn't be here!"); > break; > } >} > > >/* >OnSendRequest() is called after a request is sent to >the peer. >[Issue: Should this be called whenever any message is >sent to the peer?] >*/ >OnSendRequest(pcb) >{ > switch (pcb->Status){ > case OKAY: > if (!Pending) T = SetWatchdog(); > break; > default: > error("Shouldn't be here!"); > break; > } >} > > >/* >OnTimerElapsed() is called whenever T reaches zero (0). >*/ >OnTimerElapsed(pcb) >{ > switch (pcb->status){ > case OKAY: > if (!Pending) { > SendWatchdog(pbc); > break; > } > pcb->status = SUSPECT; > FailOver(pcb); > break ; > case SUSPECT: > pcb->status = DOWN; > CloseConnection(pcb); > OpenAttempt = FALSE; > T = SetWatchdog(); > break; > case DOWN: > if (!OpenAttempt) { > OpenAttempt = TRUE; > AttemptOpen(pcb); > break; > } > break; > default: > error("Shouldn't be here!); > break; > } >} > >/* >OnConnectionUp() is called whenever a connection comes up >*/ >OnConnectionUp(pcb) >{ > switch (pcb->status){ > case DOWN > pcb->status = REOPEN; > SendWatchdog(); > break; > default: > error("Shouldn't be here!); > break; > } >} > >/* >OnConnectionDown() is called whenever a connection goes down >*/ >OnConnectionDown(pcb) >{ > switch (pcb->status){ > case OK: > pcb->status = DOWN; > T=SetWatchdog(); > break; > case SUSPECT: > pcb->status = DOWN; > T=SetWatchdog(); > break; > case REOPEN: > pcb->status = DOWN; > T=SetWatchdog(); > break; > default: > error("Shouldn't be here!); > break; > } >} > From owner-aaa-wg@merit.edu Tue Sep 25 17:57: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 RAA16324 for ; Tue, 25 Sep 2001 17:57:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B94409120D; Tue, 25 Sep 2001 17:58:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D4A591212; Tue, 25 Sep 2001 17:58: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 850A09120D for ; Tue, 25 Sep 2001 17:58:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 784985DDB3; Tue, 25 Sep 2001 17:58:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 0D2DA5DDB9 for ; Tue, 25 Sep 2001 17:58:17 -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 f8PLva709211; Tue, 25 Sep 2001 16:57:36 -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 f8PLvaQ05513; Tue, 25 Sep 2001 16:57:36 -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 QAA24538; Tue, 25 Sep 2001 16:57:36 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA08273; Tue, 25 Sep 2001 16:57:33 -0500 (CDT) Message-ID: <3BB0FDB4.2020908@ericsson.com> Date: Tue, 25 Sep 2001 14:57:08 -0700 From: Tony Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed resolution of issue #173 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, So, doing this means that the Diameter Base protocol, the Diameter NASREQ application, the Diameter MIPv4 application, the Diameter CMS-Security application and the Transport must all be submitted as a set to final call. Right? If so, do we really want to spread dependencies over yet another draft? I'm very concerned that this could add on even more delay before we get Diameter approved, but I may have misunderstood the intention with this proposal. Regards, /Tony Bernard Aboba wrote: >From: Bernard Aboba >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Proposed resolution of issue #173 >Message-ID: >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=X-UNKNOWN >Content-Transfer-Encoding: QUOTED-PRINTABLE >Sender: owner-aaa-wg@merit.edu >Precedence: bulk > >This issue related to differences in the failover algorithm between >diameter-07 and transport-04.=20 > >The proposed solution is to include failover text in only one place, the >transport draft. Diameter base will reference that text.=20 > >Of course, there is then the issue of what the text should be. A proposal >for the next text of section 3.2 of transport -05 is included below. This >proposal contains a single timer, Tw.=20 > >Please send comments to the list.=20 > >------------------------------------------------------------------ > >3.2 Application layer watchdog > >In order to enable AAA implementations to more quickly >detect transport and application-layer failures, AAA proto=AD >cols MUST support an application layer watchdog message. > >The application layer watchdog message enables failover from >a server that has failed either because it is unreachable or >because its applications functions have failed. This is dis=AD >tinct from the purpose of the SCTP heartbeat, which is to >enable failover between interfaces. The SCTP heartbeat may >enable a failover to another path to reach the same server, >but does not adress the situation where the server system or >the application service has failed. Therefore both mecha=AD >nisms MAY be used together. > >The watchdog is used in order to enable a AAA client or >agent to determine when to resend on another connection. It >operates on all open connections and is used to suspend and >eventually close connections that are experiencing difficul=AD >ties. The watchdog is also used to re-open and validate con=AD >nections that have returned to health. The watchdog may be >utilized either within primary/secondary or load balancing >configurations. However, it is not intended as a cluster >heartbeat mechanism comparable to that proposed in [31]. > >3.2.1. Algorithm overview > >The watchdog behavior is controlled by an algorithm defined >in this section. Implementations SHOULD implement this=20 >algorithm, which operates as follows: > >[1] Watchdog behavior is controlled by a single timer (Tw). > The default value of Tw is 30 seconds. This value was > selected because it minimizes the probability that > failover will be initiated due to a routing flap, > as noted in [Paxson].=20 > > While Tw MAY be set as low as 6 seconds (not including > jitter), it MUST NOT set lower than this. Note that > setting such a low value of the watchdog timer is > likely to result in an increased probability of > duplicates, as well as an increase in spurious > failover and failback attempts.=20 > > In order to avoid synchronization behaviors that can=20 > occur with fixed timers among distributed systems, each > time the watchdog interval is calculated with a jitter > by using the Tw value and randomly adding a value drawn > between -2 and 2 seconds. Alternative calculations to=20 > create jitter MAY be used. These MUST be pseudo-random > and not cyclic.=20 > >[2] When a response is received, Tw is reset. Receiving a > watchdog from a peer constitutes activity, and Tw > should be reset. On sending a message, if the send > queue is empty, then Tw is reset. If the watchdog timer > expires and the send queue is empty, then a watchdog > packet is sent. Watchdog packets are not retransmitted > by the AAA protocol, since AAA protocols run over reli=AD > able transports that will handle all retransmissions > internally. > > If the watchdog timer expires and the send queue is not > empty, then failover is initiated. The AAA client MAY > resend the request to an alternate server, reusing the > end-to-end identifier so as to permit duplicate detec=AD > tion. However, the client MUST NOT close the primary > connection until the primary's watchdog timer has > expired twice without a response (note that the watch=AD > dog is not sent a second time, however). Once the pri=AD > mary connection has failed, subsequent requests are > sent to the alternate server until the watchdog timer > on the primary connection is reset. > > Suspension of the primary connection prevents flapping > between primary and alternate connections, and ensures > that failover behavior remains consistent. The appli=AD > cation may not receive a response to the watchdog mes=AD > sage due to a connectivity problem, in which case a > transport layer ACK will not have been received, or the > lack of response may be due to an application problem. > Without transport layer visibility, the application is > unable to tell the difference, and must behave conser=AD > vatively. > > In situations where no transport layer ACK is received > on the primary connection after multiple re-transmis=AD > sions, the RTO will be exponentially backed off. Due to > Karn's algorithm as implemented SCTP and TCP, the RTO > estimator will not be reset until another ACK is > received in response to a non-re-transmitted request. > Thus, in cases where the problem occurs at the trans=AD > port layer, after the client fails over to the alter=AD > nate server, the RTO of the primary will remain at a > high value unless an ACK is received on the primary > connection. > > In the case where the problem occurs at the transport > layer, subsequent requests sent on the primary connec=AD > tion will not receive the same service as was origi=AD > nally provided. For example, instead of failover occur=AD > ing after 3 retransmissions, failover might occur with=AD > out even a single retransmission if RTO has been suffi=AD > ciently backed off. Of course, if the lack of a watch=AD > dog response was due to an application layer problem, > then RTO will not have been backed off. However, with=AD > out transport layer visibility, there is no way for the > application to know this. > > Suspending use of the primary connection until a > response is received to a watchdog message guarantees > that the RTO timer will have been reset before the pri=AD > mary connection is reused. If no response is received > after the second Tw expiration, then the primary con=AD > nection is closed and so the suspension becomes perma=AD > nent. > > >[3] After the the expiration of two watchdog timers without > a response, the AAA client SHOULD cause a transport > reset or close to be done on the connection. While the > connection is in the closed state, the AAA client MUST > NOT attempt to send further watchdog messages on the > connection. However, after the connection is closed, > the AAA client continues to periodically attempt to re- > open the connection. The AAA client SHOULD wait for > the transport layer to report connection failure before > attempting again, but MAY choose to bound this wait > time by the watchdog interval, Tw. If the connection is > successfully opened, then the watchdog message is sent. > Once three watchdog messages have been sent and > responded to, the connection is returned to service, > and transactions are once again sent over it. Connec=AD > tion validation via receipt of multiple watchdogs is > not required when a connection is initially brought up > -- in this case, the connection can immediately be put > into service. > > When using SCTP as a transport, it is not necessary to > disable SCTP's transport-layer heartbeats. However If > AAA implementations have access to SCTP's heartbeat > parameters, they MAY chose to ensure that SCTP's heart=AD > beat interval is longer than the AAA protocol's watch=AD > dog interval, Tw. This will ensure both that alternate > paths are still probed by SCTP, while the primary path > has a minumum of heartbeat redundancy. > >In the event that a transport failure is detected with a >peer, it is necessary for all pending request messages to be >forwarded to an alternate agent, if possible. This is com=AD >monly referred to as failover. > >In order for a AAA client or agent to perform failover pro=AD >cedures, it is necessary to maintain a pending message queue >for a given peer. When an answer message is received, the >corresponding request is removed from the queue. The Hop-by- >Hop Identifier field MAY be used to match the answer with >the queued request. > >When a transport failure is detected, all messages in the >queue are sent to an alternate agent, if possible. Multiple >identical requests or answers MAY be received as a result of >a failover. The combination of an end-to-end identifier and >the origin host MUST be used to identify duplicate messages. > >3.2.2. Detailed algorithm description > >In this section, we will refer to a memory control structure >that contains all information regarding a specific peer as a >Peer Control Block, or PCB. > >For the purposes of illustrating the algorithm, each PCB >contains the following fields: > > Status - This field represents the level of confidence in the > algorithm. The following values are defined: > > OKAY: The connection is up > SUSPECT: Failover has been initiated on the connection= >=2E > DOWN: Connection has been closed. > REOPEN: Attempting to reopen a connection > > Pending - This boolean field is set to TRUE when there are no > outstanding unanswered requests. > >T is the watchdog timer, measured in seconds. Every second, >T is decremented. When it reaches 0, the OnTimerElapsed >event (see below) is invoked. > >Pseudo-code for the algorithm is as follows: > >/* > >Here is the Failover state machine: > >States: > OKAY: The connection is up > SUSPECT: Failover has been initiated on the connection. > DOWN: Connection has been closed. > REOPEN: Attempting to reopen a closed connection > Pending: Set to TRUE if there are outstanding unanswered requests > T: Watchdog timer value > >STATE Event New State Actions >=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D= >=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D >OKAY Send & OKAY SetWatchDog() > !Pending >OKAY Send & > Pending OKAY >SUSPECT Send ERROR Error() >DOWN Send ERROR Error() >OKAY Receive OKAY SetWatchDog() >SUSPECT Receive OKAY Failback() > SetWatchDog() >DOWN Receive DOWN Throwaway() >OKAY Timer expires & OKAY SendWatchdog() > !Pending >OKAY Timer expires & SUSPECT FailOver() > Pending SetWatchdog() >SUSPECT Timer expires DOWN Close Connection > SetWatchdog() >DOWN Timer expires REOPEN AttemptOpen() > SetWatchdog() >REOPEN Timer expires REOPEN SetWatchdog() >REOPEN Connection up SUSPECT SendWatchdog() >OKAY Connection down DOWN SetWatchdog() >SUSPECT Connection down DOWN SetWatchdog() >REOPEN Connection down DOWN SetWatchdog() >DOWN Connection down ERROR Error() >*/ > > >/* SetWatchdog() is called in order to set the Watchdog > timer, measured in seconds. The default value of > TWINIT is 30 seconds. A random value between > -2 and 2 seconds is added to the timer to provide jitter. >*/ > >SetWatchdog() >{ > return (TWINIT -2.0 + 4.0 * random()) ; >} > > >/* > OnReceive() is called whenever a message > is received from the peer. This message MAY > be a request or an answer, and can include > DWR and DWA messages. >*/ >OnReceive(pcb) >{ > switch (pcb->Status){ > case OKAY: > T =3D SetWatchdog(); > break; > case SUSPECT: > pcb->Status =3D OKAY; > T =3D SetWatchdog(); > Failback(); > break; > case REOPEN: > pcb->Status =3D SUSPECT; > T =3D SetWatchdog(); > break; > case DOWN: > Throwaway(received packet); > break; > default: > Error("Shouldn't be here!"); > break; > } >} > > >/* >OnSendRequest() is called after a request is sent to >the peer. >[Issue: Should this be called whenever any message is >sent to the peer?] >*/ >OnSendRequest(pcb) >{ > switch (pcb->Status){ > case OKAY: > if (!Pending) T =3D SetWatchdog(); > break; > default: > error("Shouldn't be here!"); > break; > } >} > > >/* >OnTimerElapsed() is called whenever T reaches zero (0). >*/ >OnTimerElapsed(pcb) >{ > switch (pcb->status){ > case OKAY: > if (!Pending) { > SendWatchdog(pbc); > break; > } > pcb->status =3D SUSPECT; > FailOver(pcb); > break ; > case SUSPECT: > pcb->status =3D DOWN; > CloseConnection(pcb); > OpenAttempt =3D FALSE; > T =3D SetWatchdog(); > break; > case DOWN: > if (!OpenAttempt) { > OpenAttempt =3D TRUE; > AttemptOpen(pcb); > break;=20 > } > break; > default: > error("Shouldn't be here!); > break; > } >} > >/* >OnConnectionUp() is called whenever a connection comes up >*/ >OnConnectionUp(pcb) >{ > switch (pcb->status){ > case DOWN > pcb->status =3D REOPEN; > SendWatchdog(); > break; > default: > error("Shouldn't be here!); > break; > } >} > >/* >OnConnectionDown() is called whenever a connection goes down >*/ >OnConnectionDown(pcb) >{ > switch (pcb->status){ > case OK: > pcb->status =3D DOWN; > T=3DSetWatchdog(); > break; > case SUSPECT: > pcb->status =3D DOWN; > T=3DSetWatchdog(); > break; > case REOPEN: > pcb->status =3D DOWN; > T=3DSetWatchdog(); > break; > default: > error("Shouldn't be here!); > break; > } >} > > > > > > From owner-aaa-wg@merit.edu Tue Sep 25 19:47:13 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 TAA18488 for ; Tue, 25 Sep 2001 19:47:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27BA791249; Tue, 25 Sep 2001 19:44:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF85691245; Tue, 25 Sep 2001 19:44: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 5D6E891244 for ; Tue, 25 Sep 2001 19:44:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53BBD5DDC8; Tue, 25 Sep 2001 19:44:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 903475DDB3 for ; Tue, 25 Sep 2001 19:44:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA24823; Tue, 25 Sep 2001 16:35:32 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 25 Sep 2001 16:35:32 -0700 (PDT) From: Bernard Aboba To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed resolution of issue #173 In-Reply-To: <3BB0FDB4.2020908@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > So, doing this means that the Diameter Base protocol, the Diameter > NASREQ application, the Diameter MIPv4 application, the Diameter > CMS-Security application and the Transport must all be submitted as a > set to final call. The IESG has already indicated that this was required anyway. All of these drafts will go to the IESG as a unit. In any case, I'd worry less about where the algorithm ends up (this can be changed with a cut and paste), than whether it makes sense. From owner-aaa-wg@merit.edu Wed Sep 26 14:58: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 OAA26325 for ; Wed, 26 Sep 2001 14:58:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA92991269; Wed, 26 Sep 2001 14:58:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 906EF9126B; Wed, 26 Sep 2001 14: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 78A5691269 for ; Wed, 26 Sep 2001 14:58:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 670875DDB7; Wed, 26 Sep 2001 14:58: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 953D05DDB1 for ; Wed, 26 Sep 2001 14:58: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 OAA04900 for ; Wed, 26 Sep 2001 14:50:56 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id OAA29948 for ; Wed, 26 Sep 2001 14:58:41 -0400 (EDT) From: "Mark Jones" To: Subject: [AAA-WG]: [Issue] AVP data type mismatch in Section 4.6 of base -07 Date: Wed, 26 Sep 2001 14:58:39 -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 Submitter name: Mark Jones Submitter email address: mjones@bridgewatersystems.com Date first submitted: 2001-09-26 Reference: Document: base -07 Comment type: E Priority: 'S' Section: 4.6 Rationale/Explanation of issue: Some of the data types listed in the AVP table in section 4.6 do not match those in the AVP description elsewhere in the draft. Request change: The AVP data types in section 4.6 should be corrected as follows: Accounting-Multi-Session-Id OctetString -> UTF8String Accounting-Session-Id OctetString -> UTF8String Acct-Application-Id Integer32 -> Unsigned32 Alternate-Peer OctetString -> DiameterIdentity Acct-Application-Id Integer32 -> Unsigned32 Destination-Host OctetString -> DiameterIdentity Destination-Realm OctetString -> UTF8String Error-Message OctetString -> UTF8String Error-Reporting-Host OctetString -> DiameterIdentity Origin-Host OctetString -> DiameterIdentity Origin-Realm OctetString -> UTF8String Product-Name OctetString -> UTF8String Proxy-Host IPAddress -> DiameterIdentity Redirect-Host OctetString -> DiameterIdentity Route-Record OctetString -> DiameterIdentity Session-Id OctetString -> UTF8String Source-Route OctetString -> DiameterIdentity Regards, Mark From owner-aaa-wg@merit.edu Wed Sep 26 15:20: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 PAA26858 for ; Wed, 26 Sep 2001 15:20:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AE3E9127A; Wed, 26 Sep 2001 15:21:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48A9C9127F; Wed, 26 Sep 2001 15:21: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 3A7559127A for ; Wed, 26 Sep 2001 15:21:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37D3F5DDCA; Wed, 26 Sep 2001 15:21:23 -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 279345DDB7 for ; Wed, 26 Sep 2001 15:21:22 -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 PAA05082 for ; Wed, 26 Sep 2001 15:14:23 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id PAA01458 for ; Wed, 26 Sep 2001 15:22:06 -0400 (EDT) From: "Mark Jones" To: Subject: RE: [AAA-WG]: [Issue] AVP data type mismatch in Section 4.6 of base -07 Date: Wed, 26 Sep 2001 15:22: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Apologies, please ignore this issue. It is a duplicate of issue 103 by Dave Frascone. Regards, Mark > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Mark Jones > Sent: September 26, 2001 2:59 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [Issue] AVP data type mismatch in Section 4.6 of base > -07 > > > Submitter name: Mark Jones > Submitter email address: mjones@bridgewatersystems.com > Date first submitted: 2001-09-26 > Reference: > Document: base -07 > Comment type: E > Priority: 'S' > Section: 4.6 > > Rationale/Explanation of issue: > > Some of the data types listed in the AVP table in section 4.6 do not match > those in the AVP description elsewhere in the draft. > > Request change: > > The AVP data types in section 4.6 should be corrected as follows: > > Accounting-Multi-Session-Id OctetString -> UTF8String > Accounting-Session-Id OctetString -> UTF8String > Acct-Application-Id Integer32 -> Unsigned32 > Alternate-Peer OctetString -> DiameterIdentity > Acct-Application-Id Integer32 -> Unsigned32 > Destination-Host OctetString -> DiameterIdentity > Destination-Realm OctetString -> UTF8String > Error-Message OctetString -> UTF8String > Error-Reporting-Host OctetString -> DiameterIdentity > Origin-Host OctetString -> DiameterIdentity > Origin-Realm OctetString -> UTF8String > Product-Name OctetString -> UTF8String > Proxy-Host IPAddress -> DiameterIdentity > Redirect-Host OctetString -> DiameterIdentity > Route-Record OctetString -> DiameterIdentity > Session-Id OctetString -> UTF8String > Source-Route OctetString -> DiameterIdentity > > Regards, > Mark > > From owner-aaa-wg@merit.edu Wed Sep 26 16:32: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 QAA28154 for ; Wed, 26 Sep 2001 16:32:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D22F891284; Wed, 26 Sep 2001 16:32:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 939EC91286; Wed, 26 Sep 2001 16:32: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 E8B9A91284 for ; Wed, 26 Sep 2001 16:32:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA9AD5DDCA; Wed, 26 Sep 2001 16:32: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 D426E5DDB7 for ; Wed, 26 Sep 2001 16:32:34 -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 QAA17883 for ; Wed, 26 Sep 2001 16:31:45 -0400 (EDT) Date: Wed, 26 Sep 2001 16:32:18 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: Foreign-Home authentication extension doesn't exist Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Mark Eklund Submitter email address: meklund@cisco.com Date first submitted: 26-Sep-01 Reference: Document: mobileip Comment type: Editorial Priority: '1' Should fix Section: 5.3 Rationale/Explanation of issue: According to 5.3: Upon receipt of the HAR, the home agent recovers the Foreign-Home registration key, allocates an SPI to be used with the key, and uses this key to create a Foreign-Home authentication extension to the Registration Reply message. But according to draft-ietf-mobileip-aaa-key-01.txt there is no such thing as a Foreign-Home authentication extension. Requested change: Since there is no need for the mobile node to know the Foreign-Home key, this was probably a cut and paste error. Please remove: , and uses this key to create a Foreign-Home authentication extension to the Registration Reply message. -mark From owner-aaa-wg@merit.edu Wed Sep 26 21:20: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 VAA02002 for ; Wed, 26 Sep 2001 21:20:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFA4691294; Wed, 26 Sep 2001 21:21:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A934C9129D; Wed, 26 Sep 2001 21:21: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 A961A91294 for ; Wed, 26 Sep 2001 21:21:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A2F1C5DE01; Wed, 26 Sep 2001 21:21:01 -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 2498D5DDFE for ; Wed, 26 Sep 2001 21:21:00 -0400 (EDT) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Sep 2001 10:18:10 +0900 Message-ID: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E7E3@cms3.etri.re.kr> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: when are the Diameter draft (-08) released? Date: Thu, 27 Sep 2001 10:18:09 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C146F2.449B6870" 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_01C146F2.449B6870 Content-Type: text/plain; charset="euc-kr" Hi I would like to know when the new Diameter drafts and(or) RFCs come out. Thanks in advance. ------_=_NextPart_001_01C146F2.449B6870 Content-Type: text/html; charset="euc-kr" [AAA-WG]: when are the Diameter draft (-08) released?

Hi

I would like to know when the new Diameter drafts and(or) RFCs come out.

Thanks in advance.

------_=_NextPart_001_01C146F2.449B6870-- From owner-aaa-wg@merit.edu Thu Sep 27 08:01: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 IAA27410 for ; Thu, 27 Sep 2001 08:01:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96EE691269; Thu, 27 Sep 2001 08:01:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C369127A; Thu, 27 Sep 2001 08:01: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 1BA9591269 for ; Thu, 27 Sep 2001 08:01:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E2395DDDE; Thu, 27 Sep 2001 08:01:39 -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 B845F5DD9D for ; Thu, 27 Sep 2001 08:01:38 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id DF1F17B for ; Thu, 27 Sep 2001 08:00:57 -0400 (EDT) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: Question re: draft-mobileip-07 / 1.4 Allocation of HA in Foreign Network Date: Thu, 27 Sep 2001 07:58:37 -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, Is my understanding correct here? From the text and diagrams, it appears that when the HA is allocated in the foreign network, the AAAH targets the HAR to the specific AAAF which forwarded the AMR, not to any old AAA server in the foreign network. If this is the case, then to ensure that the HAR is routed to the specific AAAF, the HAR's Destination-Realm AVP and Destination-Host AVP must be: 1. The HAR's Destination-Realm AVP contains AAAF's realm. 2. The HAR's Destination-Host AVP contains AAAF's DiameterIdentity. So... 1. The HAR's Destination-Realm is set to the value of the AMR's Origin-Realm. This is the FA's realm, which is the same as the AAAF's realm. 2. The HAR's Destination-Host is set to the value of the AMR's first Route-Record AVP. This requires that no-one is hiding network topology by removing Route-Record AVPs (per section 6.3 of base document). Bob K. From owner-aaa-wg@merit.edu Thu Sep 27 08:33: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 IAA28491 for ; Thu, 27 Sep 2001 08:33:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F17E29127A; Thu, 27 Sep 2001 08:34:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD34391284; Thu, 27 Sep 2001 08:34: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 96AEA9127A for ; Thu, 27 Sep 2001 08:34:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EEB05DDDC; Thu, 27 Sep 2001 08:34: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 2EC2E5DD9D for ; Thu, 27 Sep 2001 08:34:11 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 404997B for ; Thu, 27 Sep 2001 08:33:30 -0400 (EDT) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: Question re: draft-mobileip-07 / Maintaining session-state by AAAH Date: Thu, 27 Sep 2001 08:31:09 -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, Is it a requirement that an AAAH, which supports the Mobile-IP application, maintain session state, or can the AAAH be session stateless? The draft doesn't explicitly say that session state is required, and some sections of the draft suggest that the AAAH may be session stateless. For example, 1. Section 1.6 "Diameter Session Termination", says "MAY": "A Foreign and Home Agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks." But other areas of draft-07, and some pending draft-08 changes, describe some AAAH actions which seem to require session state. For example... 1. 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." 2. 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." 3. Diameter Issue#110 proposes that an AAAH determine if the mobile node has moved to a new domain by comparing the Origin-Realm of the current AMR against the Origin-Realm of the previous request Bob K. From owner-aaa-wg@merit.edu Thu Sep 27 08:52: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 IAA29125 for ; Thu, 27 Sep 2001 08:52:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5101912C8; Thu, 27 Sep 2001 08:52:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 780F9912B3; Thu, 27 Sep 2001 08:52: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 22FCE912DF for ; Thu, 27 Sep 2001 08:52:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B3DA5DDE9; Thu, 27 Sep 2001 08:52: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 DCFE15DDDC for ; Thu, 27 Sep 2001 08:51:49 -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 f8RCpK329587 for ; Thu, 27 Sep 2001 15:51:20 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Sep 2001 15:50:49 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 27 Sep 2001 15:50:48 +0300 Message-ID: From: henry.haverinen@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] NAS-Key-Binding and Ciphersuite Negotiation Date: Thu, 27 Sep 2001 15:50:46 +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: Henry Haverinen Submitter email address: henry.haverinen@nokia.com Date first submitted: 2001-09-27 Reference: Document: nasreq Comment type: T Priority: S Section: 2.1.6 Rationale/Explanation of issue: 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. 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. 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. Requested change: The NAS-Key-Binding AVP should not be mandatory even if the NAS-Session-Key AVP is included. Do we need the NAS-Key-Binding AVP at all? From owner-aaa-wg@merit.edu Thu Sep 27 08:52:49 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 IAA29150 for ; Thu, 27 Sep 2001 08:52:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 019B9912C9; Thu, 27 Sep 2001 08:52:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9324912C2; Thu, 27 Sep 2001 08:52: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 0C6C0912C9 for ; Thu, 27 Sep 2001 08:52:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44F445DDB7; Thu, 27 Sep 2001 08:52:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 159B15DDDE for ; Thu, 27 Sep 2001 08:52:05 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8RCpc703634 for ; Thu, 27 Sep 2001 15:51:38 +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, 27 Sep 2001 15:51:03 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 27 Sep 2001 15:51:03 +0300 Message-ID: From: henry.haverinen@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] NAS-Session-Key and Initialization Vectors Date: Thu, 27 Sep 2001 15:51:00 +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: Henry Haverinen Submitter email address: henry.haverinen@nokia.com Date first submitted: 2001-09-27 Reference: Document: nasreq Comment type: S Priority: 1 Section: 2.1.2 - 2.1.6 Rationale/Explanation of issue: The NAS-Session-Key AVP as currently specified does not include means to transport initialization vectors for encryption. Requested change: One way to support IV's would be to have a new NAS-Key-Type for them. This would make sense especially if the NAS uses the received material as a master session key from which the actual IV's are derived. Alternatively, we could specify that the keying material of cipher keys includes initialization vector material. From owner-aaa-wg@merit.edu Thu Sep 27 08:53: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 IAA29190 for ; Thu, 27 Sep 2001 08:53:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 308AC912B3; Thu, 27 Sep 2001 08:52:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F0E2912C2; Thu, 27 Sep 2001 08:52: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 44348912E0 for ; Thu, 27 Sep 2001 08:52:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FB355DDDE; Thu, 27 Sep 2001 08:52: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 EFFC95DE0F for ; Thu, 27 Sep 2001 08:52:14 -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 f8RCpj329846 for ; Thu, 27 Sep 2001 15:51:45 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 27 Sep 2001 15:51:14 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 27 Sep 2001 15:51:13 +0300 Message-ID: From: henry.haverinen@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] NAS-Session-Key and Session Master Keys Date: Thu, 27 Sep 2001 15:51:07 +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: Henry Haverinen Submitter email address: henry.haverinen@nokia.com Date first submitted: 2001-09-27 Reference: Document: nasreq Comment type: S Priority: 1 Section: 2.1.2 - 2.1.6 Rationale/Explanation of issue: The NAS-Session-Key AVP, as currently specified, can only be used to transport encryption and integrity keys. However, a IEEE 802.11 access point may need session master keys from which it derives the actual encryption and authentication keys. (This is not certain yet.) Requested change: 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 owner-aaa-wg@merit.edu Thu Sep 27 13:40: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 NAA08634 for ; Thu, 27 Sep 2001 13:40:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71749912B0; Thu, 27 Sep 2001 13:41:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45427912BF; Thu, 27 Sep 2001 13:41: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 28E7C912B0 for ; Thu, 27 Sep 2001 13:41:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 249255DDDC; Thu, 27 Sep 2001 13:41: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 97F6C5DDAB for ; Thu, 27 Sep 2001 13:41:08 -0400 (EDT) Received: (qmail 447 invoked by uid 500); 27 Sep 2001 17:26:20 -0000 Date: Thu, 27 Sep 2001 10:26:20 -0700 From: Pat Calhoun To: haenamu@etri.re.kr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: when are the Diameter draft (-08) released? Message-ID: <20010927102620.C353@charizard.diameter.org> Mail-Followup-To: haenamu@etri.re.kr, aaa-wg@merit.edu References: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E7E3@cms3.etri.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <766FA1FC5C2AD511B3C800D0B7A8AC4A30E7E3@cms3.etri.re.kr>; from haenamu@etri.re.kr on Thu, Sep 27, 2001 at 10:18:09AM +0900 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I would like to know when the new Diameter drafts and(or) RFCs come out. Due to the number of requests, I've made alpha versions available at www.diameter.org/alpha. beware that I have not sanity checked these files, so the formatting may be off. When I have a little more time, I'll modify them. btw, I plan to submit the drafts once the issues stop coming in, and I have them resolved. PatC From owner-aaa-wg@merit.edu Thu Sep 27 14:12: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 OAA09964 for ; Thu, 27 Sep 2001 14:12:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0C94912BF; Thu, 27 Sep 2001 14:13:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA5A4912C1; Thu, 27 Sep 2001 14: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 C2A6E912BF for ; Thu, 27 Sep 2001 14:13:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C10795DDE9; Thu, 27 Sep 2001 14:13:27 -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 AD1A45DDAB for ; Thu, 27 Sep 2001 14:13:27 -0400 (EDT) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id DE4B87E; Thu, 27 Sep 2001 14:12:45 -0400 (EDT) Message-ID: <3BB36C3B.7977CE80@Interlinknetworks.com> Date: Thu, 27 Sep 2001 14:13:15 -0400 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz , AAA Working Group , Patrice Calhoun Subject: Re: [AAA-WG]: Question re: draft-mobileip-07 / 1.4 Allocation of HA in Foreign Network References: Content-Type: multipart/mixed; boundary="------------6B8CBD526B470E7EE1A6F3C7" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------6B8CBD526B470E7EE1A6F3C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Per my issue 95: Requested change: Delete section 6.3. Or because this section has been here for a while, it may be safer to change 6.3 to state that an agent MUST NOT remove Route-Record AVPs. This issue is listed as resolved in Base-08. However, the reasoning behind issue 95 was that source routing of answers could not be properly implemented if Route-Record AVPs were hidden. However, issue 117 has since been resolved in favor of removing support for source routing. Therefore, the reasoning behind issue 95 has since evaporated. Therefore, thank you for documenting another reason for not removing Route-Record AVPs. Pat, can you confirm that issue 95 remains resolved as documented, that is, that section 6.3 has been deleted? David Spence Bob Kopacz wrote: > > Hi, > > Is my understanding correct here? > > From the text and diagrams, it appears that when the HA is allocated in the > foreign network, the AAAH targets the HAR to the specific AAAF which forwarded > the AMR, not to any old AAA server in the foreign network. > > If this is the case, then to ensure that the HAR is routed to the specific > AAAF, the HAR's Destination-Realm AVP and Destination-Host AVP must be: > > 1. The HAR's Destination-Realm AVP contains AAAF's realm. > 2. The HAR's Destination-Host AVP contains AAAF's DiameterIdentity. > > So... > > 1. The HAR's Destination-Realm is set to the value of the AMR's > Origin-Realm. This is the FA's realm, which is the same as the AAAF's > realm. > > 2. The HAR's Destination-Host is set to the value of the AMR's first > Route-Record AVP. This requires that no-one is hiding network topology by > removing Route-Record AVPs (per section 6.3 of base document). > > Bob K. --------------6B8CBD526B470E7EE1A6F3C7 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------6B8CBD526B470E7EE1A6F3C7-- From owner-aaa-wg@merit.edu Thu Sep 27 22:26: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 WAA18465 for ; Thu, 27 Sep 2001 22:26:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DE19912FC; Thu, 27 Sep 2001 22:27:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D5D2912FD; Thu, 27 Sep 2001 22:27: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 CA8F5912FC for ; Thu, 27 Sep 2001 22:27:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B238C5DDA6; Thu, 27 Sep 2001 22:27: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 2FC5C5DD94 for ; Thu, 27 Sep 2001 22:27:05 -0400 (EDT) Received: (qmail 1682 invoked by uid 500); 28 Sep 2001 02:12:14 -0000 Date: Thu, 27 Sep 2001 19:12:14 -0700 From: Pat Calhoun To: David Spence Cc: Bob Kopacz , AAA Working Group , Patrice Calhoun Subject: Re: [AAA-WG]: Question re: draft-mobileip-07 / 1.4 Allocation of HA in Foreign Network Message-ID: <20010927191214.B1499@charizard.diameter.org> Mail-Followup-To: David Spence , Bob Kopacz , AAA Working Group , Patrice Calhoun References: <3BB36C3B.7977CE80@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: <3BB36C3B.7977CE80@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Thu, Sep 27, 2001 at 02:13:15PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Pat, can you confirm that issue 95 remains resolved as documented, that is, > that section 6.3 has been deleted? > I checked -08 alpha 01, and it is in fact removed. PatC From owner-aaa-wg@merit.edu Fri Sep 28 08:42: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 IAA12528 for ; Fri, 28 Sep 2001 08:42:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C520F91214; Fri, 28 Sep 2001 08:43:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9717791217; Fri, 28 Sep 2001 08:43: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 7268A91214 for ; Fri, 28 Sep 2001 08:43:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53B5B5DDB6; Fri, 28 Sep 2001 08:43:14 -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 59C935DDA0 for ; Fri, 28 Sep 2001 08:43:13 -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 OAA15369 for ; Fri, 28 Sep 2001 14:42:53 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue: How to know when to use TLS Date: Fri, 28 Sep 2001 14:43:25 +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-09-28 Reference: Document: base Comment type: T Priority: 1 Section: Rationale/Explanation of issue: How should a peer know if the other side is runnig TLS or not? Requested change: One possible solution could be to add two new values to the transport attribute in the URI saying TLSoverTCP or TLSoverSCTP Another solution would be to add it as an configurable attribute to a peer. But maybe the URI solution is preferable. From owner-aaa-wg@merit.edu Fri Sep 28 14:24: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 OAA21742 for ; Fri, 28 Sep 2001 14:24:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5570991308; Fri, 28 Sep 2001 14:24:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24B8891309; Fri, 28 Sep 2001 14:24: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 14F7591308 for ; Fri, 28 Sep 2001 14:24:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E73CF5DE15; Fri, 28 Sep 2001 14:24:29 -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 D3C915DDFF for ; Fri, 28 Sep 2001 14:24:29 -0400 (EDT) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B4E5A79 for ; Fri, 28 Sep 2001 14:23:44 -0400 (EDT) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: DiameterIdentity / draft-ietf-aaa-diameter-08-alpha01 Date: Fri, 28 Sep 2001 14:21:24 -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, In the current Diameter base draft, the format of the DiameterIdentity is specified as Diameter-Identity = fqdn [ port ] [ transport ] [ protocol ] Some of the examples, though, indicate a scheme-name of "aaa://" or even "aaa://diameter/" preceding the fqdn. Is "aaa://" or "aaa://diameter/" still an optional legitimate part of the Diameter-identity, or is this a leftover from draft-06 that hasn't been cleaned up yet? Bob K. From owner-aaa-wg@merit.edu Fri Sep 28 17:38: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 RAA25391 for ; Fri, 28 Sep 2001 17:38:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3978A913A7; Fri, 28 Sep 2001 17:37:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 995D2913A8; Fri, 28 Sep 2001 17:37: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 596ED913A7 for ; Fri, 28 Sep 2001 17:36:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45AB35DE1F; Fri, 28 Sep 2001 17:36:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fridge.docomo-usa.com (unknown [216.98.102.228]) by segue.merit.edu (Postfix) with ESMTP id B84C85DDE3 for ; Fri, 28 Sep 2001 17:36:55 -0400 (EDT) Received: from geronimo2 (dhcp153.docomo-usa.com [172.21.96.153]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f8SLZXu12003; Fri, 28 Sep 2001 14:35:33 -0700 (PDT) From: "Alexander Hagen" To: , Cc: Subject: [AAA-WG]: What AAA mechanism for the Wireless WAN Date: Fri, 28 Sep 2001 14:36:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01C1482A.FC0FBA40" 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 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1482A.FC0FBA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I did not attend the BURP session at Minneapolis in March, but have carefully read Mr. Aboba's very thought provoking presentation on where to process AAA and encryption for the Wireless WAN. What then, in your view is to run on the Wireless IP client ?. Alexander Hagen Sr. Research Engineer Docomo Communications Laboratories, USA, Inc. ------=_NextPart_000_000C_01C1482A.FC0FBA40 Content-Type: text/x-vcard; name="W. Alexander Hagen.vcf" Content-Disposition: attachment; filename="W. Alexander Hagen.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Hagen;W.;Alexander FN:W. Alexander Hagen ORG:Docomo Communications Laboratories, USA, inc. TITLE:Senior Research Engineer TEL;WORK;VOICE:+1 408 451 4706 TEL;HOME;VOICE:650 728 5820 TEL;CELL;VOICE:+1 650 740 0650 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;181 Metro Drive=3D0D=3D0ASuite = 300;San Jose;CA;95110;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:181 Metro Drive=3D0D=3D0ASuite = 300=3D0D=3D0ASan Jose, CA 95110=3D0D=3D0AUnited States of=3D America EMAIL;PREF;INTERNET:ahagen@docomolabs-usa.com REV:20010910T193903Z END:VCARD ------=_NextPart_000_000C_01C1482A.FC0FBA40-- From owner-aaa-wg@merit.edu Fri Sep 28 23:32: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 XAA01866 for ; Fri, 28 Sep 2001 23:32:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D5AE91353; Fri, 28 Sep 2001 23:33:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C20C591357; Fri, 28 Sep 2001 23:33: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 F35B691353 for ; Fri, 28 Sep 2001 23:33:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D644D5DD9C; Fri, 28 Sep 2001 23:33: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 0C6515DD8F for ; Fri, 28 Sep 2001 23:33:33 -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 f8T3WT300932 for ; Sat, 29 Sep 2001 06:33:13 +0300 (EET DST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 29 Sep 2001 06:31:57 +0300 Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id ; Sat, 29 Sep 2001 06:31:57 +0300 Message-ID: <95A2D1413F29D311B3450008C7736289036EDC37@beeis03nok> From: qing.roger.liu@nokia.com To: pcalhoun@diameter.org Cc: aaa-wg@merit.edu Subject: [AAA-WG]: section 8.15 in Diameter draft (-08) alpha. Date: Sat, 29 Sep 2001 06:28:44 +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 In section 8.15(draft-ietf-aaa-diameter-08.txt): It seems DIAMETER_SESSION_TIMEOUT can be introduced as a new value in the scenario that . "OPEN Session-Timeout Expires on Access Device send STR Discon". roger -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Friday, September 28, 2001 1:26 AM To: haenamu@etri.re.kr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: when are the Diameter draft (-08) released? > I would like to know when the new Diameter drafts and(or) RFCs come out. Due to the number of requests, I've made alpha versions available at www.diameter.org/alpha. beware that I have not sanity checked these files, so the formatting may be off. When I have a little more time, I'll modify them. btw, I plan to submit the drafts once the issues stop coming in, and I have them resolved. PatC From owner-aaa-wg@merit.edu Sat Sep 29 12:24: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 MAA23125 for ; Sat, 29 Sep 2001 12:24:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF5AB9124E; Sat, 29 Sep 2001 12:25:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A91E391256; Sat, 29 Sep 2001 12:25: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 8A9EA9124E for ; Sat, 29 Sep 2001 12:25:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6632E5DE34; Sat, 29 Sep 2001 12:25:19 -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 E2BF15DD97 for ; Sat, 29 Sep 2001 12:25:18 -0400 (EDT) Received: from gwzpc (ams-vpdn-client-160.cisco.com [144.254.46.161]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA21564; Sat, 29 Sep 2001 09:16:16 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Subject: RE: [AAA-WG]: [issue] NAS-Session-Key and Session Master Keys Date: Sat, 29 Sep 2001 09:16:13 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > The NAS-Session-Key AVP, as currently specified, can only > be used to transport encryption and integrity keys. What makes you think that? > However, a IEEE 802.11 access point may need session > master keys from which it derives the actual encryption > and authentication keys. (This is not certain yet.) > > Requested change: > > 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). I think that that goes w/o out saying. > From owner-aaa-wg@merit.edu Sun Sep 30 11:15: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 LAA24489 for ; Sun, 30 Sep 2001 11:15:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C4729128B; Sun, 30 Sep 2001 11:15:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35D639128C; Sun, 30 Sep 2001 11:15: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 178B49128B for ; Sun, 30 Sep 2001 11:15:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D66B25DDBB; Sun, 30 Sep 2001 11:15:23 -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 4AD095DDB0 for ; Sun, 30 Sep 2001 11:15:23 -0400 (EDT) Received: (qmail 16350 invoked by uid 500); 30 Sep 2001 15:00:15 -0000 Date: Sun, 30 Sep 2001 08:00:15 -0700 From: Pat Calhoun To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: DiameterIdentity / draft-ietf-aaa-diameter-08-alpha01 Message-ID: <20010930080015.J16146@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 Fri, Sep 28, 2001 at 02:21:24PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk leftovers :( need to be cleaned up. PatC On Fri, Sep 28, 2001 at 02:21:24PM -0400, Bob Kopacz wrote: > Hi, > > In the current Diameter base draft, the format of the DiameterIdentity > is specified as > > Diameter-Identity = fqdn [ port ] [ transport ] [ protocol ] > > Some of the examples, though, indicate a scheme-name of "aaa://" or > even "aaa://diameter/" preceding the fqdn. > > Is "aaa://" or "aaa://diameter/" still an optional legitimate part of the > Diameter-identity, or is this a leftover from draft-06 that hasn't been > cleaned up yet? > > Bob K. > From owner-aaa-wg@merit.edu Sun Sep 30 17:22: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 RAA28098 for ; Sun, 30 Sep 2001 17:22:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 043E691207; Sun, 30 Sep 2001 17:23:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C441C91210; Sun, 30 Sep 2001 17:23: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 A5A5491207 for ; Sun, 30 Sep 2001 17:23:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76F3B5DDA8; Sun, 30 Sep 2001 17:23:07 -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 1BF8F5DD93 for ; Sun, 30 Sep 2001 17:23:07 -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 RAA27865 for ; Sun, 30 Sep 2001 17:15:56 -0400 Received: from mjones ([192.168.150.21]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA21211 for ; Sun, 30 Sep 2001 17:23:41 -0400 (EDT) From: "Mark Jones" To: "IETF AAA WG" Subject: [AAA-WG]: Questions on key generation in mobileip-08 Date: Sun, 30 Sep 2001 17:23:38 -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.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'd appreciate some clarification on the Key Distribution Center responsibilities in the -08 draft. The text in 5.x refers to the generation of Registration Keys. In the KDC AVP descriptions, there is no mention of registration keys but they do contain Session-Key AVPS. I'm assuming these are one and the same. If not, how does one generate the session key? How is the Foreign-Home Registration Key generated? Is it the same as the Mobile-Home and Mobile-Foreign Registration Keys (i.e. as per draft-ietf-mobileip-aaa-keys-08)? For a given AMR/HAR/HAA/AMA exchange, is the MIP-Key-Material in the MIP-MN-to-FA-Key AVP permitted to have the same value as that in the MIP-MN-to-HA-Key AVP or must they be different? Regards, Mark From owner-aaa-wg@merit.edu Sun Sep 30 22: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 WAA03694 for ; Sun, 30 Sep 2001 22:52:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D263591227; Sun, 30 Sep 2001 22:53:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C59C91233; Sun, 30 Sep 2001 22:53: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 5B2F891227 for ; Sun, 30 Sep 2001 22:53:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C23A5DDAA; Sun, 30 Sep 2001 22:52: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 CEF245DDA3 for ; Sun, 30 Sep 2001 22:52:40 -0400 (EDT) Received: (qmail 17313 invoked by uid 500); 1 Oct 2001 02:37:14 -0000 Date: Sun, 30 Sep 2001 19:37:14 -0700 From: Pat Calhoun To: Mark Jones Cc: IETF AAA WG Subject: Re: [AAA-WG]: Questions on key generation in mobileip-08 Message-ID: <20010930193714.A17298@charizard.diameter.org> Mail-Followup-To: Mark Jones , IETF 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 mjones@bridgewatersystems.com on Sun, Sep 30, 2001 at 05:23:38PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > The text in 5.x refers to the generation of Registration Keys. In the KDC > AVP descriptions, there is no mention of registration keys but they do > contain Session-Key AVPS. I'm assuming these are one and the same. If not, > how does one generate the session key? they are one and the same. > How is the Foreign-Home Registration Key generated? Is it the same as the > Mobile-Home and Mobile-Foreign Registration Keys (i.e. as per > draft-ietf-mobileip-aaa-keys-08)? MN-HA is a little different since key material is sent to the mobile node. However, the key received by the HA is the same as how the FA-HA keys are generated. > For a given AMR/HAR/HAA/AMA exchange, is the MIP-Key-Material in the > MIP-MN-to-FA-Key AVP permitted to have the same value as that in the > MIP-MN-to-HA-Key AVP or must they be different? aaa-keys spec states that the keys are dynamically generated, each using a different random value. PatC