From owner-aaa-wg@merit.edu Wed Aug 1 06:25: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 SMTP id GAA25696 for ; Wed, 1 Aug 2001 06:25:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D83C91294; Wed, 1 Aug 2001 06:25:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B37091295; Wed, 1 Aug 2001 06:25: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 267E591294 for ; Wed, 1 Aug 2001 06:25:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDF675DDA9; Wed, 1 Aug 2001 06:25:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 9CC105DDA8 for ; Wed, 1 Aug 2001 06:25:44 -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 MAA07333; Wed, 1 Aug 2001 12:27:09 +0200 From: "Fredrik Johansson" To: "AAA Listan" Cc: Subject: [AAA-WG]: Issue: MIPv4 comments Date: Wed, 1 Aug 2001 12:27:04 +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: Aug 1th, 2001 Reference: N/A Document: draft-ietf-aaa-diameter-mobileip-07.txt Comment type: E Priority: S Section: Rationale/Explanation of issue: Hi, here's a few editorial comments from my first glance at this version of the draft. some of the has probably showed up before, sorry about that. /Fredrik Section 1.4 "Figure 7 shows the message flows for a Mobile Node requesting to keep the Home Agent assigned in Foreign network 1 when it moves to foreign network 2. Upon reception of the AMR in Foreign network 2, the AAAF follows the procedures described earlier and forwards AMR to the Mobile Node's home network, i.e. its AAAH. If the Mobile Node was successfully authenticated the AAAH checks for the Origin-Host and the MIP-Previous-FA-Host AVPs. If a AAAH deduces that the Mobile Node has moved to a new domain, it must check whether the Mobile can still use the previously assigned Home Agent." The MIP-Previous-FA-Hoast AVP doesn't exist anymore. Remove it and perhaps indicate that in order to determine if a mobile has moved the Origin-Host need to be compared to the Origin-Host received in the previous request (AMR). Or even better, it will look for the Origin-Realm AVP and compare it to the Origin-Realm AVP received in the previous request to determine if the Mobile Node has moved to a new domain. Section 2.1 "If the MIP-Previous-FA-Host AVP is found in the request, the Diameter client requests that the server return the registration key that was assigned to the previous Foreign Agent for use with the Mobile Node and Home Agent. The registration key is identified through the use of the User-Name AVP." Remove the whole paragraph, and also the MIP-Previous-XXXX AVPs from the abnf code. Section 2.2 and 2.4 Remove the Destination-Host AVP from the abnf Section 4.0 Remove the MIP-Previous-XXXX AVPs from the table Section 5.0 "AAA support for key distribution departs slightly from the existing SPI usage, as described in [4]. The SPI values are used as key identifiers, meaning that each registration key has its own SPI value; nodes that share a key also share an SPI. The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home authentication extensions, via the Mobile IP AAA Key Request extensions [15], while the Home Agent allocates the Mobile-Foreign, Mobile-Home and Foreign-Home SPIs." Does the SPI usage really depart from the one used in mobile ip? Section 6.5 Is the MIP-Replay-Mode really needed between the Mn and the FA? Section 6.x Do we need to change this chapter to not refer to Session Key but to the Key Material that is used instead? Section 8.1 The Destination-Host should have 0 on AMA and HAA in the table. remove MIP-Previous-FA-XXXX from the table From owner-aaa-wg@merit.edu Wed Aug 1 09:11: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 SMTP id JAA01323 for ; Wed, 1 Aug 2001 09:11:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D51191235; Wed, 1 Aug 2001 09:12:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3729291265; Wed, 1 Aug 2001 09:12: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 28D3A91235 for ; Wed, 1 Aug 2001 09:12:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0AD8D5DDAD; Wed, 1 Aug 2001 09:12: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 44FB95DD8C for ; Wed, 1 Aug 2001 09:12:22 -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 f71DCBO20111; Wed, 1 Aug 2001 15:12:11 +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 f71DCA512600; Wed, 1 Aug 2001 16:12:10 +0300 (EET DST) Message-ID: <3B68002A.F8E326CE@lmf.ericsson.se> Date: Wed, 01 Aug 2001 16:12:10 +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: "Guillermo Guardia-Lozano (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Accounting questions References: <3DFC2DB418B2D211A1950008C7A4E1EA611FC4@eestqnt102> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi. This is a response to an old mail. (I don't seem to find an answer from anybody yet from archives. I apologize is this has already been discussed at length...) Seems that some errors still remain in the current draft on these issues. The comments can be found near the end. "Guillermo Guardia-Lozano (ECE)" wrote: > After reading the base draft I have several > question regarding "Accounting" and maybe > somebody in the list can clarify them. First I > have included the parts of the document that > all together lead me to confusion and, at the end, my questions. > Thanks in advance. > > Chapter 10.0 > When a service only makes use of the Accounting portion of the > Diameter protocol, even in combination with an application, the > Session-Id is still used to identify user sessions. However, the > session termination messages are not used, since a session is > signaled as being terminated by issuing an accounting stop message. > > Chapter 11.5 > A particular value of Accounting-Session-Id MUST appear only in one > sequence of accounting records from a DIAMETER client, except for the > purposes of retransmission. The one sequence that is sent MUST be > either one record with Accounting-Record-Type AVP set to the value > EVENT_RECORD, or several records starting with one having the value > START_RECORD, followed by zero or more INTERIM_RECORD, and a single > STOP_RECORD. > > Chapter 11.6 > However, there are certain applications that require multiple > accounting sub-sessions. Such applications would send messages with a > constant Session-Id AVP, but a different Accounting-Session-Id AVP. > > Chapter 13.3 > The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 > and identifies this record within one session. As Session-Id AVPs are > globally unique, the combination of Session-Id and Accounting- > Record-Number AVPs is also globally unique, and can be used in > matching accounting records with confirmations. An easy way to > produce unique numbers is to set the value to 0 for records of type > EVENT_RECORD and START_RECORD, and set the value to 1 for the first > INTERIM_RECORD, 2 for the second, and so on until the value for > STOP_RECORD is one more than for the last INTERIM_RECORD. > > Chapter 13.4 > The Accounting-Session-Id AVP (AVP Code 44) is of type UTF8String, > following the format specified in section 10.7. The Accounting- > Session-Id is not used by the Diameter protocol, since the Session-Id > defined in [1] is used for both authentication/authorization and > accounting purposes. > > Q1- > If the service only makes use of the Accounting portion, but besides, > it requires multiple accounting sub-sessions ( constant Session-Id but > a different Accounting-Session-Id ), how is this session signaled as > being terminated ? It seems that we can't do it in the current spec. Is this needed? If you have some resources to release, you should propably be using other Diameter portions as well. If you don't have resources to release, you might just rely on the fact that since you didn't receive an accounting information any more there are no further sessions. The specific application that produces the sessions and subsessions might also specify something about how to determine the true end. Possibly separate termination cause values might be used. In fact, the latter is perhaps what I would recommend. If an application produces subsessions, it should have some sort of an AVP that defines why the subsession ended, and that could take on values such as 1 - user moved from this base station to another 2 - user terminated the whole call Comments? > Is still applicable the "Accounting Session State Machine" in chapter 10.2 ? > > Q2- > Are Accounting-Record-Numbers unique within the session ( Session-Id ) > or unique within the accounting sub-session (Accounting-Session-Id ) ? The current text doesn't specify this clearly. I would propose that the record numbers keep increasing, i.e. subsessions don't reuse record numbers. > Q3- > In the message format of and > the Accounting-Session-Id AVP appears as mandatory, but the AVP description > (chapter 13.4 ) says : "The Accounting-Session-Id is not used by the Diameter > protocol, since ...." > Is it coherent ? No! Section 9.8.4 states that Accounting-Session-Id is only used for RADIUS compatibility. Section 9.6 reuses this also for sub-sessions. Yet we mandate it in the acct-req and acct-ans commands. Furthermore, we are skipping the Accounting-Multi-Session-Id from the ABNF. Here's a suggested 'issue' submission for the above problems: Subsession accounting unclarities Submitter name: Guillermo Guardia-Lozano / Jari Arkko Submitter email address: Jari.Arkko@ericsson.com Date first submitted: July 6, 2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-07/msg00010.html Document: base Comment type: T Priority: 1 Section: 9 Rationale/Explanation of issue: 1) Unclear about when the whole session ends for an application that uses only Diameter accounting, and has subsessions 2) Unclear about when record numbers reset for subsessions 3) Unclear about Accounting-Session-Id and Accounting-Multi-Session-Id mandatory/optional status in the ABNF Requested change: 1) Add the following text after the second paragraph of 9.6: "All applications that use the subsession accounting in DIAMETER MUST specify how the accounting server knows when the whole session has ended. Typically, this can take place through the reception of a special value in an AVP that describes the termination cause of the subsession." 2) Add the following text to the end of 9.8.3: "In case the session consists of several subsessions, the values is not reset for new subsessions." 3) Make Accounting-Session-Id optional in the ABNF, add Accounting-Multi-Session-Id to the ABNF, and mention in 9.8.4 the use of Accounting-Session-Id also for subsessions. /Jari From owner-aaa-wg@merit.edu Wed Aug 1 11:25: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 SMTP id LAA14925 for ; Wed, 1 Aug 2001 11:25:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF64F91206; Wed, 1 Aug 2001 11:26:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B16AC91208; Wed, 1 Aug 2001 11:26:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 869FB91206 for ; Wed, 1 Aug 2001 11:26:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D6ED5DDAD; Wed, 1 Aug 2001 11:26:21 -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 D6BA25DDA8 for ; Wed, 1 Aug 2001 11:26:20 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f71FNjx05156 for ; Wed, 1 Aug 2001 11:23:45 -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 xma005153; Wed, 1 Aug 01 11:23:23 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f71FPvi01265 for ; Wed, 1 Aug 2001 11:25:57 -0400 (EDT) Received: from (ticsmtp2.innovation.siemens.ca [172.21.24.160]) by mailman via smap (V2.1) id xma000899; Wed, 1 Aug 01 11:23:55 -0400 Received: by ticsmtp2.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Aug 2001 11:23:54 -0400 Message-ID: <53D69AD06EFAD311842300A0C99B4F08C7D035@ticsmtp2.innovation.siemens.ca> From: Lucius Schmid To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: More editorial comments on base-07 Date: Wed, 1 Aug 2001 11:23:52 -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: Lucius Schmid Submitter email address: lucius.schmid@innovation.siemens.ca Date first submitted: Aug. 1. 2001 Reference: N/A Document: base Comment type: E Priority: 1 Section: 5.6 Rationale/Explanation of issue: Hi, since there are Disconnect-Peer-x (DPR/DPA) commands codes I suggested to change the event name "Peer-Disc" to "Rcv-DPR" and the action name from "Disc" to "Snd-DPA". Requested change: pages 58/59, section 5.6: the peer state machine table replace all "x-Peer-Disc" with "x-Rcv-DPR" and "x-Disc" with "x-Snd-DPA" page 60, section 5.6.2: Events replace "Peer-Disc" with "Rcv-DPR" (explanation remains) page 61, section 5.6.3: Actions replace "Disc" with "Snd-DPA" (explanation remains) cheers Lucius From owner-aaa-wg@merit.edu Wed Aug 1 15:45: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 SMTP id PAA00661 for ; Wed, 1 Aug 2001 15:45:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C32E91297; Wed, 1 Aug 2001 15:45:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B84BF912A6; Wed, 1 Aug 2001 15:45:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A190491297 for ; Wed, 1 Aug 2001 15:45:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 434A15DDAF; Wed, 1 Aug 2001 15:45:08 -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 C8ABB5DDA9 for ; Wed, 1 Aug 2001 15:45:07 -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 f71Jj7505165 for ; Wed, 1 Aug 2001 14:45:07 -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 f71Jj6P28421 for ; Wed, 1 Aug 2001 14:45: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 OAA14490 for ; Wed, 1 Aug 2001 14:45:06 -0500 (CDT) Received: from ericsson.com ([138.85.159.113]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA00846 for ; Wed, 1 Aug 2001 14:45:03 -0500 (CDT) Message-ID: <3B685ABC.69B2370F@ericsson.com> Date: Wed, 01 Aug 2001 12:38:36 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Key disrtibutions in NASREQ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, With NASREQ, if you want to encrypt the keys destined for the client, how is that supposed to be done? Unless I have missed something, there isn't anything describing how this should be done in the NASERQ application draft. The only thing I found is how to encrypt the key between the Diameter Server (AAAH) and the access device (ie NAS), which was simply to use the CMS Security application, but nothing about how to encrypt the key between the AAAH and the client. I will go ahead and submit an issue if this is missing... /Tony From owner-aaa-wg@merit.edu Wed Aug 1 17:00:50 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04944 for ; Wed, 1 Aug 2001 17:00:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49DAC912AC; Wed, 1 Aug 2001 17:00:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1F67912AF; Wed, 1 Aug 2001 17:00: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 39DE3912AC for ; Wed, 1 Aug 2001 17:00:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 00BB65DDAF; Wed, 1 Aug 2001 17:00:18 -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 B92945DD8C for ; Wed, 1 Aug 2001 17:00:16 -0400 (EDT) Received: (qmail 11958 invoked by uid 500); 1 Aug 2001 20:49:17 -0000 Date: Wed, 1 Aug 2001 13:49:17 -0700 From: Pat Calhoun To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Key disrtibutions in NASREQ... Message-ID: <20010801134917.E8990@charizard.diameter.org> Mail-Followup-To: Tony Johansson , aaa-wg@merit.edu References: <3B685ABC.69B2370F@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B685ABC.69B2370F@ericsson.com>; from tony.johansson@ericsson.com on Wed, Aug 01, 2001 at 12:38:36PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Since clients don't speak "Diameter", presumably the AAAH, which is participating in the EAP exchange, would send the keys to the user via an EAP message. No issue is missing. PatC On Wed, Aug 01, 2001 at 12:38:36PM -0700, Tony Johansson wrote: > All, > > With NASREQ, if you want to encrypt the keys destined for the client, > how is that supposed to be done? Unless I have missed something, there > isn't anything describing how this should be done in the NASERQ > application draft. The only thing I found is how to encrypt the key > between the Diameter Server (AAAH) and the access device (ie NAS), which > was simply to use the CMS Security application, but nothing about how to > encrypt the key between the AAAH and the client. I will go ahead and > submit an issue if this is missing... > > /Tony > From owner-aaa-wg@merit.edu Thu Aug 2 18:14:57 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25996 for ; Thu, 2 Aug 2001 18:14:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21D2B91302; Thu, 2 Aug 2001 18:12:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D69D29133F; Thu, 2 Aug 2001 18:12: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 C0CF991302 for ; Thu, 2 Aug 2001 18:12:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A67E95DDC9; Thu, 2 Aug 2001 18:12:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 38E465DDB8 for ; Thu, 2 Aug 2001 18:12:43 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f72MCYi19890 for ; Thu, 2 Aug 2001 17:12:46 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 2 Aug 2001 17:12:15 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Aug 2001 17:12:15 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Key disrtibutions in NASREQ... Date: Thu, 2 Aug 2001 17:12:14 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4408618F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Key disrtibutions in NASREQ... X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEazSmCQbywWobAEdWJUgAIx6TWpQA0tuDw From: To: , Cc: , X-OriginalArrivalTime: 02 Aug 2001 22:12:15.0117 (UTC) FILETIME=[2FA563D0:01C11BA0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA25996 Clients may speak URP. And the keys from AAAH may be delivered to the user via URP messaging. -Basavaraj > > Since clients don't speak "Diameter", presumably the AAAH, which is > participating in the EAP exchange, would send the keys to the user via > an EAP message. > > No issue is missing. > > PatC > On Wed, Aug 01, 2001 at 12:38:36PM -0700, Tony Johansson wrote: > > All, > > > > With NASREQ, if you want to encrypt the keys destined for > the client, > > how is that supposed to be done? Unless I have missed > something, there > > isn't anything describing how this should be done in the NASERQ > > application draft. The only thing I found is how to encrypt the key > > between the Diameter Server (AAAH) and the access device > (ie NAS), which > > was simply to use the CMS Security application, but nothing > about how to > > encrypt the key between the AAAH and the client. I will go ahead and > > submit an issue if this is missing... > > > > /Tony > > > From owner-aaa-wg@merit.edu Thu Aug 2 18:34:24 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27277 for ; Thu, 2 Aug 2001 18:34:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5051E9130C; Thu, 2 Aug 2001 18:33:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46010912FD; Thu, 2 Aug 2001 18:33:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53D0E91305 for ; Thu, 2 Aug 2001 18:31:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 364625DDC9; Thu, 2 Aug 2001 18:31: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 140F25DDB8 for ; Thu, 2 Aug 2001 18:31:48 -0400 (EDT) Received: (qmail 20682 invoked by uid 500); 2 Aug 2001 22:20:46 -0000 Date: Thu, 2 Aug 2001 15:20:46 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 97 Message-ID: <20010802152046.I20321@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, Issue 97 recommends that an approach be adopted that allows for the path to a home server be static for a given session. The proposal is to introduce a new AVP, but I believe that the Source-Route AVP would work just as well. Do folks disagree with this feature? My personal inclination is not to adopt it, but of course I will listen to WG consensus. PatC From owner-aaa-wg@merit.edu Thu Aug 2 19:37: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 SMTP id TAA01329 for ; Thu, 2 Aug 2001 19:37:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 249BE9123E; Thu, 2 Aug 2001 19:38:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEAE791305; Thu, 2 Aug 2001 19:38:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC7A69123E for ; Thu, 2 Aug 2001 19:38:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 695245DDF1; Thu, 2 Aug 2001 19:38:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B85F95DDCC for ; Thu, 2 Aug 2001 19:38:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA93534; Thu, 2 Aug 2001 16:28:13 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 2 Aug 2001 16:28:13 -0700 (PDT) From: Bernard Aboba To: Basavaraj.Patil@nokia.com Cc: pcalhoun@diameter.org, tony.johansson@ericsson.com, aaa-wg@merit.edu, urp@research.telcordia.com Subject: RE: [AAA-WG]: Key disrtibutions in NASREQ... In-Reply-To: <697DAA22C5004B4596E033803A7CEF4408618F@daebe007.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Clients may speak URP. And the keys from AAAH may be delivered > to the user via URP messaging. > So does DIAMETER require URP support? From owner-aaa-wg@merit.edu Thu Aug 2 19: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 SMTP id TAA01488 for ; Thu, 2 Aug 2001 19:40:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 970A991305; Thu, 2 Aug 2001 19:41:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6682891306; Thu, 2 Aug 2001 19:41: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 4C72B91305 for ; Thu, 2 Aug 2001 19:41:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2AC765DDF1; Thu, 2 Aug 2001 19:41:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id CAB3E5DDCC for ; Thu, 2 Aug 2001 19:41:12 -0400 (EDT) Received: (qmail 20932 invoked by uid 500); 2 Aug 2001 23:30:11 -0000 Date: Thu, 2 Aug 2001 16:30:11 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Basavaraj.Patil@nokia.com, pcalhoun@diameter.org, tony.johansson@ericsson.com, aaa-wg@merit.edu, urp@research.telcordia.com Subject: Re: [AAA-WG]: Key disrtibutions in NASREQ... Message-ID: <20010802163011.P20321@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Basavaraj.Patil@nokia.com, pcalhoun@diameter.org, tony.johansson@ericsson.com, aaa-wg@merit.edu, urp@research.telcordia.com References: <697DAA22C5004B4596E033803A7CEF4408618F@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Thu, Aug 02, 2001 at 04:28:13PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Aug 02, 2001 at 04:28:13PM -0700, Bernard Aboba wrote: > > Clients may speak URP. And the keys from AAAH may be delivered > > to the user via URP messaging. > > > So does DIAMETER require URP support? no. PatC From owner-aaa-wg@merit.edu Thu Aug 2 19:59:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02313 for ; Thu, 2 Aug 2001 19:59:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A177A91308; Thu, 2 Aug 2001 19:46:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D29A69131F; Thu, 2 Aug 2001 19:46: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 7DE6F91308 for ; Thu, 2 Aug 2001 19:46:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 339E15DDFC; Thu, 2 Aug 2001 19:46:22 -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 2A86E5DDFF for ; Thu, 2 Aug 2001 19:46:21 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f72NkK504105 for ; Thu, 2 Aug 2001 18:46:20 -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 f72NkKP16090 for ; Thu, 2 Aug 2001 18:46:20 -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 SAA18208 for ; Thu, 2 Aug 2001 18:46:19 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id SAA15512 for ; Thu, 2 Aug 2001 18:46:15 -0500 (CDT) Message-ID: <003801c11bad$33bcd4f0$869f558a@berkeley.us.am.ericsson.se> From: "Kevin Purser" To: References: <20010802152046.I20321@charizard.diameter.org> Subject: [AAA-WG]: Issue: Inconsistencies in NASREQ AVP tables Date: Thu, 2 Aug 2001 16:45:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Inconsistencies in NASREQ AVP tables Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: August 2, 2001 Reference: none Document: NASREQ-07 Comment type: 'E'ditorial Priority: 'S' Must fix Section: 10.1 Rationale/Explanation of issue: The following AVPs are listed as being mandatory, while the corresponding ABNF definitions (sections 3.1 and 4.2) do not mandate them: Attribute Name | AAR | AAA | DER | DEA | ------------------------------|-----+-----+-----+-----| Destination-Realm | 0 | 1 | 1 | 0 | EAP-Payload | 0 | 0 | 1 | 1 | NAS-IP-Address | 1 | 0 | 1 | 0 | NAS-Port | 1 | 0 | 1 | 0 | Requested change: According to the ABNF definitions, they should be: Attribute Name | AAR | AAA | DER | DEA | ------------------------------|-----+-----+-----+-----| Destination-Realm | 0 | 0 | 1 | 0 | EAP-Payload | 0 | 0 | 1 | 0 | NAS-IP-Address | 0 | 0 | 0 | 0 | NAS-Port | 0 | 0 | 0 | 0 | -Kev ================================= Kevin Purser, Software Engineer Ericsson, Inc. --------------------------------------------- 2100 Shattuck Ave. Berkeley, CA 94704 Phone (510) 305-6100 ================================= From owner-aaa-wg@merit.edu Thu Aug 2 19:59:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02345 for ; Thu, 2 Aug 2001 19:59:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E7969123F; Thu, 2 Aug 2001 20:00:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CE7291309; Thu, 2 Aug 2001 20:00:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9FE69123F for ; Thu, 2 Aug 2001 19:59:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BED745DDF1; Thu, 2 Aug 2001 19:59:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id EE6975DDCC for ; Thu, 2 Aug 2001 19:59:46 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f72NxOi04223 for ; Thu, 2 Aug 2001 18:59:50 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 2 Aug 2001 18:58:55 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Aug 2001 18:58:55 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Key disrtibutions in NASREQ... Date: Thu, 2 Aug 2001 18:58:54 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44086195@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Key disrtibutions in NASREQ... X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEbrDjSaFJgXoeXEdWpVgBQi2kYTQAAr2+A From: To: Cc: , , , X-OriginalArrivalTime: 02 Aug 2001 23:58:55.0341 (UTC) FILETIME=[167A11D0:01C11BAF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA02345 > > > Clients may speak URP. And the keys from AAAH may be delivered > > to the user via URP messaging. > > > So does DIAMETER require URP support? > No. URP interacts with Diameter/AAA infra in the network. -Basavaraj From owner-aaa-wg@merit.edu Fri Aug 3 03:44: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 SMTP id DAA08307 for ; Fri, 3 Aug 2001 03:44:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEC8091330; Fri, 3 Aug 2001 03:38:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FE1691337; Fri, 3 Aug 2001 03:38:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3354091330 for ; Fri, 3 Aug 2001 03:37:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A1DC5DE02; Fri, 3 Aug 2001 03:37: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 495A75DE00 for ; Fri, 3 Aug 2001 03:37:55 -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 f737bsO26992 for ; Fri, 3 Aug 2001 09:37:54 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Aug 03 09:37:52 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 09:37:51 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA26@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , aaa-wg@merit.edu Cc: "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Issue 97 Date: Fri, 3 Aug 2001 09:37: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 If it is not adopted, will you get rid of the Source-Route AVP, in order to come back to the original proposal of -06? Would that mean that we would not adopt the proposal of not removing the Route-Record AVPs, while an answer is going through proxies towards the client? I would prefer removing them, just as before. I find the proposed solution for keeping static path interesting, but unnecessarily complex for what we need. I preferred much more the routing scheme of -06. That's my opinion. Regards, Martin > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Friday, August 03, 2001 12:21 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 97 > > > All, > > Issue 97 recommends that an approach be adopted that allows for the > path to a home server be static for a given session. The proposal is > to introduce a new AVP, but I believe that the Source-Route AVP would > work just as well. > > Do folks disagree with this feature? > > My personal inclination is not to adopt it, but of course I > will listen > to WG consensus. > > PatC > From owner-aaa-wg@merit.edu Fri Aug 3 06:06: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 SMTP id GAA11765 for ; Fri, 3 Aug 2001 06:06:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88B2591331; Fri, 3 Aug 2001 06:06:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53F5091332; Fri, 3 Aug 2001 06:06: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 1786591331 for ; Fri, 3 Aug 2001 06:06:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D41115DDDA; Fri, 3 Aug 2001 06:06:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 508BD5DDCD for ; Fri, 3 Aug 2001 06:06:34 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f73A6m310252 for ; Fri, 3 Aug 2001 13:06:48 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 3 Aug 2001 13:06:27 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVLPZS>; Fri, 3 Aug 2001 13:06:27 +0300 Message-ID: <9E3407CE45911B4097632389B77B20231077FA@esebe014.NOE.Nokia.com> From: Adrian.Constantin@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Questions and comments to Base-07 Date: Fri, 3 Aug 2001 13:06:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi! I have some comments to the base protocol draft 07. Could you, please, clarify these things? PEER STATE MACHINE In section 5.3 some scenarios presenting an unsuccessful peer connection establishment are presented, but they are not reflected in the peer state machine (5.6). It seems to me clearer if the state machine includes the cases when the peer connection is refused. The race condition mentioned in 5.4 could also lead to scenarios like the one bellow: Peer1 Peer2 | | | CER | |------------------------>| | | | /| | Request MSG / | |<---------------------/--| | / | | CEA / | |<------------------- | | | In this case the request message receives no answer and a deadlock can appear at Peer1. How can this be prevented? FAILOVER In case of failure the requests pending are resent to an alternate peer. In my understanding the duplicate must contain the same end-to-end and hop-by-hop identifier as the original message. Is this interpretation correct? In case of duplicate messages, the only messages discarded are the duplicated answers meant for local processing (3.0). The servers answering to a duplicate request will set different end-to-end identifier for the two answers. In this case, which scenario could lead to the receiving of a duplicate reply (with the same end-to-end id and same origin host)? MESSAGE PROCESSING PeerA PeerB | | | Request 1 | |------------------------>| | Request 2 | |------------------------>| | | | DPR | |------------------------>| (PeerB still processing Requests 1,2) | | In the scenario above is it mandatory for PeerB to send Answers 1,2 before DPA or is it implementation dependent? Regards, Adrian Constantin ------------------------------ Adrian Constantin Software Engineer Nokia Networks, IP Mobility Networks Takomotie 1/1b22, 00380 Helsinki, Finland Phone +358 718061689 Mobile +358 40 8386127 Fax. +358 9 51168770 From owner-aaa-wg@merit.edu Fri Aug 3 09:51: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 SMTP id JAA16130 for ; Fri, 3 Aug 2001 09:51:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A8479133B; Fri, 3 Aug 2001 09:52:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7E999133C; Fri, 3 Aug 2001 09:52: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 9F4679133B for ; Fri, 3 Aug 2001 09:52:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 700055DE04; Fri, 3 Aug 2001 09:52:33 -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 4E2965DDFC for ; Fri, 3 Aug 2001 09:52:32 -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 f73DqVN17753 for ; Fri, 3 Aug 2001 15:52:31 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Aug 03 15:52:30 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 15:52:29 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA29@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "Jari Arkko (LMF)" , "Guillermo Guardia-Lozano (ECE)" Cc: "'aaa-wg@merit.edu'" , "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Accounting questions Date: Fri, 3 Aug 2001 15:52:22 +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 See comments. Martin > > Q1- > > If the service only makes use of the Accounting portion, > but besides, > > it requires multiple accounting sub-sessions ( constant > Session-Id but > > a different Accounting-Session-Id ), how is this session signaled as > > being terminated ? > > It seems that we can't do it in the current spec. Is this needed? > If you have some resources to release, you should propably be > using other Diameter portions as well. If you don't have resources > to release, you might just rely on the fact that since you didn't > receive an accounting information any more there are no further > sessions. The specific application that produces the sessions > and subsessions might also specify something about how to determine > the true end. Possibly separate termination cause values might > be used. In fact, the latter is perhaps what I would recommend. > If an application produces subsessions, it should have some > sort of an AVP that defines why the subsession ended, and that > could take on values such as > > 1 - user moved from this base station to another > 2 - user terminated the whole call > > Comments? Each accounting message must contain a session-id. Furthermore, it may contain an accounting-session-id, which is used to identify subsessions within that accounting session. Each subsession MUST be considered independent, which means that they each have a termination condition, which is a STOP message for each subsession. That means that each accounting subsession should remain active until it receives a STOP message. That's the normal case. So, the following text should be added: "Each accounting message must contain a session-id, which basically identifies an accounting session on the accounting server. Furthermore, it may contain an accounting-session-id, which would be used to identify a subsession within that accounting session. Each subsession MUST be considered independent of each other, within the same session-id. An accounting message that would define only a session-id, without an Accounting-session-id AVP, MUST be considered by the accounting server as being an accounting-session-id of 0. All applications that use the accounting subsessions in Diameter MUST communicate their termination conditions to the accounting server through the means of an accounting message, indicating either an EVENT_RECORD or a STOP_RECORD in the Accounting-Record-Type AVP." The question that Guillermo had was more related to the fact that once an Accounting session is started, it seems impossible to close the accounting session unless we receive an accounting stop, at least according to the Accounting session state-machine (section 8.2). What should we count on for closing the accounting session, in fact an accounting subsession, in the case that we never receive any more messages, and obviously not a STOP? > > Is still applicable the "Accounting Session State Machine" > in chapter 10.2 ? > > > > Q2- > > Are Accounting-Record-Numbers unique within the session ( > Session-Id ) > > or unique within the accounting sub-session > (Accounting-Session-Id ) ? > > The current text doesn't specify this clearly. I would propose that > the record numbers keep increasing, i.e. subsessions don't > reuse record > numbers. I would appreciate if you could make very clear in the draft, that a client MUST send accounting messages using an increasing Record-number. It must be stated in the draft, that record-numbers of subsequent accounting messages must be incremental. That means that when a client sends an accounting message to an accounting server, it MUST keep on incrementing the record number for each accounting message sent for a particular accounting session. That implies that an accounting server MUST consider the accounting message for a particular accounting subsession as containing the latest valid accounting data, based on the highest Record-number received. For example, let's say an accounting server has received accounting messages so that it has 2 accounting-session-id for the same session-id. That would mean that 2 accounting subsessions are active for that session-id. In that case, the client MUST keep on increasing the record-number between all messages sent to the accounting server for that session-id. So, in the accounting server, each subsession would hand up receiving several accounting message, for which the only check that is required in the accounting server would be that the last accounting data stored has a record-number lower than the latest received. Otherwise, it should not be overwriting the existing data, since the accounting data is made of cumulative data. > Here's a suggested 'issue' submission for the above problems: > > Subsession accounting unclarities > Submitter name: Guillermo Guardia-Lozano / Jari Arkko > Submitter email address: Jari.Arkko@ericsson.com > Date first submitted: July 6, 2001 > Reference: > http://www.merit.edu/mail.archives/aaa-wg/2001-07/msg00010.htm l Document: base Comment type: T Priority: 1 Section: 9 Rationale/Explanation of issue: 1) Unclear about when the whole session ends for an application that uses only Diameter accounting, and has subsessions 2) Unclear about when record numbers reset for subsessions 3) Unclear about Accounting-Session-Id and Accounting-Multi-Session-Id mandatory/optional status in the ABNF Requested change: 1) Add the following text after the second paragraph of 9.6: "Each accounting message must contain a session-id, which basically identifies an accounting session on the accounting server. Furthermore, it may contain an accounting-session-id, which would be used to identify a subsession within that accounting session. An accounting message that would define only a session-id, without an Accounting-session-id AVP, MUST be considered by the accounting server as being an accounting-session-id of 0. All applications that use the accounting subsessions in Diameter MUST communicate their termination conditions to the accounting server through the means of an accounting message, indicating either an EVENT_RECORD or a STOP_RECORD in the Accounting-Record-Type AVP. Each subsession MUST be considered independent of each other, within the same session-id." 2) Add the following text to the end of 9.8.3: "Record-numbers of subsequent accounting messages must be incremental. That means that when a client sends an accounting message to an accounting server, it MUST keep on incrementing the record number for each accounting message sent for a particular accounting session. That implies that an accounting server MUST consider the accounting message for a particular accounting subsession as containing the latest valid accounting data, based on the highest Record-number received." For example, let's say an accounting server has received accounting messages so that it has 2 accounting-session-id for the same session-id. That would mean that 2 accounting subsessions are active for that session-id. In that case, the client MUST keep on increasing the record-number between all messages sent to the accounting server for that session-id. So, in the accounting server, each subsession would hand up receiving several accounting message, for which the only check that is required in the accounting server would be that the last accounting data stored has a record-number lower than the latest received. Otherwise, it should not be overwriting the existing data, since the accounting data is made of cumulative data. 3) Make Accounting-Session-Id optional in the ABNF, add Accounting-Multi-Session-Id to the ABNF, and mention in 9.8.4 the use of Accounting-Session-Id also for subsessions. /Jari From owner-aaa-wg@merit.edu Fri Aug 3 09:56:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16195 for ; Fri, 3 Aug 2001 09:56:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B2B39133D; Fri, 3 Aug 2001 09:57:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 587559133E; Fri, 3 Aug 2001 09:57:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3053F9133D for ; Fri, 3 Aug 2001 09:57:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 151E85DE04; Fri, 3 Aug 2001 09:57:00 -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 B13955DDFC for ; Fri, 3 Aug 2001 09:56:59 -0400 (EDT) Received: (qmail 27679 invoked by uid 500); 3 Aug 2001 13:45:57 -0000 Date: Fri, 3 Aug 2001 06:45:57 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 97 Message-ID: <20010803064557.B27662@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA26@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: <577066326047D41180AC00508B955DDA04D1AA26@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Fri, Aug 03, 2001 at 09:37:52AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk ok, let's discuss this in London. I agree with you completely, but there were other folks that didn't. THe problem is no one disagreed on the list when I asked, so it ended up in -07. PatC On Fri, Aug 03, 2001 at 09:37:52AM +0200, Martin Julien (ECE) wrote: > If it is not adopted, will you get rid of the Source-Route AVP, > in order to come back to the original proposal of -06? > Would that mean that we would not adopt the proposal of > not removing the Route-Record AVPs, while an answer is > going through proxies towards the client? I would prefer > removing them, just as before. > > I find the proposed solution for keeping static path interesting, > but unnecessarily complex for what we need. I preferred much > more the routing scheme of -06. That's my opinion. > > Regards, > Martin > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Friday, August 03, 2001 12:21 AM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Issue 97 > > > > > > All, > > > > Issue 97 recommends that an approach be adopted that allows for the > > path to a home server be static for a given session. The proposal is > > to introduce a new AVP, but I believe that the Source-Route AVP would > > work just as well. > > > > Do folks disagree with this feature? > > > > My personal inclination is not to adopt it, but of course I > > will listen > > to WG consensus. > > > > PatC > > From owner-aaa-wg@merit.edu Fri Aug 3 13:32:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22385 for ; Fri, 3 Aug 2001 13:32:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEFD39134A; Fri, 3 Aug 2001 13:32:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 904D49134D; Fri, 3 Aug 2001 13:32: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 C1BFC9134A for ; Fri, 3 Aug 2001 13:32:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D9C45DDD4; Fri, 3 Aug 2001 13:32:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 24EC05DDB3 for ; Fri, 3 Aug 2001 13:32:48 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2001 17:32:47 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010729163918.00c9e1b0@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 19:30:46 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] More editorial comments on base-07 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: August 3, 2001 Reference: Document: Base-07 Comment type: E Priority: 1 Section: throughout Rationale/Explanation of issue: In 5.3.1: - 1st paragraph, "...is sent to inform a peer that a reboot has occurred". I think it's just sent whenever a connection is established, and is not linked to reboots in any way (other than reboots imply a new connection, but not the opposite). Might be handy to know a device has rebooted, though (by including uptime in the CER/CEA messages for instance). In 5.3.2: - 1st paragraph, "The Capabilities-Exchange-Request (CEA)" -> "The Capabilities-Exchange-Answer (CEA)" :-) In 5.4: - 1st paragraph, "...disconnects one *of* its transport connections..." In 5.5.3: - Status, "the level of confidence in the algorithm". Needs some rewording :-) - Pending, "This boolean field is set to TRUE when there are no outstanding unanswered requests". For logic's sake, it should be FALSE when there aren't any, and TRUE when there are (and modify the rest accordingly -- actually, I think the rest actually thinks pending is true when there are outstanding unanswered requests...) - OnReceiveDWA, not sure the "if pcb->status = WAIT_DWA OR pcb->Status = SUSPECT" is actually needed? It should happen also if status is OK. Also note the capitalization of status is not constant. - OnTimerElapsed, a "T = Tw" is missing in the OK block after the SendWatchdog(pcb) In 5.5.4: - 2nd paragraph, "The Hop-by-Hop Identifier field MAY be used to match the answer with the queued request". Errr, I don't see any other way? - 3rd paragraph, "it is not possible for forward" -> "it is not possible *to* forward". - 4th paragraph, "request or answer" -> "requests or answers" In 5.6: - 2nd paragraph, "...a connection is initiated *from* MUST NOT be the port..." - in the state machine, I still think that (a) two state machines, one for receiving, one for initiating, would be a lot simpler -- the only place where they have anything in common is the election after receiving a CEA or CER, respectively; (b) the "R-Conn-CER" event is a bit too much of a shortcut since it actually involves multiple sub-events and states. In 5.6.1: - 1st paragraph, "This is because the identity of a Diameter peer is determined by host and port; and the source port of an incoming connection is arbitrary" -> "This is because the identity of a Diameter peer is determined by a specific protocol, transport, host and port the peer is listening on; and the protocol, transport, source address and source port of an incoming connection are arbitrary." - 4th paragraph, "the state machine below" -> "the state machine above". In 5.6 & 5.6.3: - the state machine states that if a connection is received (R-Conn-CER) once in Open state, then the new connection is rejected, i.e. disconnected. A CEA MUST be sent before the connection is disconnected. This is to make sure that if host A and B already talk to each other, and A finds out it needs to talk to host C (DNS, SLP, Redirect-Host...), which is actually another URI for host B, then A must know that C == B. Of course, the CEA must contain some Result-Code that says there already is a connection and that this one will be shut down. - Also I'm not 100% convinced the state machine isn't subject to some race conditions, though I didn't look into that in detail. In 6.1: - 5th paragraph "When a message is received...", references are incorrect: 6.1.1 -> 6.1.4; 6.1.2 -> 6.1.5; 6.1.5 -> 6.1.6. In 6.1.8: - in the figure, the Route-Record should be set to nas.mno.net, not drl.mno.net. In 6.1.9: - 1st paragraph, if the AVPs are put in reverse order, then it should be the FIRST Souce-Route AVP, not the last. Also, that AVP must be removed after use :-) - also, need to update 6.1 and 6.1.5 to include source-routing. In 6.4: - 1st paragraph, "or broker". I would suppose a broker would only operate relays, proxies, or redirectors, and could thus never originate messages (other than errors)? Otherwise, just state "This AVP identifies the node which originated the Diameter message." - 2nd paragraph, "The value of the Origin-Host AVP is guaranteed to be unique within a single host". I would say it must be completely unique for any given process. In 6.5: - not quite sure what the Origin-Realm is for, and not quite sure what the "realm of the originator" might be. For me, realms are for users, not nodes. In 6.6 (and other places in 6): - 1st paragraph, "This AVP MUST be present in all unsolicited agent initiated messages". Not sure why. The Source-Route AVPs should be enough. In 6.7: - maybe we need an AVP derived type for realms? - "Diameter servers initiating a request message use the value of the Origin-Realm AVP from a previous message received from the intended target host (unless it is known a priori)". This is no longer used. Haven't had time to do more yet, I'll try to finish the thing during the week-end. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Aug 3 13:34: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 SMTP id NAA22446 for ; Fri, 3 Aug 2001 13:34:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7D109134C; Fri, 3 Aug 2001 13:32:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 298AE9134E; Fri, 3 Aug 2001 13:32:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E9809134C for ; Fri, 3 Aug 2001 13:32:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07D4C5DDD4; Fri, 3 Aug 2001 13:32:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 756F85DDB3 for ; Fri, 3 Aug 2001 13:32:49 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2001 17:32:48 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010803193055.00c49ea0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 19:32:22 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] base draft 07 comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: August 3, 2001 Reference: Document: Base-07 Comment type: E Priority: 1 Section: throughout Rationale/Explanation of issue: This is just an older mail I hadn't formally filed as an issue... In 1.1: - second paragraph ("All data delivered by the protocol..."): "and AVPs which are explicitly excluded are not included": there isn't anything in the ABNF to state that AVPs are excluded. - last paragraph, "(known as a proxy)" is not consistent with other definitions in the draft. Should say "(known as a proxy or relay)". - also, that paragraph defines a server as either a proxy/relay or as a server. It should be called an agent, or the definition should be changed to only include the real "server" function. In 1.3: - "Accounting record" def is incomplete (ends with "or accounting events from several"). - the AVP definition is restrictive. It might include protocol-specific data (e.g. routing information), not only pure AAA data. - "Diameter node" suddenly mentions translation agents, while this is not listed in the "Diameter agent" definition - "Redirector": inconsistent use of "Redirect", "Redirector", "Re-direct"... [also throughout the draft]. - the definitions of "Upstream server" and "Downstream server", other than the fact that they are reversed ;-> are incorrect: it should be "nodes" and not servers, and the definition should be something "a node that is closer to the client [resp. home server] in the routing path, relative to a given node". It might be the client [resp. home server] itself, so it does not necessarily provide "routing services" towards it. In 2.0 - 5th paragraph ("Diameter proxies..."), "in addition"->"In addition" :-) - 8th paragraph ("Communication between Diameter peers..."): you mean nodes, not peers, right? - in the same paragraph, the last sentence implies that all messages are related to a session (those messages would actually be exchanged between a client and a server, not any random set of nodes/peers). This does not apply to all the base protocol messages such as CER/CEA, DWR/DWA, etc.). - in the last paragraph, the semantics of Authorization-Lifetime have not been updated In 2.1 - 3rd paragraph, "A Diameter node MAY initiate connections from any source port" *except TBD*? - same paragraph, "...MAY *be* any of a peer's valid IP addresses." - where did the 4th paragraph "A given Diameter process SHOULD use the same port number ..." come from? That's ugly and unnecessary, as the process identity will be communicated in CER/CEA. - 5th paragraph, there should be a provision for hosts marked "bad" for some reason. - 7th and last paragraph, there is a mix between the sockets API (ECONNREFUSED) and TCP/ICMP packet exchanges. Should probably replace "ECONNREFUSED (a reset from the transport)" with "a reset from the transport" (I think most TCP stacks interpret the ICMP error messages themselves and return ECONNREFUSED). Actually, this isn't that much the Diameter implementation itself, but the platform it is using. To be clarified. In 2.3.1: - 1st paragraph, "Defining a new AVP value is the best approach when a new application needs to make use of an existing Diameter application..." Isn't that recursive? :-( - last paragraph, "Furthermore, if the command code on which the AVP value is to be used would require a different set of mandatory AVPs be present *when the new AVP value is used*, the list of AVPs must accompany the request." (needs some rewording) - should reference something in 11.x, but I don't know what :-( In 2.3.2: - 1st paragraph, same application/application problem. - 2nd paragraph, why MUST it be one of the listed types? Since AVPs are opaque to those who don't use them and the AVP type is not included in the packet... - should reference 11.1.1 In 2.3.3 - should reference 11.3 In 2.4 - I guess the whole Acct-Application-Id thing with additional AVPs to support in the same Accounting messages invalidates the whole ABNF consistency thing... In 2.5: - I guess this is historical, but history in a not-yet-published RFC seems weird... Why not move the Mobile-IP application to 3? - I would also swap the E2E security app and NASREQ. The first one is more like an extension of the base draft while the second (like Mobile-IP) are real AAA apps. - oh, by the way, it's CMS, not E2E now :-) [also happens in other places in the draft] - 3rd paragraph, "Relay and redirect agents MUST advertise...": what should an agent that is a server for some requests (those for users in the local domain) and a relay/redirector for others (users in remote domains) advertise? In 2.6: - the Host identity received in CER/CEA MUST be saved! I guess there should actually be two values: one that is configured (or discovered using DNS, SLP...) until the connection is established, and then the official unique but consistent value advertised in CER/CEA. Actually, there might be several of the configured/discovered identities if the node finds out that multiple identities point to the same process. - as discussed previously, I don't think the role belongs here: a peer might be primary for a realm, secondary for another, alternate for yet another... In 2.7 - realm/domain inconsistencies (also throughout the draft), as already pointed out by Marta. - Application identifier: should clarify that accounting and auth messages might actually be sent to different servers - local action/proxy: "See section 6.1.8 for *proxying* guidelines." - local action/redirect: why home server? Should just be "agent"... - "Expiration time. Specifies the time which dynamically discovered a route table entry expire." -> "Expiration time. Specifies the time which *a* dynamically discovered route table entry expireS." ("a" moved, "s" added) - 2nd paragraph "It is important to note...", "proxies SHOULD NOT reorder AVPs": I would say they MUST NOT reorder AVPs of the same type. - last paragraph: "When a request is routed, the target server MUST have advertised the Application Identifier (see section 2.5) for the given message, or have advertised itself as a relay or proxy agent."... Mmmm. What if the local node has not connected to that agent (not server, btw) yet, so doesn't know if it actually advertises the said application? Also, what should it do if there's a mismatch here? In 2.8 - 1st paragraph, translation agents are not defined in 1.3 - 4th paragraph "A stateful agent...", Authorized-Lifetime -> Session-Timeout In 2.8.1 - 4th paragraph "The example provided...", the last part "which is routed back to NAS using Diameter routing AVPs" is no longer true -> "which is routed back to NAS using saved transaction state" In 2.8.2 - 2nd and 5th paragraphs may be a bit too strong: CMS can be applied on part of the AVPs only (those that would not be modified, e.g.). And CMS will most certainly apply to AVPs that are not modified (i.e. authorization answers and accounting requests) In 3.0 - "r(eserved) - this flag bit is..." -> "these flag bits are..." - Hop-by-Hop identifier, "The sender MUST ensure that the Hop-by-Hop identifier in a request is locally unique (to the sender)". This might be too strong: it actually needs to be unique on a per-connection basis only. - End-to-End identifier, I guess the method described should only be a recommendation, not part of the spec (which should state that it must be unique for a given Origin-Host ID for the lifetime of the message)? - same paragraph, should mention here that a server is supposed to answer the same thing it did upon reception of a duplicate, and not take any action that would affect state again? In 3.1 - should renumber everything so that we have something consistent and contiguous rather than this sparse table? In 3.2 - diameter-name = ALPHA *(ALPHA / DIGIT / "-") should probably be diameter-name = ALPHA *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) (I suppose we don't want command names ending with a dash?) In 5.3.*: - I guess we should add some AVPs to advertise the local values of the timers (Ti, Tr, Tw, Td...) so that incompatible values are detected immediately and the connection torn down with a nice log (a la OSPF IIRC - or is it IS-IS?) In 11.3: - All values, other than zero... -> All other values, except 0... On a different subject, something I've been thinking about some time ago, but didn't check against the docs: in a roaming environment, what is important to an ISP is not that the accounting data from the original client be signed by that client (it might not know the client at all, and doesn't care). What they care about is that the accounting data be signed by their roaming "peer" (partner), i.e. the one that will pay them. Actually, if the accounting data includes money (you know, $$$), proxies might change that amount on the way (to reflect margins of brokers), but it should nevertheless be signed at some point... Some AVPs might actually have multiple signatures, or be signed, then checked, then modified (old sig removed), and resigned multiple times on the way. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Aug 3 13:44: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 SMTP id NAA22713 for ; Fri, 3 Aug 2001 13:44:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1469791350; Fri, 3 Aug 2001 13:45:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F46B91351; Fri, 3 Aug 2001 13:45:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7B7891353 for ; Fri, 3 Aug 2001 13:45:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E95DA5DE02; Fri, 3 Aug 2001 13:45:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id 368D85DDD4 for ; Fri, 3 Aug 2001 13:45:01 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2001 17:44:59 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010803194030.00c895d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 19:42:20 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 97 Cc: "Martin Julien (ECE)" , "'Pat Calhoun'" , aaa-wg@merit.edu In-Reply-To: <20010803064557.B27662@charizard.diameter.org> References: <577066326047D41180AC00508B955DDA04D1AA26@eestqnt104.es.eu.ericsson.se> <577066326047D41180AC00508B955DDA04D1AA26@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I just think that if we have that stuff to get to the same Destination-Host for further requests in the same session, then I see no reason not to have the same thing for intermediary nodes. But since I won't be in London I'll probably not be followed on that one :-( Jacques. At 15:45 03/08/01, Pat Calhoun wrote: >ok, let's discuss this in London. I agree with you completely, but >there were other folks that didn't. THe problem is no one disagreed on >the list when I asked, so it ended up in -07. > >PatC >On Fri, Aug 03, 2001 at 09:37:52AM +0200, Martin Julien (ECE) wrote: > > If it is not adopted, will you get rid of the Source-Route AVP, > > in order to come back to the original proposal of -06? > > Would that mean that we would not adopt the proposal of > > not removing the Route-Record AVPs, while an answer is > > going through proxies towards the client? I would prefer > > removing them, just as before. > > > > I find the proposed solution for keeping static path interesting, > > but unnecessarily complex for what we need. I preferred much > > more the routing scheme of -06. That's my opinion. > > > > Regards, > > Martin > > > > > -----Original Message----- > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > Sent: Friday, August 03, 2001 12:21 AM > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: Issue 97 > > > > > > > > > All, > > > > > > Issue 97 recommends that an approach be adopted that allows for the > > > path to a home server be static for a given session. The proposal is > > > to introduce a new AVP, but I believe that the Source-Route AVP would > > > work just as well. > > > > > > Do folks disagree with this feature? > > > > > > My personal inclination is not to adopt it, but of course I > > > will listen > > > to WG consensus. > > > > > > PatC > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Aug 3 13:47:30 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22773 for ; Fri, 3 Aug 2001 13:47:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64F8791354; Fri, 3 Aug 2001 13:47:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F8CE9135B; Fri, 3 Aug 2001 13:47: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 10C1991354 for ; Fri, 3 Aug 2001 13:47:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E88895DE02; Fri, 3 Aug 2001 13:47:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 69B3D5DDD4 for ; Fri, 3 Aug 2001 13:47:00 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Aug 2001 17:46:58 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010803194233.00d06820@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Aug 2001 19:45:31 +0200 To: Adrian.Constantin@nokia.com From: Jacques Caron Subject: Re: [AAA-WG]: Questions and comments to Base-07 Cc: aaa-wg@merit.edu In-Reply-To: <9E3407CE45911B4097632389B77B20231077FA@esebe014.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 12:06 03/08/01, Adrian.Constantin@nokia.com wrote: >The race condition mentioned in 5.4 could also lead to >scenarios like the >one bellow: > >Peer1 Peer2 > | | > | CER | > |------------------------>| > | | > | /| > | Request MSG / | > |<---------------------/--| > | / | > | CEA / | > |<------------------- | > | | Not possible. The messages are sent over TCP or SCTP which both guarantee ordered delivery. >FAILOVER > >In case of failure the requests pending are resent to an >alternate peer. In >my understanding the duplicate must contain the same end-to-end and >hop-by-hop identifier as the original message. Is this interpretation >correct? The End-to-End identifier indeed does not change. The hop-by-hop one is local to a connection, so can be different. >In case of duplicate messages, the only messages discarded are the >duplicated answers meant for local processing (3.0). The >servers answering >to a duplicate request will set different end-to-end >identifier for the two >answers. In this case, which scenario could lead to the receiving of a >duplicate reply (with the same end-to-end id and same origin host)? The End-to-end identifier in the answer is copied from the request, so in the worst case the client just receives exactly the same answer twice, and ignores the second one. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Aug 3 14:36: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 SMTP id OAA23792 for ; Fri, 3 Aug 2001 14:36:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7837091353; Fri, 3 Aug 2001 14:36:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F89491355; Fri, 3 Aug 2001 14:36: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 CB8F691353 for ; Fri, 3 Aug 2001 14:36:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E9665DDFC; Fri, 3 Aug 2001 14:36: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 C54A35DDC9 for ; Fri, 3 Aug 2001 14:36: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 f73IaZ313570 for ; Fri, 3 Aug 2001 21:36:35 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 3 Aug 2001 21:35:57 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVL7HQ>; Fri, 3 Aug 2001 21:35:58 +0300 Message-ID: <9E3407CE45911B4097632389B77B20231077FB@esebe014.NOE.Nokia.com> From: Adrian.Constantin@nokia.com To: jacques_m_caron@yahoo.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Questions and comments to Base-07 Date: Fri, 3 Aug 2001 21:35:53 +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 Thanks for the answers. See comment bellow. > -----Original Message----- > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > Sent: 03. August 2001 20:46 > To: Constantin Adrian (NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Questions and comments to Base-07 > > > At 12:06 03/08/01, Adrian.Constantin@nokia.com wrote: > >The race condition mentioned in 5.4 could also lead to > >scenarios like the > >one bellow: > > > >Peer1 Peer2 > > | | > > | CER | > > |------------------------>| > > | | > > | /| > > | Request MSG / | > > |<---------------------/--| > > | / | > > | CEA / | > > |<------------------- | > > | | > > Not possible. The messages are sent over TCP or SCTP which > both guarantee > ordered delivery. > I agree that the scenario cannot appear if TCP is used. But I knew that in SCTP the delivery order is guaranteed only within streams. In this case the scenario is possible if Request and CEA are sent on different streams. On the other hand it might be possible for the Diameter to reorder the messages at arrival. Should this be specified in the base protocol document? > >FAILOVER > > > >In case of failure the requests pending are resent to an > >alternate peer. In > >my understanding the duplicate must contain the same end-to-end and > >hop-by-hop identifier as the original message. Is this interpretation > >correct? > > The End-to-End identifier indeed does not change. The > hop-by-hop one is > local to a connection, so can be different. > > >In case of duplicate messages, the only messages discarded are the > >duplicated answers meant for local processing (3.0). The > >servers answering > >to a duplicate request will set different end-to-end > >identifier for the two > >answers. In this case, which scenario could lead to the > receiving of a > >duplicate reply (with the same end-to-end id and same origin host)? > > The End-to-end identifier in the answer is copied from the > request, so in > the worst case the client just receives exactly the same > answer twice, and > ignores the second one. > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Fri Aug 3 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 SMTP id PAA24474 for ; Fri, 3 Aug 2001 15:08:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BCF191352; Fri, 3 Aug 2001 15:06:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D306C91356; Fri, 3 Aug 2001 15:06: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 77CBB91352 for ; Fri, 3 Aug 2001 15:05:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D36A5DDC9; Fri, 3 Aug 2001 15:05:55 -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 49EE45DDB3 for ; Fri, 3 Aug 2001 15:05:55 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA11995 for ; Fri, 3 Aug 2001 12:05:54 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA13089 for ; Fri, 3 Aug 2001 11:58:16 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3XDB0DYQ>; Fri, 3 Aug 2001 14:05:53 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECFBC@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Jacques Caron'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] base draft 07 comments Date: Fri, 3 Aug 2001 14:05:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] > Subject: [AAA-WG]: [Issue] base draft 07 comments ... > In 1.1: > - second paragraph ("All data delivered by the protocol..."): > "and AVPs > which are explicitly excluded are not included": there isn't > anything in > the ABNF to state that AVPs are excluded. I believe that the zero maximum, zero minimum occurrences served as an explicit exclusion. ... > In 2.1 > - 3rd paragraph, "A Diameter node MAY initiate connections > from any source > port" *except TBD*? What about a client that listens on SCTP port TBD, but attempts to contact other hosts with a TCP source port TBD? I don't think that there's a requirement that if a client utilizes a transport on outbound connections, it must support inbound connections on that same protocol, right? Perhaps the wording should be "A Diameter node MAY initiate connections from any source port, other than the one which they declare they accept incoming connections on." Unless, perhaps "clients MUST support either TCP or SCTP" means "clients MUST NOT support both TCP and SCTP"...(doubtful). On that note, 2.1 also says, "Note that the source and destination addresses used in request and replies MAY any of a peer's valid IP addresses" -- Aren't these addresses going to be limited to only addresses on which the node is listening? -Brian From owner-aaa-wg@merit.edu Fri Aug 3 17:18: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 RAA29415 for ; Fri, 3 Aug 2001 17:18:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D9719135A; Fri, 3 Aug 2001 17:19:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EADD99135B; Fri, 3 Aug 2001 17:19:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6A3B9135A for ; Fri, 3 Aug 2001 17:19:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9AD575DDB3; Fri, 3 Aug 2001 17:19:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 49F2A5DD96 for ; Fri, 3 Aug 2001 17:19:24 -0400 (EDT) Received: (qmail 28465 invoked by uid 500); 3 Aug 2001 21:08:19 -0000 Date: Fri, 3 Aug 2001 14:08:19 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 97 Message-ID: <20010803140819.A28375@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA26@eestqnt104.es.eu.ericsson.se> <577066326047D41180AC00508B955DDA04D1AA26@eestqnt104.es.eu.ericsson.se> <20010803064557.B27662@charizard.diameter.org> <4.3.2.7.2.20010803194030.00c895d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010803194030.00c895d0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Fri, Aug 03, 2001 at 07:42:20PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Jacques, I'll make sure that your view is heard in London. PatC On Fri, Aug 03, 2001 at 07:42:20PM +0200, Jacques Caron wrote: > Hi, > > I just think that if we have that stuff to get to the same Destination-Host > for further requests in the same session, then I see no reason not to have > the same thing for intermediary nodes. > > But since I won't be in London I'll probably not be followed on that one :-( > > Jacques. > > At 15:45 03/08/01, Pat Calhoun wrote: > >ok, let's discuss this in London. I agree with you completely, but > >there were other folks that didn't. THe problem is no one disagreed on > >the list when I asked, so it ended up in -07. > > > >PatC > >On Fri, Aug 03, 2001 at 09:37:52AM +0200, Martin Julien (ECE) wrote: > > > If it is not adopted, will you get rid of the Source-Route AVP, > > > in order to come back to the original proposal of -06? > > > Would that mean that we would not adopt the proposal of > > > not removing the Route-Record AVPs, while an answer is > > > going through proxies towards the client? I would prefer > > > removing them, just as before. > > > > > > I find the proposed solution for keeping static path interesting, > > > but unnecessarily complex for what we need. I preferred much > > > more the routing scheme of -06. That's my opinion. > > > > > > Regards, > > > Martin > > > > > > > -----Original Message----- > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > > > Sent: Friday, August 03, 2001 12:21 AM > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: Issue 97 > > > > > > > > > > > > All, > > > > > > > > Issue 97 recommends that an approach be adopted that allows for the > > > > path to a home server be static for a given session. The proposal is > > > > to introduce a new AVP, but I believe that the Source-Route AVP would > > > > work just as well. > > > > > > > > Do folks disagree with this feature? > > > > > > > > My personal inclination is not to adopt it, but of course I > > > > will listen > > > > to WG consensus. > > > > > > > > PatC > > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Mon Aug 6 04:00:33 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18719 for ; Mon, 6 Aug 2001 04:00:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF8529126A; Mon, 6 Aug 2001 03:59:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AD1991269; Mon, 6 Aug 2001 03:59: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 5F31591266 for ; Mon, 6 Aug 2001 03:59:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3446D5DDAB; Mon, 6 Aug 2001 03:59: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 B07065DD9A for ; Mon, 6 Aug 2001 03:59:33 -0400 (EDT) Received: (qmail 7470 invoked by uid 500); 6 Aug 2001 07:48:23 -0000 Date: Mon, 6 Aug 2001 00:48:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Comments on Issue 107 Message-ID: <20010806004823.D7242@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 are some comments on this issue: > Page 12, section 2.0, 2nd paragraph: > The two bullets say almost the same thing. So what about deleting the > first sentence in bullet 1 and start with "1. A set of AVPs are defined > to sign and encrypt AVPs." and keep bullet 2 as is. They actually state very different things, so your suggested change is not correct. > Page 68, section 6.2.2, 3rd and 4th paragraph: > "If the agent receives an answer message with a Result-Code AVP > indicating success, and it wishes to modify the AVP to indicate an > error, it MUST issue an STR on behalf of the access device. The agent > MUST then send the answer to the host which it received the original > request from." > > The above paragraph needs to better clarify what the relay/proxy agent > sends back to the access device. The text that I came up with is a little different. What do you think about: "If a relay or proxy agent receives an answer with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged, but not reflected in the Result-Code AVP. If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST modify the Result-Code AVP to contain the appropriate error in the message destined towards the access device as well as include the Error-Reporting-Host AVP and it MUST issue an STR on behalf of the access device." From owner-aaa-wg@merit.edu Mon Aug 6 04:03: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 EAA18778 for ; Mon, 6 Aug 2001 04:03:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB31291260; Mon, 6 Aug 2001 04:01:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A3B59126B; Mon, 6 Aug 2001 04:00: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 BCA8691264 for ; Mon, 6 Aug 2001 04:00:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BBBE5DDB4; Mon, 6 Aug 2001 04:00: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 8F2655DD9A for ; Mon, 6 Aug 2001 04:00:08 -0400 (EDT) Received: (qmail 7481 invoked by uid 500); 6 Aug 2001 07:48:58 -0000 Date: Mon, 6 Aug 2001 00:48:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Comments on Issue 103 Message-ID: <20010806004858.E7242@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 Although this issue was filed only against the base protocol, all of the Diameter specs had similar inconsistencies. I have made all of the necessary fixes and will update issue 103 to include all specs, not only the base. PatC From owner-aaa-wg@merit.edu Mon Aug 6 04:04: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 EAA18794 for ; Mon, 6 Aug 2001 04:04:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 136B891269; Mon, 6 Aug 2001 04:01:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DC3091266; Mon, 6 Aug 2001 04:01: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 4904691269 for ; Mon, 6 Aug 2001 04:00:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E5E65DDAB; Mon, 6 Aug 2001 04:00: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 D00425DD9A for ; Mon, 6 Aug 2001 04:00:39 -0400 (EDT) Received: (qmail 7488 invoked by uid 500); 6 Aug 2001 07:49:29 -0000 Date: Mon, 6 Aug 2001 00:49:29 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Comments on Issue 102 Message-ID: <20010806004929.F7242@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 been looking over issue 102, and the request is to add some descriptive text to clarify what each state means. However, the peer state machine does not have such text. At one point there was a section that described each state, but this seemed superfluous, and was later removed. What is present is a description of the events and actions. The state tables in 8.1 and 8.2 have very descriptive events, so perhaps Yiwen was looking for more text on the actual actions? Help! PatC From owner-aaa-wg@merit.edu Mon Aug 6 04:04:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18825 for ; Mon, 6 Aug 2001 04:04:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27E1D91272; Mon, 6 Aug 2001 04:02:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD31691266; Mon, 6 Aug 2001 04:01: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 878B09126D for ; Mon, 6 Aug 2001 04:01:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C5B45DDAB; Mon, 6 Aug 2001 04:01: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 F14DE5DD9A for ; Mon, 6 Aug 2001 04:01:19 -0400 (EDT) Received: (qmail 7503 invoked by uid 500); 6 Aug 2001 07:50:09 -0000 Date: Mon, 6 Aug 2001 00:50:09 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Comments on Issue 111 Message-ID: <20010806005009.G7242@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, Below is my proposed peer state machine to address this issue. The fix is actually different from the proposed fix, since we cannot simply remove R-Disc or I-Disc, since these events can occur when a peer fails. The fix is to add new events for receiving the DPR and DPA, and includes a new interim state, called Closing. Comments most appreciated (need to make sure I didn't mess this one up). If you have a state machine validator, and you know who you are, then this message is for you :) PatC ---- state event action next state ----------------------------------------------------------------- Closed Start I-Snd-Conn-Req Wait-Conn-Ack R-Conn-CER R-Accept, R-Open Process_CER, R-Snd-CEA Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA I-Rcv-Conn-Nack Cleanup Closed R-Conn-CER R-Accept, Wait-Conn-Ack/ Process-CER Elect Timeout Error Closed Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept, Wait-Returns Process-CER, Elect I-Peer-Disc I-Disc Closed I-Rcv-DPR I-Snd-DPA Closing I-Rcv-Non-CEA Error Closed Timeout Error Closed Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open R-Peer-Disc R-Disc Wait-Conn-Ack R-Rcv-DPR R-Snd-DPA, Wait-Conn-Ack R-Disc R-Conn-CER R-Reject Wait-Conn-Ack/ Elect Timeout Error Closed Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open I-Rcv-DPR I-Snd-DPA, R-Open R-Snd-CEA I-Rcv-CEA R-Snd-DPR I-Open R-Peer-Disc R-Disc Wait-I-CEA R-Rcv-DPR R-Snd-DPA, Wait-I-CEA R-Disc R-Conn-CER R-Reject Wait-Returns Timeout Error Closed 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-Reject R-Open 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 Closing I-Rcv-DPA I-Disc Closed R-Rcv-DPA R-Disc Closed Timeout Error Closed From owner-aaa-wg@merit.edu Mon Aug 6 04:05:47 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 EAA18853 for ; Mon, 6 Aug 2001 04:05:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D54491277; Mon, 6 Aug 2001 04:02:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D9DA91266; Mon, 6 Aug 2001 04:02: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 BCB4791274 for ; Mon, 6 Aug 2001 04:02:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 992D95DDB4; Mon, 6 Aug 2001 04:02: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 38DB35DD9A for ; Mon, 6 Aug 2001 04:02:02 -0400 (EDT) Received: (qmail 7515 invoked by uid 500); 6 Aug 2001 07:50:52 -0000 Date: Mon, 6 Aug 2001 00:50:52 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Comments on Issue 104 Message-ID: <20010806005052.H7242@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Here is my proposed text to resolve issue 104. Note that I've modified the text slightly from the proposed text that was sent in with the issue. I apologize for the formatting, since I do not currently have access to nroff ? Comments appreciated, PatC ---- 2.6 Connections vs. Sessions This section attempts to provide the reader with an understanding of the difference between connection and session, which are terms used extensively throughout this document. A connection is a transport level connection between two peers, used to send and receive Diameter messages. A session is a logical concept at the application layer, and is shared between an access device and a server, and is identified via the Session-Id AVP +--------+ +-------+ +--------+ | Client | | Relay | | Server | +--------+ +-------+ +--------+ <----------> <----------> peer connection A peer connection B <-----------------------------> User session x Figure 1: Diameter connections and sessions In the example provided in figure 1, peer connection A is established between the Client and its local Relay. Peer connection B is established between the Relay and the Server. User session x spans from the Client via the Relay to the Server. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once accepted by the server, both the client and the server are aware of the session. It is important to note that there is no relationship between a connection and a session, and that Diameter messages for multiple sessions are all multiplexed through a single connection. From owner-aaa-wg@merit.edu Mon Aug 6 04:06: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 EAA18868 for ; Mon, 6 Aug 2001 04:06:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD23391273; Mon, 6 Aug 2001 04:03:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4269691266; Mon, 6 Aug 2001 04:02: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 C68B391274 for ; Mon, 6 Aug 2001 04:02:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC4715DDB4; Mon, 6 Aug 2001 04:02:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B399C5DDAB for ; Mon, 6 Aug 2001 04:02:29 -0400 (EDT) Received: (qmail 7523 invoked by uid 500); 6 Aug 2001 07:51:19 -0000 Date: Mon, 6 Aug 2001 00:51:19 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Comments on Issue 100 Message-ID: <20010806005119.I7242@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 are my comments on issue 100: > In 3.0 > - Commands flags, r(eserved): should state that an error must be generated > if a packet is received with such a bit set to one. So my proposed text is: r(eserved) - this flag bit is reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. I thought about adding more details here, but it really seems unnecessary. By looking at the Result-Code AVP, one can quickly determine which error to use. > In 3.3: > - 1st paragraph: "Diameter commands typically start with an object name". > Not that sure :-) > - 2nd paragraph: "The corresponding answer MUST contain either a positive > or negative result code". What about multi-round trip messages, and redirects? Yes, I guess this section actually needed more of a re-write than anything else. Here's my proposed text: " Diameter commands typically includes one or more English words followed by the verb Request or Answer. Each English word is delimited by a hyphen. An acronym for both the request and answer is also normally provided. An example is a message set used to terminate a session. The command name is Session-Terminate-Request and Session-Terminate-Answer, while the acronyms Are STR and STA, respectively. Both the request and the answer for a given command share the same command code. The request is identified by the R(equest) bit in the Diameter header set to one (1). The request is sent to a peer to request that a particular action be performed, such as authorizing a user or terminating a session. Once the receiver has completed the request it issues the corresponding answer, which includes a result code that communicates one of the following: - The request was successful - The request failed - An additional request must be sent to provide information the peer requires prior to returning a successful or failed answer. - The receiver could not process the request, but provides information about a Diameter peer that is able to satisfy the request, known as redirect. Additional information, encoded within AVPs, MAY also be included in answer messages." > In 4.0: > - 1st paragraph: "Diameter AVPs carry specific authentication, accounting > and authorization information, security information as well as > configuration details..." They can also carry routing information (unless > that's what is meant by "configuration details". My new proposed text reads: " Diameter AVPs carry specific authentication, accounting, authorization, routing and security information as well as configuration details for the request and reply." > In 4.1: > - AVP Code: "The first 256 AVP numbers are reserved for backward > compatibility with RADIUS". Even if Vendor-Id is non-zero? Proposed text: " The first 256 AVP numbers, with the Vendor-Id set to zero (0) are reserved for backward compatibility with RADIUS..." > - AVP Flags, "Note that subsequent Diameter applications MAY define > additional bits within the AVP Header, and an unrecognized bit SHOULD be > considered an error". Didn't find an error number for that one in 7.1.x. ok, here's the new result-code value: DIAMETER_INVALID_AVP_BITS TBD A request was received that included an AVP whose flag bits are set to an unrecognized value, or that is inconsistent with the AVP's definition. > - AVP Flags, 2nd paragraph, "If an unrecognized AVP with the 'M' bit set is > received by a Diameter node..." replace node with "client, server or > proxy". The client thing raises the issue stated in the 7.1.4/7.1.5 section > about errors in answers, though. Also, it should not be only if the AVP is > unrecognized, but also if the requested AVP or value is recognized, but the > node does not accept it. Check, so the new text would read: " The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server or proxy and either the AVP or its value is unrecognized, the message MUST be rejected. Diameter Relay and Redirector agents MUST NOT reject messages with unrecognized AVPs." > - AVP Flags, 3rd paragraph, "In order to provide service to the user, the > node at fault MUST re-issue...". The client might decide that if the server > doesn't understand that AVP, it doesn't want to provide service to the > user. Make that explicit rather than implicit. Ok, added the following text to the end of the paragraph: "Alternatively, the node at fault MAY decide to simply not provide service to the user." > - AVP Flags, 4th paragraph, add a comma between "ABNF" and "is at fault". > - AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are > informational only and a receiver that receives a message with such an AVP > that is not supported MAY simply ignore the AVP." The AVP might be > supported but not the value, and it could be ignored also, right? Same > thing if the AVP and value are supported but the node does not want to > honor that AVP or value. Well, isn't ignoring an AVP also mean its value is ignored? I'm not sure that I follow your logic here :( > In 4.3, > - the definitions for Float32, 64 and 128 are truncated: "'V' bit is > enabled)." is missing. Hmmm... an nroff bug. Fixed. > In 4.4, > - 1st paragraph, "In addition to the AVP Base Data Formats" -> "In addition > to *using* the AVP Base Data Formats". Why? > - 1st paragraph, "New AVP Derived Data Formats MUST be registered with > IANA." How could they be registered? There is no "unique identifier" or > anything of the sort. And since the AVP contents are actually opaque to > those that are not involved, I don't quite see the need. They should just > be defined in any application that uses them. Also, if they must indeed be > registered, a section in 11.x is missing. You are correct, and the two paragraphs have been modified to a single Paragraph, which reads as: " In addition to the AVP Base Data Formats, applications may define data formats derived from the AVP Base Data Formats. An application that defines new AVP Derived Data Formats MUST include them in a section entitled "AVP Derived Data Formats", using the same format as the definitions below. Each new definition must be either defined or listed with a reference to the RFC that defines the format." > - IPAddress, what if an AVP must explicitly have an IPv4 or IPv6, and not > "any of those"? Then I suspect that the actual AVP would need to state that clearly. We don't To my knowledge, have any such AVPs, though. > - UTF8String, 1st paragraph, reference wrong [24] not [29] (it might be a > good thing to actually check all refs) hmmm.... I thought I had at one point, but I guess another time around before I submit the next revision. Thanks for the heads up, though. > - DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise different > identities...". Glurgs! Certainly not! It MUST be the same identity on all > connections (unless the host is a gateway between two routing domains (e.g. > private and public)). Otherwise there's no way to detect duplicate > connections, loops, etc. consistently. Remember, the DiameterIdentity, as > used in CER/CEA and Route-Records is just considered as an opaque and > unique identifier. Damn, I knew making that Route-Record change was a bad idea, and would bite us in the ... later :( Ok, so in my case where I'm talking about two identities because of a public vs. private routing domain split, what should we do? > - DiameterIdentity, 5th paragraph, this is not needed in duplicate > connection detection and loop avoidance, since the identifier is opaque. It > can save time, however, when one gets an external reference to another host > (via SLP, DNS, Redirect, Alternate-Host...) and one wants to check that > this new host doesn't match one it already knows/already is connected to. > But even if that's not done, a match would be detected upon connection to > the new host when the CER/CEAs are exchanged and the "real" (unique) > identity is discovered and can be matched against existing connections. So you are stating that this paragraph can be deleted, and in no circumstances will we ever have a situation where a node will have to parse another peer's identity? > - IPFilterRule, 2nd to last paragraph, "An access device that is unable to > interpret or apply a deny rule MUST terminate the session." Shouldn't this > be dependent on whether the M bit is set or not? Ditto for the second > sentence (though it's probably not as important). Hmmmm..... this is a change that I feel uncomfortable just making as an editorial change. What do other folks think? > - QOSFilterRule: I thought the idea was to reference an IPFilterRule to > determine what traffic should be marked or metered? No, we decided that adding QoS to the IPFilterRule format would overload that format. > In 4.5: > - 1st paragraph, swap the ' and the . in 'Grouped.' Sorry, but I cannot for the life of me find the text you are referring to :( > - 3rd paragraph, "All AVPs included in a Grouped AVP Every Grouped AVP > defined...". Either something is missing before the Every, or the all > before the Every is not needed. The latter > > In 4.5.1: > - in the paragraph starting with "The data for the optional AVPs...", why > is is stated that "AVPs do not have to begin on 8 byte boundaries"? It is > true, but I quite see why people would think it? Don't know why that sentence fragment was there, but it has been removed since not only was it unnecessary, but it sure as hell was confusing. > In 4.6: > - in the table, what if a flag is in neither column for a given AVP (e.g. P > is often absent) There's another issue officially opened on this one, so I'll just ignore this comment and address it in the formal issue, which is more complete. > - here also, what about renumbering everything in a contiguous space? Sure. Next time I happen to be standing on my head for an extended period of time. Seriously, it would be nice, but at this point I was to minimize the changes to decrease the changes of introducing new bugs. That would be one sure way to do it. > - checking section references would be a good idea, but I'm way to lazy for > that. I've done that recently, but I'll do it once more when I also check the references. > In 5.1: > - 1st paragraph, specify that this "per realm" rather than globally? Though > there is the issue of proxies that serve many many realms (with different > peers), and dynamically learned realms/peers. Paragraph changed to: " 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 per realm, and MAY have additional connections, if it is deemed necessary. Note that a given peer MAY act as a primary for a given realm, while acting as a secondary for another realm." > in 5.3: > - 5th paragraph, "Since the CER/CEA messages...", replace "an upstream" > with "a". But that would be grammatically incorrect :( > In 7.1.2: > - DIAMETER_LIMITED_SUCCESS: "When returned, the request was successfully > completed, but additional processing is required by the application in > order to provide service to the user." Gni? What is that? If you look at the Mobile IP application, it will be clear. Unfortunately, it's rather Difficult to describe here :( The basic idea is that the server says yes, but you have Additional application level stuff to do. > > In 7.1.3: > - DIAMETER_INVALID_ROUTE_RECORD is no longer needed. ok > - DIAMETER_REDIRECT_INDICATION might be better off in the informational types? Well, it requires local action, perhaps even by a relay (e.g. not the NAS, but its First hop agent). > > In 7.1.4/7.1.5: > - I'm still not quite sure of the distinction between permanent and > transient. e.g. DIAMETER_AUTHENTICATION_REJECTED [which is transient, so > can be retried] means the request can be retried after asking the user for > its password again. So it's not actually the same request, right? On the > other hand, DIAMETER_AVP_UNSUPPORTED and DIAMETER_INVALID_AVP_VALUE [which > are permanent, so shouldn't be retried] imply that you can retry by > removing the AVP or changing the value [that's actually the > "content-negociation" part of Diameter]. > Actually, we might be better off with some category that includes anything > that means neither Accepted nor Refused, but rather "more to come" (which > would include both the multi-round-trip auths and other capabilities > negociation messages). > Also, what if an error is detected on the answer rather than the request? > Ditto for capabilities negociation in that direction (e.g. if server says > "please set this feature to that value for that user" and client or proxy > want to say "don't know what you're talking about/don't want to do that"). Hmmm.... that's a whole lotta stuff, and I'm not sure exactly where you are going with it :( PatC From owner-aaa-wg@merit.edu Mon Aug 6 04:07: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 EAA18909 for ; Mon, 6 Aug 2001 04:07:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F53891274; Mon, 6 Aug 2001 04:03:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3724B91266; Mon, 6 Aug 2001 04:03: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 83EE491274 for ; Mon, 6 Aug 2001 04:03:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 69F475DDB4; Mon, 6 Aug 2001 04:03: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 198F05DD9A for ; Mon, 6 Aug 2001 04:03:20 -0400 (EDT) Received: (qmail 7530 invoked by uid 500); 6 Aug 2001 07:52:09 -0000 Date: Mon, 6 Aug 2001 00:52:09 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [Issue] base draft 07 comments Message-ID: <20010806005209.J7242@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 > -----Original Message----- > From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] > Subject: [AAA-WG]: [Issue] base draft 07 comments ... > In 1.1: > - second paragraph ("All data delivered by the protocol..."): > "and AVPs > which are explicitly excluded are not included": there isn't > anything in > the ABNF to state that AVPs are excluded. I believe that the zero maximum, zero minimum occurrences served as an explicit exclusion. correct ... > In 2.1 > - 3rd paragraph, "A Diameter node MAY initiate connections > from any source > port" *except TBD*? What about a client that listens on SCTP port TBD, but attempts to contact other hosts with a TCP source port TBD? I don't think that there's a requirement that if a client utilizes a transport on outbound connections, it must support inbound connections on that same protocol, right? Perhaps the wording should be "A Diameter node MAY initiate connections from any source port, other than the one which they declare they accept incoming connections on." Unless, perhaps "clients MUST support either TCP or SCTP" means "clients MUST NOT support both TCP and SCTP"...(doubtful). That proposed text does work for me. On that note, 2.1 also says, "Note that the source and destination addresses used in request and replies MAY any of a peer's valid IP addresses" -- Aren't these addresses going to be limited to only addresses on which the node is listening? it should state that. PatC From owner-aaa-wg@merit.edu Mon Aug 6 04:08:50 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 EAA18944 for ; Mon, 6 Aug 2001 04:08:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 296DF91266; Mon, 6 Aug 2001 04:04:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F35A9127D; Mon, 6 Aug 2001 04:04: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 DFE7E91266 for ; Mon, 6 Aug 2001 04:03:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B49115DDAB; Mon, 6 Aug 2001 04:03: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 0A7B45DD9A for ; Mon, 6 Aug 2001 04:03:50 -0400 (EDT) Received: (qmail 7537 invoked by uid 500); 6 Aug 2001 07:52:39 -0000 Date: Mon, 6 Aug 2001 00:52:39 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Questions and comments to Base-07 Message-ID: <20010806005239.K7242@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 > > Not possible. The messages are sent over TCP or SCTP which > both guarantee > ordered delivery. > I agree that the scenario cannot appear if TCP is used. But I knew that in SCTP the delivery order is guaranteed only within streams. In this case the scenario is possible if Request and CEA are sent on different streams. On the other hand it might be possible for the Diameter to reorder the messages at arrival. Should this be specified in the base protocol document? Yes, I suppose this is then possible, which will cause the connection to be dropped, according to the state machine. So, we have two options: 1. limit the streams initially used, or 2. put safeguards in the state machine. I'd vote for 2. PatC From owner-aaa-wg@merit.edu Mon Aug 6 04:09:08 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18966 for ; Mon, 6 Aug 2001 04:09:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F20F91282; Mon, 6 Aug 2001 04:05:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CF5D91283; Mon, 6 Aug 2001 04:05: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 ECCFB9127D for ; Mon, 6 Aug 2001 04:04:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C64C45DDB4; Mon, 6 Aug 2001 04:04:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 339415DD9A for ; Mon, 6 Aug 2001 04:04:55 -0400 (EDT) Received: (qmail 7546 invoked by uid 500); 6 Aug 2001 07:53:45 -0000 Date: Mon, 6 Aug 2001 00:53:45 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [pcalhoun@bstormnetworks.com: RE: Re: [AAA-WG]: Questions and comments to Base-07 Message-ID: <20010806005344.L7242@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 Comments below delimited with PatC ---- PEER STATE MACHINE In section 5.3 some scenarios presenting an unsuccessful peer connection establishment are presented, but they are not reflected in the peer state machine (5.6). It seems to me clearer if the state machine includes the cases when the peer connection is refused. The race condition mentioned in 5.4 could also lead to scenarios like the one bellow: Peer1 Peer2 | | | CER | |------------------------>| | | | /| | Request MSG / | |<---------------------/--| | / | | CEA / | |<------------------- | | | In this case the request message receives no answer and a deadlock can appear at Peer1. How can this be prevented? Well, by correctly implementing the state machine :) The state machine includes the following: Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept, Wait-Returns Process_CER, Elect I-Peer-Disc I-Disc Closed I-Rcv-Non-CEA Error Closed <============== Timeout Error Closed The Wait-I-CEA is the state that you show in your diagram above. Peer1 is waiting for the CEA from peer2, but instead receives an non-CEA message. The state machine shows that peer1 MUST close the connection. Perhaps this is not exactly the best situation, but since the protocol runs over a reliable transport that also performs message ordering, this will never occur. FAILOVER In case of failure the requests pending are resent to an alternate peer. In my understanding the duplicate must contain the same end-to-end and hop-by-hop identifier as the original message. Is this interpretation correct? In case of duplicate messages, the only messages discarded are the duplicated answers meant for local processing (3.0). The servers answering to a duplicate request will set different end-to-end identifier for the two answers. In this case, which scenario could lead to the receiving of a duplicate reply (with the same end-to-end id and same origin host)? The e2e is copied from the request, so this will never be a problem unless the server misbehaves. MESSAGE PROCESSING PeerA PeerB | | | Request 1 | |------------------------>| | Request 2 | |------------------------>| | | | DPR | |------------------------>| (PeerB still processing Requests 1,2) | | In the scenario above is it mandatory for PeerB to send Answers 1,2 before DPA or is it implementation dependent? only as far as it can. If they are available, it would be a good idea. However, chances are PeerA is shutting down anyways and will not accept those answers. So, I'm not sure that it makes sense to send them. What do other folks think? From owner-aaa-wg@merit.edu Mon Aug 6 04:09:33 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18996 for ; Mon, 6 Aug 2001 04:09:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 14C7091287; Mon, 6 Aug 2001 04:05:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DC5B91285; Mon, 6 Aug 2001 04:05: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 576A791287 for ; Mon, 6 Aug 2001 04:05:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D0805DDAB; Mon, 6 Aug 2001 04:05:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 793545DD9A for ; Mon, 6 Aug 2001 04:05:28 -0400 (EDT) Received: (qmail 7573 invoked by uid 500); 6 Aug 2001 07:54:18 -0000 Date: Mon, 6 Aug 2001 00:54:18 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Accounting questions Message-ID: <20010806005417.M7242@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 > > Q1- > > If the service only makes use of the Accounting portion, > but besides, > > it requires multiple accounting sub-sessions ( constant > Session-Id but > > a different Accounting-Session-Id ), how is this session signaled as > > being terminated ? > > It seems that we can't do it in the current spec. Is this needed? > If you have some resources to release, you should propably be > using other Diameter portions as well. If you don't have resources > to release, you might just rely on the fact that since you didn't > receive an accounting information any more there are no further > sessions. The specific application that produces the sessions > and subsessions might also specify something about how to determine > the true end. Possibly separate termination cause values might > be used. In fact, the latter is perhaps what I would recommend. > If an application produces subsessions, it should have some > sort of an AVP that defines why the subsession ended, and that > could take on values such as > > 1 - user moved from this base station to another > 2 - user terminated the whole call > > Comments? Each accounting message must contain a session-id. Furthermore, it may contain an accounting-session-id, which is used to identify subsessions within that accounting session. Each subsession MUST be considered independent, which means that they each have a termination condition, which is a STOP message for each subsession. That means that each accounting subsession should remain active until it receives a STOP message. That's the normal case. So, the following text should be added: "Each accounting message must contain a session-id, which basically identifies an accounting session on the accounting server. Furthermore, it may contain an accounting-session-id, which would be used to identify a subsession within that accounting session. Each subsession MUST be considered independent of each other, within the same session-id. An accounting message that would define only a session-id, without an Accounting-session-id AVP, MUST be considered by the accounting server as being an accounting-session-id of 0. All applications that use the accounting subsessions in Diameter MUST communicate their termination conditions to the accounting server through the means of an accounting message, indicating either an EVENT_RECORD or a STOP_RECORD in the Accounting-Record-Type AVP." Well there is an inconsistency in the base specification since the Accounting-Session-Id definition in 9.8.4 states that this AVP must only be used for RADIUS backward compatibility, while section 9.6 clearly defines what you state above. Therefore, if this is really the intended use of the Accounting-Session-Id, then I would claim that we should create a new AVP that clearly states that it is used for subsessions, and fix up the state machine accordingly. The question that Guillermo had was more related to the fact that once an Accounting session is started, it seems impossible to close the accounting session unless we receive an accounting stop, at least according to the Accounting session state-machine (section 8.2). What should we count on for closing the accounting session, in fact an accounting subsession, in the case that we never receive any more messages, and obviously not a STOP? If subsessions are used, then I would argue that each subsession MUST have a START and STOP. Otherwise, I am not sure how a server could know when a session has been relinquished. > > Is still applicable the "Accounting Session State Machine" > in chapter 10.2 ? > > > > Q2- > > Are Accounting-Record-Numbers unique within the session ( > Session-Id ) > > or unique within the accounting sub-session > (Accounting-Session-Id ) ? > > The current text doesn't specify this clearly. I would propose that > the record numbers keep increasing, i.e. subsessions don't > reuse record > numbers. I would appreciate if you could make very clear in the draft, that a client MUST send accounting messages using an increasing Record-number. It must be stated in the draft, that record-numbers of subsequent accounting messages must be incremental. That means that when a client sends an accounting message to an accounting server, it MUST keep on incrementing the record number for each accounting message sent for a particular accounting session. That implies that an accounting server MUST consider the accounting message for a particular accounting subsession as containing the latest valid accounting data, based on the highest Record-number received. For example, let's say an accounting server has received accounting messages so that it has 2 accounting-session-id for the same session-id. That would mean that 2 accounting subsessions are active for that session-id. In that case, the client MUST keep on increasing the record-number between all messages sent to the accounting server for that session-id. So, in the accounting server, each subsession would hand up receiving several accounting message, for which the only check that is required in the accounting server would be that the last accounting data stored has a record-number lower than the latest received. Otherwise, it should not be overwriting the existing data, since the accounting data is made of cumulative data. The current spec in section 9.8.3 states: "The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and Accounting-Record-Number AVPs is also globally unique, and can be used in matching accounting records with confirmations. An easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD, and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD." The above clearly states that an Accounting-Record-Number is unique across the same Session-Id. So a specific record number cannot be used across subsessions for a given Session-Id. > Here's a suggested 'issue' submission for the above problems: > > Subsession accounting unclarities > Submitter name: Guillermo Guardia-Lozano / Jari Arkko > Submitter email address: Jari.Arkko@ericsson.com > Date first submitted: July 6, 2001 > Reference: > http://www.merit.edu/mail.archives/aaa-wg/2001-07/msg00010.htm l Document: base Comment type: T Priority: 1 Section: 9 Rationale/Explanation of issue: 1) Unclear about when the whole session ends for an application that uses only Diameter accounting, and has subsessions 2) Unclear about when record numbers reset for subsessions 3) Unclear about Accounting-Session-Id and Accounting-Multi-Session-Id mandatory/optional status in the ABNF Requested change: 1) Add the following text after the second paragraph of 9.6: "Each accounting message must contain a session-id, which basically identifies an accounting session on the accounting server. Furthermore, it may contain an accounting-session-id, which would be used to identify a subsession within that accounting session. An accounting message that would define only a session-id, without an Accounting-session-id AVP, MUST be considered by the accounting server as being an accounting-session-id of 0. All applications that use the accounting subsessions in Diameter MUST communicate their termination conditions to the accounting server through the means of an accounting message, indicating either an EVENT_RECORD or a STOP_RECORD in the Accounting-Record-Type AVP. Each subsession MUST be considered independent of each other, within the same session-id." OK 2) Add the following text to the end of 9.8.3: "Record-numbers of subsequent accounting messages must be incremental. That means that when a client sends an accounting message to an accounting server, it MUST keep on incrementing the record number for each accounting message sent for a particular accounting session. That implies that an accounting server MUST consider the accounting message for a particular accounting subsession as containing the latest valid accounting data, based on the highest Record-number received." not sure this is absolutely required, but if folks think it helps, I'll add the text. For example, let's say an accounting server has received accounting messages so that it has 2 accounting-session-id for the same session-id. That would mean that 2 accounting subsessions are active for that session-id. In that case, the client MUST keep on increasing the record-number between all messages sent to the accounting server for that session-id. So, in the accounting server, each subsession would hand up receiving several accounting message, for which the only check that is required in the accounting server would be that the last accounting data stored has a record-number lower than the latest received. Otherwise, it should not be overwriting the existing data, since the accounting data is made of cumulative data. 3) Make Accounting-Session-Id optional in the ABNF, add Accounting-Multi-Session-Id to the ABNF, and mention in 9.8.4 the use of Accounting-Session-Id also for subsessions. as well as some text in the state machine. PatC From owner-aaa-wg@merit.edu Mon Aug 6 04:30: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 EAA19359 for ; Mon, 6 Aug 2001 04:30:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FCC191261; Mon, 6 Aug 2001 04:30:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F4A491262; Mon, 6 Aug 2001 04:30: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 4D58D91261 for ; Mon, 6 Aug 2001 04:30:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1ACD5DDC5; Mon, 6 Aug 2001 04:30:17 -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 58DE55DDB4 for ; Mon, 6 Aug 2001 04:30:17 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f768UHO19001 for ; Mon, 6 Aug 2001 10:30:17 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Aug 06 10:30:16 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 10:30:16 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA2D@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , aaa-wg@merit.edu Cc: "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Accounting questions Date: Mon, 6 Aug 2001 10:30:08 +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 See comments. > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Monday, August 06, 2001 9:54 AM > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Accounting questions > > > > > Q1- > > > If the service only makes use of the Accounting portion, > > but besides, > > > it requires multiple accounting sub-sessions ( constant > > Session-Id but > > > a different Accounting-Session-Id ), how is this session > signaled as > > > being terminated ? > > > > It seems that we can't do it in the current spec. Is this needed? > > If you have some resources to release, you should propably be > > using other Diameter portions as well. If you don't have resources > > to release, you might just rely on the fact that since you didn't > > receive an accounting information any more there are no further > > sessions. The specific application that produces the sessions > > and subsessions might also specify something about how to determine > > the true end. Possibly separate termination cause values might > > be used. In fact, the latter is perhaps what I would recommend. > > If an application produces subsessions, it should have some > > sort of an AVP that defines why the subsession ended, and that > > could take on values such as > > > > 1 - user moved from this base station to another > > 2 - user terminated the whole call > > > > Comments? > > Each accounting message must contain a session-id. > Furthermore, it may contain an accounting-session-id, > which is used to identify subsessions within that > accounting session. Each subsession MUST be > considered independent, which means that they each > have a termination condition, which is a STOP message > for each subsession. That means that each accounting > subsession should remain active until it receives a > STOP message. That's the normal case. > > So, the following text should be added: > > "Each accounting message must contain a session-id, > which basically identifies an accounting session > on the accounting server. Furthermore, it may > contain an accounting-session-id, which would be > used to identify a subsession within that accounting > session. Each subsession MUST be considered > independent of each other, within the same session-id. > > An accounting message that would define only a > session-id, without an Accounting-session-id AVP, > MUST be considered by the accounting server as being > an accounting-session-id of 0. > > All applications that use the accounting subsessions > in Diameter MUST communicate their termination conditions > to the accounting server through the means of an > accounting message, indicating either an EVENT_RECORD > or a STOP_RECORD in the Accounting-Record-Type AVP." > > Well there is an inconsistency in the base > specification since the > Accounting-Session-Id definition in 9.8.4 states that this > AVP must only > be used for RADIUS backward compatibility, while section 9.6 clearly > defines what you state above. Therefore, if this is really > the intended > use of the Accounting-Session-Id, then I would claim that we should > create a new AVP that clearly states that it is used for subsessions, > and fix up the state machine accordingly. > I think it is needed as well. That would be great! > The question that Guillermo > had was more related to the fact that once an > Accounting session is started, it seems impossible > to close the accounting session unless we receive an > accounting stop, at least according to the Accounting > session state-machine (section 8.2). > What should we count on for closing the accounting > session, in fact an accounting subsession, in the case > that we never receive any more messages, and obviously > not a STOP? > > If subsessions are used, then I would argue that each subsession MUST > have a START and STOP. Otherwise, I am not sure how a server > could know > when a session has been relinquished. > > > > Is still applicable the "Accounting Session State Machine" > > in chapter 10.2 ? > > > > > > Q2- > > > Are Accounting-Record-Numbers unique within the session ( > > Session-Id ) > > > or unique within the accounting sub-session > > (Accounting-Session-Id ) ? > > > > The current text doesn't specify this clearly. I would propose that > > the record numbers keep increasing, i.e. subsessions don't > > reuse record > > numbers. > > I would appreciate if you could make very clear in > the draft, that a client MUST send accounting messages > using an increasing Record-number. It must be > stated in the draft, that record-numbers > of subsequent accounting messages must be incremental. > > That means that when a client sends an accounting > message to an accounting server, it MUST keep on > incrementing the record number for each accounting > message sent for a particular accounting session. > That implies that an accounting server MUST consider > the accounting message for a particular accounting > subsession as containing the latest valid accounting > data, based on the highest Record-number received. > > For example, let's say an accounting server has > received accounting messages so that it has 2 > accounting-session-id for the same session-id. > That would mean that 2 accounting subsessions > are active for that session-id. In that case, > the client MUST keep on increasing the record-number > between all messages sent to the accounting server > for that session-id. So, in the accounting server, > each subsession would hand up receiving several > accounting message, for which the only check that > is required in the accounting server would be that > the last accounting data stored has a record-number > lower than the latest received. Otherwise, it should > not be overwriting the existing data, since the > accounting data is made of cumulative data. > > The current spec in section 9.8.3 states: > > "The Accounting-Record-Number AVP (AVP Code 485) is of type > Unsigned32 and identifies this record within one session. As > Session-Id AVPs are globally unique, the combination of > Session-Id and Accounting-Record-Number AVPs is also globally > unique, and can be used in matching accounting records with > confirmations. An easy way to produce unique numbers is > to set the value to 0 for records of type EVENT_RECORD > and START_RECORD, and set the value to 1 for the first > INTERIM_RECORD, 2 for the second, and so on until > the value for STOP_RECORD is one more than for the > last INTERIM_RECORD." > > The above clearly states that an Accounting-Record-Number is unique > across the same Session-Id. So a specific record number cannot be used > across subsessions for a given Session-Id. I would like to get a "MUST" for the increasing order of record-numbers. The problem is that it seems difficult for the accounting server to identify the latest accounting information, unless there is some kind of indication in the accounting message that brings it. So, by using the Accounting-Record-Number, it is easy for the accounting server to discard older Accounting-Record-Number received after a later one for the same session-id, in case of retries on the network that would make some accounting messages being delayed and received in the wrong order in the accounting server. The thing is also that accounting data is cumulative, and the accounting server is required to keep only the latest data. > > Here's a suggested 'issue' submission for the above problems: > > > > Subsession accounting unclarities > > Submitter name: Guillermo Guardia-Lozano / Jari Arkko > > Submitter email address: Jari.Arkko@ericsson.com > > Date first submitted: July 6, 2001 > > Reference: > > http://www.merit.edu/mail.archives/aaa-wg/2001-07/msg00010.htm > l > Document: base > Comment type: T > Priority: 1 > Section: 9 > Rationale/Explanation of issue: > > 1) Unclear about when the whole session ends for an application > that uses only Diameter accounting, and has subsessions > 2) Unclear about when record numbers reset for subsessions > 3) Unclear about Accounting-Session-Id and > Accounting-Multi-Session-Id > mandatory/optional status in the ABNF > > Requested change: > > 1) Add the following text after the second paragraph of > 9.6: > > "Each accounting message must contain a session-id, > which basically identifies an accounting session > on the accounting server. Furthermore, it may > contain an accounting-session-id, which would be > used to identify a subsession within that accounting > session. > > An accounting message that would define only a > session-id, without an Accounting-session-id AVP, > MUST be considered by the accounting server as being > an accounting-session-id of 0. > > All applications that use the accounting subsessions > in Diameter MUST communicate their termination conditions > to the accounting server through the means of an > accounting message, indicating either an EVENT_RECORD > or a STOP_RECORD in the Accounting-Record-Type AVP. > > Each subsession MUST be considered independent of > each other, within the same session-id." > > OK > > 2) Add the following text to the end of 9.8.3: > > "Record-numbers of subsequent accounting messages must be > incremental. > > That means that when a client sends an accounting > message to an accounting server, it MUST keep on > incrementing the record number for each accounting > message sent for a particular accounting session. > That implies that an accounting server MUST consider > the accounting message for a particular accounting > subsession as containing the latest valid accounting > data, based on the highest Record-number received." > > not sure this is absolutely required, but if folks > think it helps, > I'll add the text. > I'd appreciate. > > For example, let's say an accounting server has > received accounting messages so that it has 2 > accounting-session-id for the same session-id. > That would mean that 2 accounting subsessions > are active for that session-id. In that case, > the client MUST keep on increasing the record-number > between all messages sent to the accounting server > for that session-id. So, in the accounting server, > each subsession would hand up receiving several > accounting message, for which the only check that > is required in the accounting server would be that > the last accounting data stored has a record-number > lower than the latest received. Otherwise, it should > not be overwriting the existing data, since the > accounting data is made of cumulative data. > > 3) Make Accounting-Session-Id optional in the ABNF, add > Accounting-Multi-Session-Id to the ABNF, and mention in > 9.8.4 the use of Accounting-Session-Id also for subsessions. > > as well as some text in the state machine. > > PatC > > From owner-aaa-wg@merit.edu Mon Aug 6 04:35: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 EAA19411 for ; Mon, 6 Aug 2001 04:35:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 852C091226; Mon, 6 Aug 2001 04:36:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5941C91262; Mon, 6 Aug 2001 04:36: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 44B4491226 for ; Mon, 6 Aug 2001 04:36:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BAA85DDB4; Mon, 6 Aug 2001 04:36:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 9EDD95DD9A for ; Mon, 6 Aug 2001 04:36:40 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 08:36:38 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010806011048.00c3cec0@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 02:27:10 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] DiameterIdentity Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: August 5, 2001 Reference: Document: Base-07 Comment type: T Priority: 1 Section: throughout Rationale/Explanation of issue: There apparently is a lot of confusion surrounding DiameterIdentity, due to its two very different uses: 1. as a way to designate some way to access a Diameter agent, by (implicity or explicitly) specifying a FQDN, port, protocol and transport. This shall be used in configuration files, Alternate-Host and Redirect-Host AVPs, etc. Note that there might be *a lot* of different DiameterIdentity values that actually designate the same Diameter agent (as an agent might listen on multiple ports and addresses, using multiple protocols, and there might be many FQDNs pointing to any of those addresses). 2. as a way to uniquely identify a given agent for the purposes of duplicate connection detection, loop detection, etc. In this case, the identifier must be unique, and should be considered completely opaque by other servers that should do a pure binary comparison. To alleviate this confusion, I propose to separate the current DiameterIdentity derived AVP format into two different formats: 1. the DiameterURI format, using the existing syntax. Used in config files, Alternate-Host and Redirect-Host AVPs... 2. the DiameterIdentity format, using a new syntax, the only purpose of which is to make sure it is unique (and as a side effect, a lot shorter, which should help a lot in Route-Record and Source-Route AVPs). Proposed changes: In 2.6, replace the Host identity section with: - Host URI, following the conventions described for the DiameterURI derived AVP data format in section 4.4. This MAY be found by static configuration, or dynamically updated via any of the methods described in section 5.2. Note that there might be multiple DiameterURIs resolving to the same peer. - Host Identity. Following the conventions described for the DiameterIdentity derived AVP data format in section 4.4. This is copied from the Origin-Host AVP of the CER or CEA message received from the peer. In 4.4, replace the DiameterIdentity section with: DiameterURI The DiameterURI format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [29] rules specified below: Diameter-URI = fqdn [ port ] [ transport ] [ protocol ] aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol ; is diameter. fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (TBD) is ; assumed. transport-protocol = ( "tcp" | "sctp" | "udp" ) transport = ";transport=" transport-protocol ; One of the transports used to listen ; for incoming connections. If absent, ; the default SCTP [26] protocol is ; assumed. UDP MUST NOT be used when ; the aaa-protocol field is set to ; diameter. The following are examples of valid Diameter host identities: host.abc.com;transport=tcp host.abc.com:6666;transport=tcp aaa://host.abc.com;protocol=diameter aaa://host.abc.com:6666;protocol=diameter aaa://host.abc.com:6666;transport=tcp;protocol=diameter aaa://host.abc.com:1813;transport=udp;protocol=radius A DiameterURI describes a way to connect to any Diameter agent. It shall be used in configuration files, Alternate-Host and Redirect-Host AVPs, etc. DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uniquely identifies a Diameter agent, for the purposes of loop and duplication connection detection. Upon startup, the agent must select one specific (address, transport, port) tuple it is listening on for new connections, and encode the associated information in one of the formats described below. Since only one single process can be listening on a given (address, transport, port) tuple, the identity is guaranteed to be unique (see below for non-unique addresses). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved(0) | Protocol | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format is used for agents listening on IPv4 addresses only. Protocol is the protocol number of the transport used, i.e. XXX for TCP or XXX for SCTP. The 'Port' and 'IPv4 Address' fields contain the port and IPv4 address selected, respectively, in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved(0) | Protocol | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format is used for agents listening on at least one unique (i.e. not link-local, etc.) IPv6 address. If the agent is listening on both IPv4 and IPv6 addresses, it should select a tuple with an IPv6 address. 'IPv6 address' contains that value. The other fields have the same meaning as above. Note that these formats are guaranteed to be unique only for hosts that have unique IP addresses, i.e. not for hosts that use RFC1918 "private" IP addresses. Hosts using RFC1918 addresses MUST append a unique IP addresses (administratively configurable) that is related to the routing domain they're part of, such as the public IP address of the host acting as a gateway to the public Internet. A DiameterIdentity value is thus either 8, 20, 24, or 36 bytes long, depending on the presence of one or two addresses, each of which can be 4 bytes (IPv4) or 16 bytes (IPv6) long. Other formats can be used, as long as the binary reprensentation is globally unique for any given host. This requires the use of values other than 0 for the "reserved" field, which should then be registered with IANA. Any use of AVPs using the DiameterIdentity format MUST consider their contents as opaque. Any comparison MUST be purely binary (i.e. two values are equal if they have the same length and all bytes match; in all other cases they're not equal). An ordered comparison is also defined in section 5.6.4. In 5.3.8, s/Identity/URI/ In 6.4, remove 3rd paragraph. Replace 6.8.1 with: The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the CER or CEA message received from the peer. In 6.12, s/Identity/URI/ In 8.8, either: - s/Identity/URI/ + some wording to say it's one of the URIs designated the host, - or use decimal-encoded Identity - or move to purely binary Some other changes might be needed in the other drafts. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Aug 6 04:48: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 EAA19736 for ; Mon, 6 Aug 2001 04:48:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D9F391262; Mon, 6 Aug 2001 04:49:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FF6691263; Mon, 6 Aug 2001 04:48:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D6EB91262 for ; Mon, 6 Aug 2001 04:47:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2266D5DDB4; Mon, 6 Aug 2001 04:47:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D4B3A5DD9A for ; Mon, 6 Aug 2001 04:47:38 -0400 (EDT) Received: (qmail 8444 invoked by uid 500); 6 Aug 2001 08:36:28 -0000 Date: Mon, 6 Aug 2001 01:36:28 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] CHAP-Password is complex Message-ID: <20010806013628.W7242@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: August 6th, 2001 Reference: Document: NASREQ 07 Comment type: T Priority: S Section: 3.1.1.2 Rationale/Explanation of issue: The definition of the CHAP-Password AVP in -07 still shows up as being of type complex. This needs to be changed to a Grouped AVP, and some additional text on how RADIUS<->Diameter translation is needed. Requested change: Make the AVP Grouped From owner-aaa-wg@merit.edu Mon Aug 6 05:02: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 FAA20012 for ; Mon, 6 Aug 2001 05:02:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0B5C91263; Mon, 6 Aug 2001 05:03:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4A6E91264; Mon, 6 Aug 2001 05:03: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 31C1C91263 for ; Mon, 6 Aug 2001 05:02:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF2575DDA4; Mon, 6 Aug 2001 05:02:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A5A265DD9A for ; Mon, 6 Aug 2001 05:02:32 -0400 (EDT) Received: (qmail 8550 invoked by uid 500); 6 Aug 2001 08:51:18 -0000 Date: Mon, 6 Aug 2001 01:51:18 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Accounting-Session-Id definition incorrect Message-ID: <20010806015118.Y7242@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: August 6th, 2001 Reference: Document: NASREQ 07 Comment type: T Priority: S Section: 9.8.4 Rationale/Explanation of issue: The definition of the Accounting-Session-Id states that this AVP is only used for RADIUS gateway purposes, but other text in the draft shows that this AVP is used to identify Accounting subsessions. Requested change: Leave Accounting-Session-Id as-is, and create a new AVP called Accounting-Sub-Session-Id, and change the necessary text. From owner-aaa-wg@merit.edu Mon Aug 6 05:03:54 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 FAA20030 for ; Mon, 6 Aug 2001 05:03:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7038191264; Mon, 6 Aug 2001 05:04:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A3AF91267; Mon, 6 Aug 2001 05:04: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 EBB7C91264 for ; Mon, 6 Aug 2001 05:04:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D04F15DDA4; Mon, 6 Aug 2001 05:04: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 7C2765DD9A for ; Mon, 6 Aug 2001 05:04:23 -0400 (EDT) Received: (qmail 8564 invoked by uid 500); 6 Aug 2001 08:53:12 -0000 Date: Mon, 6 Aug 2001 01:53:12 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Remove support for Source-Route Message-ID: <20010806015312.Z7242@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: August 6th, 2001 Reference: Document: NASREQ 07 Comment type: T Priority: S Section: Rationale/Explanation of issue: Support for explicit paths for server-initiated messages was added in -07. Discussions I have had with folks this week show that consensus is that this feature is overly complex, and we should instead require that the network is configured properly. Requested change: Go back to -06 way of server initiated messages. From owner-aaa-wg@merit.edu Mon Aug 6 09:01:08 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22635 for ; Mon, 6 Aug 2001 09:01:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 941E29125C; Mon, 6 Aug 2001 09:00:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61F2E91268; Mon, 6 Aug 2001 09:00: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 416729125C for ; Mon, 6 Aug 2001 09:00:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 279B35DDE1; Mon, 6 Aug 2001 09:00:49 -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 92F955DDD3 for ; Mon, 6 Aug 2001 09:00:48 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f76CwAl06313; Mon, 6 Aug 2001 08:58:10 -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 xma006311; Mon, 6 Aug 01 08:58:03 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f76D0d309688; Mon, 6 Aug 2001 09:00:39 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma009560; Mon, 6 Aug 01 08:59:24 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Aug 2001 08:59:19 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Comments on Issue 102 Date: Mon, 6 Aug 2001 08:59:18 -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've been looking over issue 102, and the request is to add some > descriptive text to clarify what each state means. However, the peer > state machine does not have such text. At one point there was > a section > that described each state, but this seemed superfluous, and was later > removed. What is present is a description of the events and Sorry. I should have read it more carefully. :( > actions. The > state tables in 8.1 and 8.2 have very descriptive events, so perhaps > Yiwen was looking for more text on the actual actions? Well, I was actually looking for text on the *state*, esp. for Close and Discon states. I was confused in thinking Discon was related to the disconnection of a peer to peer connection, rather than a disconnection of a session (shouldn't we call that termination of session?) I think issue 104 clarifies this in describing the differences between the session and peer connections. If we could maybe have a statement on the what these two states mean, it would be great. My interpretation of the difference between the two, is that Disconn is an intermediate close state. After the shutting down session request gets acknowledged, the state becomes Closed, which means one user session is terminated, and the corresponding session ID becomes invalid? Also, what is the difference between Active and Open state? Is it the Active state does not require STR/STA or ASR/ASA? The event "Service to user is terminated" implies that either the Authentication-Lifetime had expired or if this AVP was set to be zero, the user session is terminated immediately because of the usage of Auth-Session-State? Thanks! From owner-aaa-wg@merit.edu Mon Aug 6 10:01: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 KAA23584 for ; Mon, 6 Aug 2001 10:01:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 30B759126D; Mon, 6 Aug 2001 10:00:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2CF49126E; Mon, 6 Aug 2001 10:00: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 9FF2F9126D for ; Mon, 6 Aug 2001 10:00:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D0265DDED; Mon, 6 Aug 2001 10:00:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 7F3DC5DDB5 for ; Mon, 6 Aug 2001 10:00:17 -0400 (EDT) Received: (qmail 21997 invoked by uid 500); 6 Aug 2001 14:00:36 -0000 Date: Mon, 6 Aug 2001 09:00:36 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Issue 100 Message-ID: <20010806090036.M19599@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010806005119.I7242@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: <20010806005119.I7242@charizard.diameter.org>; from pcalhoun@diameter.org on Mon, Aug 06, 2001 at 12:51:19AM -0700 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Since the diameter port *could* get really strange traffic, I do several other error checks in my diameter parser, that all return errors with the error bit set: o Packet Length != Transport Reported Packet Length -- Only works with SCTP. o Any reserved bit set. o AVP with reserved bit set. o AVP with Length > reported payload length. When any of these things occur, I stop parsing immediately, and return an error. On Mon, Aug 06, 2001 at 12:51:19AM -0700, Pat Calhoun wrote: > Here are my comments on issue 100: > > > > In 3.0 > > - Commands flags, r(eserved): should state that an error must be > generated > > if a packet is received with such a bit set to one. > > So my proposed text is: > > r(eserved) - this flag bit is reserved for future use, and MUST > be > set to zero, otherwise an error MUST be sent to the sender. > > I thought about adding more details here, but it really seems > unnecessary. By looking at the Result-Code AVP, one can quickly > determine which error to use. > > > In 3.3: > > - 1st paragraph: "Diameter commands typically start with an object > name". > > Not that sure :-) > > - 2nd paragraph: "The corresponding answer MUST contain either a > positive > > or negative result code". What about multi-round trip messages, and > redirects? > > Yes, I guess this section actually needed more of a re-write than > anything else. Here's my proposed text: > > " Diameter commands typically includes one or more English words > followed > by the verb Request or Answer. Each English word is delimited by a > hyphen. > An acronym for both the request and answer is also normally provided. > > An example is a message set used to terminate a session. The command > name is > Session-Terminate-Request and Session-Terminate-Answer, while the > acronyms > Are STR and STA, respectively. > > Both the request and the answer for a given command share the same > command code. The request is identified by the R(equest) bit in the > Diameter header set to one (1). The request is sent to a peer to > request that a particular action be performed, such as authorizing a > user or terminating a session. Once the receiver has completed the > request it issues the corresponding answer, which includes a result > code > that communicates one of the following: > > - The request was successful > - The request failed > - An additional request must be sent to provide information the > peer requires prior to returning a successful or failed answer. > - The receiver could not process the request, but provides > information about a Diameter peer that is able to satisfy the > request, known as redirect. > > Additional information, encoded within AVPs, MAY also be included > in answer messages." > > > In 4.0: > > - 1st paragraph: "Diameter AVPs carry specific authentication, > accounting > > and authorization information, security information as well as > > configuration details..." They can also carry routing information > (unless > > that's what is meant by "configuration details". > > My new proposed text reads: > > " Diameter AVPs carry specific authentication, accounting, > authorization, routing and security information as well as > configuration details for the request and reply." > > > In 4.1: > > - AVP Code: "The first 256 AVP numbers are reserved for backward > > compatibility with RADIUS". Even if Vendor-Id is non-zero? > > Proposed text: > " The first 256 AVP numbers, with the Vendor-Id set to zero (0) > are reserved for backward compatibility with RADIUS..." > > > - AVP Flags, "Note that subsequent Diameter applications MAY define > > additional bits within the AVP Header, and an unrecognized bit SHOULD > be > > considered an error". Didn't find an error number for that one in > 7.1.x. > > ok, here's the new result-code value: > DIAMETER_INVALID_AVP_BITS TBD > A request was received that included an AVP whose flag bits > are set to an unrecognized value, or that is inconsistent > with the AVP's definition. > > > - AVP Flags, 2nd paragraph, "If an unrecognized AVP with the 'M' bit > set is > > received by a Diameter node..." replace node with "client, server or > > proxy". The client thing raises the issue stated in the 7.1.4/7.1.5 > section > > about errors in answers, though. Also, it should not be only if the > AVP is > > unrecognized, but also if the requested AVP or value is recognized, > but the > > node does not accept it. > > Check, so the new text would read: > > " The 'M' Bit, known as the Mandatory bit, indicates whether support of > the AVP is required. If an AVP with the 'M' bit set is received by a > Diameter client, server or proxy and either the AVP or its value is > unrecognized, the message MUST be rejected. Diameter Relay and > Redirector agents MUST NOT reject messages with unrecognized AVPs." > > > - AVP Flags, 3rd paragraph, "In order to provide service to the user, > the > > node at fault MUST re-issue...". The client might decide that if the > server > > doesn't understand that AVP, it doesn't want to provide service to the > > > user. Make that explicit rather than implicit. > > Ok, added the following text to the end of the paragraph: > > "Alternatively, the node at fault MAY decide to simply not provide > service to the user." > > > - AVP Flags, 4th paragraph, add a comma between "ABNF" and "is at > fault". > > - AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are > > informational only and a receiver that receives a message with such an > AVP > > that is not supported MAY simply ignore the AVP." The AVP might be > > supported but not the value, and it could be ignored also, right? Same > > > thing if the AVP and value are supported but the node does not want to > > > honor that AVP or value. > > Well, isn't ignoring an AVP also mean its value is ignored? I'm not sure > that I follow your logic here :( > > > In 4.3, > > - the definitions for Float32, 64 and 128 are truncated: "'V' bit is > > enabled)." is missing. > Hmmm... an nroff bug. Fixed. > > > In 4.4, > > - 1st paragraph, "In addition to the AVP Base Data Formats" -> "In > addition > > to *using* the AVP Base Data Formats". > > Why? > > > - 1st paragraph, "New AVP Derived Data Formats MUST be registered with > > > IANA." How could they be registered? There is no "unique identifier" > or > > anything of the sort. And since the AVP contents are actually opaque > to > > those that are not involved, I don't quite see the need. They should > just > > be defined in any application that uses them. Also, if they must > indeed be > > registered, a section in 11.x is missing. > > You are correct, and the two paragraphs have been modified to a single > Paragraph, which reads as: > > " In addition to the AVP Base Data Formats, applications may define > data formats derived from the AVP Base Data Formats. An application > that defines new AVP Derived Data Formats MUST include them in a > section entitled "AVP Derived Data Formats", using the same format > as the definitions below. Each new definition must be either defined > or > listed with a reference to the RFC that defines the format." > > > - IPAddress, what if an AVP must explicitly have an IPv4 or IPv6, and > not > > "any of those"? > > Then I suspect that the actual AVP would need to state that clearly. We > don't > To my knowledge, have any such AVPs, though. > > > - UTF8String, 1st paragraph, reference wrong [24] not [29] (it might > be a > > good thing to actually check all refs) > > hmmm.... I thought I had at one point, but I guess another time around > before > I submit the next revision. Thanks for the heads up, though. > > > - DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise > different > > identities...". Glurgs! Certainly not! It MUST be the same identity on > all > > connections (unless the host is a gateway between two routing domains > (e.g. > > private and public)). Otherwise there's no way to detect duplicate > > connections, loops, etc. consistently. Remember, the DiameterIdentity, > as > > used in CER/CEA and Route-Records is just considered as an opaque and > > unique identifier. > > Damn, I knew making that Route-Record change was a bad idea, and would > bite > us in the ... later :( Ok, so in my case where I'm talking about two > identities > because of a public vs. private routing domain split, what should we do? > > > - DiameterIdentity, 5th paragraph, this is not needed in duplicate > > connection detection and loop avoidance, since the identifier is > opaque. It > > can save time, however, when one gets an external reference to another > host > > (via SLP, DNS, Redirect, Alternate-Host...) and one wants to check > that > > this new host doesn't match one it already knows/already is connected > to. > > But even if that's not done, a match would be detected upon connection > to > > the new host when the CER/CEAs are exchanged and the "real" (unique) > > identity is discovered and can be matched against existing > connections. > > So you are stating that this paragraph can be deleted, and in no > circumstances will > we ever have a situation where a node will have to parse another peer's > identity? > > > - IPFilterRule, 2nd to last paragraph, "An access device that is > unable to > > interpret or apply a deny rule MUST terminate the session." Shouldn't > this > > be dependent on whether the M bit is set or not? Ditto for the second > > sentence (though it's probably not as important). > > Hmmmm..... this is a change that I feel uncomfortable just making as an > editorial change. What do other folks think? > > > - QOSFilterRule: I thought the idea was to reference an IPFilterRule > to > > determine what traffic should be marked or metered? > > No, we decided that adding QoS to the IPFilterRule format would overload > that format. > > > In 4.5: > > - 1st paragraph, swap the ' and the . in 'Grouped.' > > Sorry, but I cannot for the life of me find the text you are referring > to :( > > > - 3rd paragraph, "All AVPs included in a Grouped AVP Every Grouped AVP > > > defined...". Either something is missing before the Every, or the all > > before the Every is not needed. > > The latter > > > > > In 4.5.1: > > - in the paragraph starting with "The data for the optional AVPs...", > why > > is is stated that "AVPs do not have to begin on 8 byte boundaries"? It > is > > true, but I quite see why people would think it? > > Don't know why that sentence fragment was there, but it has been removed > since not only was it unnecessary, but it sure as hell was confusing. > > > In 4.6: > > - in the table, what if a flag is in neither column for a given AVP > (e.g. P > > is often absent) > > There's another issue officially opened on this one, so I'll just ignore > this comment and address it in the formal issue, which is more complete. > > > - here also, what about renumbering everything in a contiguous space? > > Sure. Next time I happen to be standing on my head for an extended > period of time. Seriously, it would be nice, but at this point I was to > minimize the changes to decrease the changes of introducing new bugs. > That would be one sure way to do it. > > > - checking section references would be a good idea, but I'm way to > lazy for > > that. > > I've done that recently, but I'll do it once more when I also check the > references. > > > In 5.1: > > - 1st paragraph, specify that this "per realm" rather than globally? > Though > > there is the issue of proxies that serve many many realms (with > different > > peers), and dynamically learned realms/peers. > > Paragraph changed to: > > " 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 per > realm, > and MAY have additional connections, if it is deemed necessary. Note > that > a given peer MAY act as a primary for a given realm, while acting as > a > secondary for another realm." > > > in 5.3: > > - 5th paragraph, "Since the CER/CEA messages...", replace "an > upstream" > > with "a". > > But that would be grammatically incorrect :( > > > In 7.1.2: > > - DIAMETER_LIMITED_SUCCESS: "When returned, the request was > successfully > > completed, but additional processing is required by the application in > > > order to provide service to the user." Gni? What is that? > > If you look at the Mobile IP application, it will be clear. > Unfortunately, it's rather > Difficult to describe here :( The basic idea is that the server says > yes, but you have > Additional application level stuff to do. > > > > > > In 7.1.3: > > - DIAMETER_INVALID_ROUTE_RECORD is no longer needed. > > ok > > - DIAMETER_REDIRECT_INDICATION might be better off in the > informational types? > > Well, it requires local action, perhaps even by a relay (e.g. not the > NAS, but its > First hop agent). > > > > > In 7.1.4/7.1.5: > > - I'm still not quite sure of the distinction between permanent and > > transient. e.g. DIAMETER_AUTHENTICATION_REJECTED [which is transient, > so > > can be retried] means the request can be retried after asking the user > for > > its password again. So it's not actually the same request, right? On > the > > other hand, DIAMETER_AVP_UNSUPPORTED and DIAMETER_INVALID_AVP_VALUE > [which > > are permanent, so shouldn't be retried] imply that you can retry by > > removing the AVP or changing the value [that's actually the > > "content-negociation" part of Diameter]. > > Actually, we might be better off with some category that includes > anything > > that means neither Accepted nor Refused, but rather "more to come" > (which > > would include both the multi-round-trip auths and other capabilities > > negociation messages). > > Also, what if an error is detected on the answer rather than the > request? > > Ditto for capabilities negociation in that direction (e.g. if server > says > > "please set this feature to that value for that user" and client or > proxy > > want to say "don't know what you're talking about/don't want to do > that"). > > Hmmm.... that's a whole lotta stuff, and I'm not sure exactly where you > are going with it :( > > PatC > From owner-aaa-wg@merit.edu Mon Aug 6 17:40:17 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02515 for ; Mon, 6 Aug 2001 17:40:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB8D19127E; Mon, 6 Aug 2001 17:40:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D78B9127F; Mon, 6 Aug 2001 17:40: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 7B1859127E for ; Mon, 6 Aug 2001 17:40:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 573EB5DDBE; Mon, 6 Aug 2001 17:40:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id 0EB015DD8C for ; Mon, 6 Aug 2001 17:40:36 -0400 (EDT) Received: from ip137.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.137) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 21:40:31 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010806224545.00cce2c0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 22:53:02 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Comments on Issue 111 Cc: aaa-wg@merit.edu In-Reply-To: <20010806005009.G7242@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, You still need to make sure a CEA is sent before disconnecting the peer, e.g. in Wait-Returns/R-Conn-CER. Also, in Wait-Returns, aren't you supposed to have a "Lose-Election"? Actually, since Wait-Returns only handles the result of the election, you shouldn't have any of the other events there (the state machine never stays in that state waiting for anything to happen). I know I've already been told no on that one, but I would still add something about an election tie (i.e. connected to oneself). That's it for now... Jacques. At 09:50 06/08/01, Pat Calhoun wrote: >All, > >Below is my proposed peer state machine to address this issue. The fix >is actually different from the proposed fix, since we cannot simply >remove R-Disc or I-Disc, since these events can occur when a peer fails. >The fix is to add new events for receiving the DPR and DPA, and includes >a new interim state, called Closing. > >Comments most appreciated (need to make sure I didn't mess this one up). >If you have a state machine validator, and you know who you are, then >this message is for you :) > >PatC >---- > >state event action next state >----------------------------------------------------------------- >Closed Start I-Snd-Conn-Req Wait-Conn-Ack > R-Conn-CER R-Accept, R-Open > Process_CER, > R-Snd-CEA > >Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA > I-Rcv-Conn-Nack Cleanup Closed > R-Conn-CER R-Accept, Wait-Conn-Ack/ > Process-CER Elect > Timeout Error Closed > >Wait-I-CEA I-Rcv-CEA Process-CEA I-Open > R-Conn-CER R-Accept, Wait-Returns > Process-CER, > Elect > I-Peer-Disc I-Disc Closed > I-Rcv-DPR I-Snd-DPA Closing > I-Rcv-Non-CEA Error Closed > Timeout Error Closed > >Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns >Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open > R-Peer-Disc R-Disc Wait-Conn-Ack > R-Rcv-DPR R-Snd-DPA, Wait-Conn-Ack > R-Disc > R-Conn-CER R-Reject Wait-Conn-Ack/ > Elect > Timeout Error Closed > >Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > I-Rcv-DPR I-Snd-DPA, R-Open > R-Snd-CEA > I-Rcv-CEA R-Snd-DPR I-Open > R-Peer-Disc R-Disc Wait-I-CEA > R-Rcv-DPR R-Snd-DPA, Wait-I-CEA > R-Disc > R-Conn-CER R-Reject Wait-Returns > Timeout Error Closed > >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-Reject R-Open > 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 > >Closing I-Rcv-DPA I-Disc Closed > R-Rcv-DPA R-Disc Closed > Timeout Error Closed _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Aug 6 17:40:24 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02535 for ; Mon, 6 Aug 2001 17:40:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1F169127F; Mon, 6 Aug 2001 17:40:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 888B891281; Mon, 6 Aug 2001 17:40: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 68A369127F for ; Mon, 6 Aug 2001 17:40:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2FE935DDBE; Mon, 6 Aug 2001 17:40:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id DB4F45DD8C for ; Mon, 6 Aug 2001 17:40:45 -0400 (EDT) Received: from ip137.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.137) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 21:40:41 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010806225619.00cc7980@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 23:21:02 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Comments on Issue 100 Cc: aaa-wg@merit.edu In-Reply-To: <20010806005119.I7242@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 09:51 06/08/01, Pat Calhoun wrote: > An example is a message set used to terminate a session. The command >name is ...*the* message set... ...command names are... > Session-Terminate-Request and Session-Terminate-Answer, while the >acronyms > Are STR and STA, respectively. > > Both the request and the answer for a given command share the same > command code. The request is identified by the R(equest) bit in the > Diameter header set to one (1). The request is sent to a peer to > request that a particular action be performed, such as authorizing a request -> ask? Not terrific, but the repetition is not terrific either... > user or terminating a session. > - AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are > > informational only and a receiver that receives a message with such an >AVP > > that is not supported MAY simply ignore the AVP." The AVP might be > > supported but not the value, and it could be ignored also, right? Same > > > thing if the AVP and value are supported but the node does not want to > > > honor that AVP or value. > >Well, isn't ignoring an AVP also mean its value is ignored? I'm not sure >that I follow your logic here :( "...and a receiver that receives a message with such an AVP that is not supported *or the value of which is not supported* MAY simply..." > > In 4.4, > > - 1st paragraph, "In addition to the AVP Base Data Formats" -> "In >addition > > to *using* the AVP Base Data Formats". > >Why? Mmmm. Because the alternative is to define (verb), so it there should be a verb also? Really not important, though, just sounded better :-) > > - DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise >different > > identities...". Glurgs! Certainly not! It MUST be the same identity on >all > > connections (unless the host is a gateway between two routing domains >(e.g. > > private and public)). Otherwise there's no way to detect duplicate > > connections, loops, etc. consistently. Remember, the DiameterIdentity, >as > > used in CER/CEA and Route-Records is just considered as an opaque and > > unique identifier. > >Damn, I knew making that Route-Record change was a bad idea, and would >bite >us in the ... later :( I don't quite see what Route-Record change you're talking about, but anyway, see the issue I posted this morning about DiameterIdentity/DiameterURI that should make things less confusing. > > - DiameterIdentity, 5th paragraph, this is not needed in duplicate > > connection detection and loop avoidance, since the identifier is >opaque. It > > can save time, however, when one gets an external reference to another >host > > (via SLP, DNS, Redirect, Alternate-Host...) and one wants to check >that > > this new host doesn't match one it already knows/already is connected >to. > > But even if that's not done, a match would be detected upon connection >to > > the new host when the CER/CEAs are exchanged and the "real" (unique) > > identity is discovered and can be matched against existing >connections. > >So you are stating that this paragraph can be deleted, and in no >circumstances will >we ever have a situation where a node will have to parse another peer's >identity? See other issue. > > - IPFilterRule, 2nd to last paragraph, "An access device that is >unable to > > interpret or apply a deny rule MUST terminate the session." Shouldn't >this > > be dependent on whether the M bit is set or not? Ditto for the second > > sentence (though it's probably not as important). > >Hmmmm..... this is a change that I feel uncomfortable just making as an >editorial change. What do other folks think? I think we need server to client authorization AVPs negotiation. Issue coming up. > > - QOSFilterRule: I thought the idea was to reference an IPFilterRule >to > > determine what traffic should be marked or metered? > >No, we decided that adding QoS to the IPFilterRule format would overload >that format. Right, but I meant: - one defines several sets of traffic to match with multiple IPFilterRules - then defines a QOSFilterRule that says "for traffic matching the first IPFilterRule, mark with this tag; for traffic matching the seconf IPFilterRule, mark with this other tag; etc.". Requires a way to reference an IPFilterRule though (unless Grouped-AVPs are used?). > > In 4.5: > > - 1st paragraph, swap the ' and the . in 'Grouped.' > >Sorry, but I cannot for the life of me find the text you are referring >to :( 1st line: The Diameter protocol allows AVP values of type 'Grouped.' This -> The Diameter protocol allows AVP values of type 'Grouped'. This Sorry, years of proof-reading are surfacing :-/ > > in 5.3: > > - 5th paragraph, "Since the CER/CEA messages...", replace "an >upstream" > > with "a". > >But that would be grammatically incorrect :( Hu? Don't think so? "...it is still possible that a proxy receives a message..." > > Also, what if an error is detected on the answer rather than the >request? > > Ditto for capabilities negociation in that direction (e.g. if server >says > > "please set this feature to that value for that user" and client or >proxy > > want to say "don't know what you're talking about/don't want to do >that"). > >Hmmm.... that's a whole lotta stuff, and I'm not sure exactly where you >are going with it :( I'm going to open an issue with it :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Aug 6 17:40:42 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02557 for ; Mon, 6 Aug 2001 17:40:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BF8D91283; Mon, 6 Aug 2001 17:41:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4B8A91288; Mon, 6 Aug 2001 17:40: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 375B191283 for ; Mon, 6 Aug 2001 17:40:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 122195DDDD; Mon, 6 Aug 2001 17:40:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id 8DC6B5DDD3 for ; Mon, 6 Aug 2001 17:40:53 -0400 (EDT) Received: from ip137.zurich28.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.28.137) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 21:40:50 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010806225404.00c90a00@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 23:23:51 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Comments on Issue 104 Cc: aaa-wg@merit.edu In-Reply-To: <20010806005052.H7242@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 09:50 06/08/01, Pat Calhoun wrote: > between the Relay and the Server. User session x spans from the Client > via the Relay to the Server. Each "user" of a service causes an auth > request to be sent, with a unique session identifier. Once accepted by ...with a session identifier unique to that user? Otherwise it might sound like the session identifier is unique to an auth request (a transaction)? > the server, both the client and the server are aware of the session. > It is important to note that there is no relationship between a connection > and a session, and that Diameter messages for multiple sessions are all > multiplexed through a single connection. Otherwise it looks all good! :-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Aug 6 17:42: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 RAA02648 for ; Mon, 6 Aug 2001 17:42:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBB9691280; Mon, 6 Aug 2001 17:43:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9975891281; Mon, 6 Aug 2001 17:43: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 8941B91280 for ; Mon, 6 Aug 2001 17:43:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A9D95DDBE; Mon, 6 Aug 2001 17:43:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id E44F35DD8C for ; Mon, 6 Aug 2001 17:43:30 -0400 (EDT) Received: from ip248.zurich31.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.31.248) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 21:43:27 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 23:36:48 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Remove support for Source-Route Cc: aaa-wg@merit.edu In-Reply-To: <20010806015312.Z7242@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I don't quite see how it is so complex. It is nothing more than Destination-Host extended to all intermediate nodes, with backup (Alternate-Host). Actually, we should remove Destination-Host :-) If properly integrated in the text of 6.1, it will appear as natural as the Destination-Host routing. Jacques. At 10:53 06/08/01, Pat Calhoun wrote: >Submitter name: Pat Calhoun >Submitter email address: pcalhoun@diameter.org >Date first submitted: August 6th, 2001 >Reference: >Document: NASREQ 07 >Comment type: T >Priority: S >Section: >Rationale/Explanation of issue: >Support for explicit paths for server-initiated messages was added in >-07. Discussions I have had with folks this week show that consensus >is that this feature is overly complex, and we should instead require >that the network is configured properly. > >Requested change: >Go back to -06 way of server initiated messages. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Mon Aug 6 18:35: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 SAA03549 for ; Mon, 6 Aug 2001 18:35:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A16091285; Mon, 6 Aug 2001 18:36:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51F9291288; Mon, 6 Aug 2001 18:36: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 45D0E91285 for ; Mon, 6 Aug 2001 18:36:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1BAF35DDBB; Mon, 6 Aug 2001 18:36:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 4F4735DDAA for ; Mon, 6 Aug 2001 18:36:18 -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 SAA05980; Mon, 6 Aug 2001 18:35:11 -0400 (EDT) Date: Mon, 6 Aug 2001 18:36:38 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Cc: tony.johansson@ericsson.com Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP In-Reply-To: <20010802152046.I20321@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I wanted to give some input on issue 109. Issue 109 states that there is overhead involved in having to create a sample missing AVP. That is true. The suggested fix is to create a Missing-AVP of type integer to hold the missing AVP. There is one problem with this. If the AVP is vendor specific, you need to create a new Missing-Vendor-AVP to hold the vendor ID. If there is a vendor specific and an IETF AVP missing, you would have to somehow group them. So now you have to create a grouped avp to hold the Missing-AVP and the Missing-Vendor-AVP. In my opinion the overhead of creating a some fake data for the payload is much less than the extra overhead listed above. -mark From owner-aaa-wg@merit.edu Mon Aug 6 18:44: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 SAA03613 for ; Mon, 6 Aug 2001 18:44:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8289C91289; Mon, 6 Aug 2001 18:45:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD2B9128B; Mon, 6 Aug 2001 18:45:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1BA091289 for ; Mon, 6 Aug 2001 18:45:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C1185DDB7; Mon, 6 Aug 2001 18:45:07 -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 02C4B5DDAA for ; Mon, 6 Aug 2001 18:45:05 -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 SAA06141 for ; Mon, 6 Aug 2001 18:43:59 -0400 (EDT) Date: Mon, 6 Aug 2001 18:45:26 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: FilterRule Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Section 4.11 of draft-ietf-aaa-diameter-mobileip-07.txt says MIP-Filter-Rule AVP is of type FilterRule. I can't find that defined. Should it be IPFilterRule? If so, does this qualify as an issue, or can it be squeezed in under the umbrella of "editorial comments"? -mark From owner-aaa-wg@merit.edu Mon Aug 6 18:47: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 SAA03648 for ; Mon, 6 Aug 2001 18:47:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2FA7B9128A; Mon, 6 Aug 2001 18:47:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 037CE9128B; Mon, 6 Aug 2001 18:47:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 305869128A for ; Mon, 6 Aug 2001 18:47:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DBEF5DDB7; Mon, 6 Aug 2001 18:47:29 -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 42B895DDAA for ; Mon, 6 Aug 2001 18:47:28 -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 SAA06206 for ; Mon, 6 Aug 2001 18:46:21 -0400 (EDT) Date: Mon, 6 Aug 2001 18:47:48 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: FilterRule In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Sorry, I should have checked issues.html before sending out this question. It is issue 108. -mark On Mon, 6 Aug 2001, Mark Eklund wrote: > Section 4.11 of draft-ietf-aaa-diameter-mobileip-07.txt says > MIP-Filter-Rule AVP is of type FilterRule. I can't find that > defined. Should it be IPFilterRule? If so, does this qualify > as an issue, or can it be squeezed in under the umbrella of > "editorial comments"? > > -mark > > From owner-aaa-wg@merit.edu Tue Aug 7 04:49: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 EAA28056 for ; Tue, 7 Aug 2001 04:49:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 415ED91292; Tue, 7 Aug 2001 04:50:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04DFA91293; Tue, 7 Aug 2001 04:50: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 DCBA091292 for ; Tue, 7 Aug 2001 04:50:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BB315DDC8; Tue, 7 Aug 2001 04:50: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 29ED35DDC6 for ; Tue, 7 Aug 2001 04:50:09 -0400 (EDT) Received: (qmail 12622 invoked by uid 500); 7 Aug 2001 08:38:54 -0000 Date: Tue, 7 Aug 2001 01:38:54 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Remove support for Source-Route Message-ID: <20010807013854.D12506@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010806015312.Z7242@charizard.diameter.org> <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Aug 06, 2001 at 11:36:48PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Conversations I've had with numerous folks is that configuration for the reverse direction should be required, and they see no need to have a Source-Route mechanism. Furthermore, having the Alternate-Peer to handle the case where a box is no longer reachable, is rather complex. If configuration alone was used, and a box became unreachable, normal Diameter routing would ensure that the packet was sent to its destination. PatC On Mon, Aug 06, 2001 at 11:36:48PM +0200, Jacques Caron wrote: > Hi, > > I don't quite see how it is so complex. It is nothing more than > Destination-Host extended to all intermediate nodes, with backup > (Alternate-Host). Actually, we should remove Destination-Host :-) > > If properly integrated in the text of 6.1, it will appear as natural as the > Destination-Host routing. > > Jacques. > > At 10:53 06/08/01, Pat Calhoun wrote: > >Submitter name: Pat Calhoun > >Submitter email address: pcalhoun@diameter.org > >Date first submitted: August 6th, 2001 > >Reference: > >Document: NASREQ 07 > >Comment type: T > >Priority: S > >Section: > >Rationale/Explanation of issue: > >Support for explicit paths for server-initiated messages was added in > >-07. Discussions I have had with folks this week show that consensus > >is that this feature is overly complex, and we should instead require > >that the network is configured properly. > > > >Requested change: > >Go back to -06 way of server initiated messages. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Tue Aug 7 04:57: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 EAA28136 for ; Tue, 7 Aug 2001 04:57:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7BF6891293; Tue, 7 Aug 2001 04:58:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47A4391295; Tue, 7 Aug 2001 04:58:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3573091293 for ; Tue, 7 Aug 2001 04:58:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10A935DDC6; Tue, 7 Aug 2001 04:58:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7A8FE5DD8C for ; Tue, 7 Aug 2001 04:58:07 -0400 (EDT) Received: (qmail 12679 invoked by uid 500); 7 Aug 2001 08:46:50 -0000 Date: Tue, 7 Aug 2001 01:46:50 -0700 From: Pat Calhoun To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: FilterRule Message-ID: <20010807014650.H12506@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 Mon, Aug 06, 2001 at 06:45:26PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk I believe that someone already brought this up, since I have already fixed it. PatC On Mon, Aug 06, 2001 at 06:45:26PM -0400, Mark Eklund wrote: > Section 4.11 of draft-ietf-aaa-diameter-mobileip-07.txt says > MIP-Filter-Rule AVP is of type FilterRule. I can't find that > defined. Should it be IPFilterRule? If so, does this qualify > as an issue, or can it be squeezed in under the umbrella of > "editorial comments"? > > -mark > From owner-aaa-wg@merit.edu Tue Aug 7 05:01: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 FAA28180 for ; Tue, 7 Aug 2001 05:01:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 152FB91295; Tue, 7 Aug 2001 05:02:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6D2291296; Tue, 7 Aug 2001 05:02: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 6737D91295 for ; Tue, 7 Aug 2001 05:02:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41E2D5DDCE; Tue, 7 Aug 2001 05:02:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id B5FDD5DDC8 for ; Tue, 7 Aug 2001 05:02:12 -0400 (EDT) Received: from client62-2-82-70.hispeed.ch (HELO jc.yahoo.com) (62.2.82.70) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 09:02:11 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010807105113.00d002c0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 11:02:00 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Remove support for Source-Route Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010807013854.D12506@charizard.diameter.org> References: <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com> <20010806015312.Z7242@charizard.diameter.org> <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, The issues I see with using realms on the way back are: 1. Overloading of "realms". For me, realms contain users (name@realm), not devices (name.realm). Hence, a server might handle a realm for users, and be part of a different "domain". Or vice-versa. 2. If there are provisions for making sure subsequent messages are routed to the same server, I don't see why we shouldn't have the same thing for intermediate proxies (in both directions). This being said, I think it is quite easy to replace the Destination-Host routing with source route (more or less, :g/Destination-Host/s//Source-Route/g + removing the last Source-Route AVP in the list before forwarding). Do that, and you will see it is really not that complex at all. Also, we could remove support for Alternate-Peer (or make that optional), and fallback to "regular" routing when a host on the path is unreachable (then of course it will work only if appropriate routing info is present). Personally, I like very much the idea that the first request in a session "discovers" the path to the home server, and then all subsequent messages in that session, in both directions, all follow the same path until broken. I'm not a fan of proxies that require this, but I have this strange feeling that we will definitely need it and will be very sorry if we don't include support for that in some way. But I guess most of the others don't agree with me :-( Jacques. At 10:38 07/08/01, Pat Calhoun wrote: >Conversations I've had with numerous folks is that configuration for >the reverse direction should be required, and they see no need to >have a Source-Route mechanism. Furthermore, having the Alternate-Peer >to handle the case where a box is no longer reachable, is rather >complex. If configuration alone was used, and a box became unreachable, >normal Diameter routing would ensure that the packet was sent to its >destination. > >PatC > >On Mon, Aug 06, 2001 at 11:36:48PM +0200, Jacques Caron wrote: > > Hi, > > > > I don't quite see how it is so complex. It is nothing more than > > Destination-Host extended to all intermediate nodes, with backup > > (Alternate-Host). Actually, we should remove Destination-Host :-) > > > > If properly integrated in the text of 6.1, it will appear as natural as > the > > Destination-Host routing. > > > > Jacques. > > > > At 10:53 06/08/01, Pat Calhoun wrote: > > >Submitter name: Pat Calhoun > > >Submitter email address: pcalhoun@diameter.org > > >Date first submitted: August 6th, 2001 > > >Reference: > > >Document: NASREQ 07 > > >Comment type: T > > >Priority: S > > >Section: > > >Rationale/Explanation of issue: > > >Support for explicit paths for server-initiated messages was added in > > >-07. Discussions I have had with folks this week show that consensus > > >is that this feature is overly complex, and we should instead require > > >that the network is configured properly. > > > > > >Requested change: > > >Go back to -06 way of server initiated messages. > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 05:02: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 FAA28206 for ; Tue, 7 Aug 2001 05:02:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B87FB91296; Tue, 7 Aug 2001 05:03:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C56891297; Tue, 7 Aug 2001 05:03: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 4D62A91296 for ; Tue, 7 Aug 2001 05:03:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27D765DDCA; Tue, 7 Aug 2001 05:03: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 C0C295DDC8 for ; Tue, 7 Aug 2001 05:03:05 -0400 (EDT) Received: (qmail 12706 invoked by uid 500); 7 Aug 2001 08:51:52 -0000 Date: Tue, 7 Aug 2001 01:51:52 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Issue 102 Message-ID: <20010807015151.I12506@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , 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 Yiwen.Jiang@tic.siemens.ca on Mon, Aug 06, 2001 at 08:59:18AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > actions. The > > state tables in 8.1 and 8.2 have very descriptive events, so perhaps > > Yiwen was looking for more text on the actual actions? > Well, I was actually looking for text on the *state*, esp. for Close and > Discon states. I was confused in thinking Discon was related to the > disconnection of a peer to peer connection, rather than a disconnection of a > session (shouldn't we call that termination of session?) I think issue 104 > clarifies this in describing the differences between the session and peer > connections. > > If we could maybe have a statement on the what these two states mean, it > would be great. My interpretation of the difference between the two, is that > Disconn is an intermediate close state. After the shutting down session > request gets acknowledged, the state becomes Closed, which means one user > session is terminated, and the corresponding session ID becomes invalid? correct. > > Also, what is the difference between Active and Open state? Is it the Active > state does not require STR/STA or ASR/ASA? The event "Service to user is > terminated" implies that either the Authentication-Lifetime had expired or > if this AVP was set to be zero, the user session is terminated immediately > because of the usage of Auth-Session-State? Open -> state is being managed Active -> state is not managed I'll make sure that it is clearer in the draft. PatC From owner-aaa-wg@merit.edu Tue Aug 7 05:40:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28782 for ; Tue, 7 Aug 2001 05:40:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B75F491297; Tue, 7 Aug 2001 05:41:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8515391298; Tue, 7 Aug 2001 05:41:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6299E91297 for ; Tue, 7 Aug 2001 05:41:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47F125DDC8; Tue, 7 Aug 2001 05:41:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D807B5DD8C for ; Tue, 7 Aug 2001 05:41:05 -0400 (EDT) Received: (qmail 12821 invoked by uid 500); 7 Aug 2001 09:29:51 -0000 Date: Tue, 7 Aug 2001 02:29:51 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Remove support for Source-Route Message-ID: <20010807022951.A12806@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com> <20010806015312.Z7242@charizard.diameter.org> <4.3.2.7.2.20010806233419.00ca5b10@pop.mail.yahoo.com> <20010807013854.D12506@charizard.diameter.org> <4.3.2.7.2.20010807105113.00d002c0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010807105113.00d002c0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Aug 07, 2001 at 11:02:00AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Aug 07, 2001 at 11:02:00AM +0200, Jacques Caron wrote: > Hi, > > The issues I see with using realms on the way back are: > > 1. Overloading of "realms". For me, realms contain users (name@realm), not > devices (name.realm). Hence, a server might handle a realm for users, and > be part of a different "domain". Or vice-versa. > > 2. If there are provisions for making sure subsequent messages are routed > to the same server, I don't see why we shouldn't have the same thing for > intermediate proxies (in both directions). > > This being said, I think it is quite easy to replace the Destination-Host > routing with source route (more or less, > :g/Destination-Host/s//Source-Route/g + removing the last Source-Route AVP > in the list before forwarding). Do that, and you will see it is really not > that complex at all. There is a fundamental difference between Source-Route and Destination-Host. The latter is used to ensure that a message can be predictably sent to the *final* Diameter node. The former is used to ensure that the path can be enforced, modulo the fact that some of nodes encoded in the route encoded may not be reachable, and therefore alternates must be advertised. INHO, there is an order of magnitude of complexity in complexity between the two, and we need to really understand whether the complexity is warranted. Of the folks that I've heard from, they didn't think this feature was all that useful, and configuration would be sufficient. > Also, we could remove support for Alternate-Peer (or make that optional), > and fallback to "regular" routing when a host on the path is unreachable > (then of course it will work only if appropriate routing info is present). but encoding a route will not work if a node in the route fails. Normal routing works great in the typical case because the message will be routed regardless of any unavailable nodes in the network. However, if a route is stated, and one of the nodes in the path is not accessible, then the message would not be delivered. So there is a clear difference. > > Personally, I like very much the idea that the first request in a session > "discovers" the path to the home server, and then all subsequent messages > in that session, in both directions, all follow the same path until broken. > I'm not a fan of proxies that require this, but I have this strange feeling > that we will definitely need it and will be very sorry if we don't include > support for that in some way. You may be right, but if we provide the framework to support this, it certainly will be used. Otherwise, it will most likely not. > But I guess most of the others don't agree with me :-( only on this one particular issue :) PatC From owner-aaa-wg@merit.edu Tue Aug 7 05:43: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 FAA28811 for ; Tue, 7 Aug 2001 05:43:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AFFE91298; Tue, 7 Aug 2001 05:44:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AB0A91299; Tue, 7 Aug 2001 05:44: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 F078991298 for ; Tue, 7 Aug 2001 05:44:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D45FE5DD9E; Tue, 7 Aug 2001 05:44:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 683005DD8C for ; Tue, 7 Aug 2001 05:44:43 -0400 (EDT) Received: (qmail 12858 invoked by uid 500); 7 Aug 2001 09:33:24 -0000 Date: Tue, 7 Aug 2001 02:33:24 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Issue 111 Message-ID: <20010807023324.C12806@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010806005009.G7242@charizard.diameter.org> <4.3.2.7.2.20010806224545.00cce2c0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010806224545.00cce2c0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Aug 06, 2001 at 10:53:02PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk check. If I read your comment properly, this particular problem has nothing to do with Issue 111. PatC On Mon, Aug 06, 2001 at 10:53:02PM +0200, Jacques Caron wrote: > Hi, > > You still need to make sure a CEA is sent before disconnecting the peer, > e.g. in Wait-Returns/R-Conn-CER. > > Also, in Wait-Returns, aren't you supposed to have a "Lose-Election"? > Actually, since Wait-Returns only handles the result of the election, you > shouldn't have any of the other events there (the state machine never stays > in that state waiting for anything to happen). I know I've already been > told no on that one, but I would still add something about an election tie > (i.e. connected to oneself). > > That's it for now... > > Jacques. > > At 09:50 06/08/01, Pat Calhoun wrote: > >All, > > > >Below is my proposed peer state machine to address this issue. The fix > >is actually different from the proposed fix, since we cannot simply > >remove R-Disc or I-Disc, since these events can occur when a peer fails. > >The fix is to add new events for receiving the DPR and DPA, and includes > >a new interim state, called Closing. > > > >Comments most appreciated (need to make sure I didn't mess this one up). > >If you have a state machine validator, and you know who you are, then > >this message is for you :) > > > >PatC > >---- > > > >state event action next state > >----------------------------------------------------------------- > >Closed Start I-Snd-Conn-Req Wait-Conn-Ack > > R-Conn-CER R-Accept, R-Open > > Process_CER, > > R-Snd-CEA > > > >Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA > > I-Rcv-Conn-Nack Cleanup Closed > > R-Conn-CER R-Accept, Wait-Conn-Ack/ > > Process-CER Elect > > Timeout Error Closed > > > >Wait-I-CEA I-Rcv-CEA Process-CEA I-Open > > R-Conn-CER R-Accept, Wait-Returns > > Process-CER, > > Elect > > I-Peer-Disc I-Disc Closed > > I-Rcv-DPR I-Snd-DPA Closing > > I-Rcv-Non-CEA Error Closed > > Timeout Error Closed > > > >Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns > >Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open > > R-Peer-Disc R-Disc Wait-Conn-Ack > > R-Rcv-DPR R-Snd-DPA, Wait-Conn-Ack > > R-Disc > > R-Conn-CER R-Reject Wait-Conn-Ack/ > > Elect > > Timeout Error Closed > > > >Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > I-Rcv-DPR I-Snd-DPA, R-Open > > R-Snd-CEA > > I-Rcv-CEA R-Snd-DPR I-Open > > R-Peer-Disc R-Disc Wait-I-CEA > > R-Rcv-DPR R-Snd-DPA, Wait-I-CEA > > R-Disc > > R-Conn-CER R-Reject Wait-Returns > > Timeout Error Closed > > > >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-Reject R-Open > > 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 > > > >Closing I-Rcv-DPA I-Disc Closed > > R-Rcv-DPA R-Disc Closed > > Timeout Error Closed > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Tue Aug 7 05:46: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 FAA28862 for ; Tue, 7 Aug 2001 05:46:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 944B29129E; Tue, 7 Aug 2001 05:46:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 139CA9129A; Tue, 7 Aug 2001 05:46:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F014891299 for ; Tue, 7 Aug 2001 05:46:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF53C5DD9E; Tue, 7 Aug 2001 05:46: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 833CB5DD8C for ; Tue, 7 Aug 2001 05:46:26 -0400 (EDT) Received: (qmail 12874 invoked by uid 500); 7 Aug 2001 09:35:12 -0000 Date: Tue, 7 Aug 2001 02:35:12 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Issue 104 Message-ID: <20010807023512.D12806@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010806005052.H7242@charizard.diameter.org> <4.3.2.7.2.20010806225404.00c90a00@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010806225404.00c90a00@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Aug 06, 2001 at 11:23:51PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk ok, I'll make that clarification. Thanks, PatC On Mon, Aug 06, 2001 at 11:23:51PM +0200, Jacques Caron wrote: > At 09:50 06/08/01, Pat Calhoun wrote: > > between the Relay and the Server. User session x spans from the Client > > via the Relay to the Server. Each "user" of a service causes an auth > > request to be sent, with a unique session identifier. Once accepted by > > ...with a session identifier unique to that user? Otherwise it might sound > like the session identifier is unique to an auth request (a transaction)? > > > the server, both the client and the server are aware of the session. > > It is important to note that there is no relationship between a connection > > and a session, and that Diameter messages for multiple sessions are all > > multiplexed through a single connection. > > Otherwise it looks all good! :-) > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Tue Aug 7 05: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 FAA28946 for ; Tue, 7 Aug 2001 05:53:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2EF9591299; Tue, 7 Aug 2001 05:53:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEC229129A; Tue, 7 Aug 2001 05:53: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 CE67591299 for ; Tue, 7 Aug 2001 05:53:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A04695DDC8; Tue, 7 Aug 2001 05:53: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 C52B75DDC6 for ; Tue, 7 Aug 2001 05:53:48 -0400 (EDT) Received: (qmail 12893 invoked by uid 500); 7 Aug 2001 09:42:34 -0000 Date: Tue, 7 Aug 2001 02:42:34 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Comments on Issue 100 Message-ID: <20010807024234.E12806@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <20010806005119.I7242@charizard.diameter.org> <4.3.2.7.2.20010806225619.00cc7980@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010806225619.00cc7980@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Mon, Aug 06, 2001 at 11:21:02PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Aug 06, 2001 at 11:21:02PM +0200, Jacques Caron wrote: > At 09:51 06/08/01, Pat Calhoun wrote: > > An example is a message set used to terminate a session. The command > >name is > ...*the* message set... > ...command names are... > > > Session-Terminate-Request and Session-Terminate-Answer, while the > >acronyms > > Are STR and STA, respectively. > > > > Both the request and the answer for a given command share the same > > command code. The request is identified by the R(equest) bit in the > > Diameter header set to one (1). The request is sent to a peer to > > request that a particular action be performed, such as authorizing a > > request -> ask? Not terrific, but the repetition is not terrific either... what repetition? Is this text already covered? > > > user or terminating a session. > > > > - AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are > > > informational only and a receiver that receives a message with such an > >AVP > > > that is not supported MAY simply ignore the AVP." The AVP might be > > > supported but not the value, and it could be ignored also, right? Same > > > > > thing if the AVP and value are supported but the node does not want to > > > > > honor that AVP or value. > > > >Well, isn't ignoring an AVP also mean its value is ignored? I'm not sure > >that I follow your logic here :( > > "...and a receiver that receives a message with such an AVP that is not > supported *or the value of which is not supported* MAY simply..." check. > > > - DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise > >different > > > identities...". Glurgs! Certainly not! It MUST be the same identity on > >all > > > connections (unless the host is a gateway between two routing domains > >(e.g. > > > private and public)). Otherwise there's no way to detect duplicate > > > connections, loops, etc. consistently. Remember, the DiameterIdentity, > >as > > > used in CER/CEA and Route-Records is just considered as an opaque and > > > unique identifier. > > > >Damn, I knew making that Route-Record change was a bad idea, and would > >bite > >us in the ... later :( > > I don't quite see what Route-Record change you're talking about, but > anyway, see the issue I posted this morning about > DiameterIdentity/DiameterURI that should make things less confusing. I meant how loop detection is now done. > > > - IPFilterRule, 2nd to last paragraph, "An access device that is > >unable to > > > interpret or apply a deny rule MUST terminate the session." Shouldn't > >this > > > be dependent on whether the M bit is set or not? Ditto for the second > > > sentence (though it's probably not as important). > > > >Hmmmm..... this is a change that I feel uncomfortable just making as an > >editorial change. What do other folks think? > > I think we need server to client authorization AVPs negotiation. Issue > coming up. huh? This should be a very simple thing, and I don't see why any negotiation is required. I guess I'll see your intentions in your issue filing :( > > > > - QOSFilterRule: I thought the idea was to reference an IPFilterRule > >to > > > determine what traffic should be marked or metered? > > > >No, we decided that adding QoS to the IPFilterRule format would overload > >that format. > > Right, but I meant: > - one defines several sets of traffic to match with multiple IPFilterRules > - then defines a QOSFilterRule that says "for traffic matching the first > IPFilterRule, mark with this tag; for traffic matching the seconf > IPFilterRule, mark with this other tag; etc.". Requires a way to reference > an IPFilterRule though (unless Grouped-AVPs are used?). That's not what we had decided to do, since the default value for processing a packet that doesn't match an IPFilterRule set is for it to be dropped (in some cases). That would have devestating effects if the QoSFilter was to inherit this behavior. It seems like having this split it a much simpler approach, and will cause the least amount of confusion (but does admitedly increase the document size). > > > In 4.5: > > > - 1st paragraph, swap the ' and the . in 'Grouped.' > > > >Sorry, but I cannot for the life of me find the text you are referring > >to :( > > 1st line: > The Diameter protocol allows AVP values of type 'Grouped.' This > -> > The Diameter protocol allows AVP values of type 'Grouped'. This > > Sorry, years of proof-reading are surfacing :-/ check. > > > > in 5.3: > > > - 5th paragraph, "Since the CER/CEA messages...", replace "an > >upstream" > > > with "a". > > > >But that would be grammatically incorrect :( > > Hu? Don't think so? > "...it is still possible that a proxy receives a message..." wait, you are asking me to change "... an upstream" to "...a upstream". That is wrong. Or did I misunderstand you? PatC From owner-aaa-wg@merit.edu Tue Aug 7 07:47:23 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 HAA01476 for ; Tue, 7 Aug 2001 07:47:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DCD89129B; Tue, 7 Aug 2001 07:47:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33A229129C; Tue, 7 Aug 2001 07:47: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 050309129B for ; Tue, 7 Aug 2001 07:47:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DFB085DDC3; Tue, 7 Aug 2001 07:47:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 6368E5DDA9 for ; Tue, 7 Aug 2001 07:47:52 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 11:47:50 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010807133241.00c93650@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 13:34:20 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Comments on Issue 111 Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010807023324.C12806@charizard.diameter.org> References: <4.3.2.7.2.20010806224545.00cce2c0@pop.mail.yahoo.com> <20010806005009.G7242@charizard.diameter.org> <4.3.2.7.2.20010806224545.00cce2c0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Er, might be possible, I was offline when I wrote this, so I just went through the peer state machine as you requested :-) Jacques. At 11:33 07/08/01, Pat Calhoun wrote: >check. If I read your comment properly, this particular problem has >nothing to do with Issue 111. > >PatC >On Mon, Aug 06, 2001 at 10:53:02PM +0200, Jacques Caron wrote: > > Hi, > > > > You still need to make sure a CEA is sent before disconnecting the peer, > > e.g. in Wait-Returns/R-Conn-CER. > > > > Also, in Wait-Returns, aren't you supposed to have a "Lose-Election"? > > Actually, since Wait-Returns only handles the result of the election, you > > shouldn't have any of the other events there (the state machine never > stays > > in that state waiting for anything to happen). I know I've already been > > told no on that one, but I would still add something about an election tie > > (i.e. connected to oneself). > > > > That's it for now... > > > > Jacques. > > > > At 09:50 06/08/01, Pat Calhoun wrote: > > >All, > > > > > >Below is my proposed peer state machine to address this issue. The fix > > >is actually different from the proposed fix, since we cannot simply > > >remove R-Disc or I-Disc, since these events can occur when a peer fails. > > >The fix is to add new events for receiving the DPR and DPA, and includes > > >a new interim state, called Closing. > > > > > >Comments most appreciated (need to make sure I didn't mess this one up). > > >If you have a state machine validator, and you know who you are, then > > >this message is for you :) > > > > > >PatC > > >---- > > > > > >state event action next state > > >----------------------------------------------------------------- > > >Closed Start I-Snd-Conn-Req Wait-Conn-Ack > > > R-Conn-CER R-Accept, R-Open > > > Process_CER, > > > R-Snd-CEA > > > > > >Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA > > > I-Rcv-Conn-Nack Cleanup Closed > > > R-Conn-CER R-Accept, Wait-Conn-Ack/ > > > Process-CER Elect > > > Timeout Error Closed > > > > > >Wait-I-CEA I-Rcv-CEA Process-CEA I-Open > > > R-Conn-CER R-Accept, Wait-Returns > > > Process-CER, > > > Elect > > > I-Peer-Disc I-Disc Closed > > > I-Rcv-DPR I-Snd-DPA Closing > > > I-Rcv-Non-CEA Error Closed > > > Timeout Error Closed > > > > > >Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns > > >Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open > > > R-Peer-Disc R-Disc Wait-Conn-Ack > > > R-Rcv-DPR R-Snd-DPA, Wait-Conn-Ack > > > R-Disc > > > R-Conn-CER R-Reject Wait-Conn-Ack/ > > > Elect > > > Timeout Error Closed > > > > > >Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open > > > I-Rcv-DPR I-Snd-DPA, R-Open > > > R-Snd-CEA > > > I-Rcv-CEA R-Snd-DPR I-Open > > > R-Peer-Disc R-Disc Wait-I-CEA > > > R-Rcv-DPR R-Snd-DPA, Wait-I-CEA > > > R-Disc > > > R-Conn-CER R-Reject Wait-Returns > > > Timeout Error Closed > > > > > >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-Reject R-Open > > > 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 > > > > > >Closing I-Rcv-DPA I-Disc Closed > > > R-Rcv-DPA R-Disc Closed > > > Timeout Error Closed > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 07:47:35 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 HAA01494 for ; Tue, 7 Aug 2001 07:47:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B1DAD9129D; Tue, 7 Aug 2001 07:48:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F254D912A1; Tue, 7 Aug 2001 07:48:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FC3F9129D for ; Tue, 7 Aug 2001 07:47:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7AA335DDC3; Tue, 7 Aug 2001 07:47:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 30D825DDA9 for ; Tue, 7 Aug 2001 07:47:55 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 11:47:53 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010807133435.00cc1170@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 13:45:17 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Comments on Issue 100 Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010807024234.E12806@charizard.diameter.org> References: <4.3.2.7.2.20010806225619.00cc7980@pop.mail.yahoo.com> <20010806005119.I7242@charizard.diameter.org> <4.3.2.7.2.20010806225619.00cc7980@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 11:42 07/08/01, Pat Calhoun wrote: > > > Both the request and the answer for a given command share the same > > > command code. The request is identified by the R(equest) bit in the > > > Diameter header set to one (1). The request is sent to a peer to > > > request that a particular action be performed, such as authorizing a > > > > request -> ask? Not terrific, but the repetition is not terrific either... > >what repetition? Is this text already covered? "the request is sent to a peer to request..." :-( > > I think we need server to client authorization AVPs negotiation. Issue > > coming up. > >huh? This should be a very simple thing, and I don't see why any negotiation >is required. I guess I'll see your intentions in your issue filing :( Yep. Though I think I will file the issue first, and my solution later, since it seems awfully too complex :-( >That's not what we had decided to do, since the default value for processing >a packet that doesn't match an IPFilterRule set is for it to be dropped (in >some cases). That would have devestating effects if the QoSFilter was to >inherit this behavior. It seems like having this split it a much simpler >approach, and will cause the least amount of confusion (but does admitedly >increase the document size). Mmmm... I was thinking more like cisco(r)(tm) IOS(r)(tm)-type approach. Access-lists are used to classify packets into two categories: those that match (i.e. match a permit) and those that don't (i.e. match a deny or match nothing). Then depending on where the access-list is used, the two categories mean different things. If applied onto an interface directly, they mean "pass" and "drop" respectively. If applied within a QoS-type statement (e.g. rate-limit, or traffic-shape...), they mean "apply this QoS policy" and "don't do anything". Same thing for policy routing, etc. > > > > in 5.3: > > > > - 5th paragraph, "Since the CER/CEA messages...", replace "an > > >upstream" > > > > with "a". > > > > > >But that would be grammatically incorrect :( > > > > Hu? Don't think so? > > "...it is still possible that a proxy receives a message..." > >wait, you are asking me to change "... an upstream" to "...a upstream". >That is wrong. > >Or did I misunderstand you? You did. Replace "an upstream" with "a". I.e. remove the upstream, it just adds confusion (it is not clear upstream from what that node is). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 08:03: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 IAA01773 for ; Tue, 7 Aug 2001 08:03:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 109899129C; Tue, 7 Aug 2001 08:03:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC62B9129F; Tue, 7 Aug 2001 08:03: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 A5DDD9129C for ; Tue, 7 Aug 2001 08:03:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B6C25DDC6; Tue, 7 Aug 2001 08:03:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id F13485DDA9 for ; Tue, 7 Aug 2001 08:03:52 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 12:03:50 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 14:03:42 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: [Issue] Error processing/capabilities negotiation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: August 6, 2001 Reference: Document: Base-07 Comment type: E Priority: 1 Section: throughout Rationale/Explanation of issue: In the current draft, there are many situations where any agent can return an error when processing a message (e.g. when receiving an AVP tagged with the 'M' bit that it doesn' accept). However, there are no provisions for sending an error in response to an answer (an error is an answer, and can only be sent in response to a request). This makes it difficult to handle some cases, especially end-to-end capabilities negotiation (e.g. server wants access device to set up some filter, encryption, IP address, route..., but access devices cannot/will not do it: there is no way for the access device to communicate this back to the server). I think the best approach is to move from the simple Request/Answer model to a Transaction model possibly involving multiple round-trips until everybody is satisfied. Another possibility is for access devices to advertise their capabilities in advance in the initial request, but that might be quite difficult. Follows a (longish) description of one possible implementation using the Transaction model. I think most people might find it waaaaaay too complex, but: (a) it gives a clear understanding of the process and the several round-trips, why they are needed, and when. (b) there are hints at the end as to ways to simplify this A LOT :-) Creativity welcome :-) The following messages can be exchanged between two nodes: Msg Dir Description Expects ------ ---- --------------------------------------- --------------------------- REQ C->S request WMORE, AUTH, REJECT, ACCEPT MORE C->S error or additional information WMORE, AUTH, REJECT, ACCEPT NAUTH C->S auth not accepted, need new one AUTH, REJECT ACK C->S auth accepted ACCEPT ABORT C->S transaction abort REJECT WMORE S->C request for more information MORE, ABORT AUTH S->C authorization information ACK, NAUTH, ABORT REJECT S->C reject connection/non-recoverable error (nothing) ACCEPT S->C accept with negociated authorization (nothing) "server" and "client" are defined here solely in the context of the given transaction, the client being the node initiating the transaction, and the server being the node that is supposed to provide an answer. REQ is the first message of a transaction, including application, realm, etc. It is routed according to the realm routing table towards the server for regular access-device to home-server transactions, and using source-routing for home-server to access-device transactions. Routing information is collected on the way and stored in Route-Record AVPs. MORE is sent whenever the client needs to send additional or modified information in a transaction. It might be due to capabilities negociation (e.g. the server didn't understand an 'M'-AVP) or a multi-round-trip auth (e.g. EAP), that were signalled by the server using a WMORE message. NAUTH is sent whenever the client received authorization information (AUTH) for the transaction, but isn't satisfied with it (e.g. there is an 'M'-AVP that it doesn't accept). It includes the usual AVP-related info (missing AVP, bad AVP value, unrecognized AVP...), possibly with hints about accepted values (I like very much the modem AT command set extensions such as AT+command=? that give a list of allowed values, would be cool if we could have something equivalent here). ACK is sent once the client got authorization information for the transaction (AUTH) from the server, and is satisfied with it. ABORT is sent by the client if it got a WMORE message and cannot provide any new or modified information (e.g. the server didn't accept an 'M'-AVP, but the access device absolutely needs it), or got an AUTH message and doesn't accept some of the values and doesn't want to negotiate them. MORE, NAUTH, ACK, and ABORT are sent with Source-Route AVPs from the WMORE or ANS message. WMORE is sent by the server to the client if it needs the client to send additional or modified information (using a MORE message). It includes info about what it wants (e.g. further EAP messages, or modified AVPs). AUTH is sent by the server when it has any authorization information it wants to send the client. ACCEPT is sent by the server to the client to give a final yes, either directly after receiving info (REQ or MORE) if it only says "yes", or after receiving an ACK accepting previous AUTH information. REJECT is sent by the server to the client if the transaction was refused or if there was an unrecoverable error, or if the server got a NAUTH to an AUTH message and doesn't want to negotiate, or to confirm it got an ABORT. All messages from server to client (WMORE, AUTH, ACCEPT, REJECT) are routed using stored message state in proxies/relays. They also carry Route-Record information to help routing of further messages from client to server. Note that "authorization" (and of course AUTH and NAUTH) is an abuse, it's actually any negotiable AVPs the server sends to the client, but the only case I could think of is authorization information. So, in the simplest case, the scenario would be: REQ -> <- ACCEPT If there is any authorization information: REQ -> <- AUTH ACK -> <- ACCEPT In a simple 2-round trip EAP auth, the scenario might be: REQ -> <- WMORE MORE -> <- AUTH ACK -> <- ACCEPT In a simple one-round trip auth, but where the access devices doesn't agree with the authorization parameters the first time, it would be: REQ -> <- AUTH NAUTH -> <- AUTH ACK -> <- ACCEPT Server doesn't understand/accept an AVP the client sent, and the client doesn't want to do without: REQ -> <- WMORE ABORT -> <- REJECT Server thinks the access device is completely out of its mind, or knows right away the user is not allowed: REQ -> <- REJECT More generally, for a successful transaction: REQ -> [ <- WMORE MORE -> ]* [ <- AUTH [ NAUTH -> <- AUTH ]* ACK -> ]? <- ACCEPT Note that it may require adding a transaction identifier. Alternatively, the session identifier may be enough? On a final note, it might be possible to reduce the number of possible message types (by using some other AVP, e.g. different ranges of Result-Code), but it must be possible for relays/proxies to track a transaction state, i.e. know when it ends (by either a REJECT or an ACCEPT). All that is needed (as seen from the outside) are "Request" (anything client to server), "Continue" or "Challenge" (WMORE, AUTH) and "Answer" (REJECT, ACCEPT). This could be done by classifying correctly all Result-Codes that require further exchanges in a different range than those that don't. In particular, that means that any answer with negotiable AVPs should be in the first category, since they need another request to either accept them, or ask for changes. Jacques-in-complex-mode. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 08:24: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 IAA02115 for ; Tue, 7 Aug 2001 08:24:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4748D9129F; Tue, 7 Aug 2001 08:24:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14DF6912A0; Tue, 7 Aug 2001 08:24: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 F2DF69129F for ; Tue, 7 Aug 2001 08:24:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA03E5DDC6; Tue, 7 Aug 2001 08:24:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 733695DDA9 for ; Tue, 7 Aug 2001 08:24:55 -0400 (EDT) Received: (qmail 13406 invoked by uid 500); 7 Aug 2001 12:13:40 -0000 Date: Tue, 7 Aug 2001 05:13:40 -0700 From: Pat Calhoun To: Jacques Caron Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Error processing/capabilities negotiation Message-ID: <20010807051340.A13395@charizard.diameter.org> Mail-Followup-To: Jacques Caron , aaa-wg@merit.edu References: <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com>; from jacques_m_caron@yahoo.com on Tue, Aug 07, 2001 at 02:03:42PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Aug 07, 2001 at 02:03:42PM +0200, Jacques Caron wrote: > In the current draft, there are many situations where any agent can return > an error when processing a message (e.g. when receiving an AVP tagged with > the 'M' bit that it doesn' accept). However, there are no provisions for > sending an error in response to an answer (an error is an answer, and can > only be sent in response to a request). Right. So the spec states that if this should occur, the access device should terminate the session, via an STR. > > This makes it difficult to handle some cases, especially end-to-end > capabilities negotiation (e.g. server wants access device to set up some > filter, encryption, IP address, route..., but access devices cannot/will > not do it: there is no way for the access device to communicate this back > to the server). > > I think the best approach is to move from the simple Request/Answer model > to a Transaction model possibly involving multiple round-trips until > everybody is satisfied. Another possibility is for access devices to > advertise their capabilities in advance in the initial request, but that > might be quite difficult. This is not a requirement in RFC 2989, or in any of the requirements specs that were used to create RFC 2989. I would feel very uncomfortable redesigning the protocol this late in the game. IMHO, this isn't a problem. A request fails, then you ask again. An answer fails, then you terminate the session. You can ask again if necessary. > Jacques-in-complex-mode. I think I like the other Jacque better. Can you bring him back :) :) PatC From owner-aaa-wg@merit.edu Tue Aug 7 08:48: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 IAA02537 for ; Tue, 7 Aug 2001 08:48:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 74D8F912A1; Tue, 7 Aug 2001 08:48:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44EC7912AC; Tue, 7 Aug 2001 08:48: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 1E7E6912A1 for ; Tue, 7 Aug 2001 08:48:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E5D225DDA9; Tue, 7 Aug 2001 08:48:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id 917055DDC6 for ; Tue, 7 Aug 2001 08:48:15 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 12:48:14 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 14:47:59 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: [Issue] Error processing/capabilities negotiation Cc: aaa-wg@merit.edu In-Reply-To: <20010807051340.A13395@charizard.diameter.org> References: <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 14:13 07/08/01, Pat Calhoun wrote: >On Tue, Aug 07, 2001 at 02:03:42PM +0200, Jacques Caron wrote: > > In the current draft, there are many situations where any agent can return > > an error when processing a message (e.g. when receiving an AVP tagged with > > the 'M' bit that it doesn' accept). However, there are no provisions for > > sending an error in response to an answer (an error is an answer, and can > > only be sent in response to a request). > >Right. So the spec states that if this should occur, the access device >should terminate the session, via an STR. I think this is way too harsh. >This is not a requirement in RFC 2989, or in any of the requirements >specs that were used to create RFC 2989. I would feel very uncomfortable >redesigning the protocol this late in the game. I'm pretty sure I had seen capabilities negotiation somewhere in some requirements doc (though I can't find where), and I had understood that to be end-to-end, not the (very limited) peer-to-peer capabilities negotiation we do in CER/CEA. >IMHO, this isn't a problem. A request fails, then you ask again. An answer >fails, then you terminate the session. You can ask again if necessary. The request doesn't fail: it just gives you information you can't handle (or don't want to), and there is no way to retry it by specifying which parts you didn't like :-( > > Jacques-in-complex-mode. > >I think I like the other Jacque better. Can you bring him back :) :) Did you notice we had a full moon last night? ;-> Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 09:31: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 JAA03387 for ; Tue, 7 Aug 2001 09:31:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C509912A3; Tue, 7 Aug 2001 09:32:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4CCC912A5; Tue, 7 Aug 2001 09:32: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 3D8D7912A3 for ; Tue, 7 Aug 2001 09:32:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 121245DDCA; Tue, 7 Aug 2001 09:32:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B46395DDC9 for ; Tue, 7 Aug 2001 09:32:26 -0400 (EDT) Received: (qmail 13684 invoked by uid 500); 7 Aug 2001 13:21:11 -0000 Date: Tue, 7 Aug 2001 06:21:11 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Error processing/capabilities negotiation Message-ID: <20010807062111.A13665@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <20010807051340.A13395@charizard.diameter.org> <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Aug 07, 2001 at 02:47:59PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Aug 07, 2001 at 02:47:59PM +0200, Jacques Caron wrote: > At 14:13 07/08/01, Pat Calhoun wrote: > >On Tue, Aug 07, 2001 at 02:03:42PM +0200, Jacques Caron wrote: > > > In the current draft, there are many situations where any agent can return > > > an error when processing a message (e.g. when receiving an AVP tagged with > > > the 'M' bit that it doesn' accept). However, there are no provisions for > > > sending an error in response to an answer (an error is an answer, and can > > > only be sent in response to a request). > > > >Right. So the spec states that if this should occur, the access device > >should terminate the session, via an STR. > > I think this is way too harsh. Perhaps it is crude, but it is simple, and it works. > > >This is not a requirement in RFC 2989, or in any of the requirements > >specs that were used to create RFC 2989. I would feel very uncomfortable > >redesigning the protocol this late in the game. > > I'm pretty sure I had seen capabilities negotiation somewhere in some > requirements doc (though I can't find where), and I had understood that to > be end-to-end, not the (very limited) peer-to-peer capabilities negotiation > we do in CER/CEA. The capabilities negotiation discussions that I am aware of didn't include this. > > >IMHO, this isn't a problem. A request fails, then you ask again. An answer > >fails, then you terminate the session. You can ask again if necessary. > > The request doesn't fail: it just gives you information you can't handle > (or don't want to), and there is no way to retry it by specifying which > parts you didn't like :-( well, you get information back on what the sender of the answer message didn't like. THen you can try again. If the problem is with the processing of the answer message itself, then we can either: 1. do something simple as we have now (terminate session), and try again if need be. 2. re-architect the protocol to have 3 way messages (req->answ->ack) I'd opt for #1 PatC From owner-aaa-wg@merit.edu Tue Aug 7 09:42: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 JAA03689 for ; Tue, 7 Aug 2001 09:42:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 57157912A6; Tue, 7 Aug 2001 09:42:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24ACA912A7; Tue, 7 Aug 2001 09:42: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 066BD912A6 for ; Tue, 7 Aug 2001 09:42:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF6E45DDCA; Tue, 7 Aug 2001 09:42:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id 6399D5DDC9 for ; Tue, 7 Aug 2001 09:42:43 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 13:42:42 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010807153601.00d09250@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 15:42:19 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: [Issue] Error processing/capabilities negotiation Cc: Pat Calhoun , aaa-wg@merit.edu In-Reply-To: <20010807062111.A13665@charizard.diameter.org> References: <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com> <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <20010807051340.A13395@charizard.diameter.org> <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 15:21 07/08/01, Pat Calhoun wrote: >well, you get information back on what the sender of the answer message didn't >like. THen you can try again. That indeed works fn=ine when the server rejects a request. > If the problem is with the processing of the >answer message itself, then we can either: >1. do something simple as we have now (terminate session), and try again if > need be. I do you try again? You're supposed to get the same answer again, aren't you? >2. re-architect the protocol to have 3 way messages (req->answ->ack) 3. Have two types of answers: those that require further exchanges, and those that do not. On top of EAP-type stuff, any answer with 'M'-AVPs would be in the first category. Then we just need a way to send a request specifying "I didn't like your answer, dude, gimme another one". And just for symmetry (to avoid having servers maintaining state for an answer for which they might or might not get a new request), a dummy "I'm fine thank you" request. Of course all "regular" answers (the "yes/no" kind, without a collection of authorization AVPs) don't need further request/answers. >I'd opt for #1 I'd opt for #3 :-) Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 09:46:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03796 for ; Tue, 7 Aug 2001 09:46:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29CAB912A9; Tue, 7 Aug 2001 09:46:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB5BF912AB; Tue, 7 Aug 2001 09:46: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 99747912A9 for ; Tue, 7 Aug 2001 09:46:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7318B5DDCA; Tue, 7 Aug 2001 09:46:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E213B5DDC9 for ; Tue, 7 Aug 2001 09:46:13 -0400 (EDT) Received: (qmail 13754 invoked by uid 500); 7 Aug 2001 13:34:59 -0000 Date: Tue, 7 Aug 2001 06:34:59 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Error processing/capabilities negotiation Message-ID: <20010807063459.D13665@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , aaa-wg@merit.edu References: <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com> <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <4.3.2.7.2.20010806211320.00c90220@pop.fr.psi.com> <20010807051340.A13395@charizard.diameter.org> <4.3.2.7.2.20010807143948.00caac10@pop.mail.yahoo.com> <20010807062111.A13665@charizard.diameter.org> <4.3.2.7.2.20010807153601.00d09250@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010807153601.00d09250@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Aug 07, 2001 at 03:42:19PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > >1. do something simple as we have now (terminate session), and try again if > > need be. > > I do you try again? You're supposed to get the same answer again, aren't you? you will if you send the same thing again. Of course, you can modify the request instead to make sure that the response is not the same. PatC From owner-aaa-wg@merit.edu Tue Aug 7 09:46: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 JAA03828 for ; Tue, 7 Aug 2001 09:46:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BD0F912AA; Tue, 7 Aug 2001 09:46:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 177BF912AC; Tue, 7 Aug 2001 09:46: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 69C55912AA for ; Tue, 7 Aug 2001 09:46:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 457125DDCF; Tue, 7 Aug 2001 09:46:15 -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 D1F505DDC9 for ; Tue, 7 Aug 2001 09:46:14 -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 f77DkEp04106; Tue, 7 Aug 2001 08:46:14 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f77DkDS11053; Tue, 7 Aug 2001 08:46:13 -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 IAA23164; Tue, 7 Aug 2001 08:46:13 -0500 (CDT) Received: from ericsson.com ([138.85.130.32]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id IAA26902; Tue, 7 Aug 2001 08:46:09 -0500 (CDT) Message-ID: <3B6FEF84.41F2B857@ericsson.com> Date: Tue, 07 Aug 2001 06:39:16 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Eklund wrote: > All, > > I wanted to give some input on issue 109. > > Issue 109 states that there is overhead involved in having to > create a sample missing AVP. That is true. The suggested fix > is to create a Missing-AVP of type integer to hold the missing > AVP. There is one problem with this. If the AVP is vendor > specific, you need to create a new Missing-Vendor-AVP to hold > the vendor ID. I'm not really following you. If a peer finds out that a vendor specific AVP is missing, means that it also know the specific vendor Id. Right? So you would still use the same Missing-AVP, but with the Vendor Id set in the Missing-AVP header. I don't see any need for a new Missing-Vendor-AVP. > If there is a vendor specific and an IETF AVP > missing, you would have to somehow group them. > So now you have > to create a grouped avp to hold the Missing-AVP and the > Missing-Vendor-AVP. If there is more than one AVP missing you would simply add multiple Missing-AVP AVPs and for those that are vendor specific you would make use of the vendor Id in the AVP header. However, if people rather wants to use a grouped AVP in the case of multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler to add multiple Missing AVP AVPs. > > > In my opinion the overhead of creating a some fake data for the > payload is much less than the extra overhead listed above. > see comments above... Regards, /Tony > > -mark From owner-aaa-wg@merit.edu Tue Aug 7 09:52: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 JAA03941 for ; Tue, 7 Aug 2001 09:52:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28DA3912A7; Tue, 7 Aug 2001 09:52:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2935912AC; Tue, 7 Aug 2001 09:52: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 CC4B7912A7 for ; Tue, 7 Aug 2001 09:52:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF44A5DDA9; Tue, 7 Aug 2001 09:52: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 EAE9F5DD9E for ; Tue, 7 Aug 2001 09:52:48 -0400 (EDT) Received: (qmail 13777 invoked by uid 500); 7 Aug 2001 13:41:34 -0000 Date: Tue, 7 Aug 2001 06:41:34 -0700 From: Pat Calhoun To: Tony Johansson Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP Message-ID: <20010807064134.E13665@charizard.diameter.org> Mail-Followup-To: Tony Johansson , Mark Eklund , aaa-wg@merit.edu References: <3B6FEF84.41F2B857@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6FEF84.41F2B857@ericsson.com>; from tony.johansson@ericsson.com on Tue, Aug 07, 2001 at 06:39:16AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk I think Mark's comment is that if the AVP in question is vendor-specific, how would you flag that info. If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, you would have something like: AVPCode = 999 Vendor-Id = 0 Data = 600 Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do the following: AVPCode = 999 Vendor-Id = 555 Data = 600 because AVP 999/555 is different from 999/0. So I believe that Mark is stating the following is needed: AVP Code = 777 (Grouped AVP) AVP Code = 999 Data = 600 Vendor-Id = 888 Data = 555 (I used bogus AVP codes above) PatC On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: > > > Mark Eklund wrote: > > > All, > > > > I wanted to give some input on issue 109. > > > > Issue 109 states that there is overhead involved in having to > > create a sample missing AVP. That is true. The suggested fix > > is to create a Missing-AVP of type integer to hold the missing > > AVP. There is one problem with this. If the AVP is vendor > > specific, you need to create a new Missing-Vendor-AVP to hold > > the vendor ID. > > I'm not really following you. If a peer finds out that a vendor specific > AVP is missing, means that it also know the specific vendor Id. Right? > So you would still use the same Missing-AVP, but with the Vendor Id set > in the Missing-AVP header. I don't see any need for a new > Missing-Vendor-AVP. > > > If there is a vendor specific and an IETF AVP > > missing, you would have to somehow group them. > > > So now you have > > to create a grouped avp to hold the Missing-AVP and the > > Missing-Vendor-AVP. > > If there is more than one AVP missing you would simply add multiple > Missing-AVP AVPs and for those that are vendor specific you would make > use of the vendor Id in the AVP header. > > However, if people rather wants to use a grouped AVP in the case of > multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler > to add multiple Missing AVP AVPs. > > > > > > > In my opinion the overhead of creating a some fake data for the > > payload is much less than the extra overhead listed above. > > > > see comments above... > > Regards, > > /Tony > > > > > -mark > From owner-aaa-wg@merit.edu Tue Aug 7 10:00: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 KAA04140 for ; Tue, 7 Aug 2001 10:00:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3FF99912B1; Tue, 7 Aug 2001 09:59:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0724A912B8; Tue, 7 Aug 2001 09:59: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 5E707912B1 for ; Tue, 7 Aug 2001 09:59:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 438045DDC9; Tue, 7 Aug 2001 09:59:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 590835DDA9 for ; Tue, 7 Aug 2001 09:59:16 -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 JAA22746; Tue, 7 Aug 2001 09:57:34 -0400 (EDT) Date: Tue, 7 Aug 2001 09:59:02 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP In-Reply-To: <20010807064134.E13665@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, you saved me some typing. That is what I meant. -mark On Tue, 7 Aug 2001, Pat Calhoun wrote: > I think Mark's comment is that if the AVP in question is vendor-specific, > how would you flag that info. > > If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, > you would have something like: > AVPCode = 999 > Vendor-Id = 0 > Data = 600 > > Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do > the following: > AVPCode = 999 > Vendor-Id = 555 > Data = 600 > > because AVP 999/555 is different from 999/0. So I believe that Mark is > stating the following is needed: > > AVP Code = 777 (Grouped AVP) > AVP Code = 999 > Data = 600 > Vendor-Id = 888 > Data = 555 > > (I used bogus AVP codes above) > > PatC > On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: > > > > > > Mark Eklund wrote: > > > > > All, > > > > > > I wanted to give some input on issue 109. > > > > > > Issue 109 states that there is overhead involved in having to > > > create a sample missing AVP. That is true. The suggested fix > > > is to create a Missing-AVP of type integer to hold the missing > > > AVP. There is one problem with this. If the AVP is vendor > > > specific, you need to create a new Missing-Vendor-AVP to hold > > > the vendor ID. > > > > I'm not really following you. If a peer finds out that a vendor specific > > AVP is missing, means that it also know the specific vendor Id. Right? > > So you would still use the same Missing-AVP, but with the Vendor Id set > > in the Missing-AVP header. I don't see any need for a new > > Missing-Vendor-AVP. > > > > > If there is a vendor specific and an IETF AVP > > > missing, you would have to somehow group them. > > > > > So now you have > > > to create a grouped avp to hold the Missing-AVP and the > > > Missing-Vendor-AVP. > > > > If there is more than one AVP missing you would simply add multiple > > Missing-AVP AVPs and for those that are vendor specific you would make > > use of the vendor Id in the AVP header. > > > > However, if people rather wants to use a grouped AVP in the case of > > multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler > > to add multiple Missing AVP AVPs. > > > > > > > > > > > In my opinion the overhead of creating a some fake data for the > > > payload is much less than the extra overhead listed above. > > > > > > > see comments above... > > > > Regards, > > > > /Tony > > > > > > > > -mark > > > From owner-aaa-wg@merit.edu Tue Aug 7 10:08: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 KAA04376 for ; Tue, 7 Aug 2001 10:08:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA109912AF; Tue, 7 Aug 2001 10:07:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A7BF912B5; Tue, 7 Aug 2001 10:07: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 CC73A912AF for ; Tue, 7 Aug 2001 10:07:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3B875DE1D; Tue, 7 Aug 2001 10:07:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 9CBC45DE11 for ; Tue, 7 Aug 2001 10:07:40 -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 QAA12284; Tue, 7 Aug 2001 16:08:52 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , "Tony Johansson" Cc: "Mark Eklund" , Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP Date: Tue, 7 Aug 2001 16:08:54 +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: <20010807064134.E13665@charizard.diameter.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I probably missed something earlier, but didn't we ones have the mechanism to include the entire missing avp header? So if you know that one avp is missing (vendor specific or not) you create the whole avp header, which includes the vendor id if it is vendor specific. Isn't that something we can go back to and use? /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 7 augusti 2001 15:42 >To: Tony Johansson >Cc: Mark Eklund; aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called >Missing-AVP > > >I think Mark's comment is that if the AVP in question is vendor-specific, >how would you flag that info. > >If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, >you would have something like: >AVPCode = 999 >Vendor-Id = 0 >Data = 600 > >Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do >the following: >AVPCode = 999 >Vendor-Id = 555 >Data = 600 > >because AVP 999/555 is different from 999/0. So I believe that Mark is >stating the following is needed: > >AVP Code = 777 (Grouped AVP) > AVP Code = 999 > Data = 600 > Vendor-Id = 888 > Data = 555 > >(I used bogus AVP codes above) > >PatC >On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: >> >> >> Mark Eklund wrote: >> >> > All, >> > >> > I wanted to give some input on issue 109. >> > >> > Issue 109 states that there is overhead involved in having to >> > create a sample missing AVP. That is true. The suggested fix >> > is to create a Missing-AVP of type integer to hold the missing >> > AVP. There is one problem with this. If the AVP is vendor >> > specific, you need to create a new Missing-Vendor-AVP to hold >> > the vendor ID. >> >> I'm not really following you. If a peer finds out that a vendor specific >> AVP is missing, means that it also know the specific vendor Id. Right? >> So you would still use the same Missing-AVP, but with the Vendor Id set >> in the Missing-AVP header. I don't see any need for a new >> Missing-Vendor-AVP. >> >> > If there is a vendor specific and an IETF AVP >> > missing, you would have to somehow group them. >> >> > So now you have >> > to create a grouped avp to hold the Missing-AVP and the >> > Missing-Vendor-AVP. >> >> If there is more than one AVP missing you would simply add multiple >> Missing-AVP AVPs and for those that are vendor specific you would make >> use of the vendor Id in the AVP header. >> >> However, if people rather wants to use a grouped AVP in the case of >> multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler >> to add multiple Missing AVP AVPs. >> >> > >> > >> > In my opinion the overhead of creating a some fake data for the >> > payload is much less than the extra overhead listed above. >> > >> >> see comments above... >> >> Regards, >> >> /Tony >> >> > >> > -mark >> From owner-aaa-wg@merit.edu Tue Aug 7 10:15: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 KAA04544 for ; Tue, 7 Aug 2001 10:15:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A58FB912B0; Tue, 7 Aug 2001 10:16:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65069912B2; Tue, 7 Aug 2001 10:16: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 D7540912B0 for ; Tue, 7 Aug 2001 10:16:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6E4B5DDD0; Tue, 7 Aug 2001 10:16:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 26CB45DDCA for ; Tue, 7 Aug 2001 10:16:01 -0400 (EDT) Received: from gwzpc (ams-clip-vpn-dhcp4127.cisco.com [10.50.16.30]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA16801; Tue, 7 Aug 2001 07:15:26 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Valeria Garello" Cc: Subject: RE: [AAA-WG]: RADIUS Authentication Server IP address Date: Tue, 7 Aug 2001 07:15: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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > This is the mailing list of the AAA WG, which is focussed on standardizing > the Diameter protocol. Questions relating to RADIUS are off-topic, > except as they relate to the design of Diameter. Please take these issues > to the RADIUS WG mailing list, available at ietf-radius@livingston.com. Or for that matter, to the authors of the RFC (Bernard & I). > > > From owner-aaa-wg@merit.edu Tue Aug 7 10:21:03 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04632 for ; Tue, 7 Aug 2001 10:21:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8AA7B912BE; Tue, 7 Aug 2001 10:18:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BF8F912BD; Tue, 7 Aug 2001 10:18: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 90CCD912B3 for ; Tue, 7 Aug 2001 10:18:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 757135DDD0; Tue, 7 Aug 2001 10:18:52 -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 918795DD9E for ; Tue, 7 Aug 2001 10:18:51 -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 KAA23247; Tue, 7 Aug 2001 10:16:56 -0400 (EDT) Date: Tue, 7 Aug 2001 10:18:24 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Fredrik Johansson Cc: Pat Calhoun , Tony Johansson , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk We had what I described. A failed-avp that contained an integer of the AVP value, a Failed-Vendor-Id, and an Offending-AVP of type grouped that held both of them. See http://www.diameter.org/issues.html#Issue #30 as to when it got changed in base 05. -mark On Tue, 7 Aug 2001, Fredrik Johansson wrote: > I probably missed something earlier, but didn't we ones have the mechanism > to include the entire missing avp header? So if you know that one avp is > missing (vendor specific or not) you create the whole avp header, which > includes the vendor id if it is vendor specific. > > Isn't that something we can go back to and use? > > /Fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Pat Calhoun > >Sent: den 7 augusti 2001 15:42 > >To: Tony Johansson > >Cc: Mark Eklund; aaa-wg@merit.edu > >Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called > >Missing-AVP > > > > > >I think Mark's comment is that if the AVP in question is vendor-specific, > >how would you flag that info. > > > >If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, > >you would have something like: > >AVPCode = 999 > >Vendor-Id = 0 > >Data = 600 > > > >Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do > >the following: > >AVPCode = 999 > >Vendor-Id = 555 > >Data = 600 > > > >because AVP 999/555 is different from 999/0. So I believe that Mark is > >stating the following is needed: > > > >AVP Code = 777 (Grouped AVP) > > AVP Code = 999 > > Data = 600 > > Vendor-Id = 888 > > Data = 555 > > > >(I used bogus AVP codes above) > > > >PatC > >On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: > >> > >> > >> Mark Eklund wrote: > >> > >> > All, > >> > > >> > I wanted to give some input on issue 109. > >> > > >> > Issue 109 states that there is overhead involved in having to > >> > create a sample missing AVP. That is true. The suggested fix > >> > is to create a Missing-AVP of type integer to hold the missing > >> > AVP. There is one problem with this. If the AVP is vendor > >> > specific, you need to create a new Missing-Vendor-AVP to hold > >> > the vendor ID. > >> > >> I'm not really following you. If a peer finds out that a vendor specific > >> AVP is missing, means that it also know the specific vendor Id. Right? > >> So you would still use the same Missing-AVP, but with the Vendor Id set > >> in the Missing-AVP header. I don't see any need for a new > >> Missing-Vendor-AVP. > >> > >> > If there is a vendor specific and an IETF AVP > >> > missing, you would have to somehow group them. > >> > >> > So now you have > >> > to create a grouped avp to hold the Missing-AVP and the > >> > Missing-Vendor-AVP. > >> > >> If there is more than one AVP missing you would simply add multiple > >> Missing-AVP AVPs and for those that are vendor specific you would make > >> use of the vendor Id in the AVP header. > >> > >> However, if people rather wants to use a grouped AVP in the case of > >> multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler > >> to add multiple Missing AVP AVPs. > >> > >> > > >> > > >> > In my opinion the overhead of creating a some fake data for the > >> > payload is much less than the extra overhead listed above. > >> > > >> > >> see comments above... > >> > >> Regards, > >> > >> /Tony > >> > >> > > >> > -mark > >> > From owner-aaa-wg@merit.edu Tue Aug 7 10:30:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04875 for ; Tue, 7 Aug 2001 10:30:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E9EC912B2; Tue, 7 Aug 2001 10:30:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21F34912B4; Tue, 7 Aug 2001 10:30: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 98886912B2 for ; Tue, 7 Aug 2001 10:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6876F5DDA9; Tue, 7 Aug 2001 10:30:16 -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 ED22B5DD9E for ; Tue, 7 Aug 2001 10:30:15 -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 f77EUE514986; Tue, 7 Aug 2001 09:30:14 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f77EUES05628; Tue, 7 Aug 2001 09:30:14 -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 JAA25041; Tue, 7 Aug 2001 09:30:14 -0500 (CDT) Received: from ericsson.com ([138.85.130.32]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA27552; Tue, 7 Aug 2001 09:30:10 -0500 (CDT) Message-ID: <3B6FF9D5.58650BB2@ericsson.com> Date: Tue, 07 Aug 2001 07:23:17 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP References: <3B6FEF84.41F2B857@ericsson.com> <20010807064134.E13665@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 Ahhh, your are absolutely right. So what I suggested would actually add on more overhead :( /Tony Pat Calhoun wrote: > I think Mark's comment is that if the AVP in question is vendor-specific, > how would you flag that info. > > If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, > you would have something like: > AVPCode = 999 > Vendor-Id = 0 > Data = 600 > > Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do > the following: > AVPCode = 999 > Vendor-Id = 555 > Data = 600 > > because AVP 999/555 is different from 999/0. So I believe that Mark is > stating the following is needed: > > AVP Code = 777 (Grouped AVP) > AVP Code = 999 > Data = 600 > Vendor-Id = 888 > Data = 555 > > (I used bogus AVP codes above) > > PatC > On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: > > > > > > Mark Eklund wrote: > > > > > All, > > > > > > I wanted to give some input on issue 109. > > > > > > Issue 109 states that there is overhead involved in having to > > > create a sample missing AVP. That is true. The suggested fix > > > is to create a Missing-AVP of type integer to hold the missing > > > AVP. There is one problem with this. If the AVP is vendor > > > specific, you need to create a new Missing-Vendor-AVP to hold > > > the vendor ID. > > > > I'm not really following you. If a peer finds out that a vendor specific > > AVP is missing, means that it also know the specific vendor Id. Right? > > So you would still use the same Missing-AVP, but with the Vendor Id set > > in the Missing-AVP header. I don't see any need for a new > > Missing-Vendor-AVP. > > > > > If there is a vendor specific and an IETF AVP > > > missing, you would have to somehow group them. > > > > > So now you have > > > to create a grouped avp to hold the Missing-AVP and the > > > Missing-Vendor-AVP. > > > > If there is more than one AVP missing you would simply add multiple > > Missing-AVP AVPs and for those that are vendor specific you would make > > use of the vendor Id in the AVP header. > > > > However, if people rather wants to use a grouped AVP in the case of > > multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler > > to add multiple Missing AVP AVPs. > > > > > > > > > > > In my opinion the overhead of creating a some fake data for the > > > payload is much less than the extra overhead listed above. > > > > > > > see comments above... > > > > Regards, > > > > /Tony > > > > > > > > -mark > > From owner-aaa-wg@merit.edu Tue Aug 7 10:56: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 KAA05558 for ; Tue, 7 Aug 2001 10:56:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B22AA912B7; Tue, 7 Aug 2001 10:57:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BFFE912B8; Tue, 7 Aug 2001 10:57: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 7FF1F912B7 for ; Tue, 7 Aug 2001 10:57:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C8C55DDC3; Tue, 7 Aug 2001 10:57:07 -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 957E55DD9E for ; Tue, 7 Aug 2001 10:57:06 -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 QAA13175; Tue, 7 Aug 2001 16:58:23 +0200 From: "Fredrik Johansson" To: "Mark Eklund" Cc: "Pat Calhoun" , "Tony Johansson" , Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP Date: Tue, 7 Aug 2001 16:58:24 +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: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, So a missing avp is included as a whole avp in the Failed-Avp AVP (with its payload set to zeros). If several avp's are missing, they're all included in the Failed-Avp AVP. Does it mean that if the missing avp is of type uint32 I have to add 4 zeros at the end? And if it is of type octet string, then I don't need to add anything at the end? /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Mark Eklund >Sent: den 7 augusti 2001 16:18 >To: Fredrik Johansson >Cc: Pat Calhoun; Tony Johansson; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called >Missing-AVP > > >We had what I described. A failed-avp that contained an integer >of the AVP value, a Failed-Vendor-Id, and an Offending-AVP of >type grouped that held both of them. See > >http://www.diameter.org/issues.html#Issue #30 > >as to when it got changed in base 05. > >-mark > >On Tue, 7 Aug 2001, Fredrik Johansson wrote: > >> I probably missed something earlier, but didn't we ones have the >mechanism >> to include the entire missing avp header? So if you know that one avp is >> missing (vendor specific or not) you create the whole avp header, which >> includes the vendor id if it is vendor specific. >> >> Isn't that something we can go back to and use? >> >> /Fredrik >> >> >-----Original Message----- >> >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> >Pat Calhoun >> >Sent: den 7 augusti 2001 15:42 >> >To: Tony Johansson >> >Cc: Mark Eklund; aaa-wg@merit.edu >> >Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called >> >Missing-AVP >> > >> > >> >I think Mark's comment is that if the AVP in question is >vendor-specific, >> >how would you flag that info. >> > >> >If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, >> >you would have something like: >> >AVPCode = 999 >> >Vendor-Id = 0 >> >Data = 600 >> > >> >Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do >> >the following: >> >AVPCode = 999 >> >Vendor-Id = 555 >> >Data = 600 >> > >> >because AVP 999/555 is different from 999/0. So I believe that Mark is >> >stating the following is needed: >> > >> >AVP Code = 777 (Grouped AVP) >> > AVP Code = 999 >> > Data = 600 >> > Vendor-Id = 888 >> > Data = 555 >> > >> >(I used bogus AVP codes above) >> > >> >PatC >> >On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: >> >> >> >> >> >> Mark Eklund wrote: >> >> >> >> > All, >> >> > >> >> > I wanted to give some input on issue 109. >> >> > >> >> > Issue 109 states that there is overhead involved in having to >> >> > create a sample missing AVP. That is true. The suggested fix >> >> > is to create a Missing-AVP of type integer to hold the missing >> >> > AVP. There is one problem with this. If the AVP is vendor >> >> > specific, you need to create a new Missing-Vendor-AVP to hold >> >> > the vendor ID. >> >> >> >> I'm not really following you. If a peer finds out that a >vendor specific >> >> AVP is missing, means that it also know the specific vendor Id. Right? >> >> So you would still use the same Missing-AVP, but with the >Vendor Id set >> >> in the Missing-AVP header. I don't see any need for a new >> >> Missing-Vendor-AVP. >> >> >> >> > If there is a vendor specific and an IETF AVP >> >> > missing, you would have to somehow group them. >> >> >> >> > So now you have >> >> > to create a grouped avp to hold the Missing-AVP and the >> >> > Missing-Vendor-AVP. >> >> >> >> If there is more than one AVP missing you would simply add multiple >> >> Missing-AVP AVPs and for those that are vendor specific you would make >> >> use of the vendor Id in the AVP header. >> >> >> >> However, if people rather wants to use a grouped AVP in the case of >> >> multiple Missing-AVP AVPs. I'm fine with that too. I just saw >it simpler >> >> to add multiple Missing AVP AVPs. >> >> >> >> > >> >> > >> >> > In my opinion the overhead of creating a some fake data for the >> >> > payload is much less than the extra overhead listed above. >> >> > >> >> >> >> see comments above... >> >> >> >> Regards, >> >> >> >> /Tony >> >> >> >> > >> >> > -mark >> >> >> From owner-aaa-wg@merit.edu Tue Aug 7 11:35: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 LAA06448 for ; Tue, 7 Aug 2001 11:35:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5FAC5912C2; Tue, 7 Aug 2001 11:34:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E805912D6; Tue, 7 Aug 2001 11:34: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 EADFE912C2 for ; Tue, 7 Aug 2001 11:34:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B0D665DDB6; Tue, 7 Aug 2001 11:34:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 6628A5DD90 for ; Tue, 7 Aug 2001 11:34:53 -0400 (EDT) Received: from pc144.etc.psi.com (HELO jc.yahoo.com) (195.94.40.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 15:34:52 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010807173159.00c65850@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 17:34:25 +0200 To: "Fredrik Johansson" From: Jacques Caron Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP Cc: "Mark Eklund" , "Pat Calhoun" , "Tony Johansson" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, What about just having an 8-byte value, consisting of the Vendor-Ip (which can be 0 for non-vendor-specific AVPs?) and the AVP code for the missing AVP? Simple and easy. Could even put a whole list of missing AVPs in a single AVP (the number of AVPs would be AVP length - header length / 8). Just my CHF 0.02 :-) Jacques. At 16:58 07/08/01, Fredrik Johansson wrote: >Ok, > >So a missing avp is included as a whole avp in the Failed-Avp AVP (with its >payload set to zeros). If several avp's are missing, they're all included in >the Failed-Avp AVP. > >Does it mean that if the missing avp is of type uint32 I have to add 4 zeros >at the end? And if it is of type octet string, then I don't need to add >anything at the end? > > >/Fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Mark Eklund > >Sent: den 7 augusti 2001 16:18 > >To: Fredrik Johansson > >Cc: Pat Calhoun; Tony Johansson; aaa-wg@merit.edu > >Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called > >Missing-AVP > > > > > >We had what I described. A failed-avp that contained an integer > >of the AVP value, a Failed-Vendor-Id, and an Offending-AVP of > >type grouped that held both of them. See > > > >http://www.diameter.org/issues.html#Issue #30 > > > >as to when it got changed in base 05. > > > >-mark > > > >On Tue, 7 Aug 2001, Fredrik Johansson wrote: > > > >> I probably missed something earlier, but didn't we ones have the > >mechanism > >> to include the entire missing avp header? So if you know that one avp is > >> missing (vendor specific or not) you create the whole avp header, which > >> includes the vendor id if it is vendor specific. > >> > >> Isn't that something we can go back to and use? > >> > >> /Fredrik > >> > >> >-----Original Message----- > >> >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >> >Pat Calhoun > >> >Sent: den 7 augusti 2001 15:42 > >> >To: Tony Johansson > >> >Cc: Mark Eklund; aaa-wg@merit.edu > >> >Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called > >> >Missing-AVP > >> > > >> > > >> >I think Mark's comment is that if the AVP in question is > >vendor-specific, > >> >how would you flag that info. > >> > > >> >If Missing-AVP is assigned the code 999, and the missing avp is AVP 600, > >> >you would have something like: > >> >AVPCode = 999 > >> >Vendor-Id = 0 > >> >Data = 600 > >> > > >> >Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do > >> >the following: > >> >AVPCode = 999 > >> >Vendor-Id = 555 > >> >Data = 600 > >> > > >> >because AVP 999/555 is different from 999/0. So I believe that Mark is > >> >stating the following is needed: > >> > > >> >AVP Code = 777 (Grouped AVP) > >> > AVP Code = 999 > >> > Data = 600 > >> > Vendor-Id = 888 > >> > Data = 555 > >> > > >> >(I used bogus AVP codes above) > >> > > >> >PatC > >> >On Tue, Aug 07, 2001 at 06:39:16AM -0700, Tony Johansson wrote: > >> >> > >> >> > >> >> Mark Eklund wrote: > >> >> > >> >> > All, > >> >> > > >> >> > I wanted to give some input on issue 109. > >> >> > > >> >> > Issue 109 states that there is overhead involved in having to > >> >> > create a sample missing AVP. That is true. The suggested fix > >> >> > is to create a Missing-AVP of type integer to hold the missing > >> >> > AVP. There is one problem with this. If the AVP is vendor > >> >> > specific, you need to create a new Missing-Vendor-AVP to hold > >> >> > the vendor ID. > >> >> > >> >> I'm not really following you. If a peer finds out that a > >vendor specific > >> >> AVP is missing, means that it also know the specific vendor Id. Right? > >> >> So you would still use the same Missing-AVP, but with the > >Vendor Id set > >> >> in the Missing-AVP header. I don't see any need for a new > >> >> Missing-Vendor-AVP. > >> >> > >> >> > If there is a vendor specific and an IETF AVP > >> >> > missing, you would have to somehow group them. > >> >> > >> >> > So now you have > >> >> > to create a grouped avp to hold the Missing-AVP and the > >> >> > Missing-Vendor-AVP. > >> >> > >> >> If there is more than one AVP missing you would simply add multiple > >> >> Missing-AVP AVPs and for those that are vendor specific you would make > >> >> use of the vendor Id in the AVP header. > >> >> > >> >> However, if people rather wants to use a grouped AVP in the case of > >> >> multiple Missing-AVP AVPs. I'm fine with that too. I just saw > >it simpler > >> >> to add multiple Missing AVP AVPs. > >> >> > >> >> > > >> >> > > >> >> > In my opinion the overhead of creating a some fake data for the > >> >> > payload is much less than the extra overhead listed above. > >> >> > > >> >> > >> >> see comments above... > >> >> > >> >> Regards, > >> >> > >> >> /Tony > >> >> > >> >> > > >> >> > -mark > >> >> > >> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Aug 7 12:24: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 MAA07634 for ; Tue, 7 Aug 2001 12:24:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1D750912C4; Tue, 7 Aug 2001 12:22:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA975912CA; Tue, 7 Aug 2001 12:22: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 D2A7B912C4 for ; Tue, 7 Aug 2001 12:22:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B88EE5DDB6; Tue, 7 Aug 2001 12:22: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 4DB9D5DD90 for ; Tue, 7 Aug 2001 12:22:36 -0400 (EDT) Received: (qmail 14202 invoked by uid 500); 7 Aug 2001 16:11:21 -0000 Date: Tue, 7 Aug 2001 09:11:21 -0700 From: Pat Calhoun To: Jacques Caron Cc: Fredrik Johansson , Mark Eklund , Pat Calhoun , Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called Missing-AVP Message-ID: <20010807091121.A14185@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Fredrik Johansson , Mark Eklund , Pat Calhoun , Tony Johansson , aaa-wg@merit.edu References: <4.3.2.7.2.20010807173159.00c65850@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010807173159.00c65850@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Tue, Aug 07, 2001 at 05:34:25PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Aug 07, 2001 at 05:34:25PM +0200, Jacques Caron wrote: > Hi, > > What about just having an 8-byte value, consisting of the Vendor-Ip (which > can be 0 for non-vendor-specific AVPs?) and the AVP code for the missing AVP? > > Simple and easy. Could even put a whole list of missing AVPs in a single > AVP (the number of AVPs would be AVP length - header length / 8). But that would put is back in the mode os supporting AVPs of type complex. This issue is already solved using the existing AVP set. > Just my CHF 0.02 :-) Just my EUR 0.02 :) PatC From owner-aaa-wg@merit.edu Fri Aug 10 06:15: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 GAA02563 for ; Fri, 10 Aug 2001 06:15:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 365319132B; Fri, 10 Aug 2001 06:16:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E61B89132E; Fri, 10 Aug 2001 06:16: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 A0EE39132B for ; Fri, 10 Aug 2001 06:16:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8237B5DD94; Fri, 10 Aug 2001 06:16: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 192635DD8D for ; Fri, 10 Aug 2001 06:16:09 -0400 (EDT) Received: (qmail 25633 invoked by uid 500); 10 Aug 2001 10:04:45 -0000 Date: Fri, 10 Aug 2001 03:04:45 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Update on open issues Message-ID: <20010810030445.E25541@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, Of the pending technical issues, the following is an update based on this week's meeting in London. I would solicit additional comments from the list before making any changes to the specifications. Issue 95: Section 6.3 from the base specification will be removed. Issue 117: Source Routing will be removed from the base specification, and the protocol will require that reverse routes are properly configured. Issue 97: The WG consensus was to reject this issue. Issue 98: Additional clarifications will be added to better describe a primary, secondary and alternate peer. By adopting issue 117, the Alternate-Peer AVP will be removed, which will remove most of the confusion claimed by the originator of this issue. Issue 109: Based on discussions on the mailing list, this issue is not required and is rejected. Issue 114: Folks didn't seem to feel like this issue was necessary since the existing protocol works fine without spliting the DiameterIdentity into two separate formats. Issue 100: Hidden inside this issue is a request on how to handle a filter whose format is unrecognized if the 'M' bit isn't set. A new issue will be created, and this editorial issue can be closed. Issue 118: WG consensus was that this feature wasn't required in the protocol, so this issue is to be rejected. Unfiled Issue: A new issue needs to be filed on how a master accounting session is signaled as being terminated when subsessions are in use. The recommended approach is that signalling termination without a subsession avp implies that the master is shutdown, hence all of the subsessions as well. I will create a new issue Monday. As I mentioned at the meeting, I would appreciate it if folks submitted their issues sooner, rather than at the last minute, in order for us to proceed to the next step as quickly as possible. PatC From owner-aaa-wg@merit.edu Fri Aug 10 20:39: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 UAA13536 for ; Fri, 10 Aug 2001 20:39:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA64B91210; Fri, 10 Aug 2001 20:40:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC71E9121A; Fri, 10 Aug 2001 20:40: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 A009791210 for ; Fri, 10 Aug 2001 20:40:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71C895DDD4; Fri, 10 Aug 2001 20:40:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id E52715DD9C for ; Fri, 10 Aug 2001 20:40:09 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA16625; Fri, 10 Aug 2001 17:40:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7B0e8V32612; Fri, 10 Aug 2001 17:40:08 -0700 X-mProtect: Fri, 10 Aug 2001 17:40:08 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin30.iprg.nokia.com (205.226.20.224, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdVNu6Jg; Fri, 10 Aug 2001 17:40:06 PDT Message-ID: <3B747EFF.CA54BCB6@iprg.nokia.com> Date: Fri, 10 Aug 2001 17:40:31 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group Cc: AAA Working Group Mailing List Subject: [AAA-WG]: AAA for IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, At the IPv6 meeting in IETF 51, there was a discussion about whether the AAA working group should consider the possibility of accepting a work item to standardize a protocol to enable the use of AAA to authorize network access for IPv6 nodes. The general sense of the working group seemed quite positive on suggesting that such a thing would be appropriate. I am specifically _not_ asking whether our AAAv6 document should be considered as a working group document within the AAA working group. That would be a matter for the AAA working group to consider. I am only attempting to find out whether the general sense of the working group is the same as the general sense that was expressed at IETF 51. If approval is voiced, or at least objections are not raised, then I will relay the information to the AAA working group. Regards, Charlie P. From owner-aaa-wg@merit.edu Sat Aug 11 10:48: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 KAA06629 for ; Sat, 11 Aug 2001 10:48:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C26BB91225; Sat, 11 Aug 2001 10:49:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9280391226; Sat, 11 Aug 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 73D0B91225 for ; Sat, 11 Aug 2001 10:49:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 459C05DDB4; Sat, 11 Aug 2001 10:49:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D50DD5DD9A for ; Sat, 11 Aug 2001 10:49:48 -0400 (EDT) Received: (qmail 4625 invoked by uid 500); 11 Aug 2001 14:38:20 -0000 Date: Sat, 11 Aug 2001 07:38:20 -0700 From: Pat Calhoun To: Charlie Perkins Cc: IPng Working Group , AAA Working Group Mailing List Subject: Re: [AAA-WG]: AAA for IPv6 Message-ID: <20010811073820.J3420@charizard.diameter.org> Mail-Followup-To: Charlie Perkins , IPng Working Group , AAA Working Group Mailing List References: <3B747EFF.CA54BCB6@iprg.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: <3B747EFF.CA54BCB6@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Aug 10, 2001 at 05:40:31PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > From owner-aaa-wg@merit.edu Sat Aug 11 13:19: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 NAA07529 for ; Sat, 11 Aug 2001 13:19:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B74B9125C; Sat, 11 Aug 2001 13:20:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4948C9125D; Sat, 11 Aug 2001 13:20: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 49C579125C for ; Sat, 11 Aug 2001 13:20:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23DC35DD9A; Sat, 11 Aug 2001 13:20:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 87DB75DD91 for ; Sat, 11 Aug 2001 13:20:01 -0400 (EDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id KAA08480; Sat, 11 Aug 2001 10:19:23 -0700 (PDT) Received: from neastmail.entp.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc.) id KAA29166; Sat, 11 Aug 2001 10:19:22 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id KAA04666; Sat, 11 Aug 2001 10:19:20 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Aug 2001 13:19:19 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508697A@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Pat Calhoun'" , Charlie Perkins Cc: IPng Working Group , AAA Working Group Mailing List , "Engelhart, Bob" , "Molchan, John" , "'ileana.leuca@attws.com'" Subject: RE: [AAA-WG]: AAA for IPv6 Date: Sat, 11 Aug 2001 13:19:08 -0400 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 Pat, I agree with your suggestion that the "AAA WG would be a place for the Diameter application to be created". Consideration is being given in 3GPP SA5 to utilize in several application scenarios that have requirements variations. It would be very helpful to have the AAA WG as a resource to examine the scenario requirements and provide their advice. At least two perspectives of advice are needed: (1) whether it is feasible to use Diameter in a scenario and (2)whether its specific scenario configuration is correct. Other observations and suggestions would, of course, be welcomed by 3GPP SA5. The dissolution of the AAA WG, at this time, would hamper utilization of the Diameter knowledge resource. Hopefully, a dissolution decision will not occur. Thad -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Saturday, August 11, 2001 10:38 AM To: Charlie Perkins Cc: IPng Working Group; AAA Working Group Mailing List Subject: Re: [AAA-WG]: AAA for IPv6 I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > From owner-aaa-wg@merit.edu Sat Aug 11 13:50: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 NAA07802 for ; Sat, 11 Aug 2001 13:50:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06A989124C; Sat, 11 Aug 2001 13:51:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D09E39125D; Sat, 11 Aug 2001 13:51: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 DCD839124C for ; Sat, 11 Aug 2001 13:51:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE0135DD9A; Sat, 11 Aug 2001 13:51:25 -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 8A45D5DD91 for ; Sat, 11 Aug 2001 13:51:25 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Vcux-00082T-00; Sat, 11 Aug 2001 10:51:23 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kobylarz, Thaddeus" Cc: AAA Working Group Mailing List , "'ileana.leuca@attws.com'" Subject: RE: [AAA-WG]: AAA for IPv6 References: <0D3BDFD96647D211B43A00805F15E5890508697A@ner-msg03.wireless.attws.com> Message-Id: Date: Sat, 11 Aug 2001 10:51:23 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I agree with your suggestion that the "AAA WG would be a place for > the Diameter application to be created". Consideration is being given in > 3GPP SA5 to utilize in several application scenarios that have requirements > variations. It would be very helpful to have the AAA WG as a resource to > examine the scenario requirements and provide their advice. when, and only when, those scenarios are in the internet-drafts directory. randy From owner-aaa-wg@merit.edu Sat Aug 11 14:24:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08007 for ; Sat, 11 Aug 2001 14:24:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEF279121E; Sat, 11 Aug 2001 14:23:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6BF69125F; Sat, 11 Aug 2001 14:23: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 13FB99121E for ; Sat, 11 Aug 2001 14:23:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE7E25DDC5; Sat, 11 Aug 2001 14:23:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 4E7735DD91 for ; Sat, 11 Aug 2001 14:23:30 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id LAA12579; Sat, 11 Aug 2001 11:22:58 -0700 (PDT) Received: from neastmail.entp.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc.) id LAA09874; Sat, 11 Aug 2001 11:22:57 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05016; Sat, 11 Aug 2001 11:22:55 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Aug 2001 14:22:54 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508697C@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Randy Bush'" Cc: AAA Working Group Mailing List , "'ileana.leuca@attws.com'" , "Molchan, John" , "Engelhart, Bob" Subject: RE: [AAA-WG]: AAA for IPv6 Date: Sat, 11 Aug 2001 14:22:42 -0400 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 Randy, I'll gladly comply with your request. Thad -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Saturday, August 11, 2001 1:51 PM To: Kobylarz, Thaddeus Cc: AAA Working Group Mailing List; 'ileana.leuca@attws.com' Subject: RE: [AAA-WG]: AAA for IPv6 > I agree with your suggestion that the "AAA WG would be a place for > the Diameter application to be created". Consideration is being given in > 3GPP SA5 to utilize in several application scenarios that have requirements > variations. It would be very helpful to have the AAA WG as a resource to > examine the scenario requirements and provide their advice. when, and only when, those scenarios are in the internet-drafts directory. randy From owner-aaa-wg@merit.edu Mon Aug 13 11:36: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 LAA22265 for ; Mon, 13 Aug 2001 11:36:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 731759123D; Mon, 13 Aug 2001 11:37:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F0479123E; Mon, 13 Aug 2001 11:37: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 2E98F9123D for ; Mon, 13 Aug 2001 11:37:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E4C9A5DDEB; Mon, 13 Aug 2001 11:37:16 -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 965365DDA5 for ; Mon, 13 Aug 2001 11:37:15 -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 RAA32714; Mon, 13 Aug 2001 17:38:31 +0200 From: "Fredrik Johansson" To: "AAA Listan" , "Pat Calhoun" Subject: [AAA-WG]: Issue: Change section 5-6 in MIP app to relect draft-ietf-mobileip-aaa-key-08.txt Date: Mon, 13 Aug 2001 17:38:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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: August 13, 2001 Reference: Document: MIP-07 Comment type: T Priority: 1 Section: 5-6 Rationale/Explanation of issue: I'm re-submitting a part of issue 110 that wasn't a editorial issue. Section 5-6 has to be rewritten to be in line with draft-ietf-mobileip-aaa-key-08.txt Today these sections talks about how keys should be distributed, as the aaa-key draft has changed to distribute key-material, this section has to be updated to reflect that. I'v had a try to change the sections to reflect the changes. A new AVP is also defined called MIP-Key-Material AVP. /Fredrik 5.0 Key Distribution Center The mobile node and mobility agents use registration keys to compute authentication extensions applied to registration messages, as defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If registration keys are requested the AAA server(s) MUST create key- material after the Mobile Node is successfully authenticated and authorized. If the AAAH does not communicate directly with the foreign agent, and it does not wish for intermediate proxies to have access to the session keys, they SHOULD be protected using the CMS security application [9]. The 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). The SPI values are used as key identifiers, meaning that each registration key has its own SPI value; nodes that share a key also share an SPI. The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home authentication extensions, via the Mobile IP AAA Key Request extensions [15], while the Home Agent allocates the Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. Once the registration keys have been distributed, subsequent Mobile IP registrations need not invoke the AAA infrastructure until the keys expire. These registrations MUST include the Mobile-Home authentication extension. In addition, subsequent registrations MUST also include Mobile-Foreign authentication extension if the Mobile- Foreign key was generated and distributed by AAA; similarly for subsequent use of the Foreign-Home authentication extensions. Each registration key that is generated by AAA will generally be distributed to two parties; for instance, a Mobile-Foreign key goes to both a mobile node and a foreign agent. To the mobile node it is sent as key material and to the foreign agent as en encoded key. The methods by which the key is encoded will depend upon the security associations available to the AAA server and each recipient of the key. These methods will often be different for the two recipients, so that the registration key under consideration has to be encoded twice. See sections 6.0 for details about the format of the AVPs used to transport the registration keys. 5.1 Distributing the Mobile-Home Registration Key If the mobile node does not have a Mobile-Home registration key, then the AAAH is likely to be the only entity trusted that is available to the mobile node. Thus, the AAAH has to generate the Mobile-Home registration key, and encode it for eventual consumption by the mobile node and home agent. If the home agent is in the home domain, then AAAH can directly encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP and include that AVP in the HAR message for delivery to the home agent. If, on the other hand, the home agent is to be allocated in the visited domain, the AAAH does not transmit the HAR to the home agent, but instead transmits the HAR to the AAAF. When the AAAF receives the HAR, it first allocates a home agent, and then issues the HAR for that home agent. The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAA server only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IP messages and extensions [4]. For this purpose, AAAH includes the Mobile-Home registration key-material into a MIP-MN-to-HA-Key AVP, which is added to the HAR message, and delivered either to a local home agent, or to the AAAF in the case where the home agent is in the visited network. The AAAH has to rely on the home agent (that also understands Diameter) to transfer the keying information into a Mobile IP Generalized MN-HA Key Reply extension [15] in the Registration Reply message, using the SPI proposed by the Mobile Node in the MN-HA Key Request From AAA Subtype extension. The home agent can format the Reply message and extensions correctly for eventual delivery to the mobile node. The resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP. After the HAA message is parsed by the AAAH, and transformed into an AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually be received by the the foreign agent. The foreign agent can then use that AVP to recreate a Registration Reply message, containing the Generalized MN-HA Key Reply extension, for delivery to the mobile node. In summary, the AAAH generates the Mobile-Home key material. Using the key material it calculates the key as defined in [4] and encodes it into a MIP-HA-to-MN-Key AVP. The key material is also included in the MIP-MN-to-HA-Key AVP. These AVPs are delivered to a home agent by including them in a HAR message sent from either AAAH or AAAF. The home agent decodes the key for its own use. The home agent also copies the key material from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply extension appended to the Mobile IP Registration Reply message. This Registration Reply message MUST also include the Mobile-Home authentication extension, created using the newly allocated Mobile- Home registration key. The home agent then encodes the Registration Reply message and extensions into a MIP-Reg-Reply AVP included as part of the HAA message to be sent back to the AAA server. 5.2 Distributing the Mobile-Foreign Registration Key The Mobile-Foreign registration key material is also generated by AAAH (upon request), so that it can be added into a MIP-MN-to-FA-Key AVP, which is added to the HAR, and copied by the home agent into a Generalized MN-FA Key Reply Extension [15] to the Mobile IP Registration Reply message, using the SPI proposed by the Mobile Node in the MN-FA Key Request From AAA Subtype extension. Further, the home agent includes the SPI in the HAA's MIP-FA-to-MN-SPI AVP. Most of the considerations for distributing the Mobile-Foreign registration key are similar to the distribution of the Mobile-Home Registration Key. Upon receipt of the HAA, if MN-FA keying was requested the AAAH creates the MIP-FA-to-MN-Key AVP, using the SPI in the MIP-FA-to-MN- SPI, and includes the AVP in the AMA. The key is calculated using the same method as defined in the MIP-MN-to-FA-Key. If the MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent MUST include the Mobile-Foreign authentication extension in the Registration Reply, using the newly distributed key. 5.3 Distributing the Foreign-Home Registration Key If the home agent is in the home domain, then AAAH has to generate the Foreign-Home registration key. Otherwise, it is generated by AAAF. In either case, the AAA server encodes the registration key into a MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message sent to the home agent, and waits for the HAA message to be returned. Upon receipt of the HAR, the home agent recovers the Foreign-Home 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. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. Upon receipt of the HAA, the Diameter server responsible for key allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP- FA-to-HA-SPI, and includes the AVP in the AMA. 5.4 Key Distribution Example Figure 9 provides an example of subsequent Mobile IP message exchange, assuming that AAAH distributed registration keys for all three MN-FA, FA-HA and HA-MN authentication extensions. Mobile Node Foreign Agent Home Agent ----------- ------------- ---------- Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) Figure 9: Mobile IP Message Exchange 6.0 Key Distribution Center (KDC) AVPs The Mobile-IP protocol defines a set of security associations shared between the Mobile Node, Foreign Agent and Home Agents. These three security associations (Mobile-Home, Mobile-Foreign, and Foreign- Home), can be dynamically created by the AAAH. This requires that the AAAH create Mobile-IP Registration Keys, and that these keys be distributed to the three mobile entities, via the Diameter Protocol. AAA servers supporting the Diameter Mobile IP Application MUST implement the KDC AVPs defined in this document. In other words, AAA servers MUST be able to create three registration keys: the Mobile- Home, Mobile-Foreign, and Foreign-Home keys. The names of the KDC AVPs indicate the two entities sharing the security association defined by the encrypted key material; the intended receiver of the AVP is the first named entity. So, for instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key encrypted in a way that allows it to be recovered by the mobile node. If strong authentication and confidentiality of the registration keys is required, it is recommended that the CMS security application [9] be used. The following table describes the Diameter AVPs defined in the Mobile IP application, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| MIP-Algorithm- 345 6.9 Enumerated | M | P | | V | Y | Type | | | | | | MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y | MIP-FA-to-HA-SPI 318 6.13 Unsigned32 | M | P | | V | Y | MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y | MIP-FA-to-MN-SPI 319 6.12 Unsigned32 | M | P | | V | Y | MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y | MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y | MIP-MN-to-FA-Key 325 6.5 OctetString| M | P | | V | Y | MIP-MN-to-HA-Key 331 6.6 OctetString| M | P | | V | Y | MIP-Peer-SPI 342 6.7 Unsigned32 | M | P | | V | Y | MIP-Replay-Mode 346 6.11 Enumerated | M | P | | V | Y | MIP-Session-Key 343 6.8 OctetString| M | P | | V | Y | MIP-Key-Material TBD 6.9 OctetString| M | P | | V | Y | 6.1 MIP-FA-to-MN-Key AVP The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and contains the Foreign Agent's session key, which it shares with the Mobile Node. Its Data field has the following ABNF grammar: MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-Peer-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] 6.2 MIP-FA-to-HA-Key AVP The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and contains the Foreign Agent's session key, which it shares with the Home Agent. Its Data field has the following ABNF grammar: MIP-FA-to-HA-Key ::= < AVP Header: 328 > { MIP-Peer-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] 6.3 MIP-HA-to-FA-Key AVP The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and contains the Home Agent's session key, which it shares with the Foreign Agent. Its Data field has the following ABNF grammar: MIP-HA-to-FA-Key ::= < AVP Header: 329 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] 6.4 MIP-HA-to-MN-Key AVP The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and contains the Home Agent's session key, which it shares with the Mobile Node. Its Data field has the following ABNF grammar: MIP-HA-to-MN-Key ::= < AVP Header: 332 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] 6.5 MIP-MN-to-FA-Key AVP The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and contains the Mobile Node's session key, which it shares with the Foreign Agent. The Home Agent uses this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key from AAA Subtype" extension [15]. The SPI in the extension's FA SPI field is allocated by the Home Agent, but it SHOULD take into consideration the SPI requested by the Mobile Node in the "MN-FA Key Request From AAA Subtype" extension. MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Key-Material } * [ AVP ] 6.6 MIP-MN-to-HA-Key AVP The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and contains the Mobile Node's session key, which it shares with the Home Agent. The Home Agent uses this AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. The SPI in the extension's HA SPI field is allocated by the Home Agent, but it SHOULD take into consideration the SPI requested by the Mobile Node in the "MN-HA Key Request From AAA Subtype" extension. MIP-MN-to-FA-Key ::= < AVP Header: 331 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Key-Material } * [ AVP ] 6.7 MIP-Peer-SPI AVP The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and contains the Security Parameter Index to use to reference the key in the associated MIP-Session-Key AVP. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. 6.8 MIP-Session-Key AVP The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the Session Key to be used between two Mobile IP entities. 6.9 MIP-Key-Material AVP The MIP-Key-Material AVP (AVP Code TBD) is of type OctetString and contains the Session Key Material to be used to calculate the Session Key between two Mobile IP entities. 6.10 MIP-Algorithm-Type AVP The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and contains the Algorithm identifier used to generate the associated Mobile IP authentication extension. The following values are currently defined: 1 Prefix+Suffix MD5 [4] 2 HMAC-MD5 [13] 3 SHA-1 [17] 6.11 MIP-Replay-Mode AVP The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent should use when authenticating the Mobile Node. The following values are supported (see [4] for more information): 0 None 1 Timestamps 2 Nonces 6.12 MIP-FA-to-MN-SPI AVP The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and contains the Security Parameter Index the Foreign Agent is to use to refer to the session key it shares with the Mobile Node. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. This AVP MAY be added in the HAA message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of the MIP-FA-to-MN-Key AVP. 6.13 MIP-FA-to-HA-SPI AVP The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and contains the Security Parameter Index the Foreign Agent is to use to refer to the session key it shares with the Home Agent. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. This AVP MAY be added in the HAA message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of the MIP-FA-to-HA-Key AVP. From owner-aaa-wg@merit.edu Mon Aug 13 16:19: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 QAA28118 for ; Mon, 13 Aug 2001 16:19:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 967EE9123F; Mon, 13 Aug 2001 16:20:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 626D691242; Mon, 13 Aug 2001 16:20: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 43CF89123F for ; Mon, 13 Aug 2001 16:20:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C5205DDEB; Mon, 13 Aug 2001 16:20:18 -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 8325C5DDD8 for ; Mon, 13 Aug 2001 16:20:17 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f7DKFtl21594 for ; Mon, 13 Aug 2001 16:15:55 -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 xma021592; Mon, 13 Aug 01 16:15:49 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f7DKIUf04004 for ; Mon, 13 Aug 2001 16:18:30 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma003962; Mon, 13 Aug 01 16:17:37 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Aug 2001 16:17:23 -0400 Message-ID: From: Balazs Czoma To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Clarification on identifying requests and replies at application level Date: Mon, 13 Aug 2001 16:17:23 -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, The latest Base Protocol Draft states about the Hop-by-hop ID: "Hop-by-Hop Identifier The Hop-by-Hop Identifier field is four octets, and aids in matching requests and replies." My question is if the Hop-by-hop ID is meant to be used 1) to match requests and replies at Base Protocol level only (i.e: for agents to maintain transaction state, which is used for failover purposes) 2) or can the application also use it to match requests and replies when processing the answer. If the answer is option 1, what is the correct way to match requests and replies at application level? The session ID alone surely not since it may be the same over more then 1 transactions. Thank you for the clarification in advance. Regards: Balazs ____________________________________________ Balazs Czoma Siemens Telecom Innovation Centre mailto:Balazs.Czoma@tic.siemens.ca ____________________________________________ From owner-aaa-wg@merit.edu Mon Aug 13 16: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 QAA28186 for ; Mon, 13 Aug 2001 16:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A29091242; Mon, 13 Aug 2001 16:25:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F020C91243; Mon, 13 Aug 2001 16:25: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 E5F8191242 for ; Mon, 13 Aug 2001 16:25:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B99AD5DDF0; Mon, 13 Aug 2001 16:25:20 -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 D1E0C5DDD8 for ; Mon, 13 Aug 2001 16:25:19 -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 QAA10752 for ; Mon, 13 Aug 2001 16:24:05 -0400 (EDT) Date: Mon, 13 Aug 2001 16:25:41 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] 119 E bit, P bit, and proxy-info 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: 13-Aug-2001 Reference: N/A Document: base Comment type: T Priority: 2 Section: 6.1.7, 6.2, and 7.2 Rationale/Explanation of issue: 1. Can a Diameter packet contain both a 'P' bit and a 'E' bit in the packet header? 2. Will a Diameter packet with the 'P' bit set contain the proxy-info data from the request? Requested change: A diameter error packet with an 'E' bit set MUST have the required AVPS listed in section 6.2, "Diameter Answer Processing". Modify section 6.2 to state that these requirements are valid even if the 'E' bit is set. Modify section 7.2 to list the answer-message as ::= < Diameter Header: code, ERR [PXY] > and state that the 'P' bit will be set the same as the 'P' bit in the request. I'm not certain if we need to modify section 6.1.7. It will be technically correct with the requested changes, but probably could be made more clear. -mark From owner-aaa-wg@merit.edu Tue Aug 14 05:36: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 FAA24921 for ; Tue, 14 Aug 2001 05:36:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F3DF91288; Tue, 14 Aug 2001 05:35:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 405009129C; Tue, 14 Aug 2001 05:35: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 1042891288 for ; Tue, 14 Aug 2001 05:35:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7A865DDB0; Tue, 14 Aug 2001 05:35: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 1CB6F5DDA9 for ; Tue, 14 Aug 2001 05:35:50 -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 f7E9ZmO29869 for ; Tue, 14 Aug 2001 11:35:48 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA02653; Tue, 14 Aug 2001 11:35:45 +0200 (MET DST) Message-ID: <3B78F10C.EC242C@rioja.ericsson.se> Date: Tue, 14 Aug 2001 11:36:12 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, Internet Applications 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] Minor editorial changes in CMS Security Application Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-08-14 Reference: Document: CMS-02 Comment type: E Priority: 1 Section: 1.1, 1.2, 1.3, 2.0, 3.1, 3.2, 4.3, 5.0, 6.2 Rationale/Explanation of issue: Minor editorial changes in draft Requested change: In 1.1, page 5 (fourth paragraph): replace "...requires that the initiator issue a..." with "...requires that the initiator issues a..." In 1.2, figure 3: replace "PDSR" with "PDSAR" and "PDSA" with "PDSAA" In 1.3, page 7: rephrase the first paragraph. Maybe the following proposal would be enough: When a redirect agent is used, allowing the access device, or first hop relay or proxy agent, to communicate directly with the home server, the hop-by-hop security mechanisms specified in the base protocol MAY be sufficient. In 1.3, page 7 (second paragraph): replace "...signing of select Diameter..." with "...signing of selected Diameter..." In 1.3, page 7 (second paragraph): replace "AVPS" with "AVPs" In 2.0, page 9 (last paragraph): replace "section 4.5 of [1]" with "section 4.6 of [1]" In 3.1, page 11 (first item in second list): replace "TTL for this SA" with "TTL for this DSA" In 3.1, page 11 (first item in last list): replace "the certificate chain selected is..." with "the certificate chain provided [in the DSAA] is..." In 3.1, page 12 (first paragraph): replace all references to "Diameter node" with "Diameter initiator" In 3.2, page 12 (first item of the list): replace "Diamater" with "Diameter" In 4.3, page 16: replace "an Security Association" with "a Diameter Security Association" In 5.0, page 18: replace all references to "proxy server" with "relay agent" In 6.2, page 21 (second paragraph): replace "CMSEnvelopedData" with "EnvelopedData" In 6.2, page 21 (third paragraph): replace "CMS-Data" with "CMS-Encrypted-Data" Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 14 05:58: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 FAA25266 for ; Tue, 14 Aug 2001 05:58:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A807C91289; Tue, 14 Aug 2001 05:59:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 759F49128A; Tue, 14 Aug 2001 05:59: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 513F991289 for ; Tue, 14 Aug 2001 05:59:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F3EC5DDA7; Tue, 14 Aug 2001 05:59: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 808355DD8F for ; Tue, 14 Aug 2001 05:59: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 f7E9xoO12923 for ; Tue, 14 Aug 2001 11:59:51 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA04088; Tue, 14 Aug 2001 11:59:47 +0200 (MET DST) Message-ID: <3B78F6AF.8F1C8965@rioja.ericsson.se> Date: Tue, 14 Aug 2001 12:00:15 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, Internet Applications 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]: Signing of DSA requests and aswers 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, I've dealing with CMS Security Application draft and there are some issues that remain unclear for me. In 3.1 (Usage scenario), it's said that: The DSAR MAY be signed. If the originating node has a private key and protection expectations for AVPs are specified, then the DSAR SHOULD be signed. As far as I understand, any Diameter message that includes an AVP with the P flag set, must include a CMS-Signed-Data containing the digital signature of those AVPs. In 6.9 and 6.10, it's stated that both Expected-Signed-AVP and Expected-Encrypted-AVP must be authenticated using the CMS-Signed-Data AVP. According to all these points, wouldn't be necessary to change the previous paragraph and write: The DSAR MAY be signed. If the originating node has a private key and protection expectations for AVPs are specified, then the DSAR MUST be signed. since protection expectations for AVPs can only refer to Expected-Signed-AVP and Expected-Encrypted-AVP The next paragraph in 3.1 is the following: The DSAA MUST be signed by a Diameter agent or server within the user's realm, to prevent an intermediate node from modifying the protection expectations for AVPs. Neither of the mandatory AVPs of this command (Result-Code, Origin-Host, Origin-Realm, CA-Chain, AAA-Server-Certs, OCSP-Responses, Destination-Host, Auth-Application-Id, DSA-TTL) must be protected (according to 6.0). So that, if the signing of the answer is mandatory, it will be necessary to protect an AVP (just to have any AVP to sign) or to include a field whose protection is mandatory. I'm not really sure about how to deal with this. And finally an editorial question. I don't think that the sentence: "The DSA(R|A) (MAY|MUST) be signed". In fact, only protected AVPs inside the command are signed, so that I think it would be more appropriate to say "The DSA(R|A) (MAY|MUST) include a digital signature". What do you think? 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 Tue Aug 14 06:09: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 GAA25441 for ; Tue, 14 Aug 2001 06:09:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F9129128A; Tue, 14 Aug 2001 06:10:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D1D59128C; Tue, 14 Aug 2001 06:10: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 EEBD79128A for ; Tue, 14 Aug 2001 06:10:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C96FD5DDCC; Tue, 14 Aug 2001 06:10:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 2A9625DDBA for ; Tue, 14 Aug 2001 06:10: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 f7EAAfO20995 for ; Tue, 14 Aug 2001 12:10:42 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA04754; Tue, 14 Aug 2001 12:10:39 +0200 (MET DST) Message-ID: <3B78F93A.27DBBAB3@rioja.ericsson.se> Date: Tue, 14 Aug 2001 12:11: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]: Revalidation of cache in CMS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, just a question about the re-validation of DSA information. According to the CMS draft (3.1, Usage Scenario), the implementations of CMS may cache that information. Also, they must do one thing (honor the TTL setting) AND another (re-validate certificate) before using cached data. The paragraph is as follows: Implementations MAY cache the information required to establish a DSA, but MUST honor time-to-live settings and MUST re-validate certificates (possibly including revocation checks) before using cached data. What I think is that this re-validation must take place once the TTL has been passed, but the draft looks a little bit confused, because both conditions are suposed to be checked every time (so that, a certification re-validation must be done always). Am I right? Which is the right answer? Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 14 11:49: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 LAA07826 for ; Tue, 14 Aug 2001 11:49:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A940E912A6; Tue, 14 Aug 2001 11:49:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CCED912A7; Tue, 14 Aug 2001 11:49: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 BBB69912A6 for ; Tue, 14 Aug 2001 11:49:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 910DC5DDF0; Tue, 14 Aug 2001 11:49: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 C3AD35DDD7 for ; Tue, 14 Aug 2001 11:49: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 f7EFn0O26192 for ; Tue, 14 Aug 2001 17:49:00 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA23651; Tue, 14 Aug 2001 17:48:55 +0200 (MET DST) Message-ID: <3B794885.E14C8AE@rioja.ericsson.se> Date: Tue, 14 Aug 2001 17:49: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: [AAA-WG]: [issue] More editorial changes in CMS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-08-14 Reference: Document: CMS-02 Comment type: E Priority: 2 Section: Rationale/Explanation of issue: Sentences of the type "the x message must be signed" are confused since not the whole message is signed but only the required AVPs Requested change: Change all occurrences of "the x message must/may/should be signed" with "the x message must/may/should include (or carry) an appropriate digital signature" Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 14 11:55: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 LAA08018 for ; Tue, 14 Aug 2001 11:55:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1DEC912A2; Tue, 14 Aug 2001 11:56:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3A48912A4; Tue, 14 Aug 2001 11:56: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 97479912A2 for ; Tue, 14 Aug 2001 11:56:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CDF25DDF0; Tue, 14 Aug 2001 11:56:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 185465DDD7 for ; Tue, 14 Aug 2001 11:56:33 -0400 (EDT) Received: (qmail 18576 invoked by uid 500); 14 Aug 2001 15:44:55 -0000 Date: Tue, 14 Aug 2001 08:44:55 -0700 From: Pat Calhoun To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] 119 E bit, P bit, and proxy-info Message-ID: <20010814084455.A18495@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 Mon, Aug 13, 2001 at 04:25:41PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk My comments on this issue. On Mon, Aug 13, 2001 at 04:25:41PM -0400, Mark Eklund wrote: > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 13-Aug-2001 > Reference: N/A > Document: base > Comment type: T > Priority: 2 > Section: 6.1.7, 6.2, and 7.2 > Rationale/Explanation of issue: > > 1. Can a Diameter packet contain both a 'P' bit and a 'E' > bit in the packet header? I believe so. If no local action can be taken, the error must be conveyed back to the access client, right? > > 2. Will a Diameter packet with the 'P' bit set contain the > proxy-info data from the request? you mean an answer message? Then of course. > > Requested change: > > A diameter error packet with an 'E' bit set MUST have the > required AVPS listed in section 6.2, "Diameter Answer > Processing". > > Modify section 6.2 to state that these requirements are valid > even if the 'E' bit is set. > > Modify section 7.2 to list the answer-message as > ::= < Diameter Header: code, ERR [PXY] > > and state that the 'P' bit will be set the same as the 'P' > bit in the request. > > I'm not certain if we need to modify section 6.1.7. It will be > technically correct with the requested changes, but probably > could be made more clear. ok PatC From owner-aaa-wg@merit.edu Tue Aug 14 12:12: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 MAA08454 for ; Tue, 14 Aug 2001 12:12:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4744D912A4; Tue, 14 Aug 2001 12:12:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18EEF912A7; Tue, 14 Aug 2001 12:12: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 0AEF8912A4 for ; Tue, 14 Aug 2001 12:12:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D33445DDF0; Tue, 14 Aug 2001 12:12:54 -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 10D595DDF4 for ; Tue, 14 Aug 2001 12:12:54 -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 MAA04505; Tue, 14 Aug 2001 12:11:07 -0400 (EDT) Date: Tue, 14 Aug 2001 12:12:45 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] 119 E bit, P bit, and proxy-info In-Reply-To: <20010814084455.A18495@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, On Tue, 14 Aug 2001, Pat Calhoun wrote: > My comments on this issue. > > On Mon, Aug 13, 2001 at 04:25:41PM -0400, Mark Eklund wrote: > > Submitter name: Mark Eklund > > Submitter email address: meklund@cisco.com > > Date first submitted: 13-Aug-2001 > > Reference: N/A > > Document: base > > Comment type: T > > Priority: 2 > > Section: 6.1.7, 6.2, and 7.2 > > Rationale/Explanation of issue: > > > > 1. Can a Diameter packet contain both a 'P' bit and a 'E' > > bit in the packet header? > > I believe so. If no local action can be taken, the error must be conveyed > back to the access client, right? > > > > > 2. Will a Diameter packet with the 'P' bit set contain the > > proxy-info data from the request? > > you mean an answer message? Then of course. Incorrect wording. The question should have been. Will a Diameter answer with the 'E' bit bit set contain the proxy-info data from the request? My main concern for raising this issue was that I wanted to make certain that answer with the 'E' bit required the same rules as normal answers when it came to adding proxy state data and setting the 'P' bit. An example of a possible violation of this could be a redirect message. It could be considered to not be proxyable, but instead it would have to be handled locally and then a new answer generated for the previous hop depending upon how it was handled. Thus the 'P' bit wouldn't be set even though the request contained one. My suggestion makes this illegal. -mark > > > > > Requested change: > > > > A diameter error packet with an 'E' bit set MUST have the > > required AVPS listed in section 6.2, "Diameter Answer > > Processing". > > > > Modify section 6.2 to state that these requirements are valid > > even if the 'E' bit is set. > > > > Modify section 7.2 to list the answer-message as > > ::= < Diameter Header: code, ERR [PXY] > > > and state that the 'P' bit will be set the same as the 'P' > > bit in the request. > > > > I'm not certain if we need to modify section 6.1.7. It will be > > technically correct with the requested changes, but probably > > could be made more clear. > > ok > > PatC > From owner-aaa-wg@merit.edu Tue Aug 14 12:16: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 MAA08596 for ; Tue, 14 Aug 2001 12:16:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E70B3912A9; Tue, 14 Aug 2001 12:14:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F1EF912AE; Tue, 14 Aug 2001 12: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 5D4CF912A9 for ; Tue, 14 Aug 2001 12:14:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 387EE5DDF7; Tue, 14 Aug 2001 12:14:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id A767A5DDF4 for ; Tue, 14 Aug 2001 12:14:25 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7EGESi07993 for ; Tue, 14 Aug 2001 11:14:28 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 14 Aug 2001 11:14:05 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 14 Aug 2001 11:14:05 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 14 Aug 2001 11:14:01 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D0B01A6@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEidVcPaJxdVo5QEdWJUgAIx6TWpQCYvw/w From: To: , Cc: , , X-OriginalArrivalTime: 14 Aug 2001 16:14:05.0360 (UTC) FILETIME=[23B5B300:01C124DC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08596 Pat, Charlie, I believe that the work on standardizing a protocol that enables the use of AAA to authorize network access for IPv6 nodes is very important and should be started as soon as possible. In fact, I believe that such work item is great enabler for the successful deployment of AAA and IPv6 in commercial networks. However, I'm not so sure whether it should be the AAA WG to take care of such work item or if URP (when/if it becomes a WG) should work on it. According to the discussion on the URP mailing list and the feedback at the URP BOF at IETF 51, it seems to me that this work item would find a better home in URP than in AAA WG. Perhaps we should also hear from URP people to see what they think. Also, I'd like to hear comments from IPNG people to see why the AAA WG is the appropriate home for this work item and what they think about having URP as group handling the work item. Regarding the future work of AAA WG, I hope the WG will not be dismissed since, as Pat suggests, it would be the perfect place for other WG to provide their input for new applications. This would ensure that new applications can be created in a single place even if relevant to issues discussed in other WGs. This would allow some level of coordination, instead of having work done in several separate places with the risk of overlapping efforts and incompatible results. As for the AAA WG charter, if I'm not wrong in the current charter it is written that "The protocol must include attributes in support for IPv6 network access". What this actually mean is not so clear to me, since it can be read in several ways. Can somebody clarify it? Form my point of view, if the AAA WG is still alive after the current specifications are completed, the charter already supports new applications related to IPv6. As an example, applications such as the one proposed at IETF 51 (draft-le-aaa-diameter-mobileipv6-00.txt) should be supported thanks to the above statement. Thanks, Stefano F. -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Saturday, August 11, 2001 9:38 AM To: Perkins Charles (IPRG) Cc: IPng Working Group; AAA Working Group Mailing List Subject: Re: [AAA-WG]: AAA for IPv6 I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-aaa-wg@merit.edu Tue Aug 14 12:44:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09715 for ; Tue, 14 Aug 2001 12:44:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9D22912A5; Tue, 14 Aug 2001 12:45:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BF73912A8; Tue, 14 Aug 2001 12:45: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 40DD2912A5 for ; Tue, 14 Aug 2001 12:45:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F4E95DDF3; Tue, 14 Aug 2001 12:45:04 -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 7F3B35DDD7 for ; Tue, 14 Aug 2001 12:45:03 -0400 (EDT) Received: (qmail 19455 invoked by uid 500); 14 Aug 2001 16:33:25 -0000 Date: Tue, 14 Aug 2001 09:33:25 -0700 From: Pat Calhoun To: Mark Eklund Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] 119 E bit, P bit, and proxy-info Message-ID: <20010814093325.C18495@charizard.diameter.org> Mail-Followup-To: Mark Eklund , Pat Calhoun , aaa-wg@merit.edu References: <20010814084455.A18495@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 meklund@cisco.com on Tue, Aug 14, 2001 at 12:12:45PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Aug 14, 2001 at 12:12:45PM -0400, Mark Eklund wrote: > Pat, > > On Tue, 14 Aug 2001, Pat Calhoun wrote: > > > My comments on this issue. > > > > On Mon, Aug 13, 2001 at 04:25:41PM -0400, Mark Eklund wrote: > > > Submitter name: Mark Eklund > > > Submitter email address: meklund@cisco.com > > > Date first submitted: 13-Aug-2001 > > > Reference: N/A > > > Document: base > > > Comment type: T > > > Priority: 2 > > > Section: 6.1.7, 6.2, and 7.2 > > > Rationale/Explanation of issue: > > > > > > 1. Can a Diameter packet contain both a 'P' bit and a 'E' > > > bit in the packet header? > > > > I believe so. If no local action can be taken, the error must be conveyed > > back to the access client, right? > > > > > > > > 2. Will a Diameter packet with the 'P' bit set contain the > > > proxy-info data from the request? > > > > you mean an answer message? Then of course. > > Incorrect wording. The question should have been. > > Will a Diameter answer with the 'E' bit bit set contain the > proxy-info data from the request? yes. > > My main concern for raising this issue was that I wanted to make > certain that answer with the 'E' bit required the same rules as > normal answers when it came to adding proxy state data and > setting the 'P' bit. Ah, that's very important. > An example of a possible violation of this could be a redirect > message. It could be considered to not be proxyable, but > instead it would have to be handled locally and then a new > answer generated for the previous hop depending upon how it was > handled. Thus the 'P' bit wouldn't be set even though the > request contained one. well, I suppose it really depends on who handles the redirect message. It is conceivable that a dumb relay will not process these, and allow a downstream agent to take care of it. Not sure that we want to restrict network configurations here. PatC > > My suggestion makes this illegal. > > -mark > > > > > > > > > > Requested change: > > > > > > A diameter error packet with an 'E' bit set MUST have the > > > required AVPS listed in section 6.2, "Diameter Answer > > > Processing". > > > > > > Modify section 6.2 to state that these requirements are valid > > > even if the 'E' bit is set. > > > > > > Modify section 7.2 to list the answer-message as > > > ::= < Diameter Header: code, ERR [PXY] > > > > and state that the 'P' bit will be set the same as the 'P' > > > bit in the request. > > > > > > I'm not certain if we need to modify section 6.1.7. It will be > > > technically correct with the requested changes, but probably > > > could be made more clear. > > > > ok > > > > PatC > > > From owner-aaa-wg@merit.edu Tue Aug 14 12:47: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 MAA09873 for ; Tue, 14 Aug 2001 12:47:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C280912A8; Tue, 14 Aug 2001 12:48:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED02E912AA; Tue, 14 Aug 2001 12:48: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 AC88F912A8 for ; Tue, 14 Aug 2001 12:47:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7ECD55DDF3; Tue, 14 Aug 2001 12:47:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2A2275DDD7 for ; Tue, 14 Aug 2001 12:47:29 -0400 (EDT) Received: (qmail 19471 invoked by uid 500); 14 Aug 2001 16:35:52 -0000 Date: Tue, 14 Aug 2001 09:35:51 -0700 From: Pat Calhoun To: Balazs Czoma Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Clarification on identifying requests and replies at application level Message-ID: <20010814093551.D18495@charizard.diameter.org> Mail-Followup-To: Balazs Czoma , "'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 Balazs.Czoma@tic.siemens.ca on Mon, Aug 13, 2001 at 04:17:23PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Aug 13, 2001 at 04:17:23PM -0400, Balazs Czoma wrote: > Hi, > > The latest Base Protocol Draft states about the Hop-by-hop ID: > "Hop-by-Hop Identifier > The Hop-by-Hop Identifier field is four octets, and aids in > matching requests and replies." > > My question is if the Hop-by-hop ID is meant to be used > 1) to match requests and replies at Base Protocol level only (i.e: for > agents to maintain transaction state, which is used for failover purposes) > 2) or can the application also use it to match requests and replies when > processing the answer. It can work at both levels, but the problem with doing it at the application level is that the app would have to be aware of the set of peers, where messages are sent, and from whom they are received. I would propose that a translation occur somewhere in the shim between your base and app. Perhaps the app provides some form of handle, which the base protocol (let's just call it the library, in API terms) would cache, and provide back to the app when the answer is received. That's the way I would design it. > > If the answer is option 1, what is the correct way to match requests and > replies at application level? The session ID alone surely not since it may > be the same over more then 1 transactions. See above. PatC From owner-aaa-wg@merit.edu Tue Aug 14 12:52: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 MAA09984 for ; Tue, 14 Aug 2001 12:52:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B4E2F912AA; Tue, 14 Aug 2001 12:53:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8681F912AB; Tue, 14 Aug 2001 12:53: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 7069D912AA for ; Tue, 14 Aug 2001 12:53:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40DC25DDF3; Tue, 14 Aug 2001 12:53: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 AEC2C5DDD7 for ; Tue, 14 Aug 2001 12:53:23 -0400 (EDT) Received: (qmail 19494 invoked by uid 500); 14 Aug 2001 16:41:46 -0000 Date: Tue, 14 Aug 2001 09:41:46 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Signing of DSA requests and aswers Message-ID: <20010814094146.E18495@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B78F6AF.8F1C8965@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: <3B78F6AF.8F1C8965@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 14, 2001 at 12:00:15PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 14, 2001 at 12:00:15PM +0200, Miguel Ángel Monjas Llorente wrote: > Hi, > > I've dealing with CMS Security Application draft and there are some > issues that remain unclear for me. > > In 3.1 (Usage scenario), it's said that: > > The DSAR MAY be signed. If the originating node has a private key > and > protection expectations for AVPs are specified, then the DSAR > SHOULD > be signed. > > As far as I understand, any Diameter message that includes an AVP with > the P flag set, must include a CMS-Signed-Data containing the digital > signature of those AVPs. In 6.9 and 6.10, it's stated that both > Expected-Signed-AVP and Expected-Encrypted-AVP must be authenticated > using the CMS-Signed-Data AVP. According to all these points, wouldn't > be necessary to change the previous paragraph and write: > > The DSAR MAY be signed. If the originating node has a private key > and > protection expectations for AVPs are specified, then the DSAR MUST > be signed. yes, you are correct. I would file an issue on this. > > since protection expectations for AVPs can only refer to > Expected-Signed-AVP and Expected-Encrypted-AVP > > > The next paragraph in 3.1 is the following: > > The DSAA MUST be signed by a Diameter agent or server within the > user's realm, to prevent an intermediate node from modifying the > protection expectations for AVPs. > > Neither of the mandatory AVPs of this command (Result-Code, > Origin-Host, Origin-Realm, CA-Chain, AAA-Server-Certs, OCSP-Responses, > Destination-Host, Auth-Application-Id, DSA-TTL) must be protected > (according to 6.0). So that, if the signing of the answer is > mandatory, it will be necessary to protect an AVP (just to have any > AVP to sign) or to include a field whose protection is mandatory. I'm > not really sure about how to deal with this. to be clear, these AVPs MAY have the 'P' bit set, according to section 6. So, the issue is that it is a MAY, and not a MUST, right? > And finally an editorial question. I don't think that the sentence: > "The DSA(R|A) (MAY|MUST) be signed". In fact, only protected AVPs > inside the command are signed, so that I think it would be more > appropriate to say "The DSA(R|A) (MAY|MUST) include a digital > signature". What do you think? How about "... (MAY|MUST) include the CMS-Signed-Data AVP" instead? PatC From owner-aaa-wg@merit.edu Tue Aug 14 12:56: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 MAA10086 for ; Tue, 14 Aug 2001 12:56:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1D33E912B1; Tue, 14 Aug 2001 12:55:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA871912AE; Tue, 14 Aug 2001 12:55: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 1FE02912AC for ; Tue, 14 Aug 2001 12:55:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 067425DDF3; Tue, 14 Aug 2001 12:55:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 99DA95DDD7 for ; Tue, 14 Aug 2001 12:55:00 -0400 (EDT) Received: (qmail 19512 invoked by uid 500); 14 Aug 2001 16:43:23 -0000 Date: Tue, 14 Aug 2001 09:43:23 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Revalidation of cache in CMS Message-ID: <20010814094323.F18495@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B78F93A.27DBBAB3@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: <3B78F93A.27DBBAB3@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 14, 2001 at 12:11:06PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 14, 2001 at 12:11:06PM +0200, Miguel Ángel Monjas Llorente wrote: > Hi, > > just a question about the re-validation of DSA information. According > to the CMS draft (3.1, Usage Scenario), the implementations of CMS may > cache that information. Also, they must do one thing (honor the TTL > setting) AND another (re-validate certificate) before using cached > data. The paragraph is as follows: > > Implementations MAY cache the information required to establish a > DSA, but MUST honor time-to-live settings and MUST re-validate > certificates (possibly including revocation checks) before using > cached data. > > What I think is that this re-validation must take place once the TTL > has been passed, but the draft looks a little bit confused, because > both conditions are suposed to be checked every time (so that, a > certification re-validation must be done always). Am I right? Which is > the right answer? That certainly is what the text currently reads. I'm not sure about rechecking a cert each time it needs to be used, but I suspect that's the way most implementations work. Anyone have any thoughts on this one? PatC From owner-aaa-wg@merit.edu Tue Aug 14 12:59: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 MAA10184 for ; Tue, 14 Aug 2001 12:59:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34AC0912AC; Tue, 14 Aug 2001 12:59:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A6C7912AE; Tue, 14 Aug 2001 12:59: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 DE40E912AC for ; Tue, 14 Aug 2001 12:59:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C40FE5DDF4; Tue, 14 Aug 2001 12:59: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 01DBE5DDD7 for ; Tue, 14 Aug 2001 12:59: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 f7EGxsO13324; Tue, 14 Aug 2001 18:59:55 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA26911; Tue, 14 Aug 2001 18:59:51 +0200 (MET DST) Message-ID: <3B795925.7DD0EBE0@rioja.ericsson.se> Date: Tue, 14 Aug 2001 19:00: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Signing of DSA requests and aswers References: <3B78F6AF.8F1C8965@rioja.ericsson.se> <20010814094146.E18495@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 DSAR MAY be signed. If the originating node has a private key > > and > > protection expectations for AVPs are specified, then the DSAR MUST > > be signed. > > yes, you are correct. I would file an issue on this. OK > > Neither of the mandatory AVPs of this command (Result-Code, > > Origin-Host, Origin-Realm, CA-Chain, AAA-Server-Certs, OCSP-Responses, > > Destination-Host, Auth-Application-Id, DSA-TTL) must be protected > > (according to 6.0). So that, if the signing of the answer is > > mandatory, it will be necessary to protect an AVP (just to have any > > AVP to sign) or to include a field whose protection is mandatory. I'm > > not really sure about how to deal with this. > > to be clear, these AVPs MAY have the 'P' bit set, according to section 6. > So, the issue is that it is a MAY, and not a MUST, right? That's right. I just wanted to point the fact that in some extreme conditions, the command would fail if the implementation wasn't quite careful. > > And finally an editorial question. I don't think that the sentence: > > "The DSA(R|A) (MAY|MUST) be signed". In fact, only protected AVPs > > inside the command are signed, so that I think it would be more > > appropriate to say "The DSA(R|A) (MAY|MUST) include a digital > > signature". What do you think? > > How about "... (MAY|MUST) include the CMS-Signed-Data AVP" instead? Perfect!!! :-)) // M.A. From owner-aaa-wg@merit.edu Tue Aug 14 14:30: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 OAA12449 for ; Tue, 14 Aug 2001 14:30:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C518912B0; Tue, 14 Aug 2001 14:30:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 054DE912B2; Tue, 14 Aug 2001 14:30: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 A2AAD912B0 for ; Tue, 14 Aug 2001 14:30:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BF8B5DDA7; Tue, 14 Aug 2001 14:30: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 A52445DD8F for ; Tue, 14 Aug 2001 14:30:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA04884; Tue, 14 Aug 2001 11:23:09 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 14 Aug 2001 11:23:09 -0700 (PDT) From: Bernard Aboba To: stefano.faccin@nokia.com Cc: pcalhoun@diameter.org, charliep@iprg.nokia.com, aaa-wg@merit.edu, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <82ECD4351A4A9547957C606034A3CB8D0B01A6@daebe005.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > As for the AAA WG charter, if I'm not wrong in the current charter it is > written that "The protocol must include attributes in support for IPv6 > network access". What this actually mean is not so clear to me, since it > can be read in several ways. Can somebody clarify it? The current charter refers to enabling IPv6 network access in conventional NAS applications (e.g. PPPv6). Since Mobile IPv6 work was not complete at the time the original requirements work was done, AAA for MIPv6 was not included in the charter. In general, addition of a AAA WG charter item for MIPv6 is only appropriate when the appropriate subject area WGs have completed their work. So work on the authentication architecture for MIPv6 needs to occur outside AAA WG where the appropriate subject matter experts reside. Once those experts have reached consensus and produced a document, the AAA WG can consider that document as input. This process ensures proper coordination between the AAA WG and subject area WGs. So a AAA WG work item for MIPv6 is dependent on progress within the BURP and MIPv6 communities. From owner-aaa-wg@merit.edu Tue Aug 14 18:50: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 SAA16542 for ; Tue, 14 Aug 2001 18:50:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3FDA191213; Tue, 14 Aug 2001 18:51:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13DA7912B9; Tue, 14 Aug 2001 18:51: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 DF41291213 for ; Tue, 14 Aug 2001 18:51:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B330C5DDFA; Tue, 14 Aug 2001 18:51:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 65E8C5DDA7 for ; Tue, 14 Aug 2001 18:51:01 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7EMq1I20466 for ; Tue, 14 Aug 2001 17:52:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 14 Aug 2001 17:50:43 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 14 Aug 2001 17:50:47 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 14 Aug 2001 17:50:39 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D0B01A8@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEk7yL2T2g6+JDhEdWpVgBQi2kYTQADSopA From: To: Cc: , , X-OriginalArrivalTime: 14 Aug 2001 22:50:47.0073 (UTC) FILETIME=[8EA2E110:01C12513] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA16542 Bernard, thanks for your answer and the clarification. I agree that the application for the Mobile IPv6 specific case is dependent on the work in URP, since a protocol between the MN and the network needs to be defined to support the authorization and authentication (and optionally other features) of the IPv6 node. It is exactly for this reason that I suggested that the correct home for the work item proposed by Charlie (related to AAAv6) would be URP and not AAA WG. I would also add that if positive progress happens in URP, URP may indicate AAA WG the need for such an application. I also understand your concern about the relation between new applications and protocols defined in other WGs that have not been closed completely yet. However, the issues under discussion in MIPv6 do not impact the MIPv6 application proposed in the draft draft-le-aaa-diameter-mobileipv6-00.txt. In fact, unless the protocol is heavily modified besides the aspects for security of BUs (quite improbable), the draft for the MIPv6 application still applies. For this reason, I believe the group can still start working on such application. Moreover, I believe the title of the draft may be misleading and for this reason is going to be changed and the draft re-submitted. In fact, the draft applies in general to the support through the AAA Diameter infrastructure of authorization of network access for IPv6 nodes, authentication of the IPv6 node and key distribution for the IPv6 node. In addition, if the node happens to be a Mobile IPv6 node, support of mobility can be provided. For these reasons, the draft is not directly dependent on the fate of Mobile IPv6, and from your description of the charter I believe it applies to the AAA WG. Stefano F. -----Original Message----- From: ext Bernard Aboba [mailto:aboba@internaut.com] Sent: Tuesday, August 14, 2001 1:23 PM To: Faccin Stefano (NRC/Dallas) Cc: pcalhoun@diameter.org; Perkins Charles (IPRG); aaa-wg@merit.edu; ipng@sunroof.eng.sun.com; urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 > As for the AAA WG charter, if I'm not wrong in the current charter it is > written that "The protocol must include attributes in support for IPv6 > network access". What this actually mean is not so clear to me, since it > can be read in several ways. Can somebody clarify it? The current charter refers to enabling IPv6 network access in conventional NAS applications (e.g. PPPv6). Since Mobile IPv6 work was not complete at the time the original requirements work was done, AAA for MIPv6 was not included in the charter. In general, addition of a AAA WG charter item for MIPv6 is only appropriate when the appropriate subject area WGs have completed their work. So work on the authentication architecture for MIPv6 needs to occur outside AAA WG where the appropriate subject matter experts reside. Once those experts have reached consensus and produced a document, the AAA WG can consider that document as input. This process ensures proper coordination between the AAA WG and subject area WGs. So a AAA WG work item for MIPv6 is dependent on progress within the BURP and MIPv6 communities. From owner-aaa-wg@merit.edu Tue Aug 14 23:54: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 XAA22443 for ; Tue, 14 Aug 2001 23:54:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 343EE91247; Tue, 14 Aug 2001 23:55:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE1EE91248; Tue, 14 Aug 2001 23:55: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 CF99E91247 for ; Tue, 14 Aug 2001 23:55:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A0E1C5DDA6; Tue, 14 Aug 2001 23:55:09 -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 E1D3F5DD99 for ; Tue, 14 Aug 2001 23:55:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id UAA05470; Tue, 14 Aug 2001 20:48:22 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 14 Aug 2001 20:48:21 -0700 (PDT) From: Bernard Aboba To: stefano.faccin@nokia.com Cc: aaa-wg@merit.edu, deering@cisco.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <82ECD4351A4A9547957C606034A3CB8D0B01A8@daebe005.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I also understand your concern about the relation between new > applications and protocols defined in other WGs that have not been > closed completely yet. > > I believe the title of the draft may be misleading and for > this reason is going to be changed and the draft re-submitted. In fact, > the draft applies in general to the support through the AAA Diameter > infrastructure of authorization of network access for IPv6 nodes, > authentication of the IPv6 node and key distribution for the IPv6 node. Has this draft been presented within the IPNG WG? Since IPv6 architecture occurs within IPNG WG, the proposed IPv6/AAA authentication architecture would need to be presented and gain consensus within the IPNG WG before a AAA WG work item could be considered. From owner-aaa-wg@merit.edu Wed Aug 15 02:06: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 CAA09376 for ; Wed, 15 Aug 2001 02:06:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3446A91248; Wed, 15 Aug 2001 02:07:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F230191249; Wed, 15 Aug 2001 02:07:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA04791248 for ; Wed, 15 Aug 2001 02:07:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C29905DD92; Wed, 15 Aug 2001 02:07:29 -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 B66A15DDC5 for ; Wed, 15 Aug 2001 02:07:28 -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 f7F6B4G00657 for ; Wed, 15 Aug 2001 09:11:04 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 15 Aug 2001 09:07:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVTJVC>; Wed, 15 Aug 2001 09:07:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094175@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aboba@internaut.com, stefano.faccin@nokia.com Cc: aaa-wg@merit.edu, deering@cisco.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Wed, 15 Aug 2001 09:07:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Bernard, RE: AAAv6 draft > Has this draft been presented within the IPNG WG? Since IPv6 > architecture occurs within IPNG WG, the proposed IPv6/AAA > authentication architecture would need to be presented and > gain consensus within the IPNG WG before a AAA WG work item > could be considered. Charlie Perkins presented the AAAv6 draft he has been writing to the IPNG WG. There seemed to be general consensus that this was good work (in general) and be persued. It seemed to the group that IPNG WG was not the best place for this, but the AAA could be one possibility. Erik Nordmark also suggested that URP could be another home. Of course, if I have mis-interpreted the consensus, I' sure someone (Steve?) could correct me. I'm in favor of this going forward. I think that no official decision has been made on URP (whether or not it is to be a WG) - perhaps the Area Directors & Work Group chairs could discuss where the best place for this work is. best regards, John From owner-aaa-wg@merit.edu Thu Aug 16 04:21: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 EAA26005 for ; Thu, 16 Aug 2001 04:21:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7FB791220; Thu, 16 Aug 2001 04:22:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67BAE912CF; Thu, 16 Aug 2001 04:22: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 32C1291220 for ; Thu, 16 Aug 2001 04:22:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07CAF5DDF7; Thu, 16 Aug 2001 04:22:19 -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 DE92C5DDC7 for ; Thu, 16 Aug 2001 04:22:17 -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 f7G8MFN28332 for ; Thu, 16 Aug 2001 10:22:15 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA01303; Thu, 16 Aug 2001 10:22:08 +0200 (MET DST) Message-ID: <3B7B82D9.320EE9A5@rioja.ericsson.se> Date: Thu, 16 Aug 2001 10:22: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 Subject: Re: [AAA-WG]: [issue] Minor editorial changes in CMS Security Application References: <3B78F10C.EC242C@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-08-14 > Reference: > Document: CMS-02 > Comment type: E > Priority: 1 > Section: 1.1, 1.2, 1.3, 2.0, 3.1, 3.2, 4.3, 5.0, 6.2 > Rationale/Explanation of issue: BTW, in the References point, reference [11] should be "S/MIME v3 Message Specification" if we're talking about RFC 2633. Isn't it? Regards // M.A. From owner-aaa-wg@merit.edu Thu Aug 16 06:02: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 GAA27087 for ; Thu, 16 Aug 2001 06:02:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 13578912D0; Thu, 16 Aug 2001 06:03:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2F15912D1; Thu, 16 Aug 2001 06:03: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 B0C11912D0 for ; Thu, 16 Aug 2001 06:03:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81AED5DDC7; Thu, 16 Aug 2001 06:03:16 -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 A098C5DDFB for ; Thu, 16 Aug 2001 06:03:15 -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 f7GA3EN04744 for ; Thu, 16 Aug 2001 12:03:14 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA06911; Thu, 16 Aug 2001 12:03:11 +0200 (MET DST) Message-ID: <3B7B9A89.CE08171C@rioja.ericsson.se> Date: Thu, 16 Aug 2001 12:03:53 +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 Security Application procedures (I) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi again, I've trying to get a comprehensive view of CMS Security Application. I began with the CMS Security draft and with the CMS RFC (along with the RSA's specification of PKCS#7 and the Layman's Guide of ASN.1 as a starting point). I forgot to mention than I had no previous experience with MIME or S/MIME. The task has proved to be hard because there are a number of RFCs or drafts that must be read, there are a lot of backwards references and CMS Security uses just a subset of S/MIME which in turn uses only a subset of CMS. So that, finally, I've missed certain points (that should be clear for experts in S/MIME, but are not for me). I've been dealing with the process of getting CMS-Signed-Data and CMS-Encrypted-Data. What follows below is what I understantd is the process of getting a CMS-Signed-Data AVP, along with my doubts and concerns. Could someone light me? Many thanks in advance. ========================================================== In order to get a CMS-Signed-Info AVP, the following steps are necessary: a) the Diameter node collects all the AVPs with need to be protected (AVPs with the 'P' bit) in a Diameter message. b) those APVs are concatenated in the order in which they occur in the Diameter message, including padding [CMSSec, 6.1] First concern: According to [CMSSec, 6.1, second paragraph], the result of step b) is the entry to the signing process. But when [SMIME, 3.1 ("Preparing the MIME Entity for Signing and Enveloping")] describes the procedure to create MIME entities that are to be "signed, enveloped, or both signed and enveloped", it points that the procedure comprises the following steps: 1. The MIME entity is prepared according to the local convencions (which might be the process described in b) i.e. concatenating) 2. The leaf parts of the MIME entity are converted to canonical form 3. Appropriate transfer encoding is applied. Is that three-step procedure necessary to generate the message which will signed (or enveloped) to produce a CMS-Signed-Data AVP? Or is it intended that just the concatenation is enough? Or maybe I'm missing anything (because of my slight knowledge of MIME). Could anyone add any clarification to this process? BTW, according to [MIME5, 4 ("Canonical Encoding Model")], there is a fourth step: "Insertion into entity", which implies the setting of appropiate MIME headers. I assume that this step isn't necessary anyway (if not, which Content-type to use? application/octect-stream?) c) creation of the CMS-Signed-Data AVP. According to [CMS], SignedData type comprises the following components: 1. version 2. digestAlgorithms (as [CMSSec] just considers SHA-1 as hash algorithm, that will be the content of this field) 3. encapContentInfo (type EncapsulatedContentInfo). This type comprises the content type of the content being signed (eContentType) and the content itself (eContent, which is optional). According to [SMIME] eContentType must be id-data while according to [CMSSec], eContent is absent. 4. certificates. This field might convey digital certificates but, as far as I understand, [CMSSec] intends that digital signatures and certificates will be carried in different AVPs CMS-Signed-Data and CMS-Certs, respectively), so that this optional field will be absent in CMS-Signed-Data AVPs. Am I right? 5. crls. The same comments than in the previous item are applied. 6. signerInfos (type SignerInfos), a collection of per-signer information (values of type SingerInfo), each containing: - version - sid (type SingerIdentifier, the identifier of the signer) - digestAlgorithm (SHA-1) - signatureAlgorithm (RSA) - the signature itself (signature, type SignatureValue) - and, optionally, a set of signed and unsigned attributes (type Attribute). No mention about these fields is done in [CMSSec], but [SMIME, 2.5] states that "sending agents" should generate a set of signed attributes (like signingTime or sMIMECabilities). I suppose that these signed attributes aren't necessary here, but ... d) the CMS object is encoded by means of the BER (Basic Encoding Rules) e) here we have an only CMS-Signed-Data to be included in the Diameter message There are, still, some additional doubts: - [CMSSec] says in 6.1: Instead, the digest value within the SignedData structure contains the digest produced in the signature process. Which digest value is it talking about? There isn't any direct digest field in a SignedData value. Just two fields can convey "data": SignedData EncapsulatedContentInfo eContent (which carries the data being signed and is absent according to [CMSSec]) and SignedData SignerInfos signature (which is the signed digest). The only possibility is that we're talking about a value of message-digest attribute type (as defined in [CMS, 11.2]). An attribute of this type may be inserted into any of the SignerInfo values that comprises Signed Data SignerInfos (take into account that this value would be the same for all the SingerInfo value, so that only one digest algorithm must be supported in [CMSSec]). However, this attribute is only required (in [CMS, 11.2]) if any other attribute is present (if present, message-digest is a SignedAttribute). Is it mandatory to add this attribute in CMS-Signed-Data (maybe in order to allow further countersignature operations)? If so, [CMSSec] should include the following paragraph in 6.2: The CMS SignedData value encapsulated as a CMS-Signed-Data MUST include a message-digest attribute in the SingerInfo value as specified in [CMS] since its presence is necessary to compute further countersignature attributes (whose utility is depicted below). This attribute MUST be always signed. - When dealing with multiple entities wishing to add signatures, the countersignature attribute is introduced. This attribute belongs to the UnsignedAttributes in a SignerInfo value. May I assume that there will be only one singerInfo in a SignedData value (including a message-digest attribute) and that multiple signatures will be handled only like countersignature attributes (which allows not to resign the whole set of AVPs)? Or is it possible to have more than one signerInfo structure within a CMS-Signed-Data AVP? References: [CMSSec] "Diameter CMS Security Application" [CMS] "Cryptographic Message Syntax", RFC 2630 [SMIME]: "S/MIME v3 Message Specification", RFC2633. [MIME5]: "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2045 ========================================================== Regards // M.A. From owner-aaa-wg@merit.edu Thu Aug 16 08:42: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 IAA02990 for ; Thu, 16 Aug 2001 08:42:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39A48912D2; Thu, 16 Aug 2001 08:43:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09347912D3; Thu, 16 Aug 2001 08:43: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 D9105912D2 for ; Thu, 16 Aug 2001 08:43:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE0325DDF7; Thu, 16 Aug 2001 08:43:54 -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 CB3785DDC7 for ; Thu, 16 Aug 2001 08:43: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 f7GChqN16793 for ; Thu, 16 Aug 2001 14:43:52 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA16002; Thu, 16 Aug 2001 14:43:49 +0200 (MET DST) Message-ID: <3B7BC030.A8DC7571@rioja.ericsson.se> Date: Thu, 16 Aug 2001 14:44:32 +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] More editorial changes in CMS References: <3B794885.E14C8AE@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-08-14 > Reference: > Document: CMS-02 > Comment type: E > Priority: 2 > Section: > Rationale/Explanation of issue: > Sentences of the type "the x message must be signed" are confused > since not the whole message is signed but only the required AVPs > > Requested change: > Change all occurrences of "the x message must/may/should be signed" > with "the x message must/may/should include (or carry) an appropriate > digital signature" According to Pat's answer to my previous "Signing of DSA requests and aswers" , the requested change must be: "... (MUST|MAY) include the CMS-Signed-Data AVP" Regards // M.A. From owner-aaa-wg@merit.edu Thu Aug 16 09:43: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 JAA06343 for ; Thu, 16 Aug 2001 09:43:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EB5D912D3; Thu, 16 Aug 2001 09:43:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34034912D4; Thu, 16 Aug 2001 09:43: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 15EE6912D3 for ; Thu, 16 Aug 2001 09:43:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E141D5DDF7; Thu, 16 Aug 2001 09:43:47 -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 0E77D5DDC7 for ; Thu, 16 Aug 2001 09:43:47 -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 f7GDhcO18001 for ; Thu, 16 Aug 2001 15:43:42 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA19387; Thu, 16 Aug 2001 15:43:34 +0200 (MET DST) Message-ID: <3B7BCE31.203E066B@rioja.ericsson.se> Date: Thu, 16 Aug 2001 15:44: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]: CMS-Encrypted-Data AVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I've got a pair of questions regarding CMS-Encrypted-Data AVP in point 6.2 in CMS Security Application. The first one refers to the next paragraph: Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the eContentType of the EncapsulatedContentInfo MUST be id-data [11]. EncapsulatedContentInfo is the type of the value encapContentInfo inside the CMS SignedData type, not EncapsulatedData. No value of such type belongs to EncapsulatedData definition, so that I suspect this paragraph refers really to CMS-Signed-Data and should be moved to &.1 point. The sense of the next paragraph isn't quite clear for me: CMS-Encrypted-Data MAY contain more than one CMS object, that is, implementations MUST be able to add a new CMS-Encrypted-Data AVP value and also MUST be able to decrypt all CMS-Encrypted-Data AVP values which are encrypted for them. The first sentence ("CMS-Encrypted-Data MAY contain more than one CMS object") might suggest that it is possible to encrypt several AVPs into a CMS-Encrypted-Data AVP (even if those AVPs are also CMS-Encrypted-Data AVPs). That is, it refers to nested enveloping. However, the following sentence which is a consequence of the previous ("implementations MUST be able to add a new CMS-Encrypted-Data AVP value") isn't straightforward. I mean, it might suggest that a implementation MUST be able to add a new CMS-Encrypted-Data AVP to a message. The last sentence ("also MUST be able to decrypt all CMS-Encrypted-Data AVP values which are encrypted for them") contradict my previous interpretations. If there're nested encryption, just the "last" enveloped might be opened, so that a nested envelope couldn't be opened by the receiver unless he didn't open the external envelopes. On the other hand, with different CMS-Encrypted-Data AVPs inside the same message and with different recipients, any AVP would be opened by the intended recipient. Another possibility is that the paragraph is trying to say that new RecipientInfo values may be inserted. But that can't be true since it would be necessary to be a recipient to decrypt the CEK and reencrypt it with a new public key. Of course I'm little bit confused. Has anyone any clue? Regards // M.A. From owner-aaa-wg@merit.edu Fri Aug 17 07:20: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 HAA23912 for ; Fri, 17 Aug 2001 07:20:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C6CB91265; Fri, 17 Aug 2001 07:21:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 125DD91266; Fri, 17 Aug 2001 07:21: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 D7C5191265 for ; Fri, 17 Aug 2001 07:21:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A90595DE1F; Fri, 17 Aug 2001 07:21:35 -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 1681B5DDAD for ; Fri, 17 Aug 2001 07:21:35 -0400 (EDT) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.9.3/8.9.3) with SMTP id MAA21239 for ; Fri, 17 Aug 2001 12:21:29 +0100 Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Fri, 17 Aug 2001 12:18:46 +0100 Received: from baltimore.ie (ip226-24.ie.baltimore.com [10.153.24.226]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA08009; Fri, 17 Aug 2001 12:21:30 +0100 Message-ID: <3B7CFE35.4325274A@baltimore.ie> Date: Fri, 17 Aug 2001 12:21: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 Subject: Re: [AAA-WG]: Revalidation of cache in CMS References: <3B78F93A.27DBBAB3@rioja.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id MAA08009 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA23912 Miguel, I agree that the text is a bit vague. I'd suggest adding the additional text below. Note that this is a "lax" PKI policy which assumes e.g. that no new (relevant) CRLs are produced before the nextUpdate field, but I'd argue that that's ok for Diameter since I wouldn't expect very frequent revocations in this context. The next text should go in below the current text. Does this solve the problem? Regards, Stephen. During the process of certificate path validation some implementations will calculate a duration for which the certificate path may be considered "safe". For example, if an implementation did not support certificate revocation checks, then the "safe" period would be from the time of initial validation until the earliest notAfter time in the set of certificates in the path. An implementation which does support certificate revocation checks will typically be able to calculate a "safe" period based additionally on the earliest nextUpdate field in a CRL or OCSP response. Basically, the safe period is from the time of certificate validation to the earliest value from the set of notAfter and nextUpdate fields encountered during certificate validation. However, implemetors should note that CAs MAY issue additional CRLs before the nextUpdate period. Generally it is a matter of local PKI policy as to whether an implementation will make additional checks even during the calculated "safe" period. For the purposes of this specification implementations are NOT REQUIRED to make such checks and MAY assume that no re-validation of certificates is required during the "safe" period defined above. Miguel Ángel Monjas Llorente wrote: > > Hi, > > just a question about the re-validation of DSA information. According > to the CMS draft (3.1, Usage Scenario), the implementations of CMS may > cache that information. Also, they must do one thing (honor the TTL > setting) AND another (re-validate certificate) before using cached > data. The paragraph is as follows: > > Implementations MAY cache the information required to establish a > DSA, but MUST honor time-to-live settings and MUST re-validate > certificates (possibly including revocation checks) before using > cached data. > > What I think is that this re-validation must take place once the TTL > has been passed, but the draft looks a little bit confused, because > both conditions are suposed to be checked every time (so that, a > certification re-validation must be done always). Am I right? Which is > the right answer? > > Regards > > // M.A. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Fri Aug 17 11:45: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 LAA05761 for ; Fri, 17 Aug 2001 11:45:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1DAC39126B; Fri, 17 Aug 2001 11:46:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9A349126C; Fri, 17 Aug 2001 11:46: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 F0F809126B for ; Fri, 17 Aug 2001 11:46:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C28675DE25; Fri, 17 Aug 2001 11:46:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 3CD9D5DE24 for ; Fri, 17 Aug 2001 11:46:28 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id IAA13196; Fri, 17 Aug 2001 08:45:53 -0700 (PDT) Received: from neastmail.entp.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc.) id IAA16555; Fri, 17 Aug 2001 08:45:52 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id IAA12667; Fri, 17 Aug 2001 08:45:51 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 11:45:50 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508699F@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Bernard Aboba'" , aaa-wg@merit.edu Cc: "Molchan, John" , "'ileana.leuca@attws.com'" , "Daly, Brian" , "Engelhart, Bob" Subject: RE: [AAA-WG]: Updated agenda for IETF 51 Date: Fri, 17 Aug 2001 11:45:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12733.A8DC9BD0" 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_000_01C12733.A8DC9BD0 Content-Type: text/plain; charset="iso-8859-1" Bernard, Dave, As I promised to Dave, I'm submitting a draft that reflects the presentation I made at the August AAA meeting last week. Sorry for the delay. I will strive to submit my future drafts before a meeting. I'm hoping to build upon this draft to include Diameter implementation concerns for 3G wireless application in future versions. These concerns will encompass apparent protocol deficiencies (if any), need for RFC clarification, etc. The applications described in the attached version will be used as a starting point. Thanks for your help, Thad -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, July 26, 2001 4:30 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Updated agenda for IETF 51 Based on some recent changes, here is an updated agenda for IETF 51. If there are additional agenda items, please get these in NOW. ================================================================== AAA WG Agenda IETF 51, London, UK Wednesday, August 8, 2001 1300 - 1500 PRELIMINARIES (5 minutes) Agenda bashing Blue sheets Minute takers Document status DIAMETER ISSUES Open Diameter Issues (30 minutes) Pat Calhoun Documents now in AAA WG last call: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt 3G COMMENTS ON DIAMETER Diameter as a 3G Accounting Protocol (10 minutes) Thaddeus Kobylarz SUPPORT FOR MOBILE IPv6 Franck Le (10 minutes) Diameter support for Mobile IPv6 http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt Franck Le (10 minutes) AAA Local Security Association (LSA): The Temporary Shared Key (TSK) http://www.ietf.org/internet-drafts/draft-le-aaa-lsa-tsk-00.txt SUPPORT FOR SIP/HTTP AUTHENTICATION Jari Arkko (10 minutes) HTTP Authentication with EAP http://www.arkko.com/draft-torvinen-http-eap-00.txt Baruch Sterman (10 minutes) Digest Authentication in SIP using RADIUS http://www.ietf.org/internet-drafts/draft-sterman-sip-radius-00.txt Sengodan Senthil (10 minutes) Diameter support for Basic and Digest authentication http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt WRAPUP Where do we go from here? (IESG, Chairs) (10 minutes) ------_=_NextPart_000_01C12733.A8DC9BD0 Content-Type: text/plain; name="draft-ietf-aaa-diameter-3G-application-01.txt" Content-Disposition: attachment; filename="draft-ietf-aaa-diameter-3G-application-01.txt" Content-Transfer-Encoding: quoted-printable INTERNET DRAFT Thaddeus Kobylarz = Category: Informational AT&T Wireless Services Title: draft-ietf-aaa-3GPP Charging-00.txt Date: August 2001 Diameter as a 3G Wireless Accounting Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are = working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments=20 should be submitted to the diameter@diameter.org and = aaa-wg@merit.edu mailing lists. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2001. All Rights Reserved. Abstract This draft contains slides presented at the August 2001 IETF AAA=20 session. The objective of the presentation was to encourage the AAA members discuss work on "applying Diameter to 3G wireless charging" = during the "Where do we go from here?" meeting "WRAPUP". The slides describe the 3G wireless charging scenarios having potential applications of Diameter. The scenarios represent an=20 introduction to this endeavor that can form the basis to establish=20 Diameter applicability and application specific requirements. Kobylarz expires February 2002 [Page 1] INTERNET DRAFT August 2001 [SLIDE 1]* [This is merely the presentation title slide.] "Diameter as a 3G Wireless Accounting Protocol" - Thaddeus Kobylarz, AT&T Wireless Services =20 [Disclaimer - This presentation was not approved by 3GPP SA5. The current focus of 3GPP SA5 is to complete its Release 4 endeavors. Release 5 work, which includes Diameter, has been postponed until Release 4 is completed. Caveats - (1) Not being an official SA5 presentation, the following is more apt than usual to have changes. Nevertheless, the hope is that this presentation will still have value as a starting point. (2) This presentation is to induce interest so that=20 assistance in preparing Diameter for 3G wireless accounting applications will result from the today's final agenda topic of "Where do we go from here?"] [SLIDE 2] [Two] Reasons for presentation (from : =20 1. "Real-time Accounting: Real-time accounting involves the processing of information=20 on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk." [This is a satisfactory definition; but that used by 3GPP has more specificity.] (According to 3GPP: Real time charging =3D> Data acquisition, (if necessary)=20 communication, and processing to a specified task's completion=20 within 1 second. Near real time charging =3D> Data acquisition, (if necessary)=20 communication, and processing to a specified task's completion=20 within 1 minute.)** [The 3GPP definitions are a consequence of charging applications in the ALL IP wireless environment AKA IP Multi-media Subsystem (IMS). =20 Understanding these applications is important to establishing Diameter performance requirements.] ______________________________________________ * Commentary, not appearing on the slides and added for clarification,=20 is delimited by brackets; i.e., [...]. ** Information provided on the slides, intended to contrast with IETF=20 perspectives, is delimited by parentheses; i.e., (...). Kobylarz expires February 2002 [Page 2] INTERNET DRAFT August 2001 [SLIDE 3] 2. "2.0 Protocol Overview The base Diameter protocol is never used on its own. It is=20 always extended for a particular application. Three Diameter=20 applications are defined by companion documents: NASREQ [7], Mobile IP [10], CMS Security [11]. These options are introduced in this document but specified elsewhere." =20 (Reaction: This suggests an extension is needed for the accounting application. Even if not, at least AVPs will need to be defined. =20 It is requested that further accounting work be discussed in "Where=20 do we go from here?"). ["Where do we go from here?" is to be discussed in the "WRAPUP"=20 portion of the meeting. It is desired to have the AAA continue=20 its existence, but with the purpose of assisting those who intend=20 to apply Diameter. Because Diameter appears to be useful for several potential=20 applications with differing 3G charging needs, it will be valuable=20 to have AAA members examine these needs in light of Diameter's=20 capabilities and determine if these needs are satisfied.] =20 [SLIDE 4] Purpose & overview - To stimulate an interest in adapting & using Diameter for=20 accounting by demonstrating where and how it may be used. [Because Diameter appears to be useful for several potential=20 applications with differing 3G charging needs, it will be valuable=20 to have AAA members examine these needs in light of Diameter's=20 capabilities and determine if these needs are satisfied.] =20 Three scenarios will be described for these purposes: 1. Pre-paid services, 2. Third party services, 3. Roaming.=20 Kobylarz expires February 2002 [Page 3] INTERNET DRAFT August 2001 [SLIDE 5] SCENARIO 1: Pre-paid service using "real time" and "on-line".=20 [The functional entities below have been ascribed generic names,=20 intended to have mnemonic significance. The names are not used in 3GPP reference models.] +-------------+ |COMMUNICATION| USER<----->| |<----->USER =20 1 | LINK | 2 +-------------+ /\ : : :.......=20 .......: PATH 2 : : PATH 1 : : \/ =20 +-------+ +-------+ +----------+ |SESSION| PATH 3 | USAGE | PATH 4 |ACCOUNTING| PATH 5 User | |<-------| |<------>| |<------< 1 |CONTROL| |MONITOR| | FUNCTION | DATA +-------+ +-------+ +----------+ [The basic operation for prepaid is as follows: 1. User 1 initiates a session and the Accounting Function receives User 1 data while session initiation transpires. 2. The remaining time (volume) for User 1 is determined and=20 forwarded to the Usage Monitor. 3. After the session is established, the Usage Monitor compares the consumed communication time (volume) with the remaining time (volume). 4. When the consumed time (volume) equals the remaining time (volume), the Usage Monitor requests a session termination of the Session Control. This task is to be achieved within 1 second. Variations of the above basic operation may exist. For instance, a user may terminate a session prior to the consumption of the remaining time (volume).] [Some initial conclusions are tabulated below --=20 where: ? =3D> probably no ! =3D> probably yes] PATH # 1 2 3 4 5 FEATURE ALL 3 A's Encryption Diameter ? ? ? ! ! USE ? ? =20 PARAMETER time volume currency AVAILABLE ! ! ? =20 currency =3D Service provider(s) choice of local, = pre-determined,=20 or Special Drawing Rights (SDRs). (An SDR is an international basket=20 currency maintained by the International Monetary Fund who releases=20 the quotations to the central banks.) Kobylarz expires February 2002 [Page 4] INTERNET DRAFT August 2001 [SLIDE 6] SCENARIO 2: Electronic wallet service using "near real time" and "off-line".=20 [An electronic wallet provides a user with an amount of currency that can be used to make purchases from Value Added Service=20 Providers. It can have an analogy to either a debit card or a=20 credit card. The purchases can include anything that is available via debit/credit cards and more. A significant advantage of=20 purchases, via a wireless terminal, is safety. It is a relatively=20 simple matter to conceive of wireless purchase procedures that=20 virtually eliminate fraud. The basic operation for value added services is as follows: 1. The User places an order with the Value Added Service Provider; e.g., a restaurant dinner. 2. The service request, including an amount to be approved, is also provided to the Accounting Function, via the Mediation Function. 3. The purchase is approved or denied and the result is sent to the Value Added Service Provider and the User. This task is to be completed within 1 minute. 4. If approved, the completed purchase information is provided to the Accounting Function, resulting in a debit and the generation of User and the Value Added Service Provider receipts. This task is also to be completed within 1 minute.] +--------------+ +-----------+ |COMMUNICATION | |VALUE ADDED| =20 USER<----->| |<----->| SERVICE | =20 | LINK | | PROVIDER | =20 +--------------+ +-----------+ /\ /\ : : :........ ........=20 PATH 1 : : PATH 2 \/ \/ +----------+ +-----------+ |MEDIATION | PATH 3 |ACCOUNTING | | |<------->| | =20 | FUNCTION | | FUNCTION |=20 +----------+ +-----------+ [Some initial conclusions are tabulated below --=20 where: ? =3D> probably no ! =3D> probably yes] PATH # 1 2 3 FEATURE ALL 3 A's Encryption =20 Diameter ? ? ! USE ! !=20 PARAMETER time volume currency=20 AVAILABLE ? ? ! Kobylarz expires February 2002 [Page 5] INTERNET DRAFT August 2001 [SLIDE 7] SCENARIO 3: Inter-operator accounting data exchange (roaming = complexity). =20 [Currently, Charging Data Records are exchanged between wireless=20 operators by means of settlement procedures. These settlement procedures can have weeks of delay. Such delays are intolerable in the event of communication use fraud and for the anticipated new 3G services. A Diameter link between wireless operators may be the means to circumvent these problems.] +----------+ +----------+ | WIRELESS | Diameter | WIRELESS | =20 | OPERATOR |<------------->| OPERATOR | =20 | 1 | Path | 2 | =20 +----------+ +----------+ [Some initial conclusions are tabulated below --=20 where: ? =3D> probably no ! =3D> probably yes] SPEED RT NRT BATCH FEATURE ALL 3 A's Encryption =20 AVAILABLE ? ! ! USE ! ! =20 PARAMETER time volume currency =20 AVAILABLE ! ! ! [SLIDE 8] Conclusions -- =20 1. Encourage consideration of developing an RFC that addresses Diameter's use for 3G wireless accounting applicable to the GSM environment. [The RFC will describe how Diameter will be used, using the above scenarios as a starting point. For each Diameter application scenario, concerns and issues will be identified for discussion with AAA members.] 2. Further discussion of the above suggestion needs to take place during the "Where do we go from here?" dialog. [That is, it is proposed that the suggested future AAA work be discussed and approved.] 3. It is important to complete this work within the 3GPP Release 5 time table. [Currently, Release 5 is to be completed in March, 2002.] Kobylarz expires February 2002 [Page 6] ------_=_NextPart_000_01C12733.A8DC9BD0-- From owner-aaa-wg@merit.edu Mon Aug 20 05: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 FAA09909 for ; Mon, 20 Aug 2001 05:38:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7921D91217; Mon, 20 Aug 2001 05:39:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4917A91247; Mon, 20 Aug 2001 05:39: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 1A46691217 for ; Mon, 20 Aug 2001 05:39:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA2DB5DDE0; Mon, 20 Aug 2001 05:39:05 -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 EA2495DD9F for ; Mon, 20 Aug 2001 05:39:04 -0400 (EDT) Received: from linux (a3.local.ipunplugged.com [192.168.4.173]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA21754; Mon, 20 Aug 2001 11:40:12 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Martin Andersson To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Editorial change in draft-ietf-aaa-diameter-07.txt Date: Mon, 20 Aug 2001 11:39:27 +0200 X-Mailer: KMail [version 1.2] Cc: pcalhoun@diameter.org References: <0D3BDFD96647D211B43A00805F15E5890508699F@ner-msg03.wireless.attws.com> In-Reply-To: <0D3BDFD96647D211B43A00805F15E5890508699F@ner-msg03.wireless.attws.com> MIME-Version: 1.0 Message-Id: <01082011392701.00722@linux> Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Martin Andersson Submitter email address: martin.andersson@ipunplugged.com Date first submitted: 2001-08-20 Reference: Document: draft-ietf-aaa-diameter-07.txt Comment type: E Priority: 2 Section: 4.6 & 7.5 Rationale/Explanation of issue: The table in section 4.6 states that Failed-Avp should be of type OctetString while section 7.5 states it should be of type Grouped. Requested change: Change Section 4.6 to state that the Failed-Avp is of type Grouped /Martin From owner-aaa-wg@merit.edu Mon Aug 20 06:27: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 GAA10199 for ; Mon, 20 Aug 2001 06:27:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58D9191247; Mon, 20 Aug 2001 06:27:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2483091248; Mon, 20 Aug 2001 06:27: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 E3FCC91247 for ; Mon, 20 Aug 2001 06:27:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA3885DDCC; Mon, 20 Aug 2001 06:27: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 B05D95DD9F for ; Mon, 20 Aug 2001 06:27:47 -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 f7KARkK05360 for ; Mon, 20 Aug 2001 12:27:46 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA11558; Mon, 20 Aug 2001 12:27:42 +0200 (MET DST) Message-ID: <3B80E632.6D666DD6@rioja.ericsson.se> Date: Mon, 20 Aug 2001 12:28: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: [AAA-WG]: [issue] Inconsistency in OCSP-Request-Flags AVP 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-08-20 Reference: Document: CMS-02 Comment type: T Priority: S Section: 3.1 Rationale/Explanation of issue: The usage scenario chapter states that a DSAR message contains, among other information: - (optionally) a flag indicating that the originating Diameter node wishes to receive certificate status information (using OCSP messages) ... So that, the OCSP flag (I suppose we're talking about OCSP-Request-Flags AVP) is claimed as optional. However, the format of the DSAR messages indicates that OCSP-Request-Flags are mandatory (i.e. it's the nonce value what is optional, since it depends on the requestes OCSP response): ::= < Diameter-Header: 304, REQ, PXY > ... { OCSP-Request-Flags } ... [ OCSP-Nonce ] ... Requested change: Replace the previous paragraph from usage scenario chapter (the whole paragraph) with this one: - a flag indicating wheter the originating Diameter node wishes to receive certificate status information using OCSP messages. If this flag requires a fresh OCSP response, a nonce to be used by the destination Diameter node in OCSP requests MUST also be supplied. Regards // M.A. From owner-aaa-wg@merit.edu Mon Aug 20 08:57: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 IAA16727 for ; Mon, 20 Aug 2001 08:57:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A4BC91248; Mon, 20 Aug 2001 08:58:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C2179124D; Mon, 20 Aug 2001 08:58: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 CB89291248 for ; Mon, 20 Aug 2001 08:58:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AAD4F5DDE8; Mon, 20 Aug 2001 08:58: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 9A6D75DDE4 for ; Mon, 20 Aug 2001 08:58:08 -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 f7KCw7K25473 for ; Mon, 20 Aug 2001 14:58:07 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA20461; Mon, 20 Aug 2001 14:58:05 +0200 (MET DST) Message-ID: <3B810972.F746AABB@rioja.ericsson.se> Date: Mon, 20 Aug 2001 14:58: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: [AAA-WG]: [issue] Inconsistency in OCSP-Responses AVP 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-08-20 Reference: Document: CMS-02 Comment type: T Priority: S Section: 3.1, 4.2 Rationale/Explanation of issue: The usage scenario chapter states that a DSAA message contains, among other information: - (optionally, if nonce received and OCSP supported) a list of OCSP responses for the certificates in question, each of which contains the nonce from the DSAR message However, the format of the DSAA messages indicates that OCSP-Response AVP is mandatory: ::= < Diameter-Header: 304, PXY > ... * { OCSP-Responses } ... Furthermore, the chapter describing OCSP-Responses AVP says the following: The OCSP-Responses AVP [...] contains an OCSP response message from an OCSP responder. If the OCSP-Request-Flags AVP indicating a response was required in the corresponding request message, the OCSP-Responses AVP MUST be present. Furthermore, the OCSP-Request-Flags AVP MAY request a fresh OCSP response message, which MUST also include the OCSP-Nonce AVP. Which looks to suggest that if OCSP-Request-Flags AVP in DSAR was OCSP_RESPONSE or OCSP_FRESH_RESPONSE (with an OCSP-Nonce associated) there must be an OCSP-Response AVP. But not in the rest of the possibilities (NO_OCSP_RESPONSE). Requested change: Replace the previous paragraph from usage scenario chapter (3.1) with this one: - (optionally, if OCSP response was required in the DSAR and OCSP is supported) a list of OCSP responses for the certificates in question. If a fresh response was required and a nonce value was included, each response will contain the nonce from the DSAR message Replace the mandatory field of DSAA in 4.2: * { OCSP-Responses } with an optional field * [ OCSP-Responses ] Regards // M.A. From owner-aaa-wg@merit.edu Mon Aug 20 08:57:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16763 for ; Mon, 20 Aug 2001 08:57:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B87B79124D; Mon, 20 Aug 2001 08:58:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BFC591275; Mon, 20 Aug 2001 08:58: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 D18D69124D for ; Mon, 20 Aug 2001 08:58:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B154D5DDE8; Mon, 20 Aug 2001 08:58:13 -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 6348A5DDCC for ; Mon, 20 Aug 2001 08:58:08 -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 f7KCw3v11183 for ; Mon, 20 Aug 2001 14:58:03 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA20454; Mon, 20 Aug 2001 14:58:00 +0200 (MET DST) Message-ID: <3B81096E.34F3697C@rioja.ericsson.se> Date: Mon, 20 Aug 2001 14:58:22 +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] Editorial change in CMS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-08-20 Reference: Document: CMS-02 Comment type: E Priority: 2 Section: Rationale/Explanation of issue: The name "Response" in OCSP-Responses is plural. Requested change: Change all occurrences of "OCSP-Response" with "OCSP-Responses" Regards // M.A. From owner-aaa-wg@merit.edu Mon Aug 20 09:27: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 JAA19084 for ; Mon, 20 Aug 2001 09:27:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF0CC91221; Mon, 20 Aug 2001 09:28:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B31209124E; Mon, 20 Aug 2001 09:28:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 988FE91221 for ; Mon, 20 Aug 2001 09:28:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8038C5DDEB; Mon, 20 Aug 2001 09:28:50 -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 07D385DDE4 for ; Mon, 20 Aug 2001 09:28:45 -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 f7KDShK19247; Mon, 20 Aug 2001 15:28:43 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA22352; Mon, 20 Aug 2001 15:28:39 +0200 (MET DST) Message-ID: <3B81109D.63831E5D@rioja.ericsson.se> Date: Mon, 20 Aug 2001 15:29: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Signing of DSA requests and aswers References: <3B78F6AF.8F1C8965@rioja.ericsson.se> <20010814094146.E18495@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 next paragraph in 3.1 is the following: > > > > The DSAA MUST be signed by a Diameter agent or server within the > > user's realm, to prevent an intermediate node from modifying the > > protection expectations for AVPs. > > > > Neither of the mandatory AVPs of this command (Result-Code, > > Origin-Host, Origin-Realm, CA-Chain, AAA-Server-Certs, OCSP-Responses, > > Destination-Host, Auth-Application-Id, DSA-TTL) must be protected > > (according to 6.0). So that, if the signing of the answer is > > mandatory, it will be necessary to protect an AVP (just to have any > > AVP to sign) or to include a field whose protection is mandatory. I'm > > not really sure about how to deal with this. > > to be clear, these AVPs MAY have the 'P' bit set, according to section 6. > So, the issue is that it is a MAY, and not a MUST, right? Yes. That's right. But I've just noticed that this change must affect not only the paragraph written down above but also the following paragraph (also in 3.1 Usage Scenario, in the check list of the DSAR originator): - the DSAA message MUST be digitally signed and the signature MUST be validated and the signer's certificate chain MUST terminate as a CA mentioned in the DSAR message Logically, this item must be replaced by another. Maybe the following: - the DSAA message MAY include a CMS-Signed-Data AVP. If present, this signature MUST be validated and the signer's certificate chain MUST terminate as a CA mentioned in the DSAR message Regards // M.A. From owner-aaa-wg@merit.edu Mon Aug 20 10:33: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 KAA22303 for ; Mon, 20 Aug 2001 10:33:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D55C091249; Mon, 20 Aug 2001 10:34:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A539A91222; Mon, 20 Aug 2001 10:34:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84B239124B for ; Mon, 20 Aug 2001 10:34:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BA8D5DDE7; Mon, 20 Aug 2001 10:34: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 937875DDE0 for ; Mon, 20 Aug 2001 10:34:47 -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 f7KEYjK07258 for ; Mon, 20 Aug 2001 16:34:46 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA26204; Mon, 20 Aug 2001 16:34:42 +0200 (MET DST) Message-ID: <3B812018.D64D7C85@rioja.ericsson.se> Date: Mon, 20 Aug 2001 16:35:04 +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] Clarification in certificate naming schema 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-08-20 Reference: Document: CMS-02 Comment type: Technical Priority: S Section: Rationale/Explanation of issue: The naming schema of AAA servers certificates are spread among different chapters in the specification. In 1.5 it's said that "The realm of the participants is found in the subjectAltName field of the Diameter server's X.509 certificate". In 3.1, between the checks done by the DSA initiator when the DSAA is received, it's said that: - the realm part of the user's NAI must occur as a subjectAltName (with the dNSName option) in the AAA server's certificate. This dNSName MUST be of the form "Diameter-." where is the FQDN's domain component and can be anything (e.g. "Diameter-1.baltimore.com", "Diameter- west.sun.com") chosen by the Diameter server administrator. Finally, a whole chapter (3.2. Certificate Requirements) deals with the same topic. Specifically, it's said that: Certificates [...] MUST also include a Diameter node's FQDN, which is typically added in the Host-Name AVP [1], as one of the values of the subjectAltName extension of the Certificate. And For Diameter nodes (capable of acting as recipients for confidentiality), the FQDN MUST be of the form "Diameter- .". And last but not least 1. Where a Diameter node is verifying a signature it needs to be able to compare the identity of the signer against the identity in the Host-Name AVP. Requested change: The main purpose would be to clarify the whole topic. I'd suggest: - Unifying the terminology. Using "realm" always or "domain" always. - To switch the long explanation of chapter 3.1 to a more appropriate place (chapter 3.2), including a reference to it in the item of 3.1 chapter. - Explaining which AVP is Host-Name AVP Additionally I'd like to receive a clarification about the realms involved. I suppose that the "realm part of the user's NAI" is carried by means of the Destination-Realm in the DSAR, but I'm not sure. BTW Regards // M.A. From owner-aaa-wg@merit.edu Mon Aug 20 11:01: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 LAA23134 for ; Mon, 20 Aug 2001 11:01:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75CCB91250; Mon, 20 Aug 2001 11:01:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08AB891277; Mon, 20 Aug 2001 11:01: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 BFF0B91250 for ; Mon, 20 Aug 2001 11:01:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3CDA5DDEE; Mon, 20 Aug 2001 11:01:33 -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 C8B1C5DDBF for ; Mon, 20 Aug 2001 11:01: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 f7KF1RK23853 for ; Mon, 20 Aug 2001 17:01:27 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id RAA27835; Mon, 20 Aug 2001 17:01:24 +0200 (MET DST) Message-ID: <3B81265A.306918E0@rioja.ericsson.se> Date: Mon, 20 Aug 2001 17:01: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]: Questions about AVPs occurrence 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, just a couple of questions about AVPs occurrence: - Is it possible to change the Expected-*-AVP value in a DSA? I mean, is it possible to issue a new Expected-Signed-AVP if the DSA hasn't expired? - Is it necessary to establish a DSA to include a CMS-Cert AVP in a Diameter message? Or is it possible to "push" a certificate at anytime? 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 Mon Aug 20 12:58: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 MAA26764 for ; Mon, 20 Aug 2001 12:58:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3D3E91256; Mon, 20 Aug 2001 12:59:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 939A991257; Mon, 20 Aug 2001 12:59: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 6F21591256 for ; Mon, 20 Aug 2001 12:59:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3860F5DE10; Mon, 20 Aug 2001 12:59:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id E44135DDD7 for ; Mon, 20 Aug 2001 12:59:52 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7KGxvi00865 for ; Mon, 20 Aug 2001 11:59:57 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 20 Aug 2001 11:59:50 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 11:59:50 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: New Issue: Use of Application Identifiers in routing Date: Mon, 20 Aug 2001 11:59:50 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811223D4E@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: New Issue: Use of Application Identifiers in routing X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEmg+BAoPNcRJDTEdWaKAAAhjiT+ADEcREgAAAQQ1AAALRZgA== From: "Le Franck (NRC/Dallas)" To: X-OriginalArrivalTime: 20 Aug 2001 16:59:50.0264 (UTC) FILETIME=[86474F80:01C12999] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA26764 > -----Original Message----- > From: Sreemanthula Srinivas (NRC/Dallas) > Sent: 16 August, 2001 1:56 PM > To: 'aaa-wg@merit.edu' > Subject: New Issue: Use of Application Identifiers in routing > > Pat, > Please assign a number for the following issue. > > Issue: Use of Application Identifiers in routing > Submitter name: Srinivas Sreemanthula > Submitter email address: Srinivas.Sreemanthula@nokia.com > Date first submitted: August 16, 2001 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: 2.5 Last paragraph > Rationale/Explanation of issue: > In the first sentence, one may interpret the text that the use > of application identifiers in the routing is a necessary requirement. > We feel that the use of application identifiers while routing is > optional whereas the routing must be based on the destination realm > contained in the message. This would provide a flexible scenario > where proxies and relays always need to be able to route based on the > realm, and in addition, they may choose to route based on application > identifiers, as well. This would also allow for implementation > scenarios capable to hide the network topology or distribute the > server functions within a realm by use of a "gateway" diameter nodes > . > > Requested Change: > Rephrase section 2.5 last paragraph, first sentence to: > "While the diameter relay and proxy agents MUST know how to > route messages based on the destination realm indicated in the > message, they MAY be able to route the messages also based on the > application identifiers of a particular message." > From owner-aaa-wg@merit.edu Mon Aug 20 13:25: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 NAA27627 for ; Mon, 20 Aug 2001 13:25:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9901E91258; Mon, 20 Aug 2001 13:26:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C7591277; Mon, 20 Aug 2001 13:26: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 5281491258 for ; Mon, 20 Aug 2001 13:26:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24AD95DE2D; Mon, 20 Aug 2001 13:26:07 -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 9728F5DE10 for ; Mon, 20 Aug 2001 13:26:06 -0400 (EDT) Received: (qmail 31270 invoked by uid 500); 20 Aug 2001 17:14:04 -0000 Date: Mon, 20 Aug 2001 10:14:04 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about AVPs occurrence Message-ID: <20010820101404.H31100@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <3B81265A.306918E0@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: <3B81265A.306918E0@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Aug 20, 2001 at 05:01:46PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, Aug 20, 2001 at 05:01:46PM +0200, Miguel Ángel Monjas Llorente wrote: > Hi all, > > just a couple of questions about AVPs occurrence: > > - Is it possible to change the Expected-*-AVP value in a DSA? I mean, > is it possible to issue a new Expected-Signed-AVP if the DSA hasn't > expired? You can send a new message to re-establish new keying info prior to the TTL expiration. The peer needs to support this anyways, since the reason for the new message could be due to a reboot. > > - Is it necessary to establish a DSA to include a CMS-Cert AVP in a > Diameter message? Or is it possible to "push" a certificate at > anytime? Well I would think that you'd need the cert to establish the DSA. We've never discussed using the messages described in the CMS application as a way to push certs. PatC From owner-aaa-wg@merit.edu Mon Aug 20 13:43: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 NAA28227 for ; Mon, 20 Aug 2001 13:43:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F05591212; Mon, 20 Aug 2001 13:44:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D31F891277; Mon, 20 Aug 2001 13:44: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 AA60991212 for ; Mon, 20 Aug 2001 13:44:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 711B55DE31; Mon, 20 Aug 2001 13:44: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 606475DDC3 for ; Mon, 20 Aug 2001 13:44: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 f7KHiaK11954; Mon, 20 Aug 2001 19:44:37 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA05633; Mon, 20 Aug 2001 19:44:32 +0200 (MET DST) Message-ID: <3B814C98.5FC57750@rioja.ericsson.se> Date: Mon, 20 Aug 2001 19:44: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about AVPs occurrence References: <3B81265A.306918E0@rioja.ericsson.se> <20010820101404.H31100@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, Aug 20, 2001 at 05:01:46PM +0200, Miguel Ángel Monjas Llorente wrote: > > Hi all, > > > > just a couple of questions about AVPs occurrence: > > > > - Is it possible to change the Expected-*-AVP value in a DSA? I mean, > > is it possible to issue a new Expected-Signed-AVP if the DSA hasn't > > expired? > > You can send a new message to re-establish new keying info prior to the TTL > expiration. The peer needs to support this anyways, since the reason for the new > message could be due to a reboot. OK. That answer my question. > > > > - Is it necessary to establish a DSA to include a CMS-Cert AVP in a > > Diameter message? Or is it possible to "push" a certificate at > > anytime? > > Well I would think that you'd need the cert to establish the DSA. We've never > discussed using the messages described in the CMS application as a way to push > certs. Well, just to quote the specification itself: This use of the CMS-Cert AVP can be used to "push" public key and attribute certificates and CRLs using Diameter, which MAY be useful in environments where repositories (e.g. LDAP servers) are either not used or not available (e.g. due to crossing a domain boundary). So that this use is suggested by the specification itself. The next paragraph doesn't mention whether a DSA is stablished: Conforming implementations MUST be able to emit a certs-only CMS structure which contains relevant PKI related information and MUST be able to process a CMS-Cert AVP which contains a certs-only CMS structure. Regards // M.A. From owner-aaa-wg@merit.edu Mon Aug 20 14:21: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 OAA29241 for ; Mon, 20 Aug 2001 14:21:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 595FA91228; Mon, 20 Aug 2001 14:22:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 275DA91277; Mon, 20 Aug 2001 14:22: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 0C98591228 for ; Mon, 20 Aug 2001 14:22:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D804A5DE34; Mon, 20 Aug 2001 14:22: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 D199C5DE33 for ; Mon, 20 Aug 2001 14:22: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 f7KILxK17214 for ; Mon, 20 Aug 2001 20:21:59 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id UAA07191; Mon, 20 Aug 2001 20:21:57 +0200 (MET DST) Message-ID: <3B81555C.AACD0FA8@rioja.ericsson.se> Date: Mon, 20 Aug 2001 20:22: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]: Questions about DSAs through proxy agents 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'm trying to understand the overall mechanism of CMS Security when a proxy is involved. I'd be grateful for any comment about my description. An agent tries to establish a DSA with a Diameter server. Let's imagine that it requires both encrypted and signed AVPs. There is also a downstream proxy. The proxy inspects the request and checks that it won't modify any of the expected protected AVPs, so that answers with a DSAA including DIAMETER_CAN_ACT_AS_CMS_PROXY. Which additional AVPs must include this answer? It doesn't seem that the same information quoted in 3.1 must be present there (which AAA-Server-Certs AVPs are gonna be used). Finally, as stated in 1.2, the DSAA must include a CMS-Signed-Data AVP (but, on what?) along with the digital certificate of the proxy. If the agent agrees on using the proxy, I assume that the proxy establishes the DSA with the AAA server using some of the parameters provided by the agent in the first DSAR (at least TTL, Expected-Encrypted-AVP and Expected-Signed-AVP; am I right?). It signs the protected AVPs with its proper keys and includes its certificates. From the server point of view, the cryptographic partner is the proxy. Finally, the proxy issues a PDSA indicating success. From now, all the signed AVP coming from the server are checked and forwared to the agent (erasing the CMS-Signed-Data AVPs); the encrypted data is extracted and forwarded to the agent. On the other way, the AVPs that the server expects as signed are signed by the proxy. The ones required as encrypted are encrypted by the proxy. That's clear... Any comment on the first point of the mail... -- 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 Aug 20 16:16: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 QAA02739 for ; Mon, 20 Aug 2001 16:16:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E505E9122E; Mon, 20 Aug 2001 16:17:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 959AB9124A; Mon, 20 Aug 2001 16:17: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 D4E849122E for ; Mon, 20 Aug 2001 16:17:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 919C25DDA1; Mon, 20 Aug 2001 16:17:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1067C5DD9F for ; Mon, 20 Aug 2001 16:17:14 -0400 (EDT) Received: (qmail 378 invoked by uid 500); 20 Aug 2001 20:05:15 -0000 Date: Mon, 20 Aug 2001 13:05:15 -0700 From: Pat Calhoun To: Martin Andersson Cc: aaa-wg@merit.edu, pcalhoun@diameter.org Subject: Re: [AAA-WG]: [issue] Editorial change in draft-ietf-aaa-diameter-07.txt Message-ID: <20010820130515.D32693@charizard.diameter.org> Mail-Followup-To: Martin Andersson , aaa-wg@merit.edu, pcalhoun@diameter.org References: <0D3BDFD96647D211B43A00805F15E5890508699F@ner-msg03.wireless.attws.com> <01082011392701.00722@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01082011392701.00722@linux>; from martin.andersson@ipunplugged.com on Mon, Aug 20, 2001 at 11:39:27AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for the info, it has been fixed for the next version. PatC On Mon, Aug 20, 2001 at 11:39:27AM +0200, Martin Andersson wrote: > > > Submitter name: Martin Andersson > Submitter email address: martin.andersson@ipunplugged.com > Date first submitted: 2001-08-20 > Reference: > Document: draft-ietf-aaa-diameter-07.txt > Comment type: E > Priority: 2 > Section: 4.6 & 7.5 > Rationale/Explanation of issue: > > The table in section 4.6 states that Failed-Avp should be of type OctetString > while section 7.5 states it should be of type Grouped. > > > Requested change: > Change Section 4.6 to state that the Failed-Avp is of type Grouped > > > > /Martin From owner-aaa-wg@merit.edu Mon Aug 20 20:04: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 UAA07906 for ; Mon, 20 Aug 2001 20:04:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB49B91278; Mon, 20 Aug 2001 20:05:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F1A39127A; Mon, 20 Aug 2001 20:05: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 82BDC91278 for ; Mon, 20 Aug 2001 20:05:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 512BD5DD94; Mon, 20 Aug 2001 20:05:17 -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 A1E145DD92 for ; Mon, 20 Aug 2001 20:05:16 -0400 (EDT) Received: (qmail 2539 invoked by uid 500); 20 Aug 2001 23:53:18 -0000 Date: Mon, 20 Aug 2001 16:53:18 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about AVPs occurrence Message-ID: <20010820165318.E1924@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , Pat Calhoun , aaa-wg@merit.edu References: <3B81265A.306918E0@rioja.ericsson.se> <20010820101404.H31100@charizard.diameter.org> <3B814C98.5FC57750@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: <3B814C98.5FC57750@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Mon, Aug 20, 2001 at 07:44:56PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit hmmmm..... well the message is used to setup the DSA, so I suppose I assumed that the reader would understand that sending another message, for the purposes of pushing certs, would cause a rekey to occur. Are you then stating that this isn't clear, and additional clarifying text is required? PatC On Mon, Aug 20, 2001 at 07:44:56PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > On Mon, Aug 20, 2001 at 05:01:46PM +0200, Miguel Ángel Monjas Llorente wrote: > > > Hi all, > > > > > > just a couple of questions about AVPs occurrence: > > > > > > - Is it possible to change the Expected-*-AVP value in a DSA? I mean, > > > is it possible to issue a new Expected-Signed-AVP if the DSA hasn't > > > expired? > > > > You can send a new message to re-establish new keying info prior to the TTL > > expiration. The peer needs to support this anyways, since the reason for the new > > message could be due to a reboot. > > OK. That answer my question. > > > > > > > - Is it necessary to establish a DSA to include a CMS-Cert AVP in a > > > Diameter message? Or is it possible to "push" a certificate at > > > anytime? > > > > Well I would think that you'd need the cert to establish the DSA. We've never > > discussed using the messages described in the CMS application as a way to push > > certs. > > Well, just to quote the specification itself: > > This use of the CMS-Cert AVP can be used to "push" public key and > attribute certificates and CRLs using Diameter, which MAY be useful > in environments where repositories (e.g. LDAP servers) are either > not used or not available (e.g. due to crossing a domain boundary). > > So that this use is suggested by the specification itself. The next > paragraph doesn't mention whether a DSA is stablished: > > Conforming implementations MUST be able to emit a certs-only CMS > structure which contains relevant PKI related information and MUST > be > able to process a CMS-Cert AVP which contains a certs-only CMS > structure. > > Regards > > // M.A. From owner-aaa-wg@merit.edu Tue Aug 21 01:26: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 BAA16364 for ; Tue, 21 Aug 2001 01:26:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 707959127E; Tue, 21 Aug 2001 01:27:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C1279127F; Tue, 21 Aug 2001 01: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 300689127E for ; Tue, 21 Aug 2001 01:26:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 030AA5DDBF; Tue, 21 Aug 2001 01:26:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id 6D5295DDB8 for ; Tue, 21 Aug 2001 01:26:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id WAA26121; Mon, 20 Aug 2001 22:26:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7L5QVQ02434; Mon, 20 Aug 2001 22:26:31 -0700 X-mProtect: Mon, 20 Aug 2001 22:26:31 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdA14EEg; Mon, 20 Aug 2001 22:26:29 PDT Message-ID: <3B81F0A1.639DB063@iprg.nokia.com> Date: Mon, 20 Aug 2001 22:24:49 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 References: <0C1353ABB1DEB74DB067ADFF749C4EEF094175@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, Has there been any further determination about where the AAAv6 work should proceed? It seems to me that it does fit within the AAA working group now. If an URP working group is created in the future, and they want to have the work item, a transfer could be discussed at that time. In the meantime, we could start to have more discussion about particulars. Regards, Charlie P. john.loughney@nokia.com wrote: > Hi Bernard, > > RE: AAAv6 draft > > > Has this draft been presented within the IPNG WG? Since IPv6 > > architecture occurs within IPNG WG, the proposed IPv6/AAA > > authentication architecture would need to be presented and > > gain consensus within the IPNG WG before a AAA WG work item > > could be considered. > > Charlie Perkins presented the AAAv6 draft he has been writing > to the IPNG WG. There seemed to be general consensus that > this was good work (in general) and be persued. It seemed to > the group that IPNG WG was not the best place for this, but > the AAA could be one possibility. Erik Nordmark also suggested > that URP could be another home. > > Of course, if I have mis-interpreted the consensus, I' sure > someone (Steve?) could correct me. > > I'm in favor of this going forward. I think that no official > decision has been made on URP (whether or not it is to be a > WG) - perhaps the Area Directors & Work Group chairs could > discuss where the best place for this work is. > > best regards, > John From owner-aaa-wg@merit.edu Tue Aug 21 03:12: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 DAA01773 for ; Tue, 21 Aug 2001 03:12:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C36819127F; Tue, 21 Aug 2001 03:13:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 762779121F; Tue, 21 Aug 2001 03:13: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 5CD739121F for ; Tue, 21 Aug 2001 03:13:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 520F55DDC7; Tue, 21 Aug 2001 03:13:09 -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 356705DDC6 for ; Tue, 21 Aug 2001 03:13:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA17863; Tue, 21 Aug 2001 00:05:40 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 00:05:40 -0700 (PDT) From: Bernard Aboba To: Charlie Perkins Cc: aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 In-Reply-To: <3B81F0A1.639DB063@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG only considers work items resulting from a consensus draft within a subject area WG. Until the IPNG or URP WG progresses a draft on the subject, we cannot consider a work item relating to AAA for IPV6. From owner-aaa-wg@merit.edu Tue Aug 21 09:03: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 JAA10121 for ; Tue, 21 Aug 2001 09:03:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AD9291220; Tue, 21 Aug 2001 09:04:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46B8D91281; Tue, 21 Aug 2001 09:04: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 3859191220 for ; Tue, 21 Aug 2001 09:04:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A56C5DDD4; Tue, 21 Aug 2001 09:04: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 8830A5DDB3 for ; Tue, 21 Aug 2001 09:04:34 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LD4v319041 for ; Tue, 21 Aug 2001 16:04:57 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 21 Aug 2001 16:04:30 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVYJX3>; Tue, 21 Aug 2001 16:03:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB2D@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] duplicate packet detection in failure case (draft-ietf-aa a-diameter-07.txt) Date: Tue, 21 Aug 2001 16:03:08 +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, Resending this one, due to mail failure ... Issue: duplicate packet detection in failure case Submitter name: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: August 20, 2001 Reference: Document: Base Comment type: T Priority: 1 Section: In section 9.4 Fault Resilience, Rationale/Explanation of issue: The text in 9.4 may not be sufficient in failure cases. Some text is needed to describe how to handle the failure case. Requested Change: Additional text should be added to discuss The sending party sends the (maximal amount = the used send window size) unacknowledged packets (after a link failure) to the next available secondary/tertiary/etc. alternative recipient node (CG), with a mark that they are potential duplicates, to wait there for a final decision. After the original link comes up, the original sender tests with empty dummy packets if the original recipient would acknowledge those packet numbers as "already successfully handled" or "new". Then the sender just announces the secondary node which waiting packets it may release towards the final destination (like BS), and which waiting potentially duplicated packets to cancel (since they had already been successfully handled by the original recipient node just before its link went down. From owner-aaa-wg@merit.edu Tue Aug 21 09:30: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 JAA11703 for ; Tue, 21 Aug 2001 09:30:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6106691282; Tue, 21 Aug 2001 09:31:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8D5C91284; Tue, 21 Aug 2001 09:31:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E87191282 for ; Tue, 21 Aug 2001 09:31:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DA885DDE1; Tue, 21 Aug 2001 09:31:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 2B3A95DDC6 for ; Tue, 21 Aug 2001 09:31:07 -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 JAA10453 for ; Tue, 21 Aug 2001 09:29:37 -0400 (EDT) Date: Tue, 21 Aug 2001 09:31:21 -0400 (EDT) From: Mark Eklund X-X-Sender: To: Subject: [AAA-WG]: SNMP base mib. In-Reply-To: <82ECD4351A4A9547957C606034A3CB8D0B01A6@daebe005.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk There is now an updated version of the base protocol mib available at. It reflects version 7 of the base draft. http://www.ietf.org/internet-drafts/draft-koehler-aaa-diameter-base-protocol-mib-01 -mark From owner-aaa-wg@merit.edu Tue Aug 21 09:52: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 JAA13265 for ; Tue, 21 Aug 2001 09:52:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6FA2191292; Tue, 21 Aug 2001 09:53:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B2A691293; Tue, 21 Aug 2001 09:53: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 0697891292 for ; Tue, 21 Aug 2001 09:53:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C62365DDD4; Tue, 21 Aug 2001 09:53:15 -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 A610B5DDCC for ; Tue, 21 Aug 2001 09:53: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 f7LDrc317278 for ; Tue, 21 Aug 2001 16:53:38 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 21 Aug 2001 16:53:03 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVYL4G>; Tue, 21 Aug 2001 16:53:03 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D494@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, aboba@internaut.com, charliep@IPRG.nokia.com Cc: aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com, Basavaraj.Patil@nokia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 16:52: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 Thomas, The WG chairs may correct me if I misunderstood, but at the last AAA WG meeting it was evident that even work clearly on the current charter, like Mobile IPv6 Application (extension), do not get taken up by the WG. At least not before the current work is finished, and maybe the WG is re-chartered etc. So it seems hopeless to even think about work on areas outside, or bordering the current charter. I think the URP WG should be chartered ASAP and AAAv6 taken there as a possible solution. Where can I find the current proposal for the URP charter? With regards, Jarno > -----Original Message----- > From: ext Thomas Eklund [mailto:thomas.eklund@xelerated.com] > Sent: 21. elokuuta 2001 15:23 > To: 'George Tsirtsis'; 'Bernard Aboba'; Charlie Perkins > Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > ipng@sunroof.eng.sun.com; > urp@research.telcordia.com > Subject: RE: [AAA-WG]: AAA for IPv6 > > > Dear George, > What you are suggesting is already done in the draft. > > It proposes two mechanism to do access control for IPv6 > where, one way of > doing it is a stateful approach is based on ND and the other > is to do it in > the stateful approach with DHCPv6. > > Instead of people bouncing back and forth I belive that the > correct WG now > is the AAA WG. > > -- thomas > > >-----Original Message----- > >From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > >Sent: den 21 augusti 2001 14:07 > >To: 'Bernard Aboba'; Charlie Perkins > >Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > >ipng@sunroof.eng.sun.com; > >urp@research.telcordia.com > >Subject: RE: [AAA-WG]: AAA for IPv6 > > > > > >It seams to me that the subject of "AAA for IPv6" has at least two > >components that may potentially belong to different WGs. One is the > >communication between the end node and the access router and > >the other is > >the communication between the AAA client in the Access Router > >and the rest > >of the AAA infrastructure. > > > >The latter is all about IPv6 support in the AAA protocol > >(Radius, diameter, > >cops)...and thus belongs to the AAA/COPS WGs... > > > >The former is about challenging the end node and transporting the > >identification and authentication parameters over the access > >link. This is > >not part of the AAA protocol (e.g.: typically Radius does not > >run over the > >access link). What is needed is a "carrier" mechanism for the > >parameters > >that need to be fed to the AAA protocol. PPPv6 for example > >provides such a > >carrier. MIPv4 also provides such a carrier to IPv4 nodes that > >use Mobile IP > >but, MIPv6, due to the lack of FAs, does not provide such an obvious > >carrier...hence Charlie's work. Now, there are a couple of > >things that can > >be done IMO. > > > >1. Use Neighbor Discovery (ND) as a carrier for the AAA > >parameters. e.g.: > >extend Neighbor Advertisements and Router Advertisements to carry > >challenge/response messages....this to me is the job of IPv6 > >WG and could be > >the start of a much bigger fish called authenticated ND or > > > >2. Create a new carrier, independent from ND and with the > >specific task of > >carrying the appropriate challenge/response parameters...this > >to me belongs > >to URP WG. > > > >...my two drachma > > > >Regards > >George > >-----Original Message----- > >From: Bernard Aboba [mailto:aboba@internaut.com] > >Sent: Tuesday, August 21, 2001 8:06 AM > >To: Charlie Perkins > >Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > >ipng@sunroof.eng.sun.com; > >urp@research.telcordia.com > >Subject: Re: [AAA-WG]: AAA for IPv6 > > > > > >The AAA WG only considers work items resulting from a consensus draft > >within a subject area WG. Until the IPNG or URP WG progresses > >a draft on > >the subject, we cannot consider a work item relating to AAA > for IPV6. > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From owner-aaa-wg@merit.edu Tue Aug 21 11:45: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 LAA21349 for ; Tue, 21 Aug 2001 11:45:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE86A91295; Tue, 21 Aug 2001 11:46:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 980E991296; Tue, 21 Aug 2001 11:46: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 6B8F491295 for ; Tue, 21 Aug 2001 11:46:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36AC65DDC5; Tue, 21 Aug 2001 11:46:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 9DFE25DDB3 for ; Tue, 21 Aug 2001 11:46:49 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LFltI17054 for ; Tue, 21 Aug 2001 10:47:56 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 10:46:47 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 10:46:47 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 10:46:47 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E843F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEqSWN6nylJ8ZY8EdWxLgAIx6TWeAADy1mA From: "Patil Basavaraj (NET/Dallas)" To: "Rajahalme Jarno (NRC/Helsinki)" , , , , "Perkins Charles (IPRG)" Cc: , "Loughney John (NRC/Helsinki)" , , , X-OriginalArrivalTime: 21 Aug 2001 15:46:47.0595 (UTC) FILETIME=[7C6AD7B0:01C12A58] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA21349 Hi Jarno, > >Thomas, > >The WG chairs may correct me if I misunderstood, but at the last AAA WG >meeting it was evident that even work clearly on the current charter, like >Mobile IPv6 Application (extension), do not get taken up by the WG. At least >not before the current work is finished, and maybe the WG is re-chartered >etc. So it seems hopeless to even think about work on areas outside, or >bordering the current charter. > I agree with your assesment of the conclusions reached at the AAA WG meeting at the last IETF. The AAA WG currently has "Diameter Mobile IPv4 Application (draft-ietf-aaa-diameter-mobileip-07.txt)" as a WG item. At IETF51 we proposed "Diameter Mobile IPv6 Application" (draft-le-aaa-diameter-mobileipv6-00.txt) to be considered as a WG item. The response was that the AAA WG charter would need to be modified before new work items were taken up. This may happen before the next IETF meeting or sooner (at least from what I understood at the meeting in London). But I am not completely clear why the WG has to be recharterd to take on a new application when the same application for IPv4 is already a part of the WG agenda. I can accept the AAA WG not taking on the Diameter for MIPv6 application immediatley, because MIPv6 itself is not complete (yet). >I think the URP WG should be chartered ASAP and AAAv6 taken there as a >possible solution. Taking up solutions while we are still grappling with the URP charter and the specific boundaries of the problem may seem a bit like placing the cart before the horse. >Where can I find the current proposal for the URP >charter? > We are currently working on a new charter and will publish it soon. The charter that we had going into IETF51 can be obtained from the WG/BOFs agendas URL. I will also send a copy of the previous charter to the URP list if it helps. >With regards, > >Jarno > Cheers, -Basavaraj From owner-aaa-wg@merit.edu Tue Aug 21 12:01: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 MAA21921 for ; Tue, 21 Aug 2001 12:01:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B51B991226; Tue, 21 Aug 2001 12:02:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D4F891296; Tue, 21 Aug 2001 12:02:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A6EE91226 for ; Tue, 21 Aug 2001 12:02:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F22855DDD4; Tue, 21 Aug 2001 12:02:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 6548B5DDC5 for ; Tue, 21 Aug 2001 12:02:26 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LG2Ui17241 for ; Tue, 21 Aug 2001 11:02:30 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 11:02:25 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:02:25 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 11:02:24 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8442@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEqVmJd+wTEdJZDEdWJUgAIx6TWpQABFvVA From: "Patil Basavaraj (NET/Dallas)" To: "'ext Thomas Narten'" , "George Tsirtsis" Cc: "'Bernard Aboba'" , "Perkins Charles (IPRG)" , , "Loughney John (NRC/Helsinki)" , , X-OriginalArrivalTime: 21 Aug 2001 16:02:25.0063 (UTC) FILETIME=[AB311B70:01C12A5A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA21921 >> It seams to me that the subject of "AAA for IPv6" has at least two >> components that may potentially belong to different WGs. One is the >> communication between the end node and the access router > It may be the "access router" or some other entity in the access network. >This first component would appear to be exactly what the URP effort is >focusing on. That is, URP is focused on the problem of how does an >edge device "log in" and authenticate itself to the network. This >initial step (becoming authorized to use the network) may be tied in >with access control on a router, but that is a separate issue and does >not appear to be directly tied to the URP protocol. I.e., URP allows a >device to authenticate itself with some local server, that local >server may then (behind the scenes) grant permission to other devices >on the local network (e.g., routers) to allow packets from the device >to be forwarded. But the mechanism for doing that would likely be >separate (and possibly already existing) protocols rather than URP >itself. > Precisely. Thank you Thomas for "URP in a nutshell". >Thomas > -Basavaraj From owner-aaa-wg@merit.edu Tue Aug 21 12: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 MAA22814 for ; Tue, 21 Aug 2001 12:26:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44D2091224; Tue, 21 Aug 2001 12:27:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16C7B91225; Tue, 21 Aug 2001 12:27: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 0371591224 for ; Tue, 21 Aug 2001 12:27:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D13295DDD4; Tue, 21 Aug 2001 12:27: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 224065DDCC for ; Tue, 21 Aug 2001 12:27:39 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA18647; Tue, 21 Aug 2001 09:20:06 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 09:20:06 -0700 (PDT) From: Bernard Aboba To: "Patil Basavaraj (NET/Dallas)" Cc: "Rajahalme Jarno (NRC/Helsinki)" , thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, "Perkins Charles (IPRG)" , aaa-wg@merit.edu, "Loughney John (NRC/Helsinki)" , ipng@sunroof.eng.sun.com, urp@research.telcordia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E843F@daebe007.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I can accept the AAA WG not taking on the Diameter for MIPv6 > application immediatley, because MIPv6 itself is not complete (yet). Bingo. Once the remaining MIPv6 issues are ironed out, we can consider this. From owner-aaa-wg@merit.edu Tue Aug 21 13:55: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 NAA25566 for ; Tue, 21 Aug 2001 13:55:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEA8591232; Tue, 21 Aug 2001 13:56:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 988F19125C; Tue, 21 Aug 2001 13:56: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 75E4B91232 for ; Tue, 21 Aug 2001 13:56:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 445975DDC5; Tue, 21 Aug 2001 13:56:37 -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 677665DDAD for ; Tue, 21 Aug 2001 13:56:36 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA18763; Tue, 21 Aug 2001 10:48:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 10:48:59 -0700 (PDT) From: Bernard Aboba To: jarno.rajahalme@nokia.com Cc: thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, charliep@IPRG.nokia.com, aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com, Basavaraj.Patil@nokia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D494@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 WG chairs may correct me if I misunderstood, but at the last AAA WG > meeting it was evident that even work clearly on the current charter, like > Mobile IPv6 Application (extension), do not get taken up by the WG. At least > not before the current work is finished, and maybe the WG is re-chartered > etc. So it seems hopeless to even think about work on areas outside, or > bordering the current charter. The AAA WG requires that subject area WGs come to consensus before considering a work item. That ensures that the AAA WG is working cooperatively with other WGs. So if you want to look at MIPv6/AAA, the first thing to do is to finish MIPv6. If you want to look at URP/AAA, then you first need to come to consensus on URP. If you want to work on AAAv6, you've got to get consensus within IPNG WG that this approach makes sense. Same with SIP/AAA -- the SIP community needs to come to consensus first. This approach has worked well so far with MIPv4, NASREQ and ROAMOPS. Those WGs investigated their problem spaces, wrote and discussed requirements documents, and came to consensus. At that point, AAA WG picked up and responded to their requirements. Having an architectural framework and problem statement agreed to beforehand makes the AAA work straightforward and easy to deal with. Where the relevant communities are willing and able to do the required work to think through the architectural issues, and develop a framework that is the solution to a real problem, I suspect that the AAA issues will sort themselves out naturally, and AAA WG will not be a bottleneck. > > I think the URP WG should be chartered ASAP and AAAv6 taken there as a > possible solution. Where can I find the current proposal for the URP > charter? > Just as the AAA WG is not the appropriate place to do the work of subject area WGs, it is not appropriate for subject area WGs to design AAA protocols. We have separate WGs so that subject matter experts can congregate and focus on their area of expertise. So it would be best for URP to be handled in URP WG, AAA in AAA WG, and IPv6 in IPNG WG. From owner-aaa-wg@merit.edu Tue Aug 21 16:45: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 QAA00848 for ; Tue, 21 Aug 2001 16:45:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F6AD9122D; Tue, 21 Aug 2001 16:45:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B5059124C; Tue, 21 Aug 2001 16:45: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 F11CF9122D for ; Tue, 21 Aug 2001 16:45:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5F815DDC6; Tue, 21 Aug 2001 16:45:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8E2E95DDB3 for ; Tue, 21 Aug 2001 16:45:56 -0400 (EDT) Received: (qmail 9648 invoked by uid 500); 21 Aug 2001 20:33:54 -0000 Date: Tue, 21 Aug 2001 13:33:54 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: test Message-ID: <20010821133354.A9622@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 Test - I sent several e-mails today about current issues, and I have yet to see them :( PatC From owner-aaa-wg@merit.edu Tue Aug 21 16:48: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 QAA00964 for ; Tue, 21 Aug 2001 16:48:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F019B91235; Tue, 21 Aug 2001 16:49:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE0969124C; Tue, 21 Aug 2001 16:49: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 ADAB091235 for ; Tue, 21 Aug 2001 16:49:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E6BC5DDC6; Tue, 21 Aug 2001 16:49:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 36A065DDB3 for ; Tue, 21 Aug 2001 16:49:43 -0400 (EDT) Received: (qmail 9669 invoked by uid 500); 21 Aug 2001 20:37:41 -0000 Date: Tue, 21 Aug 2001 13:37:41 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 119: E bit, P bit, and proxy-info Message-ID: <20010821133741.B9622@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 > A diameter error packet with an 'E' bit set MUST have the > required AVPS listed in section 6.2, "Diameter Answer > Processing". > > Modify section 6.2 to state that these requirements are valid > even if the 'E' bit is set. > > Modify section 7.2 to list the answer-message as >::= < Diameter Header: code, ERR [PXY] > > and state that the 'P' bit will be set the same as the 'P' > bit in the request. > > I'm not certain if we need to modify section 6.1.7. It will be > technically correct with the requested changes, but probably > could be made more clear. Ok, added a sentence to the end of section 6.2, and modified section 7.2. I really don't think that section 6.1.7 needs any changes. 6.2 Diameter Answer Processing [...] Note that the error messages (see section 7.2) are also subjected to the above processing rules. [...] 7.2 Error Bit The 'E' (Error Bit) in the Diameter header is set when the request caused a protocol-related error (see section 7.1.3). Note that a message with the 'E' bit set is still subjected to the processing rules defined in section 6.2. When set, the answer message will not conform to the ABNF specification for the command, and will instead conform to the following ABNF: Message Format ::= < Diameter Header: code, ERR [PXY] > < Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Reporting-Host ] [ Proxy-Info ] * [ AVP ] Note that the code used in the header is the same that the one found in the request message, but with the 'R' bit cleared and the 'E' bit set. The 'P' bit in the header is set to the same value as the one found in the request message. PatC From owner-aaa-wg@merit.edu Tue Aug 21 16:49: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 QAA00977 for ; Tue, 21 Aug 2001 16:49:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22BB59124C; Tue, 21 Aug 2001 16:50:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E294991297; Tue, 21 Aug 2001 16: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 DA7F89124C for ; Tue, 21 Aug 2001 16:50:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDF445DDCA; Tue, 21 Aug 2001 16:50:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2CBA45DDB3 for ; Tue, 21 Aug 2001 16:50:25 -0400 (EDT) Received: (qmail 9683 invoked by uid 500); 21 Aug 2001 20:38:23 -0000 Date: Tue, 21 Aug 2001 13:38:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 120: Minor editorial changes in CMS Security Application Message-ID: <20010821133823.C9622@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 Minor comments on the requested changes: > In 1.3, page 7: > rephrase the first paragraph. Maybe the following proposal would be > enough: > > When a redirect agent is used, allowing the access device, or first > hop relay or proxy agent, to communicate directly with the home > server, the hop-by-hop security mechanisms specified in the base > protocol MAY be sufficient. How about: When a redirect agent is used, allowing an access device, relay or proxy agent to communicate directly with the home server, the hop-by-hop security mechanisms specified in the base protocol MAY be sufficient. I agree with all other proposed changes. Thanks, PatC From owner-aaa-wg@merit.edu Tue Aug 21 16:50: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 QAA01020 for ; Tue, 21 Aug 2001 16:50:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32EC291298; Tue, 21 Aug 2001 16:51:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 048E391297; Tue, 21 Aug 2001 16:51: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 C83AD91298 for ; Tue, 21 Aug 2001 16:51:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A4A5E5DDB3; Tue, 21 Aug 2001 16:51: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 230655DDCA for ; Tue, 21 Aug 2001 16:51:15 -0400 (EDT) Received: (qmail 9695 invoked by uid 500); 21 Aug 2001 20:39:13 -0000 Date: Tue, 21 Aug 2001 13:39:13 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 124: Inconsistency in OCSP-Request-Flags AVP Message-ID: <20010821133913.D9622@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 originator of this issue correctly states that the language is inconsistent with the command code's ABNF. The following text was proposed to replace existing text: " - a flag indicating whether the originating Diameter node wishes to receive certificate status information using OCSP messages. If this flag requires a fresh OCSP response, a nonce to be used by the destination Diameter node in OCSP requests MUST also be supplied." I agree with the proposed text, but feel that removing the reference to [9], as this issue proposes, is not the right thing to do. Therefore, I'd like to propose that the following sentence be added to the end of the above paragraph: "See [9] for more details on the certificate status protocol and messages." Thanks, PatC From owner-aaa-wg@merit.edu Tue Aug 21 16:50: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 QAA01046 for ; Tue, 21 Aug 2001 16:50:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9ED0591297; Tue, 21 Aug 2001 16:51:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C66D91299; Tue, 21 Aug 2001 16:51: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 543C291297 for ; Tue, 21 Aug 2001 16:51:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 361FF5DDB3; Tue, 21 Aug 2001 16:51:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AA34F5DDC6 for ; Tue, 21 Aug 2001 16:51:45 -0400 (EDT) Received: (qmail 9708 invoked by uid 500); 21 Aug 2001 20:39:44 -0000 Date: Tue, 21 Aug 2001 13:39:44 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 125: Inconsistency in OCSP-Responses AVP Message-ID: <20010821133944.E9622@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 issue included the following proposed text: " - (optionally, if OCSP response was required in the DSAR and OCSP is supported) a list of OCSP responses for the certificates in question. If a fresh response was required and a nonce value was included, each response will contain the nonce from the DSAR message" However, I found that the following minor change to the first line reads better: " - (optionally, if OCSP an response was requested in the DSAR and OCSP is supported) a list of OCSP responses for the certificates in question. If a fresh response was required and a nonce value was included, each response will contain the nonce from the DSAR message" Thanks, PatC From owner-aaa-wg@merit.edu Tue Aug 21 16:51: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 QAA01066 for ; Tue, 21 Aug 2001 16:51:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED7B591299; Tue, 21 Aug 2001 16:52:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD2159129A; Tue, 21 Aug 2001 16:52: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 A905991299 for ; Tue, 21 Aug 2001 16:52:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C1E45DDC6; Tue, 21 Aug 2001 16:52:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3903A5DDB3 for ; Tue, 21 Aug 2001 16:52:25 -0400 (EDT) Received: (qmail 9722 invoked by uid 500); 21 Aug 2001 20:40:23 -0000 Date: Tue, 21 Aug 2001 13:40:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 128: duplicate packet detection in failure case Message-ID: <20010821134023.F9622@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 text in 9.4 may not be sufficient in failure cases. Some text is > needed > to describe how to handle the failure case. > > Requested Change: > > Additional text should be added to discuss > > The sending party sends the (maximal amount = the used send window > size) > unacknowledged packets (after a link failure) to the next available > secondary/tertiary/etc. alternative recipient node (CG), with a mark that > they are potential duplicates, to wait there for a final decision. Why mark packets as duplicates? The end-to-end identifier is used to identify duplicates. So, some checks are necessary regardless on whether some resources were already consumed by the first request, right? If so, then the existing scheme seems to work fine. Perhaps I am missing the problem, though. > After the original link comes up, the original sender tests with empty > dummy > packets if the original recipient would acknowledge those packet numbers as > "already successfully handled" or "new". I feel quite uncomfortable sending dummy packets. RADIUS has gone this way because of protocol deficiencies. Personally, adding this to Diameter doesn't make it look like a solid protocol, but rather something patched (ala RADIUS). Of course, as I stated above, perhaps I am missing the problem... > Then the sender just announces the secondary node which waiting > packets it > may release towards the final destination (like BS), and which waiting > potentially duplicated packets to cancel (since they had already been > successfully handled by the original recipient node just before its link > went down. Why cancel pending requests? Isn't the objective to get packets to the home as quickly as possible? It seems like this issue is requesting that some additional overhead be created for reliability purposes, and again, I don't seem to see the reliability problem :( PatC From owner-aaa-wg@merit.edu Tue Aug 21 16:52:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01085 for ; Tue, 21 Aug 2001 16:52:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E06209129A; Tue, 21 Aug 2001 16:53:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1CB19129B; Tue, 21 Aug 2001 16:53: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 99E3B9129A for ; Tue, 21 Aug 2001 16:53:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 756485DDC6; Tue, 21 Aug 2001 16:53:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id A36935DDB3 for ; Tue, 21 Aug 2001 16:53:00 -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 QAA20255; Tue, 21 Aug 2001 16:51:06 -0400 (EDT) Date: Tue, 21 Aug 2001 16:52:51 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 119: E bit, P bit, and proxy-info In-Reply-To: <20010821133741.B9622@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Works for me. -mark On Tue, 21 Aug 2001, Pat Calhoun wrote: > > A diameter error packet with an 'E' bit set MUST have the > > required AVPS listed in section 6.2, "Diameter Answer > > Processing". > > > > Modify section 6.2 to state that these requirements are valid > > even if the 'E' bit is set. > > > > Modify section 7.2 to list the answer-message as > >::= < Diameter Header: code, ERR [PXY] > > > and state that the 'P' bit will be set the same as the 'P' > > bit in the request. > > > > I'm not certain if we need to modify section 6.1.7. It will be > > technically correct with the requested changes, but probably > > could be made more clear. > > Ok, added a sentence to the end of section 6.2, and modified section 7.2. > I really don't think that section 6.1.7 needs any changes. > > > > 6.2 Diameter Answer Processing > > [...] > > Note that the error messages (see section 7.2) are also subjected > to the above processing rules. > > [...] > > 7.2 Error Bit > > The 'E' (Error Bit) in the Diameter header is set when the > request caused a protocol-related error (see section 7.1.3). > Note that a message with the 'E' bit set is still subjected > to the processing rules defined in section 6.2. When set, the > answer message will not conform to the ABNF specification for > the command, and will instead conform to the following ABNF: > > Message Format > > ::= < Diameter Header: code, ERR [PXY] > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Result-Code } > [ Origin-State-Id ] > [ Error-Reporting-Host ] > [ Proxy-Info ] > * [ AVP ] > > Note that the code used in the header is the same that the one > found in the request message, but with the 'R' bit cleared and > the 'E' bit set. The 'P' bit in the header is set to the same > value as the one found in the request message. > > > PatC > From owner-aaa-wg@merit.edu Tue Aug 21 19:37:44 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 TAA03361 for ; Tue, 21 Aug 2001 19:37:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35B7791206; Tue, 21 Aug 2001 19:38:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6945912A0; Tue, 21 Aug 2001 19:38:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23C4D91206 for ; Tue, 21 Aug 2001 19:38:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECFAF5DDCA; Tue, 21 Aug 2001 19:38:15 -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 7CFD55DDC6 for ; Tue, 21 Aug 2001 19:38:15 -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 f7LNcE526696 for ; Tue, 21 Aug 2001 18:38:14 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f7LNcEA01214 for ; Tue, 21 Aug 2001 18:38:14 -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 SAA20317 for ; Tue, 21 Aug 2001 18:38:13 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id SAA05669 for ; Tue, 21 Aug 2001 18:38:09 -0500 (CDT) Message-ID: <009501c12a9a$578ccce0$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: References: Subject: [AAA-WG]: New Issue: NASREQ unsolicited challenge requests Date: Tue, 21 Aug 2001 16:36:59 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: August 21, 2001 Reference: none Document: NASREQ-07 Comment type: 'E'ditorial Priority: 'S' Must fix Section: 3.0 Rationale/Explanation of issue: The last paragraph of this section describes the possibility for a AAA server to "issue an unsolicited re-authentication and/or re-authorization by issueing an AA-Challenge-Ind message to the NAS." First and foremost, this kind of message no longer exists. Additionally, submitted issue #32 handles the technical issues regarding the removal of such messages. Requested change: Remove the last paragraph of section 3.0 Kev From owner-aaa-wg@merit.edu Tue Aug 21 19:37: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 TAA03371 for ; Tue, 21 Aug 2001 19:37:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EA55912A2; Tue, 21 Aug 2001 19:38:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60036912A1; Tue, 21 Aug 2001 19:38: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 F32729129F for ; Tue, 21 Aug 2001 19:38:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6B675DDCA; Tue, 21 Aug 2001 19:38:16 -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 839615DDC6 for ; Tue, 21 Aug 2001 19:38:16 -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 f7LNcFp17028 for ; Tue, 21 Aug 2001 18:38:15 -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 f7LNcFc14415 for ; Tue, 21 Aug 2001 18:38:15 -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 SAA20322 for ; Tue, 21 Aug 2001 18:38:14 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id SAA05672 for ; Tue, 21 Aug 2001 18:38:10 -0500 (CDT) Message-ID: <009601c12a9a$5831e680$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: Subject: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ Date: Tue, 21 Aug 2001 16:37:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01C12A5F.8B6275F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008B_01C12A5F.8B6275F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: August 21, 2001 Reference: none Document: NASREQ-07 Comment type: 'E'ditorial Priority: '1' Should fix Section: 3.1.1.1 Rationale/Explanation of issue:=20 This section mentions that the User-Password AVP "MUST be encrypted = using of the methods described in [2] or [13]," where [2] is the Base = Protocol, and [13] is the CMS Security Application. Of the mechanisms = described in the Base Protocol, neither IPsec or TLS deal with = encrypting portions of a diameter message, but rather the entire message = itself. Requested change:=20 Remove the reference to [2], leaving only the reference to [13]. Kev ------=_NextPart_000_008B_01C12A5F.8B6275F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.comDate=20 first submitted: August 21, 2001
Reference: none
Document:=20 NASREQ-07
Comment type: 'E'ditorial
Priority: '1' Should = fix
Section:=20 3.1.1.1
Rationale/Explanation of issue:
This section mentions = that the=20 User-Password AVP "MUST be encrypted using of the methods described in = [2] or=20 [13]," where [2] is the Base Protocol, and [13] is the CMS Security=20 Application.  Of the mechanisms described in the Base Protocol, = neither=20 IPsec or TLS deal with encrypting portions of a diameter message, but = rather the=20 entire message itself.

Requested change:
Remove the reference to [2], leaving only the reference to = [13].

 
Kev
 
------=_NextPart_000_008B_01C12A5F.8B6275F0-- From owner-aaa-wg@merit.edu Tue Aug 21 20:15: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 UAA03615 for ; Tue, 21 Aug 2001 20:15:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0975D9129F; Tue, 21 Aug 2001 20:16:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C720D912A0; Tue, 21 Aug 2001 20:16: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 703019129F for ; Tue, 21 Aug 2001 20:16:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 43B925DDD4; Tue, 21 Aug 2001 20:16:31 -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 C72615DDC6 for ; Tue, 21 Aug 2001 20:16:30 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7M0GT504809 for ; Tue, 21 Aug 2001 19:16:29 -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 f7M0GTc19411 for ; Tue, 21 Aug 2001 19:16:29 -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 TAA21324 for ; Tue, 21 Aug 2001 19:16:28 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id TAA05933 for ; Tue, 21 Aug 2001 19:16:24 -0500 (CDT) Message-ID: <009a01c12a9f$afc00c10$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: Subject: [AAA-WG]: New Issue: Use of Auth-Request-Type in NASREQ Date: Tue, 21 Aug 2001 17:16:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C12A64.FF367620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C12A64.FF367620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: August 21, 2001 Reference: none Document: NASREQ-07 Comment type: 'T'echnical Priority: '1' Should fix Section: 3.0 Rationale/Explanation of issue: In the second paragraph, "...it is possible to send a request for = authorization only. The type of service depends upon the = Auth-Request-Type AVP." However, the use of this AVP is not mandatory = in any of the messages defined in the NASREQ application, which may = produce situations where the desired functionality (only = re-authentication, only re-authorization, or both) is ambiguous. Requested change:=20 Make the Auth-Request-Type AVP mandatory in the AAR and DER, and at = least optional in the AAA and DEA to allow the AAA server to indicate = the desired functionality (only re-authentication, only = re-authorization, or both) expected. Kev ------=_NextPart_000_0097_01C12A64.FF367620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Submitter name: Kevin Purser
Submitter email address: kevin.purser@ericsson.comDate=20 first submitted: August 21, 2001
Reference: none
Document:=20 NASREQ-07
Comment type: 'T'echnical
Priority: '1' Should=20 fix
Section: 3.0
Rationale/Explanation of issue:
In the second paragraph, "...it is possible to send a request for = authorization only.  The type of service depends upon the=20 Auth-Request-Type AVP."  However, the use of this AVP is not = mandatory in=20 any of the messages defined in the NASREQ application, which may = produce=20 situations where the desired functionality (only = re-authentication, only=20 re-authorization, or both) is ambiguous.

Requested change: =
Make the=20 Auth-Request-Type AVP mandatory in the AAR and DER, and at least = optional in=20 the AAA and DEA to allow the AAA server to indicate the desired = functionality=20 (only re-authentication, only re-authorization, or both) = expected.
 
 
Kev
------=_NextPart_000_0097_01C12A64.FF367620-- From owner-aaa-wg@merit.edu Tue Aug 21 22:40: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 WAA06892 for ; Tue, 21 Aug 2001 22:40:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA0339123C; Tue, 21 Aug 2001 22:41:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83E309125D; Tue, 21 Aug 2001 22:41: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 758A49123C for ; Tue, 21 Aug 2001 22:41:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CFD25DDDC; Tue, 21 Aug 2001 22:41:31 -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 A28165DDC6 for ; Tue, 21 Aug 2001 22:41:30 -0400 (EDT) Received: from jariws1 ([62.248.154.197]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010822024129.UVMV1519.fep01-app.kolumbus.fi@jariws1>; Wed, 22 Aug 2001 05:41:29 +0300 Message-ID: <004b01c12ab3$f3b4a7a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Kevin Purser" , References: <009601c12a9a$5831e680$869f558a@ew.us.am.ericsson.se> Subject: Re: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ Date: Wed, 22 Aug 2001 05:41:31 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C12ACD.18E04DE0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C12ACD.18E04DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >This section mentions that the User-Password AVP "MUST be >encrypted using of the methods described in [2] or [13]," where >[2] is the Base Protocol, and [13] is the CMS Security Application.=20 >Of the mechanisms described in the Base Protocol, neither IPsec >or TLS deal with encrypting portions of a diameter message, but >rather the entire message itself. In cases where CMS security isn't necessary - such as when a NAS leaves e2e security to be handled by local proxy - wouldn't IPsec/TLS = encryption of the whole packet be sufficient? Jari ------=_NextPart_000_0048_01C12ACD.18E04DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>This section mentions that the User-Password AVP "MUST be
>encrypted using of the methods described in [2] or [13]," = where
>[2] is the Base Protocol, and [13] is the CMS Security=20 Application. 
>Of the mechanisms described in the Base Protocol, neither = IPsec
>or TLS deal with encrypting portions of a diameter message, = but
>rather the entire message itself.
In cases where CMS security isn't necessary - such = as when a=20 NAS leaves
e2e security to be handled by local proxy - wouldn't = IPsec/TLS=20 encryption
of the whole packet be sufficient?
 
Jari
 
------=_NextPart_000_0048_01C12ACD.18E04DE0-- From owner-aaa-wg@merit.edu Wed Aug 22 02:13: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 CAA25779 for ; Wed, 22 Aug 2001 02:13:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 856FF9125F; Wed, 22 Aug 2001 02:14:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5944E91260; Wed, 22 Aug 2001 02:14: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 40F3C9125F for ; Wed, 22 Aug 2001 02:14:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17C635DDE1; Wed, 22 Aug 2001 02:14:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 58DA15DD91 for ; Wed, 22 Aug 2001 02:14:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA19658; Tue, 21 Aug 2001 23:07:00 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 23:07:00 -0700 (PDT) From: Bernard Aboba To: Thomas Narten Cc: Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 In-Reply-To: <200108211318.f7LDI3c01321@hygro.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk For NASREQ, MIPv4, and ROAMOPS we had drafts specifying the architecture/framework, as well as requirements for a solution. The access protocols (e.g. PPP, MIPv4) were also well specified. That meant that the AAA WG only had to interface AAA to an architecture and access protocol that was understood. This makes the job *much* easier. On Tue, 21 Aug 2001, Thomas Narten wrote: > Bernard, > > Can you clarify a bit on what sort of consensus draft you would want > out of a subject area WG. Would that be (for example) a problem > statement and a corresponding set of requirements, as opposed to a > particular solution? > > Thomas > From owner-aaa-wg@merit.edu Wed Aug 22 03:37:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27027 for ; Wed, 22 Aug 2001 03:37:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8559291261; Wed, 22 Aug 2001 03:38:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5943691262; Wed, 22 Aug 2001 03:38: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 2267791261 for ; Wed, 22 Aug 2001 03:38:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07BC55DDBE; Wed, 22 Aug 2001 03:38: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 5AB1A5DD91 for ; Wed, 22 Aug 2001 03:38: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 f7M7cDK20952; Wed, 22 Aug 2001 09:38:14 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA20482; Wed, 22 Aug 2001 09:38:10 +0200 (MET DST) Message-ID: <3B836169.A5A86305@rioja.ericsson.se> Date: Wed, 22 Aug 2001 09:38: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 120: Minor editorial changes in CMS Security Application References: <20010821133823.C9622@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: > > Minor comments on the requested changes: > > > In 1.3, page 7: > > rephrase the first paragraph. Maybe the following proposal would be > > enough: > > > > When a redirect agent is used, allowing the access device, or first > > hop relay or proxy agent, to communicate directly with the home > > server, the hop-by-hop security mechanisms specified in the base > > protocol MAY be sufficient. > > How about: > > When a redirect agent is used, allowing an access device, relay or > proxy agent to communicate directly with the home server, the > hop-by-hop security mechanisms specified in the base protocol MAY > be sufficient. Perfect. I was only trying to point that the sentence was inconsistent. My English is not good enough either, so that sometimes the proposed change isn't quite good. 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 Aug 22 03:39: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 DAA27081 for ; Wed, 22 Aug 2001 03:39:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BC93A91262; Wed, 22 Aug 2001 03:40:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8852891263; Wed, 22 Aug 2001 03:40: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 5BAB091262 for ; Wed, 22 Aug 2001 03:40:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 424655DDBE; Wed, 22 Aug 2001 03:40:26 -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 708CE5DD91 for ; Wed, 22 Aug 2001 03:40:25 -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 f7M7eNK23052; Wed, 22 Aug 2001 09:40:23 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA20563; Wed, 22 Aug 2001 09:40:22 +0200 (MET DST) Message-ID: <3B8361ED.3A9BF5AF@rioja.ericsson.se> Date: Wed, 22 Aug 2001 09:40:29 +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 124: Inconsistency in OCSP-Request-Flags AVP References: <20010821133913.D9622@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 originator of this issue correctly states that the language is inconsistent > with the command code's ABNF. The following text was proposed to replace > existing text: > > " - a flag indicating whether the originating Diameter > node wishes to receive certificate status information using > OCSP messages. If this flag requires a fresh OCSP response, > a nonce to be used by the destination Diameter node in OCSP > requests MUST also be supplied." > > I agree with the proposed text, but feel that removing the reference to [9], > as this issue proposes, is not the right thing to do. Therefore, I'd like > to propose that the following sentence be added to the end of the above paragraph: > > "See [9] for more details on the certificate status protocol and messages." That's right. I was only quoting the part of the paragraph I wanted tho change (not the whole paragraph). The reference to [9] hasn't to be removed :-)) 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 Aug 22 09:36: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 JAA07136 for ; Wed, 22 Aug 2001 09:36:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6FA8391267; Wed, 22 Aug 2001 09:37:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41848912A0; Wed, 22 Aug 2001 09:37: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 10C0D91267 for ; Wed, 22 Aug 2001 09:37:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D23F05DDE8; Wed, 22 Aug 2001 09:37:14 -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 1BBB25DDCA for ; Wed, 22 Aug 2001 09:37:14 -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 f7MDehG29778 for ; Wed, 22 Aug 2001 16:40:48 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Aug 2001 16:36:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZ3T7>; Wed, 22 Aug 2001 16:36:56 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D496@esebe004.NOE.Nokia.com> From: jarno.rajahalme@nokia.com To: aboba@internaut.com, jarno.rajahalme@nokia.com Cc: thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, charliep@IPRG.nokia.com, aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com, Basavaraj.Patil@nokia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Wed, 22 Aug 2001 16:36:49 +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 Bernard Aboba wrote: > > > > I think the URP WG should be chartered ASAP and AAAv6 taken > there as a > > possible solution. Where can I find the current proposal for the URP > > charter? > > > > Just as the AAA WG is not the appropriate place to do the > work of subject > area WGs, it is not appropriate for subject area WGs to design AAA > protocols. We have separate WGs so that subject matter experts can > congregate and focus on their area of expertise. So it would > be best for > URP to be handled in URP WG, AAA in AAA WG, and IPv6 in IPNG WG. > Well, I meant the part of the AAAv6 draft that is applicable to the URP scope. The protocol stuff in the draft is focused on the interface(s) between the host and an "attendant" node in the network, which clearly is not in the AAA WG scope. Jarno From owner-aaa-wg@merit.edu Wed Aug 22 10:25: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 KAA10134 for ; Wed, 22 Aug 2001 10:25:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D454F91268; Wed, 22 Aug 2001 10:26:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A419E912A3; Wed, 22 Aug 2001 10:26: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 6D56691268 for ; Wed, 22 Aug 2001 10:26:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EDB05DDEB; Wed, 22 Aug 2001 10:26:36 -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 0556F5DDE8 for ; Wed, 22 Aug 2001 10:26:35 -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 f7MEQXv11014 for ; Wed, 22 Aug 2001 16:26:33 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA16304; Wed, 22 Aug 2001 16:26:29 +0200 (MET DST) Message-ID: <3B83C11F.7DCB4380@rioja.ericsson.se> Date: Wed, 22 Aug 2001 16:26: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: Re: [AAA-WG]: Questions about DSAs through proxy agents References: <3B81555C.AACD0FA8@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: > > Hi all, > > I'm trying to understand the overall mechanism of CMS Security when a > proxy is involved. I'd be grateful for any comment about my > description. > > An agent tries to establish a DSA with a Diameter server. Let's > imagine that it requires both encrypted and signed AVPs. There is also > a downstream proxy. > > The proxy inspects the request and checks that it won't modify any of > the expected protected AVPs, so that answers with a DSAA including > DIAMETER_CAN_ACT_AS_CMS_PROXY. Which additional AVPs must include this > answer? It doesn't seem that the same information quoted in 3.1 must > be present there (which AAA-Server-Certs AVPs are gonna be used). > Finally, as stated in 1.2, the DSAA must include a CMS-Signed-Data AVP > (but, on what?) along with the digital certificate of the proxy. Sorry. I've just read that a message with a failure Result-Code doesn't to conform to the ABNF of the command. Rest of concerns are developed in separate mails... Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 22 10:48: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 KAA11592 for ; Wed, 22 Aug 2001 10:48:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96AC691269; Wed, 22 Aug 2001 10:49:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 626B39126A; Wed, 22 Aug 2001 10:49: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 2FAA691269 for ; Wed, 22 Aug 2001 10:49:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EAEEA5DDE8; Wed, 22 Aug 2001 10:49:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 954F45DDC2 for ; Wed, 22 Aug 2001 10:49:51 -0400 (EDT) Received: (qmail 14760 invoked by uid 500); 22 Aug 2001 14:37:47 -0000 Date: Wed, 22 Aug 2001 07:37:46 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Thomas Narten , Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 Message-ID: <20010822073746.B14728@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Thomas Narten , Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com References: <200108211318.f7LDI3c01321@hygro.adsl.duke.edu> 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 Tue, Aug 21, 2001 at 11:07:00PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Although I do agree with Bernard on some points, I believe that waiting for MIPv6 to be RFCed may be too late. The issue is that many folks will need an AAA infrastructure to deploy MIPv6, and waiting for the RFC will simply push out MIPv6 deployments. The issues with MIPv6 are mostly in the security area (specifically in binding updates), and we can simply not specify any AAA interactions for binding updates until a later time). Personally, I think we should begin the work once our current specs are out of our hands. my 2 cents, PatC On Tue, Aug 21, 2001 at 11:07:00PM -0700, Bernard Aboba wrote: > For NASREQ, MIPv4, and ROAMOPS we had drafts specifying the > architecture/framework, as well as requirements for a solution. > The access protocols (e.g. PPP, MIPv4) were also well specified. > That meant that the AAA WG only had to interface AAA to an architecture > and access protocol that was understood. This makes the job *much* easier. > > On Tue, 21 Aug 2001, Thomas Narten wrote: > > > Bernard, > > > > Can you clarify a bit on what sort of consensus draft you would want > > out of a subject area WG. Would that be (for example) a problem > > statement and a corresponding set of requirements, as opposed to a > > particular solution? > > > > Thomas > > > From owner-aaa-wg@merit.edu Wed Aug 22 12:32:29 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15776 for ; Wed, 22 Aug 2001 12:32:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A5F6912A6; Wed, 22 Aug 2001 12:33:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7C20912A9; Wed, 22 Aug 2001 12:33:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78571912A6 for ; Wed, 22 Aug 2001 12:33:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E8765DDEB; Wed, 22 Aug 2001 12:33:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 110BA5DDF1 for ; Wed, 22 Aug 2001 12:33:01 -0400 (EDT) Received: (qmail 16800 invoked by uid 500); 22 Aug 2001 16:20:47 -0000 Date: Wed, 22 Aug 2001 09:20:47 -0700 From: Pat Calhoun To: Kevin Purser Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: New Issue: NASREQ unsolicited challenge requests Message-ID: <20010822092047.A16789@charizard.diameter.org> Mail-Followup-To: Kevin Purser , aaa-wg@merit.edu References: <009501c12a9a$578ccce0$869f558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009501c12a9a$578ccce0$869f558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Tue, Aug 21, 2001 at 04:36:59PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Rationale/Explanation of issue: > The last paragraph of this section describes the possibility for a AAA > server to "issue an unsolicited re-authentication and/or re-authorization by > issueing an AA-Challenge-Ind message to the NAS." > > First and foremost, this kind of message no longer exists. Additionally, > submitted issue #32 handles the technical issues regarding the removal of > such messages. > > Requested change: > Remove the last paragraph of section 3.0 Actually, removing the paragraph is the wrong fix. The correct fix is to replace AA-Challenge-Ind with Re-Auth-Request, which is defined in the base spec. Thanks, PatC From owner-aaa-wg@merit.edu Wed Aug 22 12:36: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 MAA15922 for ; Wed, 22 Aug 2001 12:36:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38C9A912B6; Wed, 22 Aug 2001 12:35:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A14E912B5; Wed, 22 Aug 2001 12:35: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 5A69F912B3 for ; Wed, 22 Aug 2001 12:35:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EC125DDF1; Wed, 22 Aug 2001 12:35:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A159B5DDEB for ; Wed, 22 Aug 2001 12:35:45 -0400 (EDT) Received: (qmail 16819 invoked by uid 500); 22 Aug 2001 16:23:40 -0000 Date: Wed, 22 Aug 2001 09:23:40 -0700 From: Pat Calhoun To: Jari Arkko Cc: Kevin Purser , aaa-wg@merit.edu Subject: Re: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ Message-ID: <20010822092340.B16789@charizard.diameter.org> Mail-Followup-To: Jari Arkko , Kevin Purser , aaa-wg@merit.edu References: <009601c12a9a$5831e680$869f558a@ew.us.am.ericsson.se> <004b01c12ab3$f3b4a7a0$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: <004b01c12ab3$f3b4a7a0$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Wed, Aug 22, 2001 at 05:41:31AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Aug 22, 2001 at 05:41:31AM +0300, Jari Arkko wrote: > >This section mentions that the User-Password AVP "MUST be > >encrypted using of the methods described in [2] or [13]," where > >[2] is the Base Protocol, and [13] is the CMS Security Application. > >Of the mechanisms described in the Base Protocol, neither IPsec > >or TLS deal with encrypting portions of a diameter message, but > >rather the entire message itself. > > In cases where CMS security isn't necessary - such as when a NAS leaves > e2e security to be handled by local proxy - wouldn't IPsec/TLS encryption > of the whole packet be sufficient? I agree. Although IPSec and/or TLS doesn't cover just portion of the secret, it may be sufficient in many (non-roaming) installations. PatC From owner-aaa-wg@merit.edu Wed Aug 22 12:55:53 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16507 for ; Wed, 22 Aug 2001 12:55:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 94685912A9; Wed, 22 Aug 2001 12:56:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 660FC912AA; Wed, 22 Aug 2001 12:56: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 39A90912A9 for ; Wed, 22 Aug 2001 12:56:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0064C5DDF2; Wed, 22 Aug 2001 12:56: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 A1CD05DDEF for ; Wed, 22 Aug 2001 12:56: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 f7MGuLK22037 for ; Wed, 22 Aug 2001 18:56:22 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA23872; Wed, 22 Aug 2001 18:56:18 +0200 (MET DST) Message-ID: <3B83E434.B98C816D@rioja.ericsson.se> Date: Wed, 22 Aug 2001 18:56: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] Multiple signatures on a set of AVPs 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 Priority: 1 Section: 6.1 Rationale/Explanation of issue: In 6.1 it's stated that: Multiple Diameter entities MAY add their signatures to an existing CMS-Signed-Data AVP using the countersignature attribute, defined in section 11.4 of [3]. The countersignature attribute requires that the signatures occur sequentially, meaning that each signature covers the existing signatures in the CMS object. May I assume that this is the only way to add multiple signatures? If so, there will be only one singerInfo in a SignedData value (including a message-digest attribute) and that multiple signatures will be handled only like countersignature attributes (which allows not to resign the whole set of AVPs) Requested change: If so, I'd change the previous paragraph to say: Multiple Diameter entities MAY add their signatures to an existing CMS-Signed-Data AVP. It MUST be done using 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. This attribute MUST be always unsigned. 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 Aug 22 13: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 NAA16611 for ; Wed, 22 Aug 2001 13:00:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 045C7912AA; Wed, 22 Aug 2001 13:00:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA2F6912AD; Wed, 22 Aug 2001 13:00: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 93860912AA for ; Wed, 22 Aug 2001 13:00:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78EA85DDEB; Wed, 22 Aug 2001 13:00: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 6AC6F5DDC2 for ; Wed, 22 Aug 2001 13:00: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 f7MH0Hv14619 for ; Wed, 22 Aug 2001 19:00:18 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA24050; Wed, 22 Aug 2001 19:00:15 +0200 (MET DST) Message-ID: <3B83E520.9F3FB4B3@rioja.ericsson.se> Date: Wed, 22 Aug 2001 19:00: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 Subject: [AAA-WG]: [issue] digest value within CMS-Signed-Data AVP 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: E Priority: 1 Section: 6.1 Rationale/Explanation of issue: In 6.1 (last sentence of page 20), it's stated that not the whole content being signed but just a digest is inserted: Instead, the digest value within the SignedData structure contains the digest produced in the signature process. This paragraph isn't clear so that there isn't any digest value within a SignedData structure. The correct name for it is message-digest attribute type (as defined in [CMS, 11.2]). An attribute of this type may be inserted into any of the SignerInfo values that comprises Signed Data SignerInfos (take into account that this value would be the same for all the SingerInfo value, so that only one digest algorithm must be supported in [CMSSec]). However, this attribute is only required (in [CMS, 11.2]) if any other attribute is present (if present, message-digest is a SignedAttribute). As the [CMSSec] specification allows countersignature operations, an attribute of this type must be required. Requested change: I'd replace the previous sentence with: 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 in the SingerInfo value. This attribute MUST be always signed. 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 Aug 22 13:02: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 NAA16693 for ; Wed, 22 Aug 2001 13:02:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F521912AC; Wed, 22 Aug 2001 13:03:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2125E912AD; Wed, 22 Aug 2001 13:03: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 CE323912AC for ; Wed, 22 Aug 2001 13:03:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4DB55DDEB; Wed, 22 Aug 2001 13:03:46 -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 D27915DDC2 for ; Wed, 22 Aug 2001 13:03:45 -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 f7MH3hK23627 for ; Wed, 22 Aug 2001 19:03:44 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA24207; Wed, 22 Aug 2001 19:03:41 +0200 (MET DST) Message-ID: <3B83E5EE.F97F6631@rioja.ericsson.se> Date: Wed, 22 Aug 2001 19:03: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] Several CMS-Encrypted-Data AVPs in a message 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: E Priority: 1 Section: Rationale/Explanation of issue: In 6.2 it's stated that: CMS-Encrypted-Data MAY contain more than one CMS object, that is, implementations MUST be able to add a new CMS-Encrypted-Data AVP value and also MUST be able to decrypt all CMS-Encrypted-Data AVP values which are encrypted for them. This text isn't clear for me: - The first sentence ("CMS-Encrypted-Data MAY contain more than one CMS object") might suggest that it is possible to encrypt several AVPs into a CMS-Encrypted-Data AVP (even if those AVPs are also CMS-Encrypted-Data AVPs). That is, it might refer to nested enveloping. - However, the next sentence, which is a consequence of the previous ("implementations MUST be able to add a new CMS-Encrypted-Data AVP value") isn't straightforward since it doesn't specify to what it can be added (to the message or maybe to an AVP?). I mean, it might suggest that an implementation MUST be able to add a new CMS-Encrypted-Data AVP to a message. - The last sentence ("also MUST be able to decrypt all CMS-Encrypted-Data AVP values which are encrypted for them") contradict my previous interpretation. If there're nested encryption, just the "last" envelope could be opened, so that a nested envelope couldn't be opened by the receiver unless he opened the external envelopes. On the other hand, with different CMS-Encrypted-Data AVPs inside the same message and with different recipients, any AVP would be opened by the its intended recipient. Another possibility is that the paragraph is trying to say that new RecipientInfo values may be inserted. But that fact can't be true since it would be necessary for an entity trying to do that to be a recipient to be able to decrypt the CEK and reencrypt it with a new key. Requested change: Replace the quoted paragraph (and maybe the next one) with a more clear 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 Wed Aug 22 13:04: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 NAA16767 for ; Wed, 22 Aug 2001 13:04:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9ED6B912AD; Wed, 22 Aug 2001 13:05:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68676912AE; Wed, 22 Aug 2001 13:05:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41FB4912AD for ; Wed, 22 Aug 2001 13:05:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 286E55DDEB; Wed, 22 Aug 2001 13:05: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 4697E5DDC2 for ; Wed, 22 Aug 2001 13:04: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 f7MH4wK23831 for ; Wed, 22 Aug 2001 19:04:58 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA24234; Wed, 22 Aug 2001 19:04:55 +0200 (MET DST) Message-ID: <3B83E639.70931B61@rioja.ericsson.se> Date: Wed, 22 Aug 2001 19:04: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] contentType instead of eContentType in CMS-Encrypted-Data AVP 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: E Priority: S Section: Rationale/Explanation of issue: In 6.2 it's stated that: Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the eContentType of the EncapsulatedContentInfo MUST be id-data [11]. However, EncapsulatedContentInfo is the type of the value encapContentInfo inside the CMS SignedData type, not EncapsulatedData. Requested change: Replace the previous paragraph with: Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the contentType of the EncryptedContentInfo value MUST be id-data [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 Wed Aug 22 13:05:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16850 for ; Wed, 22 Aug 2001 13:05:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A453C912AE; Wed, 22 Aug 2001 13:06:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75FAC912AF; Wed, 22 Aug 2001 13:06: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 51A53912AE for ; Wed, 22 Aug 2001 13:06:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 356BE5DDEB; Wed, 22 Aug 2001 13:06: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 4FC995DDC2 for ; Wed, 22 Aug 2001 13:06: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 f7MH69K24065 for ; Wed, 22 Aug 2001 19:06:09 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA24373; Wed, 22 Aug 2001 19:06:06 +0200 (MET DST) Message-ID: <3B83E680.161A478F@rioja.ericsson.se> Date: Wed, 22 Aug 2001 19:06: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 Subject: [AAA-WG]: [issue] Proxy's DSAR 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-08-22 Reference: Document: CMS-02 Comment type: T Priority: S Section: Rationale/Explanation of issue: If the agent agrees on using the proxy, I assume that the proxy establishes the DSA with the AAA server using some of the parameters provided by the agent in the first DSAR. I think that, at least, same TTL, Expected-Encrypted-AVP and Expected-Signed-AVP have to be used. However, shouldn't this point deserve some kind of guideline? For example, which AVPs values has to be just copied into the newly created DSAR? Or, which AVPs can be changed? 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 Wed Aug 22 13:06:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16929 for ; Wed, 22 Aug 2001 13:06:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD33E912AF; Wed, 22 Aug 2001 13:07:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CCB0912B0; Wed, 22 Aug 2001 13:07: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 6E501912AF for ; Wed, 22 Aug 2001 13:07:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 448FB5DDEB; Wed, 22 Aug 2001 13:07: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 63C8E5DDEF for ; Wed, 22 Aug 2001 13:07:31 -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 f7MH7QK24343 for ; Wed, 22 Aug 2001 19:07:26 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA24400; Wed, 22 Aug 2001 19:07:23 +0200 (MET DST) Message-ID: <3B83E6CD.9ABFB41@rioja.ericsson.se> Date: Wed, 22 Aug 2001 19:07: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: [AAA-WG]: [issue] CMS Proxy's DSAAs 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 Priority: 1 Section: Rationale/Explanation of issue: When a proxy is involved in the establishment of a DSA, the proxy will reject the DSA indicating to the agent that: - it is not possible to establish a DSA (Result-Code is DIAMETER_NO_CMS_THROUGH_PROXY) - it can act as a CMS proxy on behalf of it (Result-Code is DIAMETER_CAN_ACT_AS_CMS_PROXY). According to 1.2: The DSAA MUST be signed by the proxy agent, and include its certificate, to allow the access device to validate the originator of the DSAA. However, being the Result-Code a permanent failure code, the message will have the 'E' bit set, so that the message will not conform to the ABNF described for the command (DSAA). Then, on which AVPs is going to be applied the digital signature? 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 Wed Aug 22 13:08: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 NAA17007 for ; Wed, 22 Aug 2001 13:08:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DF00912B0; Wed, 22 Aug 2001 13:09:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11544912B1; Wed, 22 Aug 2001 13:09: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 DD0D0912B0 for ; Wed, 22 Aug 2001 13:08:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6EBE5DDEF; Wed, 22 Aug 2001 13:08:59 -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 EB07E5DDC2 for ; Wed, 22 Aug 2001 13:08:58 -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 f7MH8uK24745 for ; Wed, 22 Aug 2001 19:08:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA24415; Wed, 22 Aug 2001 19:08:54 +0200 (MET DST) Message-ID: <3B83E727.F301705A@rioja.ericsson.se> Date: Wed, 22 Aug 2001 19:08: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]: [issue] Signed DSA messages 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 Priority: 1 Section: Rationale/Explanation of issue: In some points of the specification, is stated that a DSA message must/may be signed: In 1.2: The DSAA MUST be signed by the proxy agent, and include its certificate, to allow the access device to validate the originator of the DSAA. In 1.3: The CMS specification allows for Diameter AVPs to be multiply-signed In 3.1 - the DSAA message MUST be digitally signed and the signature MUST be validated and the signer's certificate chain MUST terminate as a CA mentioned in the DSAR message and also The DSAR MAY be signed. If the originating node has a private key and protection expectations for AVPs are specified, then the DSAR SHOULD be signed. The DSAA MUST be signed by a Diameter agent or server within the user's realm, to prevent an intermediate node from modifying the protection expectations for AVPs. Pat has agreed on changing that expression and saying that "... (MAY|MUST) include the CMS-Signed-Data AVP". However, I'm a little bit concerned when the presence of a CMS-Signed-Data AVP is required. This AVP contains a digital signature on other (or others) AVPs. Those protected AVPs must have the 'P' bit set. But let's imagine that neither of the AVPs included in the message have the 'P' bit set (maybe because the implementation does not consider that they must be protected). I assume that the implementation must detect those cases and, when a CMS-Signed-Data AVP is required, set the 'P' bit of an AVP, maybe chosen randomly or maybe fixed in the configuration (for example, the DSA-TTL AVP is always present, so that the implementation might be configured to protect it always when a digital signature is required). Is this issue up to the implementation or should be specified in the specification? 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 Wed Aug 22 14:28: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 OAA19415 for ; Wed, 22 Aug 2001 14:28:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AE6791287; Wed, 22 Aug 2001 14:29:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 147F391288; Wed, 22 Aug 2001 14:29: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 CDDDD91287 for ; Wed, 22 Aug 2001 14:29:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6D615DDEF; Wed, 22 Aug 2001 14:29:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 1EAF85DDC7 for ; Wed, 22 Aug 2001 14:29:54 -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 f7MITQp16412; Wed, 22 Aug 2001 13:29:26 -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 f7MITQp25252; Wed, 22 Aug 2001 13:29:26 -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 NAA03457; Wed, 22 Aug 2001 13:29:22 -0500 (CDT) Received: from ericberk107 (rmt160147.am.ericsson.se [138.85.160.147]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id NAA13889; Wed, 22 Aug 2001 13:29:16 -0500 (CDT) Message-ID: <006201c12b38$5b43fdb0$93a0558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: Cc: "Pat Calhoun" , "Jari Arkko" , References: <009601c12a9a$5831e680$869f558a@ew.us.am.ericsson.se> <004b01c12ab3$f3b4a7a0$8a1b6e0a@arenanet.fi> <20010822092340.B16789@charizard.diameter.org> Subject: Re: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ Date: Wed, 22 Aug 2001 11:29:11 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, I was just confused about the wording of the text, which sounded to me like it was trying to say the AVP alone could be encrypted through the use of IPsec/TLS, which obviously isn't the case. Guess it's already clear for everybody else? Kev ----- Original Message ----- From: "Pat Calhoun" To: "Jari Arkko" Cc: "Kevin Purser" ; Sent: Wednesday, August 22, 2001 9:23 AM Subject: Re: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ > On Wed, Aug 22, 2001 at 05:41:31AM +0300, Jari Arkko wrote: > > >This section mentions that the User-Password AVP "MUST be > > >encrypted using of the methods described in [2] or [13]," where > > >[2] is the Base Protocol, and [13] is the CMS Security Application. > > >Of the mechanisms described in the Base Protocol, neither IPsec > > >or TLS deal with encrypting portions of a diameter message, but > > >rather the entire message itself. > > > > In cases where CMS security isn't necessary - such as when a NAS leaves > > e2e security to be handled by local proxy - wouldn't IPsec/TLS encryption > > of the whole packet be sufficient? > > I agree. Although IPSec and/or TLS doesn't cover just portion of the secret, > it may be sufficient in many (non-roaming) installations. > > PatC > From owner-aaa-wg@merit.edu Wed Aug 22 14:56: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 OAA20525 for ; Wed, 22 Aug 2001 14:56:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43C1B9128A; Wed, 22 Aug 2001 14:57:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 115969128B; Wed, 22 Aug 2001 14:57: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 D70109128A for ; Wed, 22 Aug 2001 14:57:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC82C5DDF2; Wed, 22 Aug 2001 14:57:49 -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 C4DDE5DDC2 for ; Wed, 22 Aug 2001 14:57:48 -0400 (EDT) Received: from jariws1 ([62.248.154.197]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010822185747.EYHO24738.fep02-app.kolumbus.fi@jariws1>; Wed, 22 Aug 2001 21:57:47 +0300 Message-ID: <00bc01c12b3c$57a75220$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Kevin Purser" , Cc: "Pat Calhoun" , References: <009601c12a9a$5831e680$869f558a@ew.us.am.ericsson.se> <004b01c12ab3$f3b4a7a0$8a1b6e0a@arenanet.fi> <20010822092340.B16789@charizard.diameter.org> <006201c12b38$5b43fdb0$93a0558a@ew.us.am.ericsson.se> Subject: Re: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ Date: Wed, 22 Aug 2001 21:57:50 +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 > Ok, I was just confused about the wording of the text, which sounded to me > like it was trying to say the AVP alone could be encrypted through the use > of IPsec/TLS, which obviously isn't the case. Guess it's already clear for > everybody else? No, I'm pretty sure we could formulate this in a clearer way. How about this: "The User-Password AVP MUST be encrypted using the methods described in [13], or where [13] isn't applied, the whole DIAMETER message flow MUST be encrypted using IPsec and/or TLS as described in [2]." Jari From owner-aaa-wg@merit.edu Wed Aug 22 15:16: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 PAA21250 for ; Wed, 22 Aug 2001 15:16:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C0E99128C; Wed, 22 Aug 2001 15:17:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EF389128D; Wed, 22 Aug 2001 15:17: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 648829128C for ; Wed, 22 Aug 2001 15:17:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D8585DDF1; Wed, 22 Aug 2001 15:17: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 CE04D5DDC2 for ; Wed, 22 Aug 2001 15:17:24 -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 f7MJHMp15784; Wed, 22 Aug 2001 14:17:22 -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 f7MJHMp09336; Wed, 22 Aug 2001 14:17:22 -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 OAA05775; Wed, 22 Aug 2001 14:17:18 -0500 (CDT) Received: from ericberk107 (rmt160147.am.ericsson.se [138.85.160.147]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id OAA14381; Wed, 22 Aug 2001 14:17:12 -0500 (CDT) Message-ID: <007c01c12b3f$0e746e50$93a0558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Jari Arkko" , Cc: "Pat Calhoun" , References: <009601c12a9a$5831e680$869f558a@ew.us.am.ericsson.se> <004b01c12ab3$f3b4a7a0$8a1b6e0a@arenanet.fi> <20010822092340.B16789@charizard.diameter.org> <006201c12b38$5b43fdb0$93a0558a@ew.us.am.ericsson.se> <00bc01c12b3c$57a75220$8a1b6e0a@arenanet.fi> Subject: Re: [AAA-WG]: New Issue: Prescribed use of encryption in NASREQ Date: Wed, 22 Aug 2001 12:17:10 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > Ok, I was just confused about the wording of the text, which sounded to me > > like it was trying to say the AVP alone could be encrypted through the use > > of IPsec/TLS, which obviously isn't the case. Guess it's already clear for > > everybody else? > > No, I'm pretty sure we could formulate this in a clearer way. > How about this: "The User-Password AVP MUST be > encrypted using the methods described in [13], or where > [13] isn't applied, the whole DIAMETER message flow > MUST be encrypted using IPsec and/or TLS as described > in [2]." > Sounds good to me. > Jari > > > From owner-aaa-wg@merit.edu Thu Aug 23 04:23: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 EAA20455 for ; Thu, 23 Aug 2001 04:23:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 733BF912C8; Thu, 23 Aug 2001 04:24:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40A21912CA; Thu, 23 Aug 2001 04:24:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA159912C8 for ; Thu, 23 Aug 2001 04:24:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD0225DDB2; Thu, 23 Aug 2001 04:24: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 298715DD9C for ; Thu, 23 Aug 2001 04:24:39 -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 f7N8OaK15916; Thu, 23 Aug 2001 10:24:37 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA03959; Thu, 23 Aug 2001 10:24:28 +0200 (MET DST) Message-ID: <3B84BDC3.97FF2F4@rioja.ericsson.se> Date: Thu, 23 Aug 2001 10:24:35 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Revalidation of cache in CMS References: <3B78F93A.27DBBAB3@rioja.ericsson.se> <3B7CFE35.4325274A@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 Hi Stephen, sorry for the latency, but I've hardly had time to review the whole specification. > I agree that the text is a bit vague. I'd suggest adding the > additional text below. Note that this is a "lax" PKI policy > which assumes e.g. that no new (relevant) CRLs are produced > before the nextUpdate field, but I'd argue that that's ok > for Diameter since I wouldn't expect very frequent > revocations in this context. > > The next text should go in below the current text. > > Does this solve the problem? From my humble point of view, just partially. As far as I understand, you're approach is very PKI-centric. I mean, my original question was really about how the "vague" original paragraph should be understood. Let me explain it with some figures. This is the scenario as far as I understood it (before you added your clarification time): __________________________________________________ DSA | ================================== | | | | | beginning of | | | the DSA t1 (any special time | | in which a message | | is issued) | | end of the DSA | t2 (other issued message) What I wanted to assure is that in t1, the implementation may choose not to revalidate the certificates. But in t2, the implementation must revalidate the certificates. This statement wasn't clear (in my oppinion), and I wanted to make it more explicit. You've introduced a very interesting point (more related to PKI). In short, it's the following (please, correct me if I'm wrong): Depending on the parameters of the certificates belonging to the certificate chain (or belongint to the OCSP response or the CRL), a "safe" period with no revocation checks will be computed (I assume that if this safe period is smaller than the length of the DSA, a revocation check must be done once the safe period ends; but in the other hand, if the safe period is bigger than the DSA length, the revalidation must be done once the DSA expires). Additional checks might be done depending on the local PKI policy. My conclusion is that the following paragraph must be changed: Implementations MAY cache the information required to establish a DSA, but MUST honor time-to-live settings and MUST re-validate certificates (possibly including revocation checks) before using cached data. With this paragraph: Implementations MAY cache the information required to establish a DSA. However, they MUST honor time-to-live settings so that certificates MUST re-validated (possibly including revocation checks) once the DSA has expired. Revalidations MIGHT also occur before the DSA expires according to PKI policies. During the process of certificate path validation... and the rest of the contributions by Stephen 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 Aug 23 04:53: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 EAA20654 for ; Thu, 23 Aug 2001 04:53:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 560AE912CA; Thu, 23 Aug 2001 04:54:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23703912CB; Thu, 23 Aug 2001 04:54: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 0766E912CA for ; Thu, 23 Aug 2001 04:54:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFCCD5DDB2; Thu, 23 Aug 2001 04:54: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 3A3945DD9C for ; Thu, 23 Aug 2001 04:54:53 -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 f7N8sov29828; Thu, 23 Aug 2001 10:54:51 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA05795; Thu, 23 Aug 2001 10:54:44 +0200 (MET DST) Message-ID: <3B84C4DB.52034F0E@rioja.ericsson.se> Date: Thu, 23 Aug 2001 10:54: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about AVPs occurrence References: <3B81265A.306918E0@rioja.ericsson.se> <20010820101404.H31100@charizard.diameter.org> <3B814C98.5FC57750@rioja.ericsson.se> <20010820165318.E1924@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: > > hmmmm..... well the message is used to setup the DSA, so I suppose I assumed > that the reader would understand that sending another message, for the purposes > of pushing certs, would cause a rekey to occur. > > Are you then stating that this isn't clear, and additional clarifying text > is required? I'm afraid so (at least IMHO). Furthermore, additional clarifying text is never a bad idea. 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 Aug 23 05:04: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 FAA20725 for ; Thu, 23 Aug 2001 05:04:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 862A0912CB; Thu, 23 Aug 2001 05:05:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 559F4912CD; Thu, 23 Aug 2001 05:05: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 12FBF912CB for ; Thu, 23 Aug 2001 05:05:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE9095DDAF; Thu, 23 Aug 2001 05:05:13 -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 47EE45DD9C for ; Thu, 23 Aug 2001 05:05:13 -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 f7N95AK17760; Thu, 23 Aug 2001 11:05:11 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA06471; Thu, 23 Aug 2001 11:05:04 +0200 (MET DST) Message-ID: <3B84C747.920689F1@rioja.ericsson.se> Date: Thu, 23 Aug 2001 11:05: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: stephen.farrell@baltimore.ie Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Revalidation of cache in CMS (again) References: <3B78F93A.27DBBAB3@rioja.ericsson.se> <3B7CFE35.4325274A@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 Sorry. Some of you might have received this mail badly. I hope this one will be received better... =========================================== Hi Stephen, sorry for the latency, but I've hardly had time to review the whole specification. > I agree that the text is a bit vague. I'd suggest adding the > additional text below. Note that this is a "lax" PKI policy > which assumes e.g. that no new (relevant) CRLs are produced > before the nextUpdate field, but I'd argue that that's ok > for Diameter since I wouldn't expect very frequent > revocations in this context. > > The next text should go in below the current text. > > Does this solve the problem? From my humble point of view, just partially. As far as I understand, you're approach is very PKI-centric. I mean, my original question was really about how the "vague" original paragraph should be understood. Let me explain it with some figures. This is the scenario as far as I understood it (before you added your clarification time): __________________________________________________ DSA | ================================== | | | | | beginning of | | | the DSA t1 (any special time | | in which a message | | is issued) | | end of the DSA | t2 (other issued message) What I wanted to assure is that in t1, the implementation may choose not to revalidate the certificates. But in t2, the implementation must revalidate the certificates. This statement wasn't clear (in my oppinion), and I wanted to make it more explicit. You've introduced a very interesting point (more related to PKI). In short, it's the following (please, correct me if I'm wrong): Depending on the parameters of the certificates belonging to the certificate chain (or belongint to the OCSP response or the CRL), a "safe" period with no revocation checks will be computed (I assume that if this safe period is smaller than the length of the DSA, a revocation check must be done once the safe period ends; but in the other hand, if the safe period is bigger than the DSA length, the revalidation must be done once the DSA expires). Additional checks might be done depending on the local PKI policy. My conclusion is that the following paragraph must be changed: Implementations MAY cache the information required to establish a DSA, but MUST honor time-to-live settings and MUST re-validate certificates (possibly including revocation checks) before using cached data. With this paragraph: Implementations MAY cache the information required to establish a DSA. However, they MUST honor time-to-live settings so that certificates MUST re-validated (possibly including revocation checks) once the DSA has expired. Revalidations MIGHT also occur before the DSA expires according to PKI policies. During the process of certificate path validation... and the rest of the contributions by Stephen 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 Aug 23 05:36: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 FAA21014 for ; Thu, 23 Aug 2001 05:36:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4EC66912CD; Thu, 23 Aug 2001 05:37:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF21F912CE; Thu, 23 Aug 2001 05:37: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 B2D3D912CD for ; Thu, 23 Aug 2001 05:37:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 820795DDA0; Thu, 23 Aug 2001 05:37: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 B1C155DD9C for ; Thu, 23 Aug 2001 05:37:37 -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 f7N9bZK11378 for ; Thu, 23 Aug 2001 11:37:36 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA08484; Thu, 23 Aug 2001 11:37:30 +0200 (MET DST) Message-ID: <3B84CEE1.4144B5A@rioja.ericsson.se> Date: Thu, 23 Aug 2001 11:37: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] Key Management chapter rephrasing 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-23 Reference: Document: CMS-02 Comment type: E Priority: 2 Section: 3.0 Rationale/Explanation of issue: In 3.0 chapter a number of issues are listed in order to provide solutions for them in the rest of 3.x chapters. However, phrases like: "a specific Diameter key distribution mechanism is defined here" "Another issue that must be addressed..." "This section describes..." aren't lucky since there isn't a specific mention to which chapters will actually address the issues. Requested change: Add clarifying phrases in order to state the chapters in which any issue will be addressed. 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 Aug 23 06:06: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 GAA21307 for ; Thu, 23 Aug 2001 06:06:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 08DB7912CE; Thu, 23 Aug 2001 06:06:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C85D5912CF; Thu, 23 Aug 2001 06:06: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 AE557912CE for ; Thu, 23 Aug 2001 06:06:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 868805DDB4; Thu, 23 Aug 2001 06:06:55 -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 721F25DD9C for ; Thu, 23 Aug 2001 06:06:54 -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 f7NA6rK29955 for ; Thu, 23 Aug 2001 12:06:53 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Aug 23 12:06:36 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 12:06:30 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA40@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: [New Issue] Can Answer be rejected? Date: Thu, 23 Aug 2001 12:06:30 +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 Issue: Can Answer be rejected? Submitter name: Martin Julien Submitter email address: martin.julien@ericsson.com Date first submitted: 23/08/01 Reference: Document: Base Comment type: T Priority: 1 Section: Rationale/Explanation of issue: It is not really clear in the draft whether or not answer messages can be rejected. Should it be allowed or not? That needs to be clarified in the draft. From owner-aaa-wg@merit.edu Thu Aug 23 06:13: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 GAA21377 for ; Thu, 23 Aug 2001 06:13:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5AB3912CF; Thu, 23 Aug 2001 06:14:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AB81912D0; Thu, 23 Aug 2001 06:14: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 6EF6A912CF for ; Thu, 23 Aug 2001 06:14:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4762F5DDB4; Thu, 23 Aug 2001 06:14:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BB7FE5DD9C for ; Thu, 23 Aug 2001 06:14:19 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08489; Thu, 23 Aug 2001 04:14:00 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7NAE2N01283; Thu, 23 Aug 2001 12:14:02 +0200 (MET DST) Date: Thu, 23 Aug 2001 12:10:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [AAA-WG]: AAA for IPv6 To: Thomas Eklund Cc: "'Bernard Aboba '" , "'Charlie Perkins '" , "'aaa-wg@merit.edu '" , "'john.loughney@nokia.com '" , "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" In-Reply-To: "Your message with ID" <31A473DBB655D21180850008C71E251A04ECA9E7@mail.kebne.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Bernard, > It was rough consenus on the IPv6 WG meeting that this was something that is > of interest of IPv6 WG and the WG supports that it becomes a AAA WG item. I'm not sure about that one. For one thing the "this" above can have rather different interpretations: - the general problem area - the more specific problem as specified in the draft in question - the solution specified in the draft At the most IPNG discussed the first bullet as I recall. Erik From owner-aaa-wg@merit.edu Thu Aug 23 06:15: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 GAA21405 for ; Thu, 23 Aug 2001 06:15:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 657EF912D0; Thu, 23 Aug 2001 06:16:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1366C912D1; Thu, 23 Aug 2001 06:16: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 C9C04912D0 for ; Thu, 23 Aug 2001 06:16:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B06485DDA0; Thu, 23 Aug 2001 06:16: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 CEC2C5DD9C for ; Thu, 23 Aug 2001 06:16: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 f7NAGHv24950 for ; Thu, 23 Aug 2001 12:16:21 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA10867; Thu, 23 Aug 2001 12:16:13 +0200 (MET DST) Message-ID: <3B84D7F5.B0909F3A@rioja.ericsson.se> Date: Thu, 23 Aug 2001 12:16: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: [AAA-WG]: [issue] OCSP Response request additional text 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: E Priority: 2 Section: 3.1 Rationale/Explanation of issue: An additional clarifying text might be added to depict the way in which OCSP responses are required. Requested change: Replace the following paragraph: If certificate status (revocation) is an issue for the Diameter initiator, then the DSAR message MAY contain a nonce value. The idea is that the sender of the DSAA makes OCSP requests on behalf of the Diameter initiator and returns the OCSP responses to the Diameter initiator as part of the DSAR message. The use of the nonce value ensures that the sender of the DSAA cannot return cached or otherwise fake OCSP responses to the Diameter initiator. with this one: If certificate status is an issue for the Diameter initiator (it has been configured to check if the certificates has not been revoked), then the DSAR message MUST contain a flag indicating that it wishes to receive certificate status information. The DSAR message MAY contain a nonce value (depending on whether the initiator wishes a "fresh" response). The idea is that the sender of the DSAA makes OCSP requests on behalf of the Diameter initiator and returns the OCSP responses to the Diameter node as part of the DSAR message. The use of the nonce value ensures that the sender of the DSAA cannot return cached or otherwise fake OCSP responses to the Diameter node. If the initiator indicated that no fresh response was required (so that no nonce value was provided) it MAY accept a stale response. 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 Aug 23 06: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 GAA21855 for ; Thu, 23 Aug 2001 06:52:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C2221912D1; Thu, 23 Aug 2001 06:53:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9397D912D2; Thu, 23 Aug 2001 06:53: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 6D67B912D1 for ; Thu, 23 Aug 2001 06:52:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40CC35DDC2; Thu, 23 Aug 2001 06:52:59 -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 7C0A55DDB4 for ; Thu, 23 Aug 2001 06:52:58 -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 f7NAquK29798 for ; Thu, 23 Aug 2001 12:52:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA13466; Thu, 23 Aug 2001 12:52:51 +0200 (MET DST) Message-ID: <3B84E08B.D651A1B7@rioja.ericsson.se> Date: Thu, 23 Aug 2001 12:52:59 +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] CEKMaxDecrypts value vs DSA length 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-23 Reference: Document: CMS-02 Comment type: T Priority: S Section: 3.4 Rationale/Explanation of issue: As stated in 6.2, CEK reuse should be supported by Diameter nodes. The description of the open issues left by the "Reuse of CMS CEKs" is done in 3.4. When talking about the maximum number of decryptions allowed it's said that may be higher than 1 (the default value). But, which is the relationship between the maximum number of decryptions and the length of the DSA? I mean, is it possible to reuse a CEK even if the DSA has already expired? 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 Thu Aug 23 06:58: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 GAA21903 for ; Thu, 23 Aug 2001 06:58:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55A59912D2; Thu, 23 Aug 2001 06:59:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F045912D3; Thu, 23 Aug 2001 06: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 F30BB912D2 for ; Thu, 23 Aug 2001 06:59:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA8DA5DDC2; Thu, 23 Aug 2001 06:59:14 -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 0667E5DD9C for ; Thu, 23 Aug 2001 06:59: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 f7NAxBv23469 for ; Thu, 23 Aug 2001 12:59:13 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA13842; Thu, 23 Aug 2001 12:59:06 +0200 (MET DST) Message-ID: <3B84E202.18CCBE76@rioja.ericsson.se> Date: Thu, 23 Aug 2001 12:59:14 +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] Editorial changes in CMS #4 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-08-23 Reference: Document: CMS-02 Comment type: E Priority: 2 Section: 3.1, 3.2, 4.3, 6.2, 11.0 Rationale/Explanation of issue: Requested change: In 3.1 (last line): replace "certicate" with "certificate" In 3.2 (last point in page 12): replace "certificiates" with "certificates" In 3.2 (first item in page 13): replace "certfificates" with "certificates" In 4.3 (title) replace "Assocation" with "Association" In 6.2 (second last paragraph) In order to maintain coherence, replace "content encryption key re-use" with "content encryption key reuse" In 11.0: replace "S/MIME v2 Message Specification" with "S/MIME v2 Message Specification" Regards // M.A. From owner-aaa-wg@merit.edu Thu Aug 23 08:55: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 IAA22855 for ; Thu, 23 Aug 2001 08:55:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56D64912D4; Thu, 23 Aug 2001 08:56:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2051B912D5; Thu, 23 Aug 2001 08:56: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 C60A4912D4 for ; Thu, 23 Aug 2001 08:56:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9DBDD5DDC2; Thu, 23 Aug 2001 08:56:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by segue.merit.edu (Postfix) with ESMTP id B3C7F5DDA0 for ; Thu, 23 Aug 2001 08:56:28 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id f7NCuRT17737 for ; Thu, 23 Aug 2001 14:56:27 +0200 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id OAA24742 for ; Thu, 23 Aug 2001 14:56:26 +0200 (MET DST) Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta) id xma020513; Thu, 23 Aug 01 14:55:02 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 14:55:01 +0200 Message-ID: From: Klausberger Walter To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter implementation Date: Thu, 23 Aug 2001 14:55:00 +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, are there any diameter implementations freely available for testing (eg.: under LINUX)? We plan to do a diameter client with a NAS application at first and need a server to test against. regards - walter From owner-aaa-wg@merit.edu Thu Aug 23 09: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 JAA23396 for ; Thu, 23 Aug 2001 09:41:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D67A912DA; Thu, 23 Aug 2001 09:41:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B5D6912D7; Thu, 23 Aug 2001 09:41: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 D81CC912DA for ; Thu, 23 Aug 2001 09:41:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFA335DDD0; Thu, 23 Aug 2001 09:41: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 BC9D05DDA0 for ; Thu, 23 Aug 2001 09:41: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 f7NDf1K25315 for ; Thu, 23 Aug 2001 15:41:02 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA24065; Thu, 23 Aug 2001 15:40:56 +0200 (MET DST) Message-ID: <3B8507F1.2FA720FC@rioja.ericsson.se> Date: Thu, 23 Aug 2001 15:41: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] OCSP Support 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-23 Reference: Issue 125 (Inconsistency in OCSP-Responses AVP) Document: CMS-02 Comment type: T Priority: S Section: Rationale/Explanation of issue: The specification doesn't mention which level of requirement OCSP has. When reading the specification, I've found that OCSP may be used with two different purposes: - Certificate validation in order to decide if a certificate in cache can be used or not. - Certificate validation on behalf of other DSA participant. Although the purposes is different, the implementation would be the same. However, how mandatory is the OCSP support? The specification itself only seems to talk about the first purpose (6.3) by saying: Optionally, the Diameter node MAY check the status of certificates using another mechanism, such as Online Certificate Status Protocol (OCSP) [9]. According to this paragraph, OCSP support is optional. However, when discussing about issue 125, we reached an agreement by which OCSP-Responses AVP in DSAA is optional. I've got two concerns: - Does a Diameter implementation supporting CMS Sec have to support online and CRL validation functionality? Is it mandatory to support one, both? Is it optional? - What happens when after a DSAR requesting an OCSP response arrives to a Diameter node that doesn't support OCSP? I suppose than no OCSP-Responses AVP is included in the DSAA, so that the iniciator deduces that OCSP isn't supported. Requested change: Including a paragraph stating which certificate validation mechanisms must support a CMS-compliant and how mandatory they are. Adding a sentence to the first paragraph of page 12 (3.1) saying something like: If the sender of the DSAA does not support OCSP, it would simply return a DSAA without any OCSP-Responses 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 Thu Aug 23 13:16: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 NAA27555 for ; Thu, 23 Aug 2001 13:16:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB7B9912E7; Thu, 23 Aug 2001 13:16:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93177912ED; Thu, 23 Aug 2001 13:16: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 76F42912E7 for ; Thu, 23 Aug 2001 13:16:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 559A95DDAA; Thu, 23 Aug 2001 13:16:36 -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 114185DDA3 for ; Thu, 23 Aug 2001 13:16:36 -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 f7NHGZ512751 for ; Thu, 23 Aug 2001 12:16:35 -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 f7NHGZU15735 for ; Thu, 23 Aug 2001 12:16:35 -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 MAA25322; Thu, 23 Aug 2001 12:16:34 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA26105; Thu, 23 Aug 2001 12:16:29 -0500 (CDT) Message-ID: <3B85389F.A9C9BFC8@ericsson.com> Date: Thu, 23 Aug 2001 10:08:48 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: [New Issue] Can Answer be rejected? References: <577066326047D41180AC00508B955DDA04D1AA40@eestqnt104.es.eu.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 Martin, I believe that we already have an issue on this, which will go in to base -08. It's part of issue 107 in the issue list.. /Tony Issue 107: More editorial comments Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: July 31th, 2001 Reference: N/A Document: base Comment type: E Priority: 2 Section: Rationale/Explanation of issue: .... Page 68, section 6.2.2, 3rd and 4th paragraph: “If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. The agent MUST then send the answer to the host which it received the original request from.” The above paragraph needs to better clarify what the relay/proxy agent sends back to the access device. Suggested change: “If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. The agent MUST then send the answer to the access device with the modified Result-Code AVP indicating the error and MUST also add the Error-Reporting-Host AVP, which will contain the identity of this agent.” ..... "Martin Julien (ECE)" wrote: > Issue: Can Answer be rejected? > Submitter name: Martin Julien > Submitter email address: martin.julien@ericsson.com > Date first submitted: 23/08/01 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > > It is not really clear in the draft whether or not answer > messages can be rejected. Should it be allowed or not? > > That needs to be clarified in the draft. From owner-aaa-wg@merit.edu Thu Aug 23 14: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 OAA28806 for ; Thu, 23 Aug 2001 14:32:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82695912ED; Thu, 23 Aug 2001 14:33:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 541AD912EF; Thu, 23 Aug 2001 14:33: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 5E16C912ED for ; Thu, 23 Aug 2001 14:32:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 293505DDFF; Thu, 23 Aug 2001 14:32:49 -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 686585DDFB for ; Thu, 23 Aug 2001 14:32:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA22481; Thu, 23 Aug 2001 11:25:00 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 23 Aug 2001 11:25:00 -0700 (PDT) From: Bernard Aboba To: =?iso-8859-1?q?Harold=20De=20Dios?= Cc: Erik Nordmark , Thomas Eklund , "'Charlie Perkins '" , "'aaa-wg@merit.edu '" , "'john.loughney@nokia.com '" , "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <20010823180408.39823.qmail@web14908.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Please take this to the Cisco TAC, rather than spamming multiple IETF mailing lists. On Thu, 23 Aug 2001, [iso-8859-1] Harold De Dios wrote: > > Hi i have been having troubles whit a cisco 3640, > i installed cisco IOS image 12.2T. From owner-aaa-wg@merit.edu Thu Aug 23 15:13: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 PAA29600 for ; Thu, 23 Aug 2001 15:13:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77A96912EF; Thu, 23 Aug 2001 15:14:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B52E912F0; Thu, 23 Aug 2001 15:14: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 41680912EF for ; Thu, 23 Aug 2001 15:14:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E63C5DDA3; Thu, 23 Aug 2001 15:14:23 -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 3D9685DDA0 for ; Thu, 23 Aug 2001 15:14:22 -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 PAA15397; Thu, 23 Aug 2001 15:12:49 -0400 (EDT) Date: Thu, 23 Aug 2001 15:14:37 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: tony.johannson@ericsson.com, kevin.purser@ericsson.com Cc: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Bake-off Test specification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Tony, Kevin, How soon will the Diameter Bake-off Test Specification be available at http://standards.ericsson.net/diameter-bake-off/? Thanks, -mark From owner-aaa-wg@merit.edu Thu Aug 23 16:22: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 QAA00831 for ; Thu, 23 Aug 2001 16:22:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 94641912F0; Thu, 23 Aug 2001 16:23:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57C1D912F1; Thu, 23 Aug 2001 16:23: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 3D9C6912F0 for ; Thu, 23 Aug 2001 16:23:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F6495DDA3; Thu, 23 Aug 2001 16:23:04 -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 C203A5DD93 for ; Thu, 23 Aug 2001 16:23:03 -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 f7NKN3518495; Thu, 23 Aug 2001 15:23:03 -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 f7NKN3p13994; Thu, 23 Aug 2001 15:23:03 -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 PAA03354; Thu, 23 Aug 2001 15:23:02 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA28224; Thu, 23 Aug 2001 15:22:57 -0500 (CDT) Message-ID: <3B856452.A13CF7D9@ericsson.com> Date: Thu, 23 Aug 2001 13:15:14 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: kevin.purser@ericsson.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Bake-off Test specification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, We are working on it right now and we hope to have something ready next week. Regards, /Tony Mark Eklund wrote: > Tony, Kevin, > > How soon will the Diameter Bake-off Test Specification be > available at http://standards.ericsson.net/diameter-bake-off/? > > Thanks, > > -mark From owner-aaa-wg@merit.edu Fri Aug 24 03:34: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 DAA26828 for ; Fri, 24 Aug 2001 03:34:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EE0B9131B; Fri, 24 Aug 2001 03:33:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 533F391319; Fri, 24 Aug 2001 03:33: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 2214491317 for ; Fri, 24 Aug 2001 03:33:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6F585DDC1; Fri, 24 Aug 2001 03:33: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 1F4DB5DD98 for ; Fri, 24 Aug 2001 03:33:44 -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 f7O7Xhv20832 for ; Fri, 24 Aug 2001 09:33:43 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Aug 24 09:33:36 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 09:33:42 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Tony Johansson'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: [New Issue] Can Answer be rejected? Date: Fri, 24 Aug 2001 09:33:38 +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 Hej Tony, I was aware of that issue, but it remains unclear in the draft whether or not an answer could be rejected (E) back towards the originator of the answer? In other words, when a client sends a request, it can be rejected by any of the agents towards the Home, or even the home itself, of course. In such a case, the message will have the R bit cleared, and the E bit set, and will be sent to the client. However, when the Home answers the request without indicating an error (in the Answer message), is there any possibilities that the client or any agents decide to reject the Answer, by returning it with the E bit set towards the Home, instead of the client? From what I understand now, that should not be possible, meaning that a message with the E bit set should ONLY be directed towards clients, in response to a request. Do I understand it correctly? My confusion is that, as far as I remember, it used to be possible a few months back. However, I much prefer the Home to receive an STR in that case, like it seems to be suggested now. If some clear statements on that could be added to the draft, it would be perfect. Cheers, Martin > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Thursday, August 23, 2001 7:09 PM > To: Martin Julien (ECE) > Cc: 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: [New Issue] Can Answer be rejected? > > > Martin, > > I believe that we already have an issue on this, which will go in to > base -08. It's part of issue 107 in the issue list.. > > /Tony > > Issue 107: More editorial comments > Submitter name: Tony Johansson > Submitter email address: tony.johansson@ericsson.com > Date first submitted: July 31th, 2001 > Reference: N/A > Document: base > Comment type: E > Priority: 2 > Section: > Rationale/Explanation of issue: > > .... > > Page 68, section 6.2.2, 3rd and 4th paragraph: > "If the agent receives an answer message with a Result-Code AVP > indicating success, and it wishes to modify the AVP to indicate an > error, it MUST issue an STR on behalf of the access device. The agent > MUST then send the answer to the host which it received the original > request from." > > The above paragraph needs to better clarify what the relay/proxy agent > sends back to the access device. > > Suggested change: > "If the agent receives an answer message with a Result-Code AVP > indicating success, and it wishes to modify the AVP to indicate an > error, it MUST issue an STR on behalf of the access device. The agent > MUST then send the answer to the access device with the modified > Result-Code AVP indicating the error and MUST also add the > Error-Reporting-Host AVP, which will contain the identity of this > agent." > > ..... > > > > "Martin Julien (ECE)" wrote: > > > Issue: Can Answer be rejected? > > Submitter name: Martin Julien > > Submitter email address: martin.julien@ericsson.com > > Date first submitted: 23/08/01 > > Reference: > > Document: Base > > Comment type: T > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > It is not really clear in the draft whether or not answer > > messages can be rejected. Should it be allowed or not? > > > > That needs to be clarified in the draft. > From owner-aaa-wg@merit.edu Fri Aug 24 08:53: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 IAA03808 for ; Fri, 24 Aug 2001 08:53:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 676E69120A; Fri, 24 Aug 2001 08:54:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B6C99120C; Fri, 24 Aug 2001 08:54:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E86609120A for ; Fri, 24 Aug 2001 08:54:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B52005DD8C; Fri, 24 Aug 2001 08:54:14 -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 D6D665DDC3 for ; Fri, 24 Aug 2001 08:54:13 -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 f7OCsCv08624 for ; Fri, 24 Aug 2001 14:54:12 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA08351; Fri, 24 Aug 2001 14:54:09 +0200 (MET DST) Message-ID: <3B864E7F.ED9658FB@rioja.ericsson.se> Date: Fri, 24 Aug 2001 14:54:23 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [issue] Order in CMS-proxy messages 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-24 Reference: Document: Base-07, CMS-02 Comment type: T Priority: S Section: (base) 2.7, (CMS) 6.2 Rationale/Explanation of issue: As stated in (base) 2.7: Relay agents MUST NOT reorder AVPs, and proxies SHOULD NOT reorder AVPs. However, in (CMS) 6.2: All AVPs to be encrypted are concatenated, and the encryptor is free to order AVPs in whatever way it chooses. My deduction is that the encryption of AVPs in a proxy acting as a CMS proxy on behalf of a client would break the requirement in (base) 2.7 since the receiver would never know which order was the original (of course that route-related AVPs are not encryptable, so that its order would never change). Requested change: To rephrase the requirement in (base) 2.7 in order to take into account what is stated in (CMS) 6.2 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 Aug 24 10:52: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 KAA06290 for ; Fri, 24 Aug 2001 10:52:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1BAE191226; Fri, 24 Aug 2001 10:53:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7A9991228; Fri, 24 Aug 2001 10:53: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 B0F5091226 for ; Fri, 24 Aug 2001 10:53:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8078F5DDCE; Fri, 24 Aug 2001 10:53:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 37B8D5DDCB for ; Fri, 24 Aug 2001 10:53:33 -0400 (EDT) Received: (qmail 7933 invoked by uid 500); 24 Aug 2001 14:41:22 -0000 Date: Fri, 24 Aug 2001 07:41:22 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Tony Johansson'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: [New Issue] Can Answer be rejected? Message-ID: <20010824074122.A7919@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Tony Johansson' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA43@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: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Fri, Aug 24, 2001 at 09:33:38AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Aug 24, 2001 at 09:33:38AM +0200, Martin Julien (ECE) wrote: > Hej Tony, > > I was aware of that issue, but it remains unclear in the > draft whether or not an answer could be rejected (E) back > towards the originator of the answer? so perhaps a simple sentence is needed here. > > In other words, when a client sends a request, it can be > rejected by any of the agents towards the Home, or even > the home itself, of course. In such a case, the message will > have the R bit cleared, and the E bit set, and will be > sent to the client. > > However, when the Home answers the request without > indicating an error (in the Answer message), is there > any possibilities that the client or any agents decide to > reject the Answer, by returning it with the E bit set > towards the Home, instead of the client? the state machine makes this quite clear in the following: Pending Error processing successful Sent STR Discon Service-Specific authorization answer > > From what I understand now, that should not be possible, > meaning that a message with the E bit set should ONLY be > directed towards clients, in response to a request. > Do I understand it correctly? a request can be initiated by a server, so your statement is incorrect. However, you are correct that the 'E' bit is only sent in response to a request. > My confusion is that, as far as I remember, it used to be > possible a few months back. Not to my knowledge. There were some discussions on the list, but we never introduced a three way handshake. > However, I much prefer the > Home to receive an STR in that case, like it seems to be > suggested now. correct. That's what the state machine says. > If some clear statements on that could be added to the > draft, it would be perfect. ok PatC From owner-aaa-wg@merit.edu Fri Aug 24 12:56: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 MAA09476 for ; Fri, 24 Aug 2001 12:56:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD3C191235; Fri, 24 Aug 2001 12:57:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 891B191240; Fri, 24 Aug 2001 12:57: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 B42FE91235 for ; Fri, 24 Aug 2001 12:57:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 948085DDA9; Fri, 24 Aug 2001 12:57:33 -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 235D55DD98 for ; Fri, 24 Aug 2001 12:57:33 -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 f7OGvW526460 for ; Fri, 24 Aug 2001 11:57:32 -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 f7OGvWr19801 for ; Fri, 24 Aug 2001 11:57:32 -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 LAA16112 for ; Fri, 24 Aug 2001 11:57:31 -0500 (CDT) Received: from ericberk107 ([138.85.159.134]) by pop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id LAA08836 for ; Fri, 24 Aug 2001 11:57:27 -0500 (CDT) Message-ID: <001901c12cbd$dd1b75d0$869f558a@ew.us.am.ericsson.se> From: "Kevin Purser" To: References: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se> <20010824074122.A7919@charizard.diameter.org> Subject: [AAA-WG]: Question about Chap-Password AVP Date: Fri, 24 Aug 2001 09:57:27 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Regarding NASREQ-07, I am aware that the Chap-Password AVP will be re-written as a grouped AVP (as per issue #115) in the next version of the spec, which will most likely include an AVP to indicate the CHAP identifier. I wanted to ask if this new grouped AVP would also include an additional AVP to indicate the algorithm used in calculation of the password. This additional AVP would correspond to the Algorithm field of the authentication-protocol configuration option packet as specified in section 3 of RFC 1994-PPP Challenge Handshake Authentication Protocol. Kev From owner-aaa-wg@merit.edu Fri Aug 24 13:40: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 NAA10591 for ; Fri, 24 Aug 2001 13:40:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F45F91232; Fri, 24 Aug 2001 13:41:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D34391240; Fri, 24 Aug 2001 13:41: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 22F0F91232 for ; Fri, 24 Aug 2001 13:41:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F249B5DDB0; Fri, 24 Aug 2001 13:41:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 91AC85DDC5 for ; Fri, 24 Aug 2001 13:41:14 -0400 (EDT) Received: (qmail 8412 invoked by uid 500); 24 Aug 2001 17:29:03 -0000 Date: Fri, 24 Aug 2001 10:29:03 -0700 From: Pat Calhoun To: Kevin Purser Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about Chap-Password AVP Message-ID: <20010824102903.F8333@charizard.diameter.org> Mail-Followup-To: Kevin Purser , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se> <20010824074122.A7919@charizard.diameter.org> <001901c12cbd$dd1b75d0$869f558a@ew.us.am.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001901c12cbd$dd1b75d0$869f558a@ew.us.am.ericsson.se>; from kevin.purser@ericsson.com on Fri, Aug 24, 2001 at 09:57:27AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Regarding NASREQ-07, I am aware that the Chap-Password AVP will be > re-written as a grouped AVP (as per issue #115) in the next version of the > spec, which will most likely include an AVP to indicate the CHAP identifier. Correct. The text is as follows: 3.1.1.2 CHAP-Auth AVP The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains the information necessary to authenticate a user using the PPP Challenge-Handshake Authentication Protocol (CHAP) [6]. If the CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see section 3.1.1.5) MUST be present as well. Its Data field has the following ABNF grammar: CHAP-Auth ::= < AVP Header: TBD > { CHAP-Ident } { CHAP-Response } 3.1.1.3 CHAP-Ident AVP The CHAP-Ident AVP (AVP Code 410) is of type OctetString and contains the one octet CHAP Identifier used in the computation of the CHAP response [6]. 3.1.1.4 CHAP-Response AVP The CHAP-Response AVP (AVP Code 411) is of type OctetString and contains the 16 octet authentication data provided by the user in response to the CHAP challenge [16]. The actual computation of the CHAP response can be found in [6]. > I wanted to ask if this new grouped AVP would also include an additional AVP > to indicate the algorithm used in calculation of the password. This > additional AVP would correspond to the Algorithm field of the > authentication-protocol configuration option packet as specified in section > 3 of RFC 1994-PPP Challenge Handshake Authentication Protocol. CHAP has been in use for many years (well, at least since 96), and to date there has yet been any new algorithms defined for CHAP. I would argue that any new auth schemes are being defined for EAP, and not CHAP. Therefore, I don't see a need to support this AVP at this time. PatC > > Kev > From owner-aaa-wg@merit.edu Fri Aug 24 14:02: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 OAA11192 for ; Fri, 24 Aug 2001 14:02:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A6A1B91240; Fri, 24 Aug 2001 14:03:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 704C391241; Fri, 24 Aug 2001 14:03: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 6C44391240 for ; Fri, 24 Aug 2001 14:03:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DFE25DDC5; Fri, 24 Aug 2001 14:03:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by segue.merit.edu (Postfix) with ESMTP id 7F1A45DDB4 for ; Fri, 24 Aug 2001 14:03:16 -0400 (EDT) Received: (from barney@localhost) by tp.databus.com (8.11.4/8.11.4) id f7OI3Fs31321 for aaa-wg@merit.edu; Fri, 24 Aug 2001 14:03:15 -0400 (EDT) (envelope-from barney) Date: Fri, 24 Aug 2001 14:03:10 -0400 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about Chap-Password AVP Message-ID: <20010824140310.A31256@tp.databus.com> References: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se> <20010824074122.A7919@charizard.diameter.org> <001901c12cbd$dd1b75d0$869f558a@ew.us.am.ericsson.se> <20010824102903.F8333@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: <20010824102903.F8333@charizard.diameter.org>; from pcalhoun@diameter.org on Fri, Aug 24, 2001 at 10:29:03AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, if CHAP-Auth is now grouped, why not move the challenge into it? When would a challenge ever be present without the response? MS-CHAP does exist and (unless I'm misremembering) does use a different algorithm id. Sure it's not standard, but it is at least documented. Regards, Barney From owner-aaa-wg@merit.edu Fri Aug 24 14:31: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 OAA11969 for ; Fri, 24 Aug 2001 14:31:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C76C291241; Fri, 24 Aug 2001 14:32:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57C6E91242; Fri, 24 Aug 2001 14:32: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 14D1591241 for ; Fri, 24 Aug 2001 14:32:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D22E45DDB4; Fri, 24 Aug 2001 14:32:55 -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 51DD45DDB0 for ; Fri, 24 Aug 2001 14:32:55 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22730; Fri, 24 Aug 2001 11:32:49 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26824; Fri, 24 Aug 2001 14:32:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.6+Sun/8.11.6) id f7OIXYY05546; Fri, 24 Aug 2001 14:33:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15238.40446.67772.672933@gargle.gargle.HOWL> Date: Fri, 24 Aug 2001 14:33:34 -0400 (EDT) From: James Carlson To: Barney Wolff Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about Chap-Password AVP In-Reply-To: Barney Wolff's message of 24 August 2001 14:03:10 References: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se> <20010824074122.A7919@charizard.diameter.org> <001901c12cbd$dd1b75d0$869f558a@ew.us.am.ericsson.se> <20010824102903.F8333@charizard.diameter.org> <20010824140310.A31256@tp.databus.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barney Wolff writes: > Pat, if CHAP-Auth is now grouped, why not move the challenge into it? > When would a challenge ever be present without the response? > > MS-CHAP does exist and (unless I'm misremembering) does use a different > algorithm id. It does. In fact, it uses two -- 0x80 for MS-CHAPv1 and 0x81 for MS-CHAPv2. > Sure it's not standard, but it is at least documented. Yep: Informational RFC 2433 for MS-CHAPv1 and 2759 for MS-CHAPv2. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-aaa-wg@merit.edu Fri Aug 24 17: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 RAA15846 for ; Fri, 24 Aug 2001 17:25:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2251591245; Fri, 24 Aug 2001 17:26:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E435D91246; Fri, 24 Aug 2001 17:26:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D804C91245 for ; Fri, 24 Aug 2001 17:26:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD7295DDD5; Fri, 24 Aug 2001 17:26: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 69A425DD8C for ; Fri, 24 Aug 2001 17:26:21 -0400 (EDT) Received: (qmail 9589 invoked by uid 500); 24 Aug 2001 21:14:09 -0000 Date: Fri, 24 Aug 2001 14:14:09 -0700 From: Pat Calhoun To: James Carlson Cc: Barney Wolff , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about Chap-Password AVP Message-ID: <20010824141409.E9512@charizard.diameter.org> Mail-Followup-To: James Carlson , Barney Wolff , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA43@eestqnt104.es.eu.ericsson.se> <20010824074122.A7919@charizard.diameter.org> <001901c12cbd$dd1b75d0$869f558a@ew.us.am.ericsson.se> <20010824102903.F8333@charizard.diameter.org> <20010824140310.A31256@tp.databus.com> <15238.40446.67772.672933@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15238.40446.67772.672933@gargle.gargle.HOWL>; from james.d.carlson@east.sun.com on Fri, Aug 24, 2001 at 02:33:34PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Right, but there are separate RADIUS attributes for use with MS-CHAPn. These same attributes could be used in Diameter as well, right? Is there any additional work really required? PatC On Fri, Aug 24, 2001 at 02:33:34PM -0400, James Carlson wrote: > Barney Wolff writes: > > Pat, if CHAP-Auth is now grouped, why not move the challenge into it? > > When would a challenge ever be present without the response? > > > > MS-CHAP does exist and (unless I'm misremembering) does use a different > > algorithm id. > > It does. In fact, it uses two -- 0x80 for MS-CHAPv1 and 0x81 for > MS-CHAPv2. > > > Sure it's not standard, but it is at least documented. > > Yep: Informational RFC 2433 for MS-CHAPv1 and 2759 for MS-CHAPv2. > > -- > James Carlson, Solaris Networking > SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-aaa-wg@merit.edu Sun Aug 26 20:30:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16785 for ; Sun, 26 Aug 2001 20:30:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D96391206; Sun, 26 Aug 2001 20:30:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D84891208; Sun, 26 Aug 2001 20:30: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 F350E91206 for ; Sun, 26 Aug 2001 20:30:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2E405DDD7; Sun, 26 Aug 2001 20:30:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 5A65F5DDC9 for ; Sun, 26 Aug 2001 20:30:21 -0400 (EDT) Received: from gwzpc (sjc-vpn1-159.cisco.com [10.21.96.159]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA29305; Sun, 26 Aug 2001 17:29:38 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Kevin Purser" Cc: Subject: RE: [AAA-WG]: Question about Chap-Password AVP Date: Sun, 26 Aug 2001 17:29:35 -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 In-Reply-To: <20010824102903.F8333@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@diameter.org] writes: > > Regarding NASREQ-07, I am aware that the Chap-Password AVP will be > > re-written as a grouped AVP (as per issue #115) in the next > version of the > > spec, which will most likely include an AVP to indicate the > CHAP identifier. > > Correct. The text is as follows: > > 3.1.1.2 CHAP-Auth AVP > > The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains > the information necessary to authenticate a user using the > PPP Challenge-Handshake Authentication Protocol (CHAP) [6]. If the > CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see > section 3.1.1.5) MUST be present as well. Its Data field has the > following ABNF grammar: > > CHAP-Auth ::= < AVP Header: TBD > > { CHAP-Ident } > { CHAP-Response } > > > 3.1.1.3 CHAP-Ident AVP > > The CHAP-Ident AVP (AVP Code 410) is of type OctetString and > contains the one octet CHAP Identifier used in the computation > of the CHAP response [6]. > > > 3.1.1.4 CHAP-Response AVP > > The CHAP-Response AVP (AVP Code 411) is of type OctetString and > contains the 16 octet authentication data provided by the user > in response to the CHAP challenge [16]. The actual computation of > the CHAP response can be found in [6]. > > > I wanted to ask if this new grouped AVP would also include an > additional AVP > > to indicate the algorithm used in calculation of the password. This > > additional AVP would correspond to the Algorithm field of the > > authentication-protocol configuration option packet as > specified in section > > 3 of RFC 1994-PPP Challenge Handshake Authentication Protocol. > > CHAP has been in use for many years (well, at least since 96), and to date > there has yet been any new algorithms defined for CHAP. True, but why not future-proof Diameter? After all, RC4 was beleived to be fairly secure until recently; what if something similar happens WRT MD5? I would also include the Chap-Challenge in this group, for that matter... > I would argue that > any new auth schemes are being defined for EAP, and not CHAP. Therefore, I > don't see a need to support this AVP at this time. > > PatC > > > > Kev > > > From owner-aaa-wg@merit.edu Sun Aug 26 20:46: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 UAA16889 for ; Sun, 26 Aug 2001 20:46:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 823FA91208; Sun, 26 Aug 2001 20:47:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5054A9121B; Sun, 26 Aug 2001 20:47: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 3336191208 for ; Sun, 26 Aug 2001 20:47:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F069F5DDDF; Sun, 26 Aug 2001 20:47: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 47B625DDC9 for ; Sun, 26 Aug 2001 20:47:23 -0400 (EDT) Received: (qmail 22236 invoked by uid 500); 27 Aug 2001 00:35:04 -0000 Date: Sun, 26 Aug 2001 17:35:04 -0700 From: Pat Calhoun To: Glen Zorn Cc: Pat Calhoun , Kevin Purser , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Question about Chap-Password AVP Message-ID: <20010826173504.A22226@charizard.diameter.org> Mail-Followup-To: Glen Zorn , Pat Calhoun , Kevin Purser , aaa-wg@merit.edu References: <20010824102903.F8333@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gwz@cisco.com on Sun, Aug 26, 2001 at 05:29:35PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk ok, I will work out the details of adding an algorithm ID, and will post the result early this week. PatC On Sun, Aug 26, 2001 at 05:29:35PM -0700, Glen Zorn wrote: > Pat Calhoun [mailto:pcalhoun@diameter.org] writes: > > > > Regarding NASREQ-07, I am aware that the Chap-Password AVP will be > > > re-written as a grouped AVP (as per issue #115) in the next > > version of the > > > spec, which will most likely include an AVP to indicate the > > CHAP identifier. > > > > Correct. The text is as follows: > > > > 3.1.1.2 CHAP-Auth AVP > > > > The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains > > the information necessary to authenticate a user using the > > PPP Challenge-Handshake Authentication Protocol (CHAP) [6]. If the > > CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see > > section 3.1.1.5) MUST be present as well. Its Data field has the > > following ABNF grammar: > > > > CHAP-Auth ::= < AVP Header: TBD > > > { CHAP-Ident } > > { CHAP-Response } > > > > > > 3.1.1.3 CHAP-Ident AVP > > > > The CHAP-Ident AVP (AVP Code 410) is of type OctetString and > > contains the one octet CHAP Identifier used in the computation > > of the CHAP response [6]. > > > > > > 3.1.1.4 CHAP-Response AVP > > > > The CHAP-Response AVP (AVP Code 411) is of type OctetString and > > contains the 16 octet authentication data provided by the user > > in response to the CHAP challenge [16]. The actual computation of > > the CHAP response can be found in [6]. > > > > > I wanted to ask if this new grouped AVP would also include an > > additional AVP > > > to indicate the algorithm used in calculation of the password. This > > > additional AVP would correspond to the Algorithm field of the > > > authentication-protocol configuration option packet as > > specified in section > > > 3 of RFC 1994-PPP Challenge Handshake Authentication Protocol. > > > > CHAP has been in use for many years (well, at least since 96), and to date > > there has yet been any new algorithms defined for CHAP. > > True, but why not future-proof Diameter? After all, RC4 was beleived to be > fairly secure until recently; what if something similar happens WRT MD5? I > would also include the Chap-Challenge in this group, for that matter... > > > I would argue that > > any new auth schemes are being defined for EAP, and not CHAP. Therefore, I > > don't see a need to support this AVP at this time. > > > > PatC > > > > > > Kev > > > > > > From owner-aaa-wg@merit.edu Mon Aug 27 10:43: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 KAA20421 for ; Mon, 27 Aug 2001 10:43:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 777D691230; Mon, 27 Aug 2001 10:44:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F45291231; Mon, 27 Aug 2001 10:44:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22B4D91230 for ; Mon, 27 Aug 2001 10:44:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 000575DDE9; Mon, 27 Aug 2001 10:44: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 AF8095DDE7 for ; Mon, 27 Aug 2001 10:44:36 -0400 (EDT) Received: (qmail 24043 invoked by uid 500); 27 Aug 2001 14:32:16 -0000 Date: Mon, 27 Aug 2001 07:32:16 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 132: Multiple signatures on a set of AVPs Message-ID: <20010827073216.C23877@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 original issue included the following proposed text: "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. This attribute MUST be always unsigned." I have two comments. First, I'd like to propose the following text instead (a slight variation from the above): "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. This attribute MUST be always unsigned. " My second comment has to do with the last sentence. What exactly is the attribute that must be unsigned? Does this mean unsigned as in how the field is treated (meaning most significant bit is part of the value), or rather that the attribute doesn't include a digital signature? If the latter, then the text reads that the countersignature attribute requires a signature, but it is unsigned. confused PatC From owner-aaa-wg@merit.edu Mon Aug 27 10:50: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 KAA20634 for ; Mon, 27 Aug 2001 10:50:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9072891231; Mon, 27 Aug 2001 10:51:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 502819123C; Mon, 27 Aug 2001 10:51: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 39B9091231 for ; Mon, 27 Aug 2001 10:51:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 178F55DDE9; Mon, 27 Aug 2001 10:51: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 C3FDB5DE0E for ; Mon, 27 Aug 2001 10:51:09 -0400 (EDT) Received: (qmail 24092 invoked by uid 500); 27 Aug 2001 14:38:49 -0000 Date: Mon, 27 Aug 2001 07:38:49 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 133: digest value within CMS-Signed-Data AVP Message-ID: <20010827073849.D23877@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk The proposed text reads: "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 in the SingerInfo value. This attribute MUST be always signed." What attribute must be signed, and are we talking about digital signatures, or the format of the field? PatC From owner-aaa-wg@merit.edu Mon Aug 27 11:23: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 LAA21554 for ; Mon, 27 Aug 2001 11:23:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0D789125E; Mon, 27 Aug 2001 11:24:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B27609125F; Mon, 27 Aug 2001 11:24: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 9A1CA9125E for ; Mon, 27 Aug 2001 11:24:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 716A55DDE9; Mon, 27 Aug 2001 11:24:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id 9523C5DDE5 for ; Mon, 27 Aug 2001 11:24:24 -0400 (EDT) Received: from cc.hut.fi (root@gamma.hut.fi [130.233.224.52]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id SAA97739; Mon, 27 Aug 2001 18:24:10 +0300 (EEST) Message-ID: <3B8A68A0.677B647D@cc.hut.fi> Date: Mon, 27 Aug 2001 18:34:56 +0300 From: Tom =?iso-8859-1?Q?Weckstr=F6m?= Organization: HUT/TKK X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20smp i686) X-Accept-Language: fi,sv,de MIME-Version: 1.0 To: gwz@cisco.com Cc: John Schnizlein , Bernard Aboba , Randy Bush , aaa-wg@merit.edu Subject: Re: [AAA-WG]: WECA 'extending' RADIUS? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello folks. I digged this thread from my ancient-old unread AAA emails. Has there been any more news on the WISPr and its adventures lately? Is there any draft specs available inside or outside WECA? What is the timeframe for this project? Have anyone of the AAA WG members been in contact or otherwise involved in the WISPr work? Best Regards, Tom Glen Zorn wrote: > > John Schnizlein [mailto:jschnizl@cisco.com] writes: > > > What is the fuss about? > > The reporter discovered that using RADIUS accounting for 802.11b > > wireless access exploits the benefits built into it for dial access. > > Nice of him to notice, but not a technology breakthrough. > > If it was just the reporter it wouldn't bother me, but it seems that WISPr > itself is on a voyage of discovery through laboriously charted lands... > > > > > The article does not mention any extensions to RADIUS, > > it simply describes a new use of RADIUS, especially its capability > > for global roaming through what we have been calling proxy forwarding. > > The "tag" the article mentions is just the home domain. > > >From the article: > > "Specifically, WISPr is looking to define a tag that users could tack onto > their subscriber name. > ^^^^^^ > The tag will alert any WISP that the user requesting service is "owned" by > some other provider." > > RFC 2486. > > > > > The discussion about the importance of billing might create the > > impression of something new, but it looks like RADIUS accounting to me. > > And clearinghouse technology for RADIUS accounting has been used for > > PPP and voice calls, so this is not new either. > > >From the article, again: > '"The billing systems are key to this," Homan said. "We're extending the > RADIUS protocol with specific [new] attributes, such as user name, time > spent online, bytes in or out, and so on. We'll also have information about > where the user is, through a location code, so we can return site-specific > services to that user.' > > Of these, the only thing that is new is the "location code" (which poses > significant privacy issues, BTW). Note that this quote is from a WISPr > "spokesman", not the reporter. Although it's certainly possible that he was > misquoted, if this statement is close to accurate we have people "extending" > the RADIUS protocol with "features" already present in it... > > > > > Considering who has chimed in on this thread, > > I am now wearing my flame-retardant shorts. ;-) > > > > John > > > > At 11:22 AM 6/1/2001, Bernard Aboba wrote: > > >A good argument for "Expert review" as opposed to IANA assignment ;) > > > > > >On Fri, 1 Jun 2001, Randy Bush wrote: > > >> via bert > > >> > > >> Story date(time): 05/29/2001(02:18 AM) > > >> Effort afoot to provide wireless LAN roaming > > >> InfoWorld Daily News via DowVision > > >> > > >> By John Cox, Network World Fusion InfoWorld.com > > > > -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-aaa-wg@merit.edu Mon Aug 27 12: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 MAA22774 for ; Mon, 27 Aug 2001 12:00:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C2AC19125F; Mon, 27 Aug 2001 12:01:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 619CB91261; Mon, 27 Aug 2001 12:01:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFAAE9125F for ; Mon, 27 Aug 2001 12:00:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACD1F5DDE5; Mon, 27 Aug 2001 12:00: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 29F945DDB9 for ; Mon, 27 Aug 2001 12:00:59 -0400 (EDT) Received: (qmail 24423 invoked by uid 500); 27 Aug 2001 15:48:38 -0000 Date: Mon, 27 Aug 2001 08:48:38 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 134: Several CMS-Encrypted-Data AVPs in a message Message-ID: <20010827084838.N23877@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 following text is currently present in the I-D: "CMS-Encrypted-Data MAY contain more than one CMS object, that is, implementations MUST be able to add a new CMS-Encrypted-Data AVP value and also MUST be able to decrypt all CMS-Encrypted-Data AVP values which are encrypted for them." This issue is a request to clarify the somewhat ambiguous text in the draft. I would like to propose the following text instead: "A CMS-Encrypted-Data AVP MAY contain more than one EnvelopedData, where one or more AVP would be encrypted within separate EnvelopedData structures. However, implementations MUST be able to support the presence of multiple CMS-Encrypted-Data AVPs, where one or more AVP is added to a separate CMS-Encrypted-Data AVP. Finally, a receiver MUST be able to decrypt all CMS-Encrypted-Data AVPs for which it is a recipient, as indicated in the EnvelopedData's RecipientInfos field [3]. " Would this work? PatC From owner-aaa-wg@merit.edu Mon Aug 27 12:17:11 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23286 for ; Mon, 27 Aug 2001 12:17:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9222091262; Mon, 27 Aug 2001 12:14:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5385A91263; Mon, 27 Aug 2001 12:14: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 3D06091262 for ; Mon, 27 Aug 2001 12:14:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1795A5DDE7; Mon, 27 Aug 2001 12:14: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 CB1255DDB9 for ; Mon, 27 Aug 2001 12:14:12 -0400 (EDT) Received: (qmail 24496 invoked by uid 500); 27 Aug 2001 16:01:52 -0000 Date: Mon, 27 Aug 2001 09:01:52 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client Message-ID: <20010827090152.Q23877@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 Miguel, I've been reading this issue, and I don't understand it :( The issue states that a DSA created by a proxy on behalf of a client should use some information from the first DSAR. I'm not sure what the first DSAR is. Perhaps you meant PDSR, but the PDSR doesn't include these AVPs. Any help would be appreciated, PatC From owner-aaa-wg@merit.edu Mon Aug 27 12:23: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 MAA23496 for ; Mon, 27 Aug 2001 12:23:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1F3D91263; Mon, 27 Aug 2001 12:24:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97F6B91265; Mon, 27 Aug 2001 12:24: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 8393D91263 for ; Mon, 27 Aug 2001 12:24:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 539135DDCA; Mon, 27 Aug 2001 12:24: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 0EB4D5DDB9 for ; Mon, 27 Aug 2001 12:24:47 -0400 (EDT) Received: (qmail 24526 invoked by uid 500); 27 Aug 2001 16:12:26 -0000 Date: Mon, 27 Aug 2001 09:12:26 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 137: CMS Proxy's DSAAs Message-ID: <20010827091226.R23877@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 > When a proxy is involved in the establishment of a DSA, the proxy will > reject the DSA indicating to the agent that: > > - it is not possible to establish a DSA (Result-Code is > DIAMETER_NO_CMS_THROUGH_PROXY) > - it can act as a CMS proxy on behalf of it (Result-Code is > DIAMETER_CAN_ACT_AS_CMS_PROXY). According to 1.2: > > The DSAA MUST be signed by the proxy agent, and include its > certificate, to allow the access device to validate the > originator of the DSAA. > > However, being the Result-Code a permanent failure code, the message > will have the 'E' bit set, so that the message will not conform to the > ABNF described for the command (DSAA). Then, on which AVPs is going to > be applied the digital signature? This assumes that the 'E' bit will be set for the above Result Codes, but if one looks at the Result-Code value definitions: DIAMETER_NO_CMS_THROUGH_PROXY 5020 This error code is returned when a non-transparent proxy receives an DSAR message to state that it doesn't allow a DSA through it since it plans to modify AVPs. DIAMETER_CAN_ACT_AS_CMS_PROXY 5021 This error code is returned when a non-transparent proxy receives an DSAR message, and although it doesn't allow a DSA through it, it is willing to initiate a DSA on behalf of the access device. you can see that these are not defined as protocol errors, and the following text can be found in the base protocol: [...] 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. [...] 7.1.3 Protocol Errors Errors that fall within the Protocol Error category SHOULD be treated on a per-hop basis, and Diameter proxies MAY attempt to correct the error, if it is possible. Note that these errors MUST only be used in answer messages whose 'E' bit is set. so as you can see from above, the 'E' bit wouldn't be set for errors in the 5xxx class, which is where the CMS Result-Code AVP values are defined. So I propose that we reject this issue. PatC From owner-aaa-wg@merit.edu Mon Aug 27 12:56:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24434 for ; Mon, 27 Aug 2001 12:56:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0C6291265; Mon, 27 Aug 2001 12:57:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E8B691266; Mon, 27 Aug 2001 12:57: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 5A05991265 for ; Mon, 27 Aug 2001 12:57:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B2E15DDE4; Mon, 27 Aug 2001 12:57:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DCF955DDCA for ; Mon, 27 Aug 2001 12:57:45 -0400 (EDT) Received: (qmail 24597 invoked by uid 500); 27 Aug 2001 16:45:25 -0000 Date: Mon, 27 Aug 2001 09:45:25 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 138: Signed DSA messages Message-ID: <20010827094525.V23877@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 > However, I'm a little bit concerned when the presence of a > CMS-Signed-Data AVP is required. This AVP contains a digital signature > on other (or others) AVPs. Those protected AVPs must have the 'P' bit > set. But let's imagine that neither of the AVPs included in the > message have the 'P' bit set (maybe because the implementation does > not consider that they must be protected). I assume that the > implementation must detect those cases and, when a CMS-Signed-Data AVP > is required, set the 'P' bit of an AVP, maybe chosen randomly or maybe > fixed in the configuration (for example, the DSA-TTL AVP is always > present, so that the implementation might be configured to protect it > always when a digital signature is required). Is this issue up to the > implementation or should be specified in the specification? This issue has to do with the fact that there is no mandatory AVP in the DSAA, which MUST be signed, whose 'P' bit MUST be set. One proposal (above) is to require that the DSA-TTL AVP MUST have the 'P' bit set. However, the DSA-TTL is also mandatory in the DSAR, which currently states that it SHOULD be signed, and such a change would make it a MUST be signed. I propose that the AAA-Server-Certs AVP MUST have the 'P' bit set, which will require the presence of the CMS-Signed-AVP AVP. PatC From owner-aaa-wg@merit.edu Mon Aug 27 13:41: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 NAA25553 for ; Mon, 27 Aug 2001 13:41:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52C3291266; Mon, 27 Aug 2001 13:41:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 207D991267; Mon, 27 Aug 2001 13:41: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 0C3AA91266 for ; Mon, 27 Aug 2001 13:41:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D89725DDC4; Mon, 27 Aug 2001 13:41: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 5616F5DDB9 for ; Mon, 27 Aug 2001 13:41:57 -0400 (EDT) Received: (qmail 24742 invoked by uid 500); 27 Aug 2001 17:29:36 -0000 Date: Mon, 27 Aug 2001 10:29:36 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 139: Key Management chapter rephrasing Message-ID: <20010827102936.A23877@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, Below is my proposed text for the new section 3.0: 3.0 Key Management For DSA origin authentication, CMS itself already provides sufficient key management without the need for additional specification. Basically, the originating Diameter node signs and includes whatever certificates are necessary for validation of the digital signature. Section 3.1 provides an example of how the Diameter CMS Security application is used. In order to encrypt AVPs for a recipient, the originating Diameter node must have a copy of the recipient's public key. There are many well-known key retrieval schemes (e.g. LDAP [6]), but this specification also allows for the transportation of certificates within Diameter AVPs, which is expected to simplify implementations. Section 3.2 describes how Diameter node names are encoded within such certificates. Finally, it is anticipated that the overhead of key generation for each Diameter message sent to a given peer could be significant. Section 3.4 specifies how CMS encryption keys may be reused for multiple Diameter messages." Comments appreciated, PatC From owner-aaa-wg@merit.edu Mon Aug 27 13:45: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 NAA25651 for ; Mon, 27 Aug 2001 13:45:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFC0891267; Mon, 27 Aug 2001 13:46:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A96E091268; Mon, 27 Aug 2001 13:46: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 84F0191267 for ; Mon, 27 Aug 2001 13:46:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 692FE5DDE8; Mon, 27 Aug 2001 13:46:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 053325DDE4 for ; Mon, 27 Aug 2001 13:46:43 -0400 (EDT) Received: (qmail 24758 invoked by uid 500); 27 Aug 2001 17:34:22 -0000 Date: Mon, 27 Aug 2001 10:34:22 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Tom_Weckstr=F6m?= Cc: gwz@cisco.com, John Schnizlein , Bernard Aboba , Randy Bush , aaa-wg@merit.edu Subject: Re: [AAA-WG]: WECA 'extending' RADIUS? Message-ID: <20010827103422.B23877@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Tom_Weckstr=F6m?= , gwz@cisco.com, John Schnizlein , Bernard Aboba , Randy Bush , aaa-wg@merit.edu References: <3B8A68A0.677B647D@cc.hut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8A68A0.677B647D@cc.hut.fi>; from tweckstr@cc.hut.fi on Mon, Aug 27, 2001 at 06:34:56PM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I digged this thread from my ancient-old unread AAA emails. > Has there been any more news on the WISPr and its adventures lately? All I've heard is that they were meeting in Seattle this month, and it was a closed door meeting (yes, I was told I couldn't attend) :( > Is there any draft specs available inside or outside WECA? perhaps within WECA, but not to the outside community. > What is the timeframe for this project? don't know > Have anyone of the AAA WG members been in contact or > otherwise involved in the WISPr work? I've contacted the chair because I was a little surprised with the amount of press WEP has been gathering that they would foolishly be looking at the use of RADIUS, when it was clearly documented a couple of years ago how it was inappropriate for use in roaming networks. I would have thought that they would be looking at the AAA stuff, but alas, they are not. If anyone has any insight on whether they are considering our work, and not RADIUS, I would be most interested. PatC From owner-aaa-wg@merit.edu Mon Aug 27 13:49: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 NAA25708 for ; Mon, 27 Aug 2001 13:49:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3347D91268; Mon, 27 Aug 2001 13:50:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F127A91269; Mon, 27 Aug 2001 13:50: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 ED12491268 for ; Mon, 27 Aug 2001 13:50:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D0AA75DDC4; Mon, 27 Aug 2001 13:50: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 4E45C5DDB9 for ; Mon, 27 Aug 2001 13:50:34 -0400 (EDT) Received: (qmail 24777 invoked by uid 500); 27 Aug 2001 17:38:13 -0000 Date: Mon, 27 Aug 2001 10:38:13 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 140: Can Answer be rejected? Message-ID: <20010827103813.C23877@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, As per the previous thread on this issue, it was determined that a simple statement be added that clarifies that 'E' bit messages cannot be sent in response to an answer message. So I've added a sentence in the following: 7.2 Error Bit The 'E' (Error Bit) in the Diameter header is set when the request caused a protocol-related error (see section 7.1.3). A message with the 'E' bit MUST NOT be sent as a response to an answer message. Note that a message with the 'E' bit set is still subjected to the processing rules defined in section 6.2. When set, the answer message will not conform to the ABNF specification for the command, and will instead conform to the following ABNF: Thanks, PatC From owner-aaa-wg@merit.edu Mon Aug 27 14:01: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 OAA26043 for ; Mon, 27 Aug 2001 14:01:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7FD19126A; Mon, 27 Aug 2001 14:02:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BAD79126B; Mon, 27 Aug 2001 14:02:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 433D69126A for ; Mon, 27 Aug 2001 14:02:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23FA85DDB9; Mon, 27 Aug 2001 14:02: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 971CC5DD96 for ; Mon, 27 Aug 2001 14:02:05 -0400 (EDT) Received: (qmail 24801 invoked by uid 500); 27 Aug 2001 17:49:44 -0000 Date: Mon, 27 Aug 2001 10:49:44 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 141: OCSP Response request additional text Message-ID: <20010827104944.D23877@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 would like to propose the following text to replace the paragraph pointed to by this issue: " If the DSA initiator's policy states that certicate status is required, it MUST indicate that it requires an OCSP response from the DSA peer in the DSAA message, via the OCSP-Request AVP. Further, the DSA initiator MAY request that the OCSP response be fresh (non cached) via the OCSP-Request and OCSP-Nonce AVPs. Upon receipt of a DSAR message requesting an OCSP response, the receiver issues an OCSP request and returns the response within the DSAA message's OCSP-Responses AVP. The sender of the DSAA MAY included a cached OCSP response, unless the requestor specifically requested a fresh response." Comments appreciated, PatC From owner-aaa-wg@merit.edu Mon Aug 27 14:19: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 OAA26497 for ; Mon, 27 Aug 2001 14:19:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E82C791234; Mon, 27 Aug 2001 14:20:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B42989126B; Mon, 27 Aug 2001 14:20:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5BCF91234 for ; Mon, 27 Aug 2001 14:20:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 872285DDB9; Mon, 27 Aug 2001 14:20:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 076DC5DDC4 for ; Mon, 27 Aug 2001 14:20:08 -0400 (EDT) Received: (qmail 24891 invoked by uid 500); 27 Aug 2001 18:07:47 -0000 Date: Mon, 27 Aug 2001 11:07:47 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 144: Message-ID: <20010827110746.F23877@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, In order to fix this problem, I've added text to section 3.1: " In the event the DSAR requested OCSP validation, via the OCSP-Request AVP, and OCSP is not locally supported, the DSAA MUST be returned with the Result-Code AVP set to DIAMETER_OCSP_NOT_SUPPORTED. Otherwise, the destination node returns the DSAA message which contains:" and added the following Result-Code value: DIAMETER_OCSP_NOT_SUPPORTED 5022 This error code is returned when a DSAR message is received requesting OCSP validation, and the receiver does not support OCSP. Does this work? PatC From owner-aaa-wg@merit.edu Mon Aug 27 14:26: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 OAA26618 for ; Mon, 27 Aug 2001 14:26:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DA629126B; Mon, 27 Aug 2001 14:27:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 417A891280; Mon, 27 Aug 2001 14:27: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 2B3059126B for ; Mon, 27 Aug 2001 14:27:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED6AE5DDB9; Mon, 27 Aug 2001 14:27: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 513285DD96 for ; Mon, 27 Aug 2001 14:27:50 -0400 (EDT) Received: (qmail 24939 invoked by uid 500); 27 Aug 2001 18:15:29 -0000 Date: Mon, 27 Aug 2001 11:15:29 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 145: Order in CMS-Proxy messages Message-ID: <20010827111529.G23877@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 is a request to change the language that pertains to encryption of AVPs, and the fact that the current text states that the AVPs may be ordered in any manner prior to the encryption process. If the encryptor is the client, or the home server, we don't have much of an issue, which is where this text was directed to. However, if a proxy is performing the encryption on behalf of a client, it will have to reorder the AVPs for them to fit within the CMS-Encrypted-Data AVP (because the AVPs are pulled from the message, and included in the AVP). Of course, we could require that each individual AVP be encrypted separately, and the resulting CMS-Encrypted-Data AVP be inserted in the same location the original AVP was in. Personally, I think this is just too much overhead. So, I would opt to leave the language as is. Proxies are evil anyways, and they will reorder if they feel like it. This is one case where reorder is actually necessary. PatC From owner-aaa-wg@merit.edu Mon Aug 27 15:03: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 PAA27317 for ; Mon, 27 Aug 2001 15:03:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B42BD9125D; Mon, 27 Aug 2001 15:04:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83F8F91260; Mon, 27 Aug 2001 15:04: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 7DE539125D for ; Mon, 27 Aug 2001 15:04:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 623545DDB9; Mon, 27 Aug 2001 15:04:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D5F7F5DD96 for ; Mon, 27 Aug 2001 15:04:32 -0400 (EDT) Received: (qmail 25076 invoked by uid 500); 27 Aug 2001 18:52:11 -0000 Date: Mon, 27 Aug 2001 11:52:11 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 126: Clarification in certificate naming schema Message-ID: <20010827115211.M23877@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 following changes were requested in this issue: > - Unifying the terminology. Using "realm" always or "domain" always. This was already covered by another issue, and has since been fixed. > - To switch the long explanation of chapter 3.1 to a more appropriate > place (chapter 3.2), including a reference to it in the item of 3.1 > chapter. The text in 3.1 was replaced with: - the name in the certificate is consistent with the rules detailed in section 3.2. > - Explaining which AVP is Host-Name AVP This was an error. The AVP in question is actually the Origin-Host AVP. I have made that change. > > Additionally I'd like to receive a clarification about the realms > involved. I suppose that the "realm part of the user's NAI" is carried > by means of the Destination-Realm in the DSAR, but I'm not sure. BTW I've added clarifying text in 1.5: "... MUST belong to the same realm as the user being authorized (the realm portion of the Network Access Identifier found in the User-Name AVP)" PatC From owner-aaa-wg@merit.edu Mon Aug 27 15:23: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 PAA27803 for ; Mon, 27 Aug 2001 15:23:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9733591260; Mon, 27 Aug 2001 15:24:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62E8D91280; Mon, 27 Aug 2001 15:24: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 468BD91260 for ; Mon, 27 Aug 2001 15:24:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C1D15DDB9; Mon, 27 Aug 2001 15:24:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 672CD5DDC4 for ; Mon, 27 Aug 2001 15:24:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA30445 for ; Mon, 27 Aug 2001 12:16:42 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 27 Aug 2001 12:16:41 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Expiration of AAA WG last call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG last call has expired on the following documents: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt Issues arising from the WG last call comments are being tracked at: http://www.diameter.org/issues.html Once these issues have been resolved and changes reflected in new documents, another WG last call will be required for those documents where the changes are substantial and technical in nature. Given the issue breakdown (see below), this would appear to be most likely to apply to diameter-07 and cms-sec-02. In general, given the substantial number of issues arising in last call on these documents, I would encourage WG participants to continue to post outstanding issues, so that the oustanding issues can be addressed in the next revision and the next WG last call can be the last one. Curently the issue breakdown is as follows: transport-04: Issue #94 nasreq-07: Issues #131 diameter-07: Issues #98, 100, 113, 123, 128, 140 cms-sec-02: Issues #126, 132, 133, 134, 136, 137, 138, 139, 141, 142, 144, 145 I also believe that the following issues need to be re-opened: nasreq-07: Issue #29 (need to substitute RFC 3162 attribute #s for TBD) Issue #36 (need to remove AES/OCB from list, change "WEP2" to WEP-128"). From owner-aaa-wg@merit.edu Mon Aug 27 15:50: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 PAA28369 for ; Mon, 27 Aug 2001 15:50:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 983DB91280; Mon, 27 Aug 2001 15:51:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63CC791281; Mon, 27 Aug 2001 15:51: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 4792491280 for ; Mon, 27 Aug 2001 15:51:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E4BF5DDC7; Mon, 27 Aug 2001 15:51: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 BEFC15DD96 for ; Mon, 27 Aug 2001 15:51:33 -0400 (EDT) Received: (qmail 25175 invoked by uid 500); 27 Aug 2001 19:39:12 -0000 Date: Mon, 27 Aug 2001 12:39:12 -0700 From: Pat Calhoun To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Expiration of AAA WG last call Message-ID: <20010827123912.O23877@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , 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 aboba@internaut.com on Mon, Aug 27, 2001 at 12:16:41PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Given the number of changes, I agree with Bernard that another go-around is required. I would, however, request that the period not exceed two weeks, since we are starting to push the P2 deadline. PatC On Mon, Aug 27, 2001 at 12:16:41PM -0700, Bernard Aboba wrote: > AAA WG last call has expired on the following documents: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt > http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt > > Issues arising from the WG last call comments are being tracked at: > > http://www.diameter.org/issues.html > > Once these issues have been resolved and changes reflected in new > documents, another WG last call will be required for those documents > where the changes are substantial and technical in nature. Given the > issue breakdown (see below), this would appear to be most likely to apply > to diameter-07 and cms-sec-02. In general, given the substantial number of > issues arising in last call on these documents, I would encourage WG > participants to continue to post outstanding issues, so that the > oustanding issues can be addressed in the next revision and the next WG > last call can be the last one. > > Curently the issue breakdown is as follows: > > transport-04: Issue #94 > nasreq-07: Issues #131 > diameter-07: Issues #98, 100, 113, 123, 128, 140 > cms-sec-02: Issues #126, 132, 133, 134, 136, 137, 138, 139, 141, 142, 144, > 145 > > I also believe that the following issues need to be re-opened: > > nasreq-07: Issue #29 (need to substitute RFC 3162 attribute #s for > TBD) > Issue #36 (need to remove AES/OCB from list, change "WEP2" > to WEP-128"). > From owner-aaa-wg@merit.edu Mon Aug 27 16:00:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28558 for ; Mon, 27 Aug 2001 16:00:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2EB8591281; Mon, 27 Aug 2001 16:00:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE8E691283; Mon, 27 Aug 2001 16:00: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 D852A91281 for ; Mon, 27 Aug 2001 16:00:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7ED55DDC4; Mon, 27 Aug 2001 16:00:53 -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 EF8B85DD96 for ; Mon, 27 Aug 2001 16:00:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id MAA30488; Mon, 27 Aug 2001 12:53:03 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 27 Aug 2001 12:53:03 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Expiration of AAA WG last call In-Reply-To: <20010827123912.O23877@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Not all documents will require another go-round; there appear to be no issues on mobileip-07, for example, and changes on transport-04 are largely editorial. Agree that we will do a standard two week last call on the next go-round. On Mon, 27 Aug 2001, Pat Calhoun wrote: > Given the number of changes, I agree with Bernard that another go-around > is required. I would, however, request that the period not exceed two > weeks, since we are starting to push the P2 deadline. > > PatC From owner-aaa-wg@merit.edu Mon Aug 27 16:07:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28746 for ; Mon, 27 Aug 2001 16:07:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B16C91283; Mon, 27 Aug 2001 16:08:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CACA291284; Mon, 27 Aug 2001 16:08: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 B8B0B91283 for ; Mon, 27 Aug 2001 16:08:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F4075DDF0; Mon, 27 Aug 2001 16:08: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 EF5FC5DDEB for ; Mon, 27 Aug 2001 16:08:49 -0400 (EDT) Received: (qmail 25213 invoked by uid 500); 27 Aug 2001 19:56:28 -0000 Date: Mon, 27 Aug 2001 12:56:28 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Expiration of AAA WG last call Message-ID: <20010827125628.P23877@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010827123912.O23877@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 Mon, Aug 27, 2001 at 12:53:03PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Right, but the documents need to go through IESG as a set, which is why I didn't see any harm in just doing the last call on all of them. I'll let you work out the logistics. I don't care either way. PatC On Mon, Aug 27, 2001 at 12:53:03PM -0700, Bernard Aboba wrote: > Not all documents will require another go-round; there appear to be no > issues on mobileip-07, for example, and changes on transport-04 are > largely editorial. Agree that we will do a standard two week last call on > the next go-round. > > On Mon, 27 Aug 2001, Pat Calhoun wrote: > > > Given the number of changes, I agree with Bernard that another go-around > > is required. I would, however, request that the period not exceed two > > weeks, since we are starting to push the P2 deadline. > > > > PatC > From owner-aaa-wg@merit.edu Mon Aug 27 16:11: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 QAA28793 for ; Mon, 27 Aug 2001 16:10:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB52D91284; Mon, 27 Aug 2001 16:11:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F09491285; Mon, 27 Aug 2001 16:11: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 64D9C91284 for ; Mon, 27 Aug 2001 16:11:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2AC115DDD7; Mon, 27 Aug 2001 16:11:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C9A1F5DD96 for ; Mon, 27 Aug 2001 16:11:54 -0400 (EDT) Received: (qmail 25230 invoked by uid 500); 27 Aug 2001 19:59:34 -0000 Date: Mon, 27 Aug 2001 12:59:33 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 98: Message-ID: <20010827125933.Q23877@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 raised basically because the use of the term alternate, and the introduction of the Alternate-Peer, caused lots of confusion. Since Issue 117 removed the Source-Route, this isn't much of an issue anymore, but I did decide to try to clean up some of the language (and hopefully succeeded). New text: 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 two peers per realm, known as the primary and secondary peers. Of course, a node MAY have additional connections, if it is deemed necessary. Typically, all messages for a realm are sent to the primary peer, but in the event that failover procedures are invoked, any pending requests are sent to the secondary peer. However, implementations are free to load balance requests between a set of peers. Note that a given peer MAY act as a primary for a given realm, while acting as a secondary for another realm. When a peer is deemed suspect, which could occur for various reasons, including not receiving a DWA within an alloted timeframe, no new requests should be forwarded to the peer, but failover procedures are not invoked. When an active peer is moved to this mode, additional connections SHOULD be established to ensure that the necessary number of active connections exists. There are two ways that a peer is removed from the suspect peer list: 1. The peer is no longer reachable, causing the transport connection to be shutdown. The peer is moved to the closed state. 2. Three watchdog messages are exchanged with accepted round trip times, and the connection to the peer is considered stabilized. In the event the peer being removed is either the primary or secondary, an alternate peer SHOULD replace the deleted peer, and assume the role of either primary or secondary. Comments appreciated, PatC From owner-aaa-wg@merit.edu Mon Aug 27 16:40: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 QAA29479 for ; Mon, 27 Aug 2001 16:40:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D5AFB91285; Mon, 27 Aug 2001 16:41:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A756891286; Mon, 27 Aug 2001 16:41: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 9342591285 for ; Mon, 27 Aug 2001 16:41:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71C275DDD6; Mon, 27 Aug 2001 16:41: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 2D5C85DDD3 for ; Mon, 27 Aug 2001 16:41:10 -0400 (EDT) Received: (qmail 25314 invoked by uid 500); 27 Aug 2001 20:28:48 -0000 Date: Mon, 27 Aug 2001 13:28:48 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Message-ID: <20010827132848.R23877@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 issue states: > In the first sentence, one may interpret the text that the use > of application identifiers in the routing is a necessary requirement. > We feel that the use of application identifiers while routing is > optional whereas the routing must be based on the destination realm > contained in the message. This would provide a flexible scenario > where proxies and relays always need to be able to route based on the > realm, and in addition, they may choose to route based on application > identifiers, as well. This would also allow for implementation > scenarios capable to hide the network topology or distribute the > server functions within a realm by use of a "gateway" diameter nodes > . > > Requested Change: > Rephrase section 2.5 last paragraph, first sentence to: > "While the diameter relay and proxy agents MUST know how to > route messages based on the destination realm indicated in the > message, they MAY be able to route the messages also based on the > application identifiers of a particular message." Now that I am about to tackle this one, I believe that I disagree with the above. The issue claims that the use of application-id should be optional to allow for "gateway", which I presume is a relay agent. For this reason, we defined the Relay Application-Id, which a node advertises if it wishes to receive messages for ANY Diameter application. I would prefer to not adopt this proposed change. Comments? PatC From owner-aaa-wg@merit.edu Mon Aug 27 17:07: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 RAA00534 for ; Mon, 27 Aug 2001 17:07:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 258C89126C; Mon, 27 Aug 2001 17:08:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D724891287; Mon, 27 Aug 2001 17:08: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 CD0199126C for ; Mon, 27 Aug 2001 17:08:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4A765DDD3; Mon, 27 Aug 2001 17:08:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 74D905DDCC for ; Mon, 27 Aug 2001 17:08:43 -0400 (EDT) Received: (qmail 25412 invoked by uid 500); 27 Aug 2001 20:56:22 -0000 Date: Mon, 27 Aug 2001 13:56:22 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issues review complete Message-ID: <20010827135622.V23877@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 have just finished updating the spec with all remaining issues. Of those that I had additional comments, I have sent e-mail to the list. Also, there are a couple of issues that I didn't agree with, and sent e-mail to the list stating my stance of the issue. My deadline is to have the next rev sent to the secretariat this Thursday. So if no one responds to my e-mail by then, I will include my proposed change in the draft (and in some cases, I propose to reject the issue for specific technical reasons). Your attention is greatly appreciated, PatC From owner-aaa-wg@merit.edu Mon Aug 27 17:15: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 RAA00777 for ; Mon, 27 Aug 2001 17:15:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E7FB91286; Mon, 27 Aug 2001 17:02:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DF7691287; Mon, 27 Aug 2001 17:02: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 2447B91286 for ; Mon, 27 Aug 2001 17:02:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3C9B5DDCC; Mon, 27 Aug 2001 17:02: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 9101A5DDC3 for ; Mon, 27 Aug 2001 17:02:09 -0400 (EDT) Received: (qmail 25393 invoked by uid 500); 27 Aug 2001 20:49:03 -0000 Date: Mon, 27 Aug 2001 13:49:03 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 142: CEKMaxDecrypts value cs DSA length Message-ID: <20010827134903.U23877@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 Miguel, I'm not sure if you are genuinely confused, or if you were just making a point, but the difference between both is that the CEKMaxDecrypts is used throughout the length of a DSA. The CEK draft discusses how keys are re-used within CMS, so this happens within the CMS protocol. The DSA TTL, however, states when the DSA expires, and a new DSAR message needs to be sent. Is this clearer? I'm not sure how to express this in ascii, since one really does have to read the CEK spec to understand this anyways. thoughts? PatC From owner-aaa-wg@merit.edu Mon Aug 27 17:28:12 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 RAA01115 for ; Mon, 27 Aug 2001 17:28:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96F9E91289; Mon, 27 Aug 2001 17:28:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66A199128A; Mon, 27 Aug 2001 17:28: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 3611291289 for ; Mon, 27 Aug 2001 17:28:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EEB35DDD3; Mon, 27 Aug 2001 17:28:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 94F415DDCC for ; Mon, 27 Aug 2001 17:28:57 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7RLU9I17273 for ; Mon, 27 Aug 2001 16:30:09 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Aug 2001 16:28:56 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 16:28:56 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Date: Mon, 27 Aug 2001 16:28:55 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811223E6A@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Thread-Index: AcEvOKcKWlQM5psrEdWBSQBQi2X+DwABd/2g From: "Le Franck (NRC/Dallas)" To: "'ext Pat Calhoun'" , X-OriginalArrivalTime: 27 Aug 2001 21:28:56.0146 (UTC) FILETIME=[46DDA320:01C12F3F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01115 Pat, thanks for the reply. But, I feel that the "gateway" nodes are more than likely proxy nodes that are located on the edge of a network (realm). All the messages for this realm will arrive at this gateway node based on realm based routing. They may have the knowledge of specific AAA servers within its realm supporting specific applications (MIP, NASREQ etc.) and perform the routing using the application identifier information. The point, which not clear from the existing text, is that the use of application identifiers is not a MUST (or required as in the text) but there are cases where it is useful and therefore a "MAY". Sreemanthula Srinivas -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: 27 August, 2001 3:29 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 123: Use of Application Identifiers in routing The issue states: > In the first sentence, one may interpret the text that the use > of application identifiers in the routing is a necessary requirement. > We feel that the use of application identifiers while routing is > optional whereas the routing must be based on the destination realm > contained in the message. This would provide a flexible scenario > where proxies and relays always need to be able to route based on the > realm, and in addition, they may choose to route based on application > identifiers, as well. This would also allow for implementation > scenarios capable to hide the network topology or distribute the > server functions within a realm by use of a "gateway" diameter nodes > . > > Requested Change: > Rephrase section 2.5 last paragraph, first sentence to: > "While the diameter relay and proxy agents MUST know how to > route messages based on the destination realm indicated in the > message, they MAY be able to route the messages also based on the > application identifiers of a particular message." Now that I am about to tackle this one, I believe that I disagree with the above. The issue claims that the use of application-id should be optional to allow for "gateway", which I presume is a relay agent. For this reason, we defined the Relay Application-Id, which a node advertises if it wishes to receive messages for ANY Diameter application. I would prefer to not adopt this proposed change. Comments? PatC From owner-aaa-wg@merit.edu Mon Aug 27 17:41: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 RAA01423 for ; Mon, 27 Aug 2001 17:41:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41CE79128B; Mon, 27 Aug 2001 17:42:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 116F39128C; Mon, 27 Aug 2001 17:42:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D38929128B for ; Mon, 27 Aug 2001 17:41:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9F9C5DDCC; Mon, 27 Aug 2001 17:41:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 570BB5DDC4 for ; Mon, 27 Aug 2001 17:41:59 -0400 (EDT) Received: (qmail 25500 invoked by uid 500); 27 Aug 2001 21:29:38 -0000 Date: Mon, 27 Aug 2001 14:29:38 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ Chap Changes Message-ID: <20010827142938.W23877@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Following the thread earlier this week (or last week), here is my proposed text: 3.1.1.2 CHAP-Auth AVP The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains the information necessary to authenticate a user using the PPP Challenge-Handshake Authentication Protocol (CHAP) [6]. If the CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see section 3.1.1.6) MUST be present as well. The AVP containing the CHAP response depends upon the value of the CHAP-Algorithm AVP (see section 3.1.1.4 for more info). Its Data field has the following ABNF grammar: CHAP-Auth ::= < AVP Header: 409 > { CHAP-Algorithm } { CHAP-Ident } [ CHAP-Response ] [ AVP ] 3.1.1.3 CHAP-Ident AVP The CHAP-Ident AVP (AVP Code 410) is of type OctetString and contains the one octet CHAP Identifier used in the computation of the CHAP response [6]. 3.1.1.4 CHAP-Algorithm AVP The CHAP-Algorithm AVP (AVP Code 412) is of type Enumerated and contains the algorithm identifier used in the computation of the CHAP response [6]. The following values are currently supported: CHAP with MD5 5 The CHAP response is computed using the procedure decribed in [6]. The CHAP-Response AVP MUST be present in the CHAP-Auth AVP. 3.1.1.5 CHAP-Response AVP The CHAP-Response AVP (AVP Code 411) is of type OctetString and contains the 16 octet authentication data provided by the user in response to the CHAP challenge [16]. The actual computation of the CHAP response can be found in [6]. 3.1.1.6 CHAP-Challenge AVP The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and contains the CHAP Challenge sent by the NAS to a PPP Challenge-Handshake Authentication Protocol (CHAP) [6] user. Comments welcomed! Thanks, PatC From owner-aaa-wg@merit.edu Mon Aug 27 17:57: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 RAA01923 for ; Mon, 27 Aug 2001 17:57:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C86A9128C; Mon, 27 Aug 2001 17:58:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E2D99128D; Mon, 27 Aug 2001 17:58:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C1609128C for ; Mon, 27 Aug 2001 17:58:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 413625DDCC; Mon, 27 Aug 2001 17:58: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 E09065DDC4 for ; Mon, 27 Aug 2001 17:58:39 -0400 (EDT) Received: (qmail 25520 invoked by uid 500); 27 Aug 2001 21:46:18 -0000 Date: Mon, 27 Aug 2001 14:46:18 -0700 From: Pat Calhoun To: "Sreemanthula Srinivas (NRC/Dallas)" Cc: aaa-wg@merit.edu, pcalhoun@diameter.org, "Le Franck (NRC/Dallas)" Subject: Re: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Message-ID: <20010827144618.X23877@charizard.diameter.org> Mail-Followup-To: "Sreemanthula Srinivas (NRC/Dallas)" , aaa-wg@merit.edu, pcalhoun@diameter.org, "Le Franck (NRC/Dallas)" References: <07EE0E021034014F99A57B032BC9C0E50FF5C0@daebe001.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: <07EE0E021034014F99A57B032BC9C0E50FF5C0@daebe001.NOE.Nokia.com>; from Srinivas.Sreemanthula@nokia.com on Mon, Aug 27, 2001 at 04:23:09PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Aug 27, 2001 at 04:23:09PM -0500, Sreemanthula Srinivas (NRC/Dallas) wrote: > Pat, thanks for the reply. But, I feel that the "gateway" nodes are > more than likely proxy nodes that are located on the edge of a network > (realm). Just want to make sure that you understand that the use of the term proxy node implies specific functionality. If you are not aware of that, I would urge you to read section 2.9.2 in the base spec (but if you are in fact talking about a proxy, then ignore my comment). > All the messages for this realm will arrive at this gateway > node based on realm based routing. They may have the knowledge of > specific AAA servers within its realm supporting specific applications > (MIP, NASREQ etc.) and perform the routing using the application > identifier information. Right, and the reason your network would work this way is because the "gateway" advertises itself as a relay (advertises all applications), so it is guaranteed to receive all requests destined for the local realm. The "gateway" then forwards the message to the appropriate internal server, based on the application. This is exactly the way the base spec is written. > The point, which not clear from the existing > text, is that the use of application identifiers is not a MUST (or > required as in the text) but there are cases where it is useful and > therefore a "MAY". Your above sentence unfortunately confuses me. Are you stating that the routing using appl-id is NOT a MUST in the current spec, or that it is and you want it softened? If the former, then it needs to be fixed, if the latter, please provide why the above example, using the existing text, doesn't work for you. Thanks, PatC From owner-aaa-wg@merit.edu Mon Aug 27 18:06: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 SAA02103 for ; Mon, 27 Aug 2001 18:06:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC4B29128D; Mon, 27 Aug 2001 18:07:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91CB19128E; Mon, 27 Aug 2001 18:07: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 758C49128D for ; Mon, 27 Aug 2001 18:07:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 428D05DDCC; Mon, 27 Aug 2001 18:07: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 F27765DDB3 for ; Mon, 27 Aug 2001 18:07:35 -0400 (EDT) Received: (qmail 25552 invoked by uid 500); 27 Aug 2001 21:55:14 -0000 Date: Mon, 27 Aug 2001 14:55:14 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 146: CHAP Algorithm missing Message-ID: <20010827145514.Z23877@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010827142938.W23877@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: <20010827142938.W23877@charizard.diameter.org>; from pcalhoun@diameter.org on Mon, Aug 27, 2001 at 02:29:38PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Same e-mail as previously, but there was no issue open to handle this. I have formally opened issue 146. PatC On Mon, Aug 27, 2001 at 02:29:38PM -0700, Pat Calhoun wrote: > Following the thread earlier this week (or last week), here is my proposed > text: > > 3.1.1.2 CHAP-Auth AVP > > The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains > the information necessary to authenticate a user using the > PPP Challenge-Handshake Authentication Protocol (CHAP) [6]. If the > CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see > section 3.1.1.6) MUST be present as well. The AVP containing the > CHAP response depends upon the value of the CHAP-Algorithm AVP (see > section 3.1.1.4 for more info). Its Data field has the following > ABNF grammar: > > CHAP-Auth ::= < AVP Header: 409 > > { CHAP-Algorithm } > { CHAP-Ident } > [ CHAP-Response ] > [ AVP ] > > > 3.1.1.3 CHAP-Ident AVP > > The CHAP-Ident AVP (AVP Code 410) is of type OctetString and > contains the one octet CHAP Identifier used in the computation > of the CHAP response [6]. > > > 3.1.1.4 CHAP-Algorithm AVP > > The CHAP-Algorithm AVP (AVP Code 412) is of type Enumerated and > contains the algorithm identifier used in the computation of > the CHAP response [6]. The following values are currently > supported: > > CHAP with MD5 5 > The CHAP response is computed using the procedure decribed in [6]. > The CHAP-Response AVP MUST be present in the CHAP-Auth AVP. > > > 3.1.1.5 CHAP-Response AVP > > The CHAP-Response AVP (AVP Code 411) is of type OctetString and > contains the 16 octet authentication data provided by the user > in response to the CHAP challenge [16]. The actual computation of > the CHAP response can be found in [6]. > > > 3.1.1.6 CHAP-Challenge AVP > > The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and contains the > CHAP Challenge sent by the NAS to a PPP Challenge-Handshake > Authentication Protocol (CHAP) [6] user. > > > Comments welcomed! > > Thanks, > > PatC From owner-aaa-wg@merit.edu Mon Aug 27 18:18: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 SAA02596 for ; Mon, 27 Aug 2001 18:18:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B2619128E; Mon, 27 Aug 2001 18:19:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CDB891291; Mon, 27 Aug 2001 18:19: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 48A609128E for ; Mon, 27 Aug 2001 18:19:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 113F35DDBC; Mon, 27 Aug 2001 18:19: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 837B15DDB8 for ; Mon, 27 Aug 2001 18:19:36 -0400 (EDT) Received: (qmail 25578 invoked by uid 500); 27 Aug 2001 22:07:15 -0000 Date: Mon, 27 Aug 2001 15:07:15 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Bernard's implied issues Message-ID: <20010827150715.A23877@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 Bernard, You implied new issues in the following statement: "I also believe that the following issues need to be re-opened: nasreq-07: Issue #29 (need to substitute RFC 3162 attribute #s for TBD) Issue #36 (need to remove AES/OCB from list, change "WEP2" to WEP-128"). " I will create two new issues (easier to track than re-opening the old ones). As far as the second issue, is the following the correct reference for WEP? [22] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999. Thanks, PatC From owner-aaa-wg@merit.edu Mon Aug 27 18:36: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 SAA03264 for ; Mon, 27 Aug 2001 18:36:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0809891291; Mon, 27 Aug 2001 18:37:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDC9491293; Mon, 27 Aug 2001 18:37:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9E9591291 for ; Mon, 27 Aug 2001 18:37:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB8E05DDBC; Mon, 27 Aug 2001 18:37: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 29B7E5DDB8 for ; Mon, 27 Aug 2001 18:37:26 -0400 (EDT) Received: (qmail 25627 invoked by uid 500); 27 Aug 2001 22:25:04 -0000 Date: Mon, 27 Aug 2001 15:25:04 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 147: NASREQ Loose ends Message-ID: <20010827152504.D23877@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 Issue 147: CHAP Algorithm missing Submitter name: Pat Calhoun Submitter email address: pcalhoun@diameter.org Date first submitted: 2001-08-27 Reference: Document: NASREQ-07 Comment type: T Priority: S Section: 2.1.6, 7.2.5.4, 7.2.5.5, 7.2.5.6, 7.2.5.7 Rationale/Explanation of issue: The NASREQ specification requires the following changes: - Replace TBD for IPv6 RADIUS attribute numbers to the values found in RFC 3162. - Remove AES as a possible key type in section 2.1.6 - Change WEP2 to WEP-128 as a possible key type in section 2.1.6 - Include a reference to WEP. From owner-aaa-wg@merit.edu Mon Aug 27 19:00: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 TAA03673 for ; Mon, 27 Aug 2001 19:00:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 886D39126E; Mon, 27 Aug 2001 19:00:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E1B291293; Mon, 27 Aug 2001 19:00: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 E8DB99126E for ; Mon, 27 Aug 2001 19:00:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C57ED5DDB3; Mon, 27 Aug 2001 19:00:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 3E0BA5DDA7 for ; Mon, 27 Aug 2001 19:00:34 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7RN0di23369 for ; Mon, 27 Aug 2001 18:00:39 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Aug 2001 18:00:32 -0500 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 18:00:32 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Date: Mon, 27 Aug 2001 18:00:32 -0500 Message-ID: <07EE0E021034014F99A57B032BC9C0E50FF5C1@daebe001.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 123: Use of Application Identifiers in routing X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEvQ29ZNw6mMJsqEdWrxAAIx6S5QwAAOQcg From: "Sreemanthula Srinivas (NRC/Dallas)" To: "'ext Pat Calhoun'" Cc: X-OriginalArrivalTime: 27 Aug 2001 23:00:32.0591 (UTC) FILETIME=[130095F0:01C12F4C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03673 >On Mon, Aug 27, 2001 at 04:23:09PM -0500, Sreemanthula Srinivas (NRC/Dallas) wrote: >> Pat, thanks for the reply. But, I feel that the "gateway" nodes are >> more than likely proxy nodes that are located on the edge of a network >> (realm). > >Just want to make sure that you understand that the use of the term proxy >node implies specific functionality. If you are not aware of that, I would >urge you to read section 2.9.2 in the base spec (but if you are in fact >talking about a proxy, then ignore my comment). I see that they can enforce routing, roaming and other policies, hence they are proxies. >> All the messages for this realm will arrive at this gateway >> node based on realm based routing. They may have the knowledge of >> specific AAA servers within its realm supporting specific applications >> (MIP, NASREQ etc.) and perform the routing using the application >> identifier information. >Right, and the reason your network would work this way is because the "gateway" >advertises itself as a relay (advertises all applications), so it is guaranteed >to receive all requests destined for the local realm. The "gateway" then >forwards the message to the appropriate internal server, based on the >application. >This is exactly the way the base spec is written. My understanding is that only Relay and redirect agents use the "Relay" application id while others must specifically advertise the supported identifiers. >> The point, which not clear from the existing >> text, is that the use of application identifiers is not a MUST (or >> required as in the text) but there are cases where it is useful and >> therefore a "MAY". >Your above sentence unfortunately confuses me. Are you stating that the >routing using appl-id is NOT a MUST in the current spec, or that it is >and you want it softened? If the former, then it needs to be fixed, if >the latter, please provide why the above example, using the existing text, >doesn't work for you. Ok, it is the latter. The use of application id in routing need only be optional. We are insisting on the realm based routing, because this guarantees that any diameter message will arrive at the destination network irrespective of the capabilities supported in the intermediary network. We do not want the message to be rejected because some broker is not able to support the application. This may be more of an issue as new applications For two networks A and B supporting a new application id, >Thanks, >PatC From owner-aaa-wg@merit.edu Mon Aug 27 19:02:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03744 for ; Mon, 27 Aug 2001 19:02:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1C29691293; Mon, 27 Aug 2001 19:03:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E203B91294; Mon, 27 Aug 2001 19:03: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 A3DF691293 for ; Mon, 27 Aug 2001 19:03:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 719F05DDB3; Mon, 27 Aug 2001 19:03:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id E82005DDA7 for ; Mon, 27 Aug 2001 19:03:39 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7RN4kI20211 for ; Mon, 27 Aug 2001 18:04:51 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Aug 2001 18:03:33 -0500 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 18:03:33 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Date: Mon, 27 Aug 2001 18:03:33 -0500 Message-ID: <07EE0E021034014F99A57B032BC9C0E50BDA5F@daebe001.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 123: Use of Application Identifiers in routing X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEvQ29ZNw6mMJsqEdWrxAAIx6S5QwAAOQcgAAFILMA= From: "Sreemanthula Srinivas (NRC/Dallas)" To: "Sreemanthula Srinivas (NRC/Dallas)" , "'ext Pat Calhoun'" Cc: X-OriginalArrivalTime: 27 Aug 2001 23:03:33.0500 (UTC) FILETIME=[7ED51BC0:01C12F4C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03744 Sorry, the mail was accidentally sent before I completed it. Here is the rest. >On Mon, Aug 27, 2001 at 04:23:09PM -0500, Sreemanthula Srinivas (NRC/Dallas) wrote: >> Pat, thanks for the reply. But, I feel that the "gateway" nodes are >> more than likely proxy nodes that are located on the edge of a network >> (realm). > >Just want to make sure that you understand that the use of the term proxy >node implies specific functionality. If you are not aware of that, I would >urge you to read section 2.9.2 in the base spec (but if you are in fact >talking about a proxy, then ignore my comment). I see that they can enforce routing, roaming and other policies, hence they are proxies. >> All the messages for this realm will arrive at this gateway >> node based on realm based routing. They may have the knowledge of >> specific AAA servers within its realm supporting specific applications >> (MIP, NASREQ etc.) and perform the routing using the application >> identifier information. >Right, and the reason your network would work this way is because the "gateway" >advertises itself as a relay (advertises all applications), so it is guaranteed >to receive all requests destined for the local realm. The "gateway" then >forwards the message to the appropriate internal server, based on the >application. >This is exactly the way the base spec is written. My understanding is that only Relay and redirect agents use the "Relay" application id while others must specifically advertise the supported identifiers. >> The point, which not clear from the existing >> text, is that the use of application identifiers is not a MUST (or >> required as in the text) but there are cases where it is useful and >> therefore a "MAY". >Your above sentence unfortunately confuses me. Are you stating that the >routing using appl-id is NOT a MUST in the current spec, or that it is >and you want it softened? If the former, then it needs to be fixed, if >the latter, please provide why the above example, using the existing text, >doesn't work for you. Ok, it is the latter. The use of application id in routing need only be optional. We are insisting on the realm based routing, because this guarantees that any diameter message will arrive at the destination network irrespective of the capabilities supported in the intermediary network. We do not want the message to be rejected because some broker is not able to support the application. This may be more of an issue as new applications come in action. For two networks A and B supporting a new application id, there is no need for intermediary network to be upgraded. Thanks, Srini >Thanks, >PatC From owner-aaa-wg@merit.edu Mon Aug 27 19: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 TAA03792 for ; Mon, 27 Aug 2001 19:03:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2414B91294; Mon, 27 Aug 2001 19:04:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7D8791296; Mon, 27 Aug 2001 19:04: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 C375691294 for ; Mon, 27 Aug 2001 19:04:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9BD435DDB3; Mon, 27 Aug 2001 19:04:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AF8695DDA7 for ; Mon, 27 Aug 2001 19:04:10 -0400 (EDT) Received: (qmail 25704 invoked by uid 500); 27 Aug 2001 22:51:49 -0000 Date: Mon, 27 Aug 2001 15:51:49 -0700 From: Pat Calhoun To: "Sreemanthula Srinivas (NRC/Dallas)" Cc: "'ext Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Message-ID: <20010827155148.E23877@charizard.diameter.org> Mail-Followup-To: "Sreemanthula Srinivas (NRC/Dallas)" , 'ext Pat Calhoun' , aaa-wg@merit.edu References: <07EE0E021034014F99A57B032BC9C0E50FF5C1@daebe001.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: <07EE0E021034014F99A57B032BC9C0E50FF5C1@daebe001.NOE.Nokia.com>; from Srinivas.Sreemanthula@nokia.com on Mon, Aug 27, 2001 at 06:00:32PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk I believe I understand your concern, so I have the following question for the WG. Do folks feel comfortable changing the base spec to now state that application-ids are optional in the routing decision process? I really need some feedback from the WG to determine whether folks are in general agreement with such a change. It is a rather large change to make during a last call. If I make such a change now, and later the WG decides it was a bad idea, it could require another cycle through last call. PatC On Mon, Aug 27, 2001 at 06:00:32PM -0500, Sreemanthula Srinivas (NRC/Dallas) wrote: > >On Mon, Aug 27, 2001 at 04:23:09PM -0500, Sreemanthula Srinivas > (NRC/Dallas) wrote: > >> Pat, thanks for the reply. But, I feel that the "gateway" nodes are > >> more than likely proxy nodes that are located on the edge of a > network > >> (realm). > > > >Just want to make sure that you understand that the use of the term > proxy > >node implies specific functionality. If you are not aware of that, I > would > >urge you to read section 2.9.2 in the base spec (but if you are in fact > >talking about a proxy, then ignore my comment). > > I see that they can enforce routing, roaming and other policies, > hence they are proxies. > > >> All the messages for this realm will arrive at this gateway > >> node based on realm based routing. They may have the knowledge of > >> specific AAA servers within its realm supporting specific > applications > >> (MIP, NASREQ etc.) and perform the routing using the application > >> identifier information. > > >Right, and the reason your network would work this way is because the > "gateway" > >advertises itself as a relay (advertises all applications), so it is > guaranteed > >to receive all requests destined for the local realm. The "gateway" > then > >forwards the message to the appropriate internal server, based on the > >application. > > >This is exactly the way the base spec is written. > > My understanding is that only Relay and redirect agents use the "Relay" > application > id while others must specifically advertise the supported identifiers. > > >> The point, which not clear from the existing > >> text, is that the use of application identifiers is not a MUST (or > >> required as in the text) but there are cases where it is useful and > >> therefore a "MAY". > > >Your above sentence unfortunately confuses me. Are you stating that the > >routing using appl-id is NOT a MUST in the current spec, or that it is > >and you want it softened? If the former, then it needs to be fixed, if > >the latter, please provide why the above example, using the existing > text, > >doesn't work for you. > > Ok, it is the latter. The use of application id in routing need only be > optional. > We are insisting on the realm based routing, because this guarantees > that any diameter > message will arrive at the destination network irrespective of the > capabilities supported > in the intermediary network. We do not want the message to be rejected > because some > broker is not able to support the application. This may be more of an > issue as new applications For two networks A and B supporting a new > application id, > > >Thanks, > > >PatC From owner-aaa-wg@merit.edu Mon Aug 27 19:05:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03842 for ; Mon, 27 Aug 2001 19:05:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2644091296; Mon, 27 Aug 2001 19:06:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E806A9129B; Mon, 27 Aug 2001 19:06: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 D5F2591296 for ; Mon, 27 Aug 2001 19:06:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B69065DDB8; Mon, 27 Aug 2001 19:06: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 72D695DDA7 for ; Mon, 27 Aug 2001 19:06:20 -0400 (EDT) Received: (qmail 25720 invoked by uid 500); 27 Aug 2001 22:53:58 -0000 Date: Mon, 27 Aug 2001 15:53:58 -0700 From: Pat Calhoun To: "Sreemanthula Srinivas (NRC/Dallas)" Cc: "'ext Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Message-ID: <20010827155358.F23877@charizard.diameter.org> Mail-Followup-To: "Sreemanthula Srinivas (NRC/Dallas)" , 'ext Pat Calhoun' , aaa-wg@merit.edu References: <07EE0E021034014F99A57B032BC9C0E50BDA5F@daebe001.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: <07EE0E021034014F99A57B032BC9C0E50BDA5F@daebe001.NOE.Nokia.com>; from Srinivas.Sreemanthula@nokia.com on Mon, Aug 27, 2001 at 06:03:33PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Ok, it is the latter. The use of application id in routing need only be > optional. > We are insisting on the realm based routing, because this guarantees > that any diameter > message will arrive at the destination network irrespective of the > capabilities supported > in the intermediary network. We do not want the message to be rejected > because some > broker is not able to support the application. This may be more of an > issue as new applications come in action. For two networks A and B > supporting a new application id, there is no > need for intermediary network to be upgraded. If it is a proxy, then by its very definition, the intermediary network MUST be upgraded. A proxy is a intermediate device that understands specific applications, and makes policy changes to request and/or answer messages. In order to make such changes, it must be upgraded to support future applications. It really sounds like you want a relay, and not a proxy. PatC From owner-aaa-wg@merit.edu Mon Aug 27 19:11: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 TAA03950 for ; Mon, 27 Aug 2001 19:11:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 806309129B; Mon, 27 Aug 2001 19:11:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47E309129C; Mon, 27 Aug 2001 19:11: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 156589129B for ; Mon, 27 Aug 2001 19:11:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D836C5DDB8; Mon, 27 Aug 2001 19:11:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 8AB255DDA7 for ; Mon, 27 Aug 2001 19:11:56 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7RNC2i24012 for ; Mon, 27 Aug 2001 18:12:02 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Aug 2001 18:11:55 -0500 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 18:11:55 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Date: Mon, 27 Aug 2001 18:11:55 -0500 Message-ID: <07EE0E021034014F99A57B032BC9C0E50BDA60@daebe001.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 123: Use of Application Identifiers in routing X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEvTONJeqc9zJs/EdWBSQBQi2X+DwAAo+2w From: "Sreemanthula Srinivas (NRC/Dallas)" To: "'ext Pat Calhoun'" Cc: X-OriginalArrivalTime: 27 Aug 2001 23:11:55.0866 (UTC) FILETIME=[AA4413A0:01C12F4D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03950 -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: 27 August, 2001 5:54 PM To: Sreemanthula Srinivas (NRC/Dallas) Cc: 'ext Pat Calhoun'; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 123: Use of Application Identifiers in routing >> Ok, it is the latter. The use of application id in routing need only be >> optional. >> We are insisting on the realm based routing, because this guarantees >> that any diameter >> message will arrive at the destination network irrespective of the >> capabilities supported >> in the intermediary network. We do not want the message to be rejected >> because some >> broker is not able to support the application. This may be more of an >> issue as new applications come in action. For two networks A and B >> supporting a new application id, there is no >> need for intermediary network to be upgraded. >If it is a proxy, then by its very definition, the intermediary network >MUST be upgraded. A proxy is a intermediate device that understands specific >applications, and makes policy changes to request and/or answer messages. >In order to make such changes, it must be upgraded to support future >applications. >It really sounds like you want a relay, and not a proxy. But, the intermediary networks can have their own proxies for determining diamter traffic or for any other purposes. I had taken the example of gateways to show that the application ids are indeed useful. But, the use of application ids can be a problem in the deployment at a large scale. Hence, I would like to make the suggestion of optional use of application ids in the routing. Thanks, Srini PatC From owner-aaa-wg@merit.edu Mon Aug 27 19:15:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03996 for ; Mon, 27 Aug 2001 19:15:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3CD09129C; Mon, 27 Aug 2001 19:15:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A36EF9129D; Mon, 27 Aug 2001 19:15: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 0B5CF9129C for ; Mon, 27 Aug 2001 19:15:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC2685DDB8; Mon, 27 Aug 2001 19:15: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 6761C5DDA7 for ; Mon, 27 Aug 2001 19:15:09 -0400 (EDT) Received: (qmail 25770 invoked by uid 500); 27 Aug 2001 23:02:47 -0000 Date: Mon, 27 Aug 2001 16:02:47 -0700 From: Pat Calhoun To: "Sreemanthula Srinivas (NRC/Dallas)" Cc: "'ext Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 123: Use of Application Identifiers in routing Message-ID: <20010827160247.H23877@charizard.diameter.org> Mail-Followup-To: "Sreemanthula Srinivas (NRC/Dallas)" , 'ext Pat Calhoun' , aaa-wg@merit.edu References: <07EE0E021034014F99A57B032BC9C0E50BDA60@daebe001.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: <07EE0E021034014F99A57B032BC9C0E50BDA60@daebe001.NOE.Nokia.com>; from Srinivas.Sreemanthula@nokia.com on Mon, Aug 27, 2001 at 06:11:55PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk > >> Ok, it is the latter. The use of application id in routing need only > be > >> optional. > >> We are insisting on the realm based routing, because this guarantees > >> that any diameter > >> message will arrive at the destination network irrespective of the > >> capabilities supported > >> in the intermediary network. We do not want the message to be > rejected > >> because some > >> broker is not able to support the application. This may be more of > an > >> issue as new applications come in action. For two networks A and B > >> supporting a new application id, there is no > >> need for intermediary network to be upgraded. > > >If it is a proxy, then by its very definition, the intermediary network > >MUST be upgraded. A proxy is a intermediate device that understands > specific > >applications, and makes policy changes to request and/or answer > messages. > >In order to make such changes, it must be upgraded to support future > >applications. > > >It really sounds like you want a relay, and not a proxy. > > But, the intermediary networks can have their own proxies for > determining diamter > traffic or for any other purposes. Perhaps I am just not seeing the proposed scenario. A proxy is a box that MUST support a given application, but you seem to state that it doesn't need to, and will not be upgraded in the future, but at the same time you want to receive all traffic, regardless of the app. Sounds like a hybrid between a relay and a proxy, and given that we've never explored such a scenario before (it wasn't even in any of the ROAMOPS or NASREQng, or even the AAA WG proxy draft), I am having a hard time justifying to myself that such a change is needed. However, I will shut up, and will take input from the list. PatC From owner-aaa-wg@merit.edu Tue Aug 28 00:13: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 AAA10464 for ; Tue, 28 Aug 2001 00:13:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B1E7912A5; Mon, 27 Aug 2001 23:58:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEF18912A6; Mon, 27 Aug 2001 23:58: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 B05BB912A5 for ; Mon, 27 Aug 2001 23:57:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 967C65DDD3; Mon, 27 Aug 2001 23:57:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3F99B5DDCC for ; Mon, 27 Aug 2001 23:57:59 -0400 (EDT) Received: (qmail 26377 invoked by uid 500); 28 Aug 2001 03:45:36 -0000 Date: Mon, 27 Aug 2001 20:45:36 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: stephen.farrell@baltimore.ie, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Revalidation of cache in CMS (again) Message-ID: <20010827204536.D26162@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , stephen.farrell@baltimore.ie, aaa-wg@merit.edu References: <3B78F93A.27DBBAB3@rioja.ericsson.se> <3B7CFE35.4325274A@baltimore.ie> <3B84C747.920689F1@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: <3B84C747.920689F1@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Thu, Aug 23, 2001 at 11:05:11AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit This really needs to be added as an official issue, otherwise I will most certainly miss it in my review of pending issues. PatC On Thu, Aug 23, 2001 at 11:05:11AM +0200, Miguel Ángel Monjas Llorente wrote: > Sorry. Some of you might have received this mail badly. I hope this > one will be received better... > > =========================================== > > Hi Stephen, > > sorry for the latency, but I've hardly had time to review the whole > specification. > > > I agree that the text is a bit vague. I'd suggest adding the > > additional text below. Note that this is a "lax" PKI policy > > which assumes e.g. that no new (relevant) CRLs are produced > > before the nextUpdate field, but I'd argue that that's ok > > for Diameter since I wouldn't expect very frequent > > revocations in this context. > > > > The next text should go in below the current text. > > > > Does this solve the problem? > > From my humble point of view, just partially. As far as I understand, > you're approach is very PKI-centric. I mean, my original question was > really about how the "vague" original paragraph should be understood. > > Let me explain it with some figures. > > This is the scenario as far as I understood it (before you added your > clarification time): > > __________________________________________________ > DSA | > ================================== | > | | | | > beginning of | | | > the DSA t1 (any special time | | > in which a message | | > is issued) | | > end of the DSA | > t2 (other > issued message) > > What I wanted to assure is that in t1, the implementation may choose > not to revalidate the certificates. But in t2, the implementation must > revalidate the certificates. This statement wasn't clear (in my > oppinion), and I wanted to make it more explicit. > > You've introduced a very interesting point (more related to PKI). In > short, it's the following (please, correct me if I'm wrong): > > Depending on the parameters of the certificates belonging to the > certificate chain (or belongint to the OCSP response or the CRL), a > "safe" period with no revocation checks will be computed (I assume > that if this safe period is smaller than the length of the DSA, a > revocation check must be done once the safe period ends; but in the > other hand, if the safe period is bigger than the DSA length, the > revalidation must be done once the DSA expires). Additional checks > might be done depending on the local PKI policy. > > My conclusion is that the following paragraph must be changed: > > Implementations MAY cache the information required to establish a > DSA, but MUST honor time-to-live settings and MUST re-validate > certificates (possibly including revocation checks) before using > cached data. > > With this paragraph: > > Implementations MAY cache the information required to establish a > DSA. However, they MUST honor time-to-live settings so that > certificates MUST re-validated (possibly including revocation > checks) once the DSA has expired. > > Revalidations MIGHT also occur before the DSA expires according to > PKI policies. During the process of certificate path validation... > > and the rest of the contributions by Stephen > > 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 Aug 28 00:19: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 AAA10555 for ; Tue, 28 Aug 2001 00:19:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 412B091273; Tue, 28 Aug 2001 00:20:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06C9C912A7; Tue, 28 Aug 2001 00:20: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 D264291273 for ; Tue, 28 Aug 2001 00:20:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA29E5DDD3; Tue, 28 Aug 2001 00:20:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 28F765DDCC for ; Tue, 28 Aug 2001 00:20:31 -0400 (EDT) Received: from gwzpc (rtp-dial-1-19.cisco.com [10.83.97.19]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA07752; Mon, 27 Aug 2001 21:19:13 -0700 (PDT) Reply-To: From: "Glen Zorn" To: =?iso-8859-1?Q?Tom_Weckstr=F6m?= Cc: "John Schnizlein" , "Bernard Aboba" , "Randy Bush" , Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? Date: Mon, 27 Aug 2001 21:18:36 -0700 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: <3B8A68A0.677B647D@cc.hut.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit A draft spedc is available to WECA members only. I attended the last WISPr meeting. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Tom Weckström > Sent: Monday, August 27, 2001 8:35 AM > To: gwz@cisco.com > Cc: John Schnizlein; Bernard Aboba; Randy Bush; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: WECA 'extending' RADIUS? > > > > Hello folks. > > I digged this thread from my ancient-old unread AAA emails. > Has there been any more news on the WISPr and its adventures lately? > Is there any draft specs available inside or outside WECA? > What is the timeframe for this project? > Have anyone of the AAA WG members been in contact or > otherwise involved in the WISPr work? > > Best Regards, > Tom > > Glen Zorn wrote: > > > > John Schnizlein [mailto:jschnizl@cisco.com] writes: > > > > > What is the fuss about? > > > The reporter discovered that using RADIUS accounting for 802.11b > > > wireless access exploits the benefits built into it for dial access. > > > Nice of him to notice, but not a technology breakthrough. > > > > If it was just the reporter it wouldn't bother me, but it seems > that WISPr > > itself is on a voyage of discovery through laboriously charted lands... > > > > > > > > The article does not mention any extensions to RADIUS, > > > it simply describes a new use of RADIUS, especially its capability > > > for global roaming through what we have been calling proxy forwarding. > > > The "tag" the article mentions is just the home domain. > > > > >From the article: > > > > "Specifically, WISPr is looking to define a tag that users > could tack onto > > their subscriber name. > > ^^^^^^ > > The tag will alert any WISP that the user requesting service is > "owned" by > > some other provider." > > > > RFC 2486. > > > > > > > > The discussion about the importance of billing might create the > > > impression of something new, but it looks like RADIUS > accounting to me. > > > And clearinghouse technology for RADIUS accounting has been used for > > > PPP and voice calls, so this is not new either. > > > > >From the article, again: > > '"The billing systems are key to this," Homan said. "We're extending the > > RADIUS protocol with specific [new] attributes, such as user name, time > > spent online, bytes in or out, and so on. We'll also have > information about > > where the user is, through a location code, so we can return > site-specific > > services to that user.' > > > > Of these, the only thing that is new is the "location code" (which poses > > significant privacy issues, BTW). Note that this quote is from a WISPr > > "spokesman", not the reporter. Although it's certainly > possible that he was > > misquoted, if this statement is close to accurate we have > people "extending" > > the RADIUS protocol with "features" already present in it... > > > > > > > > Considering who has chimed in on this thread, > > > I am now wearing my flame-retardant shorts. ;-) > > > > > > John > > > > > > At 11:22 AM 6/1/2001, Bernard Aboba wrote: > > > >A good argument for "Expert review" as opposed to IANA assignment ;) > > > > > > > >On Fri, 1 Jun 2001, Randy Bush wrote: > > > >> via bert > > > >> > > > >> Story date(time): 05/29/2001(02:18 AM) > > > >> Effort afoot to provide wireless LAN roaming > > > >> InfoWorld Daily News via DowVision > > > >> > > > >> By John Cox, Network World Fusion InfoWorld.com > > > > > > > > -- > Tom Weckström Dynamics group > Helsinki University of Technology > dynamics@cs.hut.fi > http://www.cs.hut.fi/Research/Dynamics/ > From owner-aaa-wg@merit.edu Tue Aug 28 00: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 AAA10657 for ; Tue, 28 Aug 2001 00:24:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA64B912A7; Tue, 28 Aug 2001 00:25:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5ED0912A8; Tue, 28 Aug 2001 00:25: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 99FF0912A7 for ; Tue, 28 Aug 2001 00:25:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 796965DDD3; Tue, 28 Aug 2001 00:25: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 A2C215DDCC for ; Tue, 28 Aug 2001 00:25:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id VAA31125; Mon, 27 Aug 2001 21:17:36 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 27 Aug 2001 21:17:36 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues In-Reply-To: <20010827150715.A23877@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk WEP reference is correct. Will try to find reference for WEP-128 (there is no IEEE standard for this). RFC 3162 will issue soon. On Mon, 27 Aug 2001, Pat Calhoun wrote: > Bernard, > > You implied new issues in the following statement: > > "I also believe that the following issues need to be re-opened: > > nasreq-07: Issue #29 (need to substitute RFC 3162 attribute #s for > TBD) > Issue #36 (need to remove AES/OCB from list, change "WEP2" > to WEP-128"). " > > I will create two new issues (easier to track than re-opening the old ones). > As far as the second issue, is the following the correct reference for WEP? > > [22] Information technology - Telecommunications and information > exchange between systems - Local and metropolitan area networks - > Specific Requirements Part 11: Wireless LAN Medium Access Control > (MAC) and Physical Layer (PHY) Specifications, IEEE Std. > 802.11-1999, 1999. > > Thanks, > > PatC > From owner-aaa-wg@merit.edu Tue Aug 28 03:38:55 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28892 for ; Tue, 28 Aug 2001 03:38:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10F56912BF; Tue, 28 Aug 2001 03:36:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDE0D912BD; Tue, 28 Aug 2001 03:36: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 1D4C5912C3 for ; Tue, 28 Aug 2001 03:34:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E79225DDE8; Tue, 28 Aug 2001 03:34:49 -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 21B6C5DDD3 for ; Tue, 28 Aug 2001 03:34:49 -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 f7S7YkK16486 for ; Tue, 28 Aug 2001 09:34:47 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA07452; Tue, 28 Aug 2001 09:34:44 +0200 (MET DST) Message-ID: <3B8B49AC.BF0E9EA5@rioja.ericsson.se> Date: Tue, 28 Aug 2001 09:35: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 Subject: Re: [AAA-WG]: Issue 142: CEKMaxDecrypts value cs DSA length References: <20010827134903.U23877@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: > > Miguel, > > I'm not sure if you are genuinely confused, or if you were just making a > point, Just making a point. > but the difference between both is that the CEKMaxDecrypts > is used throughout the length of a DSA. The CEK draft discusses how > keys are re-used within CMS, so this happens within the CMS protocol. > The DSA TTL, however, states when the DSA expires, and a new DSAR message > needs to be sent. > > Is this clearer? Yes. It's clear. That's what I thought but I just wanted to know whether I was right. My basic pursose is to make the specification as accurate as possible to prevent any possible error in implementation... A paragraph similar to the previous by you would be very explicit (but it's up to you). Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 03:39: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 DAA28904 for ; Tue, 28 Aug 2001 03:39:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67C4491320; Tue, 28 Aug 2001 03:38:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22C4391322; Tue, 28 Aug 2001 03:38: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 BC2AD91320 for ; Tue, 28 Aug 2001 03:38:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A534C5DDE8; Tue, 28 Aug 2001 03:38:30 -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 D8A5C5DDD3 for ; Tue, 28 Aug 2001 03:38:29 -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 f7S7cSK19301 for ; Tue, 28 Aug 2001 09:38:28 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA07701; Tue, 28 Aug 2001 09:38:26 +0200 (MET DST) Message-ID: <3B8B4A9B.E1EC30D5@rioja.ericsson.se> Date: Tue, 28 Aug 2001 09:39: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: Re: [AAA-WG]: Issue 141: OCSP Response request additional text References: <20010827104944.D23877@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: > > I would like to propose the following text to replace the paragraph > pointed to by this issue: > > " If the DSA initiator's policy states that certicate status is > required, it MUST indicate that it requires an OCSP response from > the DSA peer in the DSAA message, via the OCSP-Request AVP. Further, > the DSA initiator MAY request that the OCSP response be fresh (non > cached) via the OCSP-Request and OCSP-Nonce AVPs. Upon receipt of > a DSAR message requesting an OCSP response, the receiver issues an > OCSP request and returns the response within the DSAA message's > OCSP-Responses AVP. The sender of the DSAA MAY included a cached > OCSP response, unless the requestor specifically requested a fresh > response." > > Comments appreciated, I wouldn't say it better. Go with it!! Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 03:56: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 DAA29080 for ; Tue, 28 Aug 2001 03:56:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44546912BE; Tue, 28 Aug 2001 03:57:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09C5B912C3; Tue, 28 Aug 2001 03:57: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 E5C0D912BE for ; Tue, 28 Aug 2001 03:57:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7C625DDE8; Tue, 28 Aug 2001 03:57:03 -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 EED635DDD3 for ; Tue, 28 Aug 2001 03:57:02 -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 f7S7upv29047 for ; Tue, 28 Aug 2001 09:56:56 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA09114; Tue, 28 Aug 2001 09:56:25 +0200 (MET DST) Message-ID: <3B8B4ED1.AA8E7465@rioja.ericsson.se> Date: Tue, 28 Aug 2001 09:57: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]: Issue 133: digest value within CMS-Signed-Data AVP References: <20010827073849.D23877@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 proposed text reads: > > "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 in the SingerInfo value. > This attribute MUST be always signed." > > What attribute must be signed, and are we talking about digital > signatures, or the format of the field? That sentence is actually redundant. It simply regards the CMS specification (RFC 2630) but, in fact, I misread the paragraph since "The countersignature attribute must be an unsigned attribute". Anyway, it has only to do with objects of SignedData type, so that this sentence can be dropped since the process to generate a CMS SignedData object will always keep countersignature as an unsigned attribute. Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 04:29: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 EAA29508 for ; Tue, 28 Aug 2001 04:29:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 761D3912CC; Tue, 28 Aug 2001 04:23:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36E1091274; Tue, 28 Aug 2001 04:23: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 73484912CC for ; Tue, 28 Aug 2001 04:22:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 503AC5DDE2; Tue, 28 Aug 2001 04:22: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 472195DDCF for ; Tue, 28 Aug 2001 04:22: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 f7S8Mtv25034 for ; Tue, 28 Aug 2001 10:22:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA11144; Tue, 28 Aug 2001 10:22:50 +0200 (MET DST) Message-ID: <3B8B5503.6BCE731@rioja.ericsson.se> Date: Tue, 28 Aug 2001 10:23: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: Re: [AAA-WG]: Issue 133: digest value within CMS-Signed-Data AVP References: <20010827073849.D23877@charizard.diameter.org> <3B8B4ED1.AA8E7465@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 Please, drop the previous mail... I was cross-answering several Pat's mails and I've mixed the content of two of them... What I wanted to say is depicted below: Pat Calhoun wrote: > > The proposed text reads: > > "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 in the SingerInfo value. > This attribute MUST be always signed." > > What attribute must be signed, and are we talking about digital > signatures, or the format of the field? That sentence is actually redundant. It simply "quotes" the CMS specification (RFC 2630) which says that (in signing context) "The message-digest attribute must be a signed attribute". That is, in the framework of CMS SignedData objects, message-digest attributes must be signed. However, saying that in the Diameter CMS specification can be confused. I agree on dropping that sentence since the process to generate a CMS SignedData object will always keep message-digest as a signed attribute. The paragraph should be something like the following: "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 in the SingerInfo value (message-digest attributes are defined in 11.2 of [3])" Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 04:33: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 EAA29582 for ; Tue, 28 Aug 2001 04:33:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DA5491274; Tue, 28 Aug 2001 04:34:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8DC6912C0; Tue, 28 Aug 2001 04:34: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 8C23991274 for ; Tue, 28 Aug 2001 04:33:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25EC15DDE2; Tue, 28 Aug 2001 04:33:41 -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 6665E5DDCF for ; Tue, 28 Aug 2001 04:33:40 -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 f7S8Xcv05366 for ; Tue, 28 Aug 2001 10:33:39 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA11861; Tue, 28 Aug 2001 10:33:35 +0200 (MET DST) Message-ID: <3B8B5787.349DF183@rioja.ericsson.se> Date: Tue, 28 Aug 2001 10:34: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 132: Multiple signatures on a set of AVPs References: <20010827073216.C23877@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 original issue included the following proposed text: > > "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. This > attribute MUST be always unsigned." > > I have two comments. First, I'd like to propose the following text > instead (a slight variation from the above): > > "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. This > attribute MUST be always unsigned. " I've read carefully both paragraphs and... they are the same!!! Finally I checked the original paragraph proposed by my and saw what is Pat proposing (sometimes cut&paste fails :-))) The change is stylistic (and sounds better), so that you can go ahead with your proposal. > My second comment has to do with the last sentence. What exactly is > the attribute that must be unsigned? Does this mean unsigned as in > how the field is treated (meaning most significant bit is part of the > value), or rather that the attribute doesn't include a digital signature? > If the latter, then the text reads that the countersignature attribute > requires a signature, but it is unsigned. > > confused Yes, a little bit confused. In my answer to issue #133 I make it clear: according to CMS specification, countersignature is an unsigned attribute within a SignedData SignedInfo value while message-digest is signed. But those facts are relevant within CMS not in Diameter CMS Security. My proposal is to drop that sentence: "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. " Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 04: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 EAA29634 for ; Tue, 28 Aug 2001 04:36:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B74DC912C0; Tue, 28 Aug 2001 04:37:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86C2C912C1; Tue, 28 Aug 2001 04:37: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 66B38912C0 for ; Tue, 28 Aug 2001 04:37:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 331055DDE9; Tue, 28 Aug 2001 04:37: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 0FE7C5DDCF for ; Tue, 28 Aug 2001 04:37: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 f7S8bDK22488 for ; Tue, 28 Aug 2001 10:37:14 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA12108; Tue, 28 Aug 2001 10:37:11 +0200 (MET DST) Message-ID: <3B8B5860.C783A073@rioja.ericsson.se> Date: Tue, 28 Aug 2001 10:37: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: [AAA-WG]: Issue 139: Key Management chapter rephrasing References: <20010827102936.A23877@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, > > Below is my proposed text for the new section 3.0: > > 3.0 Key Management > > For DSA origin authentication, CMS itself already provides sufficient > key management without the need for additional specification. Basically, > the originating Diameter node signs and includes whatever certificates > are necessary for validation of the digital signature. Section 3.1 > provides an example of how the Diameter CMS Security application is used. > > In order to encrypt AVPs for a recipient, the originating Diameter > node must have a copy of the recipient's public key. There are many > well-known key retrieval schemes (e.g. LDAP [6]), but this > specification also allows for the transportation of certificates > within Diameter AVPs, which is expected to simplify implementations. > Section 3.2 describes how Diameter node names are encoded within such > certificates. > > Finally, it is anticipated that the overhead of key generation for > each Diameter message sent to a given peer could be significant. > Section 3.4 specifies how CMS encryption keys may be reused for > multiple Diameter messages." > > Comments appreciated, Section 3.0 is much more clear now. A last comment... Does it make any sense to keep 3.3 section (algorithms) within 3.0 (focused on key management). Wouldn't be better to put it outside (maybe like a top-level chapter)? Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 05:43: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 FAA00656 for ; Tue, 28 Aug 2001 05:43:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96A79912C1; Tue, 28 Aug 2001 05:44:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 681D9912C2; Tue, 28 Aug 2001 05:44: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 4A110912C1 for ; Tue, 28 Aug 2001 05:44:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 213E85DDD6; Tue, 28 Aug 2001 05:44: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 1F2595DD96 for ; Tue, 28 Aug 2001 05:44:30 -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 f7S9iSK21374 for ; Tue, 28 Aug 2001 11:44:29 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA17164; Tue, 28 Aug 2001 11:44:24 +0200 (MET DST) Message-ID: <3B8B6821.DE20965@rioja.ericsson.se> Date: Tue, 28 Aug 2001 11:45: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]: Issue 138: Signed DSA messages References: <20010827094525.V23877@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: > > This issue has to do with the fact that there is no mandatory AVP > in the DSAA, which MUST be signed, whose 'P' bit MUST be set. One > proposal (above) is to require that the DSA-TTL AVP MUST have the 'P' > bit set. However, the DSA-TTL is also mandatory in the DSAR, which > currently states that it SHOULD be signed, and such a change would > make it a MUST be signed. > > I propose that the AAA-Server-Certs AVP MUST have the 'P' bit set, > which will require the presence of the CMS-Signed-AVP AVP. The solution seems good to me. However, it only solves half the problem. I mean, it deals only with the DSAA message. But, what happens with the DSAR message? There is also no mandatory AVP in the DSAR. Expected-Signed-AVP and Expected-Encrypted-AVP are mandatory to protect, so that, if issued, the must be signed. But, what happens if no such AVPs are included in the DSAR? Let's imagine the following scenario. A NAS is wishing to send accounting messages to a Home Server. It's supposed that such messages will contain AVPs that must be encrypted. But the indication about such fact will be carried by the DSAA issued by the Home Server, not by the NAS. So that, the NAS will establish a DSA with the Home Server in order to send subsequently accounting messages. It's up to the Home Server to include an Expected-Encrypted-AVP in its DSAA. The DSAR won't include any AVP which must be protected. If so, the problem is the same as the stated in the original issue.... Comments? // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 06:02: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 GAA00825 for ; Tue, 28 Aug 2001 06:02:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11F6D912C2; Tue, 28 Aug 2001 06:03:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3876912C3; Tue, 28 Aug 2001 06:03: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 B781E912C2 for ; Tue, 28 Aug 2001 06:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CF745DDB2; Tue, 28 Aug 2001 06:03:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id D22FF5DD96 for ; Tue, 28 Aug 2001 06:03: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 f7SA3PK03975; Tue, 28 Aug 2001 12:03:25 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA18400; Tue, 28 Aug 2001 12:03:21 +0200 (MET DST) Message-ID: <3B8B6C92.BEAA2280@rioja.ericsson.se> Date: Tue, 28 Aug 2001 12:04: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 137: CMS Proxy's DSAAs References: <20010827091226.R23877@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: > > so as you can see from above, the 'E' bit wouldn't be set for errors > in the 5xxx class, which is where the CMS Result-Code AVP values are > defined. > > So I propose that we reject this issue. OK. I understand what you mean (I didn't read carefully the base specification about the different kinds of errors). But the fact I was trying to point is the following: what happens with the format of a DSAA when a Permanent Error result code is issued by a proxy? Which is the content of AAA-Server-Certs and DSA-TTL AVPs when the result code is 5020 or 5021 (since no DSA is finally established)? Comments? // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 06:14:50 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 GAA00928 for ; Tue, 28 Aug 2001 06:14:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7B8A9131C; Tue, 28 Aug 2001 06:11:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1386591322; Tue, 28 Aug 2001 06:11: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 C9FCC9131D for ; Tue, 28 Aug 2001 06:11:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A775C5DDCF; Tue, 28 Aug 2001 06:11:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id D308B5DDB2 for ; Tue, 28 Aug 2001 06:11:51 -0400 (EDT) Received: from rioja.ericsson.se (rioja.es.eu.ericsson.se [164.48.92.5]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7SABnv23099 for ; Tue, 28 Aug 2001 12:11:50 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA18949; Tue, 28 Aug 2001 12:11:47 +0200 (MET DST) Message-ID: <3B8B6E8D.74822334@rioja.ericsson.se> Date: Tue, 28 Aug 2001 12:12:29 +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 144: OCSP support References: <20010827110746.F23877@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, > > In order to fix this problem, I've added text to section 3.1: > > " In the event the DSAR requested OCSP validation, via the > OCSP-Request AVP, and OCSP is not locally supported, the DSAA > MUST be returned with the Result-Code AVP set to > DIAMETER_OCSP_NOT_SUPPORTED. Otherwise, the destination node > returns the DSAA message which contains:" > > and added the following Result-Code value: > > DIAMETER_OCSP_NOT_SUPPORTED 5022 > This error code is returned when a DSAR message is received > requesting OCSP validation, and the receiver does not support OCSP. > > Does this work? It looks a good solution. But after reviewing the Base Specification in order to answer to issue 137 I've noticed that a permanent failure means that "that the request failed, and should not be attempted again". Is that really true? I mean, when a node requests OCSP validation and OCSP is not locally supported, the DSA must be dropped? I consider that the originator may determine then whether it is willing to provide service, based on its local policy. Shouldn't be DIAMETER_OCSP_NOT_SUPPORTED a transient failure error? Comments? // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 06:15: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 GAA00944 for ; Tue, 28 Aug 2001 06:15:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 792539131D; Tue, 28 Aug 2001 06:15:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31E649132B; Tue, 28 Aug 2001 06:15: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 E1B619131D for ; Tue, 28 Aug 2001 06:15:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5FEA5DDCF; Tue, 28 Aug 2001 06:15: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 C3D155DD96 for ; Tue, 28 Aug 2001 06:15: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 f7SAFQv25957 for ; Tue, 28 Aug 2001 12:15:26 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA19181; Tue, 28 Aug 2001 12:15:23 +0200 (MET DST) Message-ID: <3B8B6F65.BFB08ACD@rioja.ericsson.se> Date: Tue, 28 Aug 2001 12:16: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]: Revalidation of cache in CMS (again) References: <3B78F93A.27DBBAB3@rioja.ericsson.se> <3B7CFE35.4325274A@baltimore.ie> <3B84C747.920689F1@rioja.ericsson.se> <20010827204536.D26162@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: > > This really needs to be added as an official issue, otherwise I will > most certainly miss it in my review of pending issues. OK. I'll do it in the appropriate way Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 06:33: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 GAA01218 for ; Tue, 28 Aug 2001 06:33:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D5BE912C4; Tue, 28 Aug 2001 06:34:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD05D912C6; Tue, 28 Aug 2001 06:34:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6B0E912C4 for ; Tue, 28 Aug 2001 06:34:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C2855DDCF; Tue, 28 Aug 2001 06:34: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 350DB5DD96 for ; Tue, 28 Aug 2001 06:34: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 f7SAYfK25464 for ; Tue, 28 Aug 2001 12:34:41 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA20453; Tue, 28 Aug 2001 12:34:38 +0200 (MET DST) Message-ID: <3B8B73E8.8F90AE73@rioja.ericsson.se> Date: Tue, 28 Aug 2001 12:35: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] Revalidation of certificates in cache 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-27 Reference: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00083.html and http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html Document: CMS-02 Comment type: T Priority: S Section: Rationale/Explanation of issue: According to the CMS draft (3.1, Usage Scenario), the implementations of CMS may cache DSA setup information. Also, they must honor the TTL setting and re-validate certificates before using cached data. The draft looks a little bit confused, so that Stephen Farrel proposed and additional text in order to make it clear (see http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00101.html). His basic statement was the following: Depending on the parameters of the certificates belonging to the certificate chain (or belongint to the OCSP response or the CRL), a "safe" period with no revocation checks will be computed (I assume that if this safe period is smaller than the length of the DSA, a revocation check must be done once the safe period ends; but in the other hand, if the safe period is bigger than the DSA length, the revalidation must be done once the DSA expires). Additional checks might be done depending on the local PKI policy. However, from my humble point of view, the text just partially solved the problem since its approach was very PKI-centric. I'll explain my approach with some figures. This is the scenario as far as I understood it: ____________________________________________ DSA | ================================== | | | | | beginning of | | | the DSA t1 (any special time | | in which a message | | is issued) | | end of | the DSA | t2 (other issued message) What I wanted to assure is that in t1, the implementation may choose not to revalidate the certificates. But in t2, the implementation must revalidate the certificates. This statement wasn't clear (in my oppinion), and I wanted to make it more explicit. Requested change: The following paragraph must be changed: Implementations MAY cache the information required to establish a DSA, but MUST honor time-to-live settings and MUST re-validate certificates (possibly including revocation checks) before using cached data. With this paragraph (which includes Stephen's contributions): Implementations MAY cache the information required to establish a DSA. However, they MUST honor time-to-live settings so that certificates MUST re-validated (possibly including revocation checks) once the DSA has expired. Revalidations MIGHT also occur before the DSA expires according to PKI policies. During the process of certificate path validation some implementations will calculate a duration for which the certificate path may be considered "safe". For example, if an implementation did not support certificate revocation checks, then the "safe" period would be from the time of initial validation until the earliest notAfter time in the set of certificates in the path. An implementation which does support certificate revocation checks will typically be able to calculate a "safe" period based additionally on the earliest nextUpdate field in a CRL or OCSP response. Basically, the safe period is from the time of certificate validation to the earliest value from the set of notAfter and nextUpdate fields encountered during certificate validation. However, implemetors should note that CAs MAY issue additional CRLs before the nextUpdate period. Generally it is a matter of local PKI policy as to whether an implementation will make additional checks even during the calculated "safe" period. For the purposes of this specification implementations are NOT REQUIRED to make such checks and MAY assume that no re-validation of certificates is required during the "safe" period defined above. 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 Aug 28 06:35: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 GAA01252 for ; Tue, 28 Aug 2001 06:35:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9868B912C6; Tue, 28 Aug 2001 06:36:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E136912C7; Tue, 28 Aug 2001 06: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 51F03912C6 for ; Tue, 28 Aug 2001 06:36:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E6925DDD3; Tue, 28 Aug 2001 06:36:49 -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 1E85C5DDCF for ; Tue, 28 Aug 2001 06:36:48 -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 f7SAakK26807 for ; Tue, 28 Aug 2001 12:36:46 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA20646; Tue, 28 Aug 2001 12:36:44 +0200 (MET DST) Message-ID: <3B8B7466.76E90295@rioja.ericsson.se> Date: Tue, 28 Aug 2001 12: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 126: Clarification in certificate naming schema References: <20010827115211.M23877@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 changes were requested in this issue: > > > - Unifying the terminology. Using "realm" always or "domain" always. > > This was already covered by another issue, and has since been fixed. > > > - To switch the long explanation of chapter 3.1 to a more appropriate > > place (chapter 3.2), including a reference to it in the item of 3.1 > > chapter. > > The text in 3.1 was replaced with: > > - the name in the certificate is consistent with the rules detailed > in section 3.2. > > > - Explaining which AVP is Host-Name AVP > > This was an error. The AVP in question is actually the Origin-Host AVP. > I have made that change. > > > > > Additionally I'd like to receive a clarification about the realms > > involved. I suppose that the "realm part of the user's NAI" is carried > > by means of the Destination-Realm in the DSAR, but I'm not sure. BTW > > I've added clarifying text in 1.5: > > "... MUST belong to the same realm as the user being authorized (the > realm portion of the Network Access Identifier found in the User-Name AVP)" OK. Those changes solve all my concerns Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 08:49: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 IAA08151 for ; Tue, 28 Aug 2001 08:49:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 916D9912CB; Tue, 28 Aug 2001 08:50:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61176912CD; Tue, 28 Aug 2001 08:50: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 2049F912CB for ; Tue, 28 Aug 2001 08:50:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F30EB5DDCF; Tue, 28 Aug 2001 08:50:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 79FCF5DDC7 for ; Tue, 28 Aug 2001 08:50:17 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15903; Tue, 28 Aug 2001 06:50:11 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07331; Tue, 28 Aug 2001 08:50:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.6+Sun/8.11.6) id f7SCp4A13279; Tue, 28 Aug 2001 08:51:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15243.37816.403980.879584@gargle.gargle.HOWL> Date: Tue, 28 Aug 2001 08:51:04 -0400 (EDT) From: James Carlson To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 146: CHAP Algorithm missing In-Reply-To: Pat Calhoun's message of 27 August 2001 14:55:14 References: <20010827142938.W23877@charizard.diameter.org> <20010827145514.Z23877@charizard.diameter.org> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun writes: > > CHAP-Auth ::= < AVP Header: 409 > > > { CHAP-Algorithm } > > { CHAP-Ident } > > [ CHAP-Response ] > > [ AVP ] This implies that the CHAP-Algorithm AVP is required, right? That might be too strong -- if I'm missing the CHAP-Ident, I know I can't process anything correctly, and it's therefore an error, but if I'm missing CHAP-Algorithm, I can reasonably assume 05 (MD5) and allow others to fail on the hash validation. (Requiring it is probably not a big deal, either ...) -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-aaa-wg@merit.edu Tue Aug 28 09:38: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 JAA10079 for ; Tue, 28 Aug 2001 09:38:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0EA291290; Tue, 28 Aug 2001 09:39:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE794912CD; Tue, 28 Aug 2001 09:39: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 8A23091290 for ; Tue, 28 Aug 2001 09:39:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62F2D5DDCD; Tue, 28 Aug 2001 09:39:41 -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 7D4AE5DDC2 for ; Tue, 28 Aug 2001 09:39:40 -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 f7SDdWK11762 for ; Tue, 28 Aug 2001 15:39:34 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA02816; Tue, 28 Aug 2001 15:39:28 +0200 (MET DST) Message-ID: <3B8B9F3B.58A0B79@rioja.ericsson.se> Date: Tue, 28 Aug 2001 15:40: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 136: Proxy's DSAR on behalf of a client References: <20010827090152.Q23877@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: > > Miguel, > > I've been reading this issue, and I don't understand it :( > > The issue states that a DSA created by a proxy on behalf of a client > should use some information from the first DSAR. I'm not sure what > the first DSAR is. Perhaps you meant PDSR, but the PDSR doesn't > include these AVPs. > > Any help would be appreciated, OK. I've made a mistake with this issue. I'll try to explain it. The point is that, according to figure 3, I thought that a previous DSA setup attempt was necessary to issue a PDSR. If so, it was natural to think that there must be some relationship between the parameters of the DSA setup attempt and the ones used by the proxy to establish it own DSA with the Home Server. There are actually two scenarios regarding proxy agents and CMS: - The NAS hasn't got any cryptographic capability (or knows that there's a proxy in its route or has been configured for always issuing a PDSR to its aggregating proxy), so that it issues a PDSR. It's up to the proxy to choose a DSA-TTL, provide Local-CA-Info or request OCSP responses. - The NAS has cryptographic capabilities (and doesn't know whether there's a proxy in its route). If so, it issues a DSAR when he needs it (according to its policy). The proxy provides the appropriate result code and, if the NAS allows to use it as CMS proxy, it will issue a PDSR. However, the proxy doesn't maintain any data from previous DSA setup attempst, so that its own DSAR uses parameters according to its policy, not to previous DSA setup data. Just a clarification, I'd add the following paragraph before the last one in page 6: If the access device determines that it is able to allow the proxy agent to establish a DSA on its behalf, it would issue a Proxy Diameter Security Association Request (PDSR). This request MUST contain the realm with wich the access server wants the server to establish a DSA. The proxy agent MUST use its own policy to establish the DSA (without using any of the parameters provided by the access device in the previous DSA setup attempt). Once established the DSA, the proxy agent MUST issue a Proxy Diameter Security Association Answer (PDSA). Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 09:46: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 JAA10205 for ; Tue, 28 Aug 2001 09:46:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67125912CD; Tue, 28 Aug 2001 09:47:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3695E912CE; Tue, 28 Aug 2001 09:47: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 20989912CD for ; Tue, 28 Aug 2001 09:47:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 065E15DDCF; Tue, 28 Aug 2001 09:47:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 711525DDCD for ; Tue, 28 Aug 2001 09:47:52 -0400 (EDT) Received: (qmail 27860 invoked by uid 500); 28 Aug 2001 13:35:28 -0000 Date: Tue, 28 Aug 2001 06:35:28 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client Message-ID: <20010828063528.A27840@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@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: <3B8B9F3B.58A0B79@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 03:40:11PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 03:40:11PM +0200, Miguel Ángel Monjas Llorente wrote: > OK. I've made a mistake with this issue. I'll try to explain it. The > point is that, according to figure 3, I thought that a previous DSA > setup attempt was necessary to issue a PDSR. If so, it was natural to > think that there must be some relationship between the parameters of > the DSA setup attempt and the ones used by the proxy to establish it > own DSA with the Home Server. It isn't necessary. In the example I've provided, the client tries to establish the DSA, and the proxy agent returns a failure. The client then requests that a DSA be established with the far end. The proxy agent establishes the DSA with the home server. If the proxy agent wants to cache information from the first DSAR, then it could, but this is purely an implementation issue. > > There are actually two scenarios regarding proxy agents and CMS: > > - The NAS hasn't got any cryptographic capability (or knows that > there's a proxy in its route or has been configured for always issuing > a PDSR to its aggregating proxy), so that it issues a PDSR. It's up to > the proxy to choose a DSA-TTL, provide Local-CA-Info or request OCSP > responses. correct. I believe this is the more common case. > - The NAS has cryptographic capabilities (and doesn't know whether > there's a proxy in its route). If so, it issues a DSAR when he needs > it (according to its policy). The proxy provides the appropriate > result code and, if the NAS allows to use it as CMS proxy, it will > issue a PDSR. However, the proxy doesn't maintain any data from > previous DSA setup attempst, so that its own DSAR uses parameters > according to its policy, not to previous DSA setup data. correct. > Just a clarification, I'd add the following paragraph before the last > one in page 6: > > If the access device determines that it is able to allow the proxy > agent > to establish a DSA on its behalf, it would issue a Proxy Diameter > Security Association Request (PDSR). This request MUST contain the > realm > with wich the access server wants the server to establish a DSA. The > proxy agent MUST use its own policy to establish the DSA (without > using > any of the parameters provided by the access device in the previous > DSA > setup attempt). Once established the DSA, the proxy agent MUST issue a > Proxy Diameter Security Association Answer (PDSA). ok, but the above no longer allows the proxy agent from using previous info from the DSAR, which it *could* use if it wanted to. There is no reason to prohibit it, no? PatC From owner-aaa-wg@merit.edu Tue Aug 28 09:47: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 JAA10255 for ; Tue, 28 Aug 2001 09:47:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 450ED912CE; Tue, 28 Aug 2001 09:48:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A55C912CF; Tue, 28 Aug 2001 09:48: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 E88F0912CE for ; Tue, 28 Aug 2001 09:48:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0B135DDDD; Tue, 28 Aug 2001 09:48: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 5FA975DDCD for ; Tue, 28 Aug 2001 09:48:47 -0400 (EDT) Received: (qmail 27873 invoked by uid 500); 28 Aug 2001 13:36:23 -0000 Date: Tue, 28 Aug 2001 06:36:23 -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 137: CMS Proxy's DSAAs Message-ID: <20010828063623.B27840@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , Pat Calhoun , aaa-wg@merit.edu References: <20010827091226.R23877@charizard.diameter.org> <3B8B6C92.BEAA2280@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: <3B8B6C92.BEAA2280@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 12:04:02PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 12:04:02PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > so as you can see from above, the 'E' bit wouldn't be set for errors > > in the 5xxx class, which is where the CMS Result-Code AVP values are > > defined. > > > > So I propose that we reject this issue. > > OK. I understand what you mean (I didn't read carefully the base > specification about the different kinds of errors). > > But the fact I was trying to point is the following: what happens with > the format of a DSAA when a Permanent Error result code is issued by a > proxy? Which is the content of AAA-Server-Certs and DSA-TTL AVPs when > the result code is 5020 or 5021 (since no DSA is finally established)? So the issue is that these AVPs must be optional, but must be present if the result code is successful. right? PatC From owner-aaa-wg@merit.edu Tue Aug 28 09:49: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 JAA10330 for ; Tue, 28 Aug 2001 09:49:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E239912CF; Tue, 28 Aug 2001 09:50:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1BD2912D0; Tue, 28 Aug 2001 09:50: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 D3DCF912CF for ; Tue, 28 Aug 2001 09:50:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B83D15DDDD; Tue, 28 Aug 2001 09:50: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 52AC05DDCD for ; Tue, 28 Aug 2001 09:50:47 -0400 (EDT) Received: (qmail 27894 invoked by uid 500); 28 Aug 2001 13:38:23 -0000 Date: Tue, 28 Aug 2001 06:38:23 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 138: Signed DSA messages Message-ID: <20010828063823.C27840@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827094525.V23877@charizard.diameter.org> <3B8B6821.DE20965@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: <3B8B6821.DE20965@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 11:45:05AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 11:45:05AM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > This issue has to do with the fact that there is no mandatory AVP > > in the DSAA, which MUST be signed, whose 'P' bit MUST be set. One > > proposal (above) is to require that the DSA-TTL AVP MUST have the 'P' > > bit set. However, the DSA-TTL is also mandatory in the DSAR, which > > currently states that it SHOULD be signed, and such a change would > > make it a MUST be signed. > > > > I propose that the AAA-Server-Certs AVP MUST have the 'P' bit set, > > which will require the presence of the CMS-Signed-AVP AVP. > > The solution seems good to me. However, it only solves half the > problem. I mean, it deals only with the DSAA message. But, what > happens with the DSAR message? There is also no mandatory AVP in the > DSAR. Expected-Signed-AVP and Expected-Encrypted-AVP are mandatory to > protect, so that, if issued, the must be signed. But, what happens if > no such AVPs are included in the DSAR? > > Let's imagine the following scenario. A NAS is wishing to send > accounting messages to a Home Server. It's supposed that such messages > will contain AVPs that must be encrypted. But the indication about > such fact will be carried by the DSAA issued by the Home Server, not > by the NAS. So that, the NAS will establish a DSA with the Home Server > in order to send subsequently accounting messages. It's up to the Home > Server to include an Expected-Encrypted-AVP in its DSAA. The DSAR > won't include any AVP which must be protected. If so, the problem is > the same as the stated in the original issue.... That's because protecting the DSAR is a SHOULD, not a MUST. If one includes the expected-*****-AVP, then it will have to protect the message. Adding a mandatory AVP, which has the 'P' bit always set, would now make protecting the DSAR a MUST, and text throughout the spec would have to be revised to reflect this change. PatC From owner-aaa-wg@merit.edu Tue Aug 28 09:50: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 JAA10356 for ; Tue, 28 Aug 2001 09:50:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E4D0C912D2; Tue, 28 Aug 2001 09:51:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B44C0912D0; Tue, 28 Aug 2001 09:51: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 88733912D2 for ; Tue, 28 Aug 2001 09:51:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14F235DDCD; Tue, 28 Aug 2001 09:51: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 94B165DDC2 for ; Tue, 28 Aug 2001 09:51:35 -0400 (EDT) Received: (qmail 27908 invoked by uid 500); 28 Aug 2001 13:39:12 -0000 Date: Tue, 28 Aug 2001 06:39:12 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 139: Key Management chapter rephrasing Message-ID: <20010828063912.D27840@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827102936.A23877@charizard.diameter.org> <3B8B5860.C783A073@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: <3B8B5860.C783A073@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 10:37:52AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 10:37:52AM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > All, > > > > Below is my proposed text for the new section 3.0: > > > > 3.0 Key Management > > > > For DSA origin authentication, CMS itself already provides sufficient > > key management without the need for additional specification. Basically, > > the originating Diameter node signs and includes whatever certificates > > are necessary for validation of the digital signature. Section 3.1 > > provides an example of how the Diameter CMS Security application is used. > > > > In order to encrypt AVPs for a recipient, the originating Diameter > > node must have a copy of the recipient's public key. There are many > > well-known key retrieval schemes (e.g. LDAP [6]), but this > > specification also allows for the transportation of certificates > > within Diameter AVPs, which is expected to simplify implementations. > > Section 3.2 describes how Diameter node names are encoded within such > > certificates. > > > > Finally, it is anticipated that the overhead of key generation for > > each Diameter message sent to a given peer could be significant. > > Section 3.4 specifies how CMS encryption keys may be reused for > > multiple Diameter messages." > > > > Comments appreciated, > > Section 3.0 is much more clear now. A last comment... Does it make any > sense to keep 3.3 section (algorithms) within 3.0 (focused on key > management). Wouldn't be better to put it outside (maybe like a > top-level chapter)? If you think it makes sense, I can make this change. PatC From owner-aaa-wg@merit.edu Tue Aug 28 09:53: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 JAA10419 for ; Tue, 28 Aug 2001 09:53:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A86A912D0; Tue, 28 Aug 2001 09:54:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FDD0912D1; Tue, 28 Aug 2001 09:54: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 E9F2F912D0 for ; Tue, 28 Aug 2001 09:54:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C19DE5DDCD; Tue, 28 Aug 2001 09:54: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 6C6AC5DDC2 for ; Tue, 28 Aug 2001 09:54:09 -0400 (EDT) Received: (qmail 27940 invoked by uid 500); 28 Aug 2001 13:41:46 -0000 Date: Tue, 28 Aug 2001 06:41:45 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 144: OCSP support Message-ID: <20010828064145.E27840@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827110746.F23877@charizard.diameter.org> <3B8B6E8D.74822334@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: <3B8B6E8D.74822334@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 12:12:29PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 12:12:29PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > All, > > > > In order to fix this problem, I've added text to section 3.1: > > > > " In the event the DSAR requested OCSP validation, via the > > OCSP-Request AVP, and OCSP is not locally supported, the DSAA > > MUST be returned with the Result-Code AVP set to > > DIAMETER_OCSP_NOT_SUPPORTED. Otherwise, the destination node > > returns the DSAA message which contains:" > > > > and added the following Result-Code value: > > > > DIAMETER_OCSP_NOT_SUPPORTED 5022 > > This error code is returned when a DSAR message is received > > requesting OCSP validation, and the receiver does not support OCSP. > > > > Does this work? > > It looks a good solution. But after reviewing the Base Specification > in order to answer to issue 137 I've noticed that a permanent failure > means that "that the request failed, and should not be attempted > again". Is that really true? I mean, when a node requests OCSP > validation and OCSP is not locally supported, the DSA must be dropped? > I consider that the originator may determine then whether it is > willing to provide service, based on its local policy. Shouldn't be > DIAMETER_OCSP_NOT_SUPPORTED a transient failure error? Actually, I believe that you are correct, and errors 5020 and 5021 should probably also be transient errors. PatC From owner-aaa-wg@merit.edu Tue Aug 28 10:00: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 KAA10601 for ; Tue, 28 Aug 2001 10:00:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A6C1912D4; Tue, 28 Aug 2001 10:00:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33F87912D5; Tue, 28 Aug 2001 10:00: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 34E62912D4 for ; Tue, 28 Aug 2001 10:00:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 191A65DDDD; Tue, 28 Aug 2001 10:00:17 -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 0AD955DDC2 for ; Tue, 28 Aug 2001 10:00:16 -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 f7SE09v13752 for ; Tue, 28 Aug 2001 16:00:11 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA04436; Tue, 28 Aug 2001 16:00:06 +0200 (MET DST) Message-ID: <3B8BA411.5422C361@rioja.ericsson.se> Date: Tue, 28 Aug 2001 16:00: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 Subject: Re: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@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: > > ok, but the above no longer allows the proxy agent from using previous > info from the DSAR, which it *could* use if it wanted to. There is no > reason to prohibit it, no? No, of course not :-)) // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 10:00: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 KAA10618 for ; Tue, 28 Aug 2001 10:00:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0578912D5; Tue, 28 Aug 2001 10:00:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DCE891315; Tue, 28 Aug 2001 10:00:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDA9A912D5 for ; Tue, 28 Aug 2001 10:00:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 794265DDCD; Tue, 28 Aug 2001 10:00: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 6A4095DDC2 for ; Tue, 28 Aug 2001 10:00:41 -0400 (EDT) Received: (qmail 27980 invoked by uid 500); 28 Aug 2001 13:48:17 -0000 Date: Tue, 28 Aug 2001 06:48:17 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues Message-ID: <20010828064817.G27840@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Pat Calhoun , aaa-wg@merit.edu References: <20010827150715.A23877@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 Mon, Aug 27, 2001 at 09:17:36PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Aug 27, 2001 at 09:17:36PM -0700, Bernard Aboba wrote: > WEP reference is correct. Will try to find reference for WEP-128 (there is > no IEEE standard for this). RFC 3162 will issue soon. If we cannot find such a reference (because the work is in progress), we have two options: 1. Leave it as-is with no reference, or 2. Remove it from the spec, and request a number from IANA in the future. Your call. PatC From owner-aaa-wg@merit.edu Tue Aug 28 10:02: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 KAA10697 for ; Tue, 28 Aug 2001 10:02:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B2FF912D6; Tue, 28 Aug 2001 10:04:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0E07912D8; Tue, 28 Aug 2001 10:04: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 B2C0C912D6 for ; Tue, 28 Aug 2001 10:03:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A5285DDDD; Tue, 28 Aug 2001 10:03: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 BD4065DDC2 for ; Tue, 28 Aug 2001 10:03: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 f7SE3vv16634 for ; Tue, 28 Aug 2001 16:03:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA04687; Tue, 28 Aug 2001 16:03:55 +0200 (MET DST) Message-ID: <3B8BA4F6.BE56C909@rioja.ericsson.se> Date: Tue, 28 Aug 2001 16:04: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 137: CMS Proxy's DSAAs References: <20010827091226.R23877@charizard.diameter.org> <3B8B6C92.BEAA2280@rioja.ericsson.se> <20010828063623.B27840@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 Tue, Aug 28, 2001 at 12:04:02PM +0200, Miguel Ángel Monjas Llorente wrote: > > Pat Calhoun wrote: > > > > > > so as you can see from above, the 'E' bit wouldn't be set for errors > > > in the 5xxx class, which is where the CMS Result-Code AVP values are > > > defined. > > > > > > So I propose that we reject this issue. > > > > OK. I understand what you mean (I didn't read carefully the base > > specification about the different kinds of errors). > > > > But the fact I was trying to point is the following: what happens with > > the format of a DSAA when a Permanent Error result code is issued by a > > proxy? Which is the content of AAA-Server-Certs and DSA-TTL AVPs when > > the result code is 5020 or 5021 (since no DSA is finally established)? > > So the issue is that these AVPs must be optional, but must be present > if the result code is successful. right? Yes. I should have begun with that :-)) // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 10:10: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 KAA10904 for ; Tue, 28 Aug 2001 10:10:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23F45912D8; Tue, 28 Aug 2001 10:11:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E794F912DA; Tue, 28 Aug 2001 10:11:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D59E8912D8 for ; Tue, 28 Aug 2001 10:11:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BBC1B5DDDD; Tue, 28 Aug 2001 10:11:42 -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 E25555DDC2 for ; Tue, 28 Aug 2001 10:11:41 -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 f7SEBdv22152 for ; Tue, 28 Aug 2001 16:11:40 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA05234; Tue, 28 Aug 2001 16:11:35 +0200 (MET DST) Message-ID: <3B8BA6C2.42EE2EE@rioja.ericsson.se> Date: Tue, 28 Aug 2001 16:12: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: Re: [AAA-WG]: Issue 138: Signed DSA messages References: <20010827094525.V23877@charizard.diameter.org> <3B8B6821.DE20965@rioja.ericsson.se> <20010828063823.C27840@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: > > That's because protecting the DSAR is a SHOULD, not a MUST. If one includes > the expected-*****-AVP, then it will have to protect the message. Adding a > mandatory AVP, which has the 'P' bit always set, would now make protecting > the DSAR a MUST, and text throughout the spec would have to be revised to > reflect this change. No such change is necessary. Maybe the point is that protecting the DSAR is a MUST only when a Expected-*-AVP is included and a MAY in the rest of the cases. I mean, according to the definition of the command, the paragraph (third in the page 12) might be something like this: The DSAR MAY include a CMS-Signed-Data AVP. If the originating node has a private key, it might specify protection expectations for AVPs. If so, the DSAR MUST include a CMS-Signed-Data AVP. Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 10:16: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 KAA11021 for ; Tue, 28 Aug 2001 10:16:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 854CB9121D; Tue, 28 Aug 2001 10:17:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DEA1912D7; Tue, 28 Aug 2001 10:17: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 6C8519121D for ; Tue, 28 Aug 2001 10:17:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CC875DDDD; Tue, 28 Aug 2001 10:17:37 -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 740705DDC2 for ; Tue, 28 Aug 2001 10:17:36 -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 f7SEHXv26416 for ; Tue, 28 Aug 2001 16:17:34 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA05543; Tue, 28 Aug 2001 16:17:31 +0200 (MET DST) Message-ID: <3B8BA826.717DEFCA@rioja.ericsson.se> Date: Tue, 28 Aug 2001 16:18:14 +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 145: Order in CMS-Proxy messages References: <20010827111529.G23877@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: > > This issue is a request to change the language that pertains to > encryption of AVPs, and the fact that the current text states that the > AVPs may be ordered in any manner prior to the encryption process. > > If the encryptor is the client, or the home server, we don't have much of > an issue, which is where this text was directed to. However, if a proxy is > performing the encryption on behalf of a client, it will have to reorder > the AVPs for them to fit within the CMS-Encrypted-Data AVP (because > the AVPs are pulled from the message, and included in the AVP). That's right. > Of course, we could require that each individual AVP be encrypted > separately, and the resulting CMS-Encrypted-Data AVP be inserted in the > same location the original AVP was in. > > Personally, I think this is just too much overhead. Me too. > So, I would opt to leave the language as is. Proxies are evil anyways, > and they will reorder if they feel like it. This is one case where reorder > is actually necessary. Yes, that's right. I felt that it was necessary to point that when in the base protocol it's said that "proxies SHOULD NOT reorder AVPs" a sentence like "(however, when acting as CMS proxy, AVPs reorder is made implicitly)". But possibly it isn't necessary. Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 10:25: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 KAA11253 for ; Tue, 28 Aug 2001 10:25:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2CE99130D; Tue, 28 Aug 2001 10:24:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73DFE91319; Tue, 28 Aug 2001 10:24: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 B79029130D for ; Tue, 28 Aug 2001 10:24:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EABD5DDC2; Tue, 28 Aug 2001 10:24:14 -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 919AF5DDDD for ; Tue, 28 Aug 2001 10:24:13 -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 f7SEO3v00352 for ; Tue, 28 Aug 2001 16:24:08 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA06050; Tue, 28 Aug 2001 16:24:00 +0200 (MET DST) Message-ID: <3B8BA9AB.E481C96@rioja.ericsson.se> Date: Tue, 28 Aug 2001 16:24: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]: Issue 134: Several CMS-Encrypted-Data AVPs in a message References: <20010827084838.N23877@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, > > The following text is currently present in the I-D: > > "CMS-Encrypted-Data MAY contain more than one CMS object, that is, > implementations MUST be able to add a new CMS-Encrypted-Data > AVP value and also MUST be able to decrypt all CMS-Encrypted-Data > AVP values which are encrypted for them." > > This issue is a request to clarify the somewhat ambiguous text in > the draft. I would like to propose the following text instead: > > "A CMS-Encrypted-Data AVP MAY contain more than one EnvelopedData, > where one or more AVP would be encrypted within separate > EnvelopedData structures. However, implementations MUST be able > to support the presence of multiple CMS-Encrypted-Data AVPs, where > one or more AVP is added to a separate CMS-Encrypted-Data AVP. > Finally, a receiver MUST be able to decrypt all CMS-Encrypted-Data > AVPs for which it is a recipient, as indicated in the > EnvelopedData's RecipientInfos field [3]. " > > Would this work? Unfortunately, I'm not quite sure. Let's say that a CMS-Encrypted-Data AVP contains several EnvelopedData structures. I assume that it's made by means of S/MIME (BTW, no MIME mention is done in 6.3, CMS-Encrypted-Data AVP). What I've missed is the last sentence. If a CMS-Encrypted-Data contains several EnvelopedData values, the receiver can be only able to decrypt all EnvelopedData within CMS-Encrypted-Data AVPs for which it is a recipient (so that the RecipientInfo value belongs to EnvelopedData not to CMS-Encrypted-Data). Comments? // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 10:38:36 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11771 for ; Tue, 28 Aug 2001 10:38:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1C7891312; Tue, 28 Aug 2001 10:37:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAFFC91321; Tue, 28 Aug 2001 10:37: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 7F45291312 for ; Tue, 28 Aug 2001 10:37:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5AA6E5DDC2; Tue, 28 Aug 2001 10:37:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zaphod.smallworks.com (unknown [216.12.241.6]) by segue.merit.edu (Postfix) with ESMTP id BD6A05DDB2 for ; Tue, 28 Aug 2001 10:37:37 -0400 (EDT) Received: (from jim@localhost) by zaphod.smallworks.com (8.11.2/8.11.2) id f7SEblH05522; Tue, 28 Aug 2001 09:37:47 -0500 From: Jim Thompson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15243.44219.254933.133151@zaphod.smallworks.com> Date: Tue, 28 Aug 2001 09:37:47 -0500 To: gwz@cisco.com Cc: tweckstr@cc.hut.fi, jschnizl@cisco.com, aboba@internaut.com, randy@psg.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? In-Reply-To: References: <3B8A68A0.677B647D@cc.hut.fi> X-Mailer: VM 6.95 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn writes: > A draft spedc is available to WECA members only. I attended the last WISPr > meeting. A recent version of the draft WISPr document was sent to me without any duty of confidentiality, and with markings in the document that claim that the distribution of said document is unlimited. ftp://ftp.smallworks.com/pub/Wisprdraft_0808011.doc (original) ftp://ftp.smallworks.com/pub/Wisprdraft_0808011.html (converted) If you want to know what they're up to. I have asked them to open their process several times now, they have steadfastly refused. Jim From owner-aaa-wg@merit.edu Tue Aug 28 12:06:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14025 for ; Tue, 28 Aug 2001 12:06:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67E019131E; Tue, 28 Aug 2001 12:07:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3114491322; Tue, 28 Aug 2001 12:07: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 216149131E for ; Tue, 28 Aug 2001 12:07:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01B535DDC4; Tue, 28 Aug 2001 12:07:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AD2D15DDC2 for ; Tue, 28 Aug 2001 12:07:00 -0400 (EDT) Received: (qmail 28445 invoked by uid 500); 28 Aug 2001 15:54:37 -0000 Date: Tue, 28 Aug 2001 08:54:36 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 134: Several CMS-Encrypted-Data AVPs in a message Message-ID: <20010828085436.A28427@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827084838.N23877@charizard.diameter.org> <3B8BA9AB.E481C96@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: <3B8BA9AB.E481C96@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 04:24:43PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 04:24:43PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > All, > > > > The following text is currently present in the I-D: > > > > "CMS-Encrypted-Data MAY contain more than one CMS object, that is, > > implementations MUST be able to add a new CMS-Encrypted-Data > > AVP value and also MUST be able to decrypt all CMS-Encrypted-Data > > AVP values which are encrypted for them." > > > > This issue is a request to clarify the somewhat ambiguous text in > > the draft. I would like to propose the following text instead: > > > > "A CMS-Encrypted-Data AVP MAY contain more than one EnvelopedData, > > where one or more AVP would be encrypted within separate > > EnvelopedData structures. However, implementations MUST be able > > to support the presence of multiple CMS-Encrypted-Data AVPs, where > > one or more AVP is added to a separate CMS-Encrypted-Data AVP. > > Finally, a receiver MUST be able to decrypt all CMS-Encrypted-Data > > AVPs for which it is a recipient, as indicated in the > > EnvelopedData's RecipientInfos field [3]. " > > > > Would this work? > > Unfortunately, I'm not quite sure. > > Let's say that a CMS-Encrypted-Data AVP contains several EnvelopedData > structures. I assume that it's made by means of S/MIME (BTW, no MIME > mention is done in 6.3, CMS-Encrypted-Data AVP). What I've missed is > the last sentence. If a CMS-Encrypted-Data contains several > EnvelopedData values, the receiver can be only able to decrypt all > EnvelopedData within CMS-Encrypted-Data AVPs for which it is a > recipient (so that the RecipientInfo value belongs to EnvelopedData > not to CMS-Encrypted-Data). > > Comments? Ah, I see the confusion. How about: "Finally, a receiver MUST be able to decrypt any EnvelopedData for which it is a recipient, as indicated in the EnvelopedData's RecipientInfos field [3], and the receiver MUST be able to process one or more CMS-Encrypted-Data AVPs" Does this make more sense? PatC > > // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 12:10: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 MAA14160 for ; Tue, 28 Aug 2001 12:10:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC49B91322; Tue, 28 Aug 2001 12:09:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FF0091324; Tue, 28 Aug 2001 12:09: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 03C7691322 for ; Tue, 28 Aug 2001 12:09:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD45D5DDC4; Tue, 28 Aug 2001 12:09: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 58D665DDC2 for ; Tue, 28 Aug 2001 12:09:10 -0400 (EDT) Received: (qmail 28474 invoked by uid 500); 28 Aug 2001 15:56:46 -0000 Date: Tue, 28 Aug 2001 08:56:46 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client Message-ID: <20010828085646.C28427@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8BA411.5422C361@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: <3B8BA411.5422C361@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 04:00:49PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 04:00:49PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > ok, but the above no longer allows the proxy agent from using previous > > info from the DSAR, which it *could* use if it wanted to. There is no > > reason to prohibit it, no? > > No, of course not :-)) Then I am confused on what your position is. Could you rephrase the text that you believe is correct? confused :( PatC From owner-aaa-wg@merit.edu Tue Aug 28 12:16: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 MAA14366 for ; Tue, 28 Aug 2001 12:16:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0171591328; Tue, 28 Aug 2001 12:16:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B09A491332; Tue, 28 Aug 2001 12:15: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 5C4C391328 for ; Tue, 28 Aug 2001 12:15:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C4C35DDDD; Tue, 28 Aug 2001 12:15:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id CC6B55DDC4 for ; Tue, 28 Aug 2001 12:15:54 -0400 (EDT) Received: (qmail 28502 invoked by uid 500); 28 Aug 2001 16:03:31 -0000 Date: Tue, 28 Aug 2001 09:03:31 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 145: Order in CMS-Proxy messages Message-ID: <20010828090331.D28427@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827111529.G23877@charizard.diameter.org> <3B8BA826.717DEFCA@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: <3B8BA826.717DEFCA@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 04:18:14PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > So, I would opt to leave the language as is. Proxies are evil anyways, > > and they will reorder if they feel like it. This is one case where reorder > > is actually necessary. > > Yes, that's right. I felt that it was necessary to point that when in > the base protocol it's said that "proxies SHOULD NOT reorder AVPs" a > sentence like "(however, when acting as CMS proxy, AVPs reorder is > made implicitly)". But possibly it isn't necessary. ok, so I've added the following paragraph prior to the last paragraph in section 1.2: " It is important to note that proxy agents establishing DSA's on behalf of a client will most likely need to reorder AVPs during the encryption process, in order to fit the encrypted AVPs within a CMS-Encrypted-Data AVP. This is contrary to the rule established in the Diameter base protocol [1], which states that proxy agents SHOULD NOT reorder AVPs." Does this work for you? PatC From owner-aaa-wg@merit.edu Tue Aug 28 12:21: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 MAA14652 for ; Tue, 28 Aug 2001 12:21:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9957991324; Tue, 28 Aug 2001 12:21:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FC8591342; Tue, 28 Aug 2001 12:21: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 C50FE91324 for ; Tue, 28 Aug 2001 12:21:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB41A5DDC4; Tue, 28 Aug 2001 12:21:34 -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 9F28D5DDC2 for ; Tue, 28 Aug 2001 12:21:33 -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 f7SGLUK11700 for ; Tue, 28 Aug 2001 18:21:32 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA12733; Tue, 28 Aug 2001 18:21:28 +0200 (MET DST) Message-ID: <3B8BC533.CEBB55E2@rioja.ericsson.se> Date: Tue, 28 Aug 2001 18:22: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 145: Order in CMS-Proxy messages References: <20010827111529.G23877@charizard.diameter.org> <3B8BA826.717DEFCA@rioja.ericsson.se> <20010828090331.D28427@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: > > > > So, I would opt to leave the language as is. Proxies are evil anyways, > > > and they will reorder if they feel like it. This is one case where reorder > > > is actually necessary. > > > > Yes, that's right. I felt that it was necessary to point that when in > > the base protocol it's said that "proxies SHOULD NOT reorder AVPs" a > > sentence like "(however, when acting as CMS proxy, AVPs reorder is > > made implicitly)". But possibly it isn't necessary. > > ok, so I've added the following paragraph prior to the last paragraph > in section 1.2: > > " It is important to note that proxy agents establishing DSA's on > behalf of a client will most likely need to reorder AVPs during the > encryption process, in order to fit the encrypted AVPs within a > CMS-Encrypted-Data AVP. This is contrary to the rule established in > the Diameter base protocol [1], which states that proxy agents SHOULD > NOT reorder AVPs." > > Does this work for you? Works fine. Thanks. // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 12:28:51 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14908 for ; Tue, 28 Aug 2001 12:28:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 280CB91329; Tue, 28 Aug 2001 12:27:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D94649132F; Tue, 28 Aug 2001 12:27: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 C54FC91329 for ; Tue, 28 Aug 2001 12:27:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A5F405DDC4; Tue, 28 Aug 2001 12: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 1FA6E5DDF2 for ; Tue, 28 Aug 2001 12: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 f7SGRNK13303 for ; Tue, 28 Aug 2001 18:27:24 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA13093; Tue, 28 Aug 2001 18:27:21 +0200 (MET DST) Message-ID: <3B8BC695.5524E6EE@rioja.ericsson.se> Date: Tue, 28 Aug 2001 18:28: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]: Issue 136: Proxy's DSAR on behalf of a client References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8BA411.5422C361@rioja.ericsson.se> <20010828085646.C28427@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 Tue, Aug 28, 2001 at 04:00:49PM +0200, Miguel Ángel Monjas Llorente wrote: > > Pat Calhoun wrote: > > > > > > ok, but the above no longer allows the proxy agent from using previous > > > info from the DSAR, which it *could* use if it wanted to. There is no > > > reason to prohibit it, no? > > > > No, of course not :-)) > > Then I am confused on what your position is. Could you rephrase the text > that you believe is correct? > > confused :( Sorry. I didn't wanted to confuse you :-)) I just wanted to clarify the proxy behaviour when acting as a CMS proxy. I've got no preference about it using cached data or not. What about the following? If the access device determines that it is able to allow the proxy agent to establish a DSA on its behalf, it would issue a Proxy Diameter Security Association Request (PDSR). This request MUST contain the realm with wich the access server wants the server to establish a DSA. The proxy agent MAY use any of the parameters provided by the access device in the previous DSA setup attempt to establish the DSA. Once established the DSA, the proxy agent MUST issue a Proxy Diameter Security Association Answer (PDSA). Is it a little bit clearer? // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 12:29:06 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14930 for ; Tue, 28 Aug 2001 12:29:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5EE6391330; Tue, 28 Aug 2001 12:27:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E64B91332; Tue, 28 Aug 2001 12:27: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 61CD791330 for ; Tue, 28 Aug 2001 12:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 466BF5DDE9; Tue, 28 Aug 2001 12:27: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 E0AF35DDC4 for ; Tue, 28 Aug 2001 12:27:37 -0400 (EDT) Received: (qmail 28558 invoked by uid 500); 28 Aug 2001 16:15:14 -0000 Date: Tue, 28 Aug 2001 09:15:14 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 137: CMS Proxy's DSAAs Message-ID: <20010828091514.H28427@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827091226.R23877@charizard.diameter.org> <3B8B6C92.BEAA2280@rioja.ericsson.se> <20010828063623.B27840@charizard.diameter.org> <3B8BA4F6.BE56C909@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: <3B8BA4F6.BE56C909@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 04:04:38PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > So the issue is that these AVPs must be optional, but must be present > > if the result code is successful. right? > > Yes. I should have begun with that :-)) > so how abou the following: "4.2 Diameter-Security-Association-Answer The Diameter-Security-Association-Answer command, indicated by the Command-Code field set to 304, with the 'R' bit in the Command Flags cleared, in response to a DSAR. The CMS-Signed-Data AVP MUST be present if any AVP in the message has the 'P' bit set. If the Result-Code AVP indicates success, the CA-Chain, AAA-Server-Certs, DSA-TTL and CMS-Signed-Data AVPs MUST be present. Message Format ::= < Diameter-Header: 304, PXY > { Result-Code } { Origin-Host } { Auth-Application-Id } [ Origin-Realm ] 0*1[ CA-Chain ] * [ AAA-Server-Certs ] [ DSA-TTL } * [ OCSP-Responses ] * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] [ CMS-Signed-Data ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ]" PatC From owner-aaa-wg@merit.edu Tue Aug 28 12:30: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 MAA15020 for ; Tue, 28 Aug 2001 12:30:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD5E891325; Tue, 28 Aug 2001 12:30:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8A5A9133B; Tue, 28 Aug 2001 12:30: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 A108891325 for ; Tue, 28 Aug 2001 12:30:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86BC95DDC4; Tue, 28 Aug 2001 12:30: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 2FE3C5DDC2 for ; Tue, 28 Aug 2001 12:30:41 -0400 (EDT) Received: (qmail 28577 invoked by uid 500); 28 Aug 2001 16:18:17 -0000 Date: Tue, 28 Aug 2001 09:18:17 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 138: Signed DSA messages Message-ID: <20010828091817.I28427@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827094525.V23877@charizard.diameter.org> <3B8B6821.DE20965@rioja.ericsson.se> <20010828063823.C27840@charizard.diameter.org> <3B8BA6C2.42EE2EE@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: <3B8BA6C2.42EE2EE@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 04:12:18PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, Aug 28, 2001 at 04:12:18PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > That's because protecting the DSAR is a SHOULD, not a MUST. If one includes > > the expected-*****-AVP, then it will have to protect the message. Adding a > > mandatory AVP, which has the 'P' bit always set, would now make protecting > > the DSAR a MUST, and text throughout the spec would have to be revised to > > reflect this change. > > No such change is necessary. > > Maybe the point is that protecting the DSAR is a MUST only when a > Expected-*-AVP is included and a MAY in the rest of the cases. I mean, > according to the definition of the command, the paragraph (third in > the page 12) might be something like this: > > The DSAR MAY include a CMS-Signed-Data AVP. If the originating node > has a private key, it might specify protection expectations for > AVPs. > If so, the DSAR MUST include a CMS-Signed-Data AVP. > but the current text (in my version of the draft) is: 4.1 Diameter-Security-Association-Request The Diameter-Security-Association-Request command, indicated by the Command-Code field set to 304 and the 'R' bit set in the message flags field, is sent by a Diameter node to establish a Diameter Security Association. The DSAR message MUST NOT be used simply as a convenient certificate distribution protocol without establishing a DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the message has the 'P' bit set. Is anything else necessary? Doesn't the above pretty much state what you did above, or was there something else needed? PatC From owner-aaa-wg@merit.edu Tue Aug 28 12:37: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 MAA15266 for ; Tue, 28 Aug 2001 12:37:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD0F5912FF; Tue, 28 Aug 2001 12:38:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A094191326; Tue, 28 Aug 2001 12:38:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C958912FF for ; Tue, 28 Aug 2001 12:38:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 73BE35DDC4; Tue, 28 Aug 2001 12:38: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 68DA85DDC2 for ; Tue, 28 Aug 2001 12:38: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 f7SGcfK15963 for ; Tue, 28 Aug 2001 18:38:43 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA13560; Tue, 28 Aug 2001 18:38:39 +0200 (MET DST) Message-ID: <3B8BC93B.D7AD3E6A@rioja.ericsson.se> Date: Tue, 28 Aug 2001 18:39:23 +0200 From: Miguel =?iso-8859-1?Q?=C1ngel?= Monjas Llorente Organization: Ericsson =?iso-8859-1?Q?Espa=F1a?=, GSM/UMTS Systems Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,es-ES MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 137: CMS Proxy's DSAAs References: <20010827091226.R23877@charizard.diameter.org> <3B8B6C92.BEAA2280@rioja.ericsson.se> <20010828063623.B27840@charizard.diameter.org> <3B8BA4F6.BE56C909@rioja.ericsson.se> <20010828091514.H28427@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: > > > > So the issue is that these AVPs must be optional, but must be present > > > if the result code is successful. right? > > > > Yes. I should have begun with that :-)) > > > > so how abou the following: Looks great! // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 12:45:05 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 MAA15472 for ; Tue, 28 Aug 2001 12:45:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0528491327; Tue, 28 Aug 2001 12:43:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE9319132B; Tue, 28 Aug 2001 12:43: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 9AA7391327 for ; Tue, 28 Aug 2001 12:43:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58CBE5DDEA; Tue, 28 Aug 2001 12:43:06 -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 7E1425DDE9 for ; Tue, 28 Aug 2001 12:43:05 -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 f7SGh3v04612 for ; Tue, 28 Aug 2001 18:43:04 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA13864; Tue, 28 Aug 2001 18:42:59 +0200 (MET DST) Message-ID: <3B8BCA3F.510D124D@rioja.ericsson.se> Date: Tue, 28 Aug 2001 18:43: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]: Issue 138: Signed DSA messages References: <20010827094525.V23877@charizard.diameter.org> <3B8B6821.DE20965@rioja.ericsson.se> <20010828063823.C27840@charizard.diameter.org> <3B8BA6C2.42EE2EE@rioja.ericsson.se> <20010828091817.I28427@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: > > but the current text (in my version of the draft) is: > > 4.1 Diameter-Security-Association-Request > > The Diameter-Security-Association-Request command, indicated by the > Command-Code field set to 304 and the 'R' bit set in the message > flags field, is sent by a Diameter node to establish a Diameter > Security Association. The DSAR message MUST NOT be used simply as > a convenient certificate distribution protocol without establishing > a DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the > message has the 'P' bit set. > > Is anything else necessary? Doesn't the above pretty much state what > you did above, or was there something else needed? No. It's OK. Just take into account that my proposal and your statement belong to different parts of the draft (mine to 3.1 and yours to 4.1). Both say the same, so if a paragraph describing the signature "status" of DSAR is included in 3.1, it should be similar to my paragraph (otherwise, that paragraph, and the one describing DSAA should be dropped). Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 12:48: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 MAA15641 for ; Tue, 28 Aug 2001 12:48:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0623A91339; Tue, 28 Aug 2001 12:46:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16F2E9133D; Tue, 28 Aug 2001 12:46: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 55F2D91339 for ; Tue, 28 Aug 2001 12:46:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A3B75DDDD; Tue, 28 Aug 2001 12:46:03 -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 7E6415DDC4 for ; Tue, 28 Aug 2001 12:46:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA32128; Tue, 28 Aug 2001 09:38:08 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 28 Aug 2001 09:38:08 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues In-Reply-To: <20010828064817.G27840@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The reference exists (it's already been implemented by several vendors). The question is where it is documented (since it's not an IEEE standard, it might be a WECA document). On Tue, 28 Aug 2001, Pat Calhoun wrote: > On Mon, Aug 27, 2001 at 09:17:36PM -0700, Bernard Aboba wrote: > > WEP reference is correct. Will try to find reference for WEP-128 (there is > > no IEEE standard for this). RFC 3162 will issue soon. > > If we cannot find such a reference (because the work is in progress), we > have two options: > > 1. Leave it as-is with no reference, or > 2. Remove it from the spec, and request a number from IANA in the future. > > Your call. > > PatC > From owner-aaa-wg@merit.edu Tue Aug 28 12:52:07 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15715 for ; Tue, 28 Aug 2001 12:52:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E49791332; Tue, 28 Aug 2001 12:52:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BB869134A; Tue, 28 Aug 2001 12:52:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D790991332 for ; Tue, 28 Aug 2001 12:51:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD6325DDDD; Tue, 28 Aug 2001 12:51: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 E190C5DDC4 for ; Tue, 28 Aug 2001 12:51:54 -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 f7SGprv06939 for ; Tue, 28 Aug 2001 18:51:53 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id SAA14386; Tue, 28 Aug 2001 18:51:50 +0200 (MET DST) Message-ID: <3B8BCC52.391512F4@rioja.ericsson.se> Date: Tue, 28 Aug 2001 18:52:34 +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 134: Several CMS-Encrypted-Data AVPs in a message References: <20010827084838.N23877@charizard.diameter.org> <3B8BA9AB.E481C96@rioja.ericsson.se> <20010828085436.A28427@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: > > Ah, I see the confusion. How about: > > "Finally, a receiver MUST be able to decrypt any EnvelopedData for > which it is a recipient, as indicated in the EnvelopedData's > RecipientInfos field [3], and the receiver MUST be able to process > one or more CMS-Encrypted-Data AVPs" > > Does this make more sense? Yes, it make more sense. This issue may be closed. However, I'm still concerned about MIME (no mention about it has been made). Since it's a little bit long, I'll write the point in a separate issue. Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 13:07: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 NAA16045 for ; Tue, 28 Aug 2001 13:07:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9B059133D; Tue, 28 Aug 2001 13:04:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 890079133C; Tue, 28 Aug 2001 13: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 639EB9133E for ; Tue, 28 Aug 2001 13:04:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48B1D5DDC4; Tue, 28 Aug 2001 13:04:26 -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 833675DDC2 for ; Tue, 28 Aug 2001 13:04:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA32159 for ; Tue, 28 Aug 2001 09:56:32 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 28 Aug 2001 09:56:32 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: WECA 'extending' RADIUS? In-Reply-To: <15243.44219.254933.133151@zaphod.smallworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hmmm. This specification is in the format of an IETF "Best Common Practice" (BCP) document. Yet it violates RFC 2486, requires implementation of a location identifier in a format different from GEOPRIV WG, and assigns RADIUS attribute numbers without consulting IANA. If it shows up in IETF last call, my recommendation would be "do not publish". On Tue, 28 Aug 2001, Jim Thompson wrote: > > Glen Zorn writes: > > A draft spedc is available to WECA members only. I attended the last WISPr > > meeting. > > A recent version of the draft WISPr document was sent to me without > any duty of confidentiality, and with markings in the document that > claim that the distribution of said document is unlimited. > > ftp://ftp.smallworks.com/pub/Wisprdraft_0808011.doc (original) > ftp://ftp.smallworks.com/pub/Wisprdraft_0808011.html (converted) > > If you want to know what they're up to. I have asked them to open their > process several times now, they have steadfastly refused. > > Jim > > From owner-aaa-wg@merit.edu Tue Aug 28 13:10: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 NAA16124 for ; Tue, 28 Aug 2001 13:10:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21B9E91336; Tue, 28 Aug 2001 13:10:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC83C91350; Tue, 28 Aug 2001 13:10: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 E7FB091336 for ; Tue, 28 Aug 2001 13:10:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CC1E15DDD3; Tue, 28 Aug 2001 13:10:41 -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 1EDB95DDC4 for ; Tue, 28 Aug 2001 13:10:36 -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 f7SHAUv11390 for ; Tue, 28 Aug 2001 19:10:31 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA15168; Tue, 28 Aug 2001 19:10:27 +0200 (MET DST) Message-ID: <3B8BD0AF.46051D98@rioja.ericsson.se> Date: Tue, 28 Aug 2001 19:11: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: [AAA-WG]: [issue] 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-08-27 Reference: Document: CMS-02 Comment type: T Priority: 1 Section: Rationale/Explanation of issue: S/MIME is used as the "encoding" scheme within Diameter CMS Security Application. However, I miss an explainatory chapter introducing S/MIME (and CMS), saying which relationship there is bewteen them, why the name of the specification is CMS Security and not S/MIME security, and why it has been chosen (apparently the reason is darkly buried in 6.1 "This method of encapsulating AVPs allows existing S/MIME toolkits to be used without changes in order to provide authentication within the Diameter application layer.") Besides, no mention about MIME encoding is made in 6.2 (CMS-Encrypted-Data AVP). The way in which several EnvelopedData values are encoded in a single CSM-Enveloped-Data AVP isn't defined (I assume that no nesting is employed since an "outside" envelope hides all the content it's enveloping so that only the recipient of this external envelope can extract the contents). Requested change: a) add an introductory chapter explaining the relationship between the different standards involved (along with the reasons to use it and so on) b) add clarifying text to describe the MIME operations involved in CMS Security application Regards // M.A. From owner-aaa-wg@merit.edu Tue Aug 28 13:12: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 NAA16202 for ; Tue, 28 Aug 2001 13:12:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF8E2912DF; Tue, 28 Aug 2001 13:13:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCFBB912E4; Tue, 28 Aug 2001 13:13: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 AD212912DF for ; Tue, 28 Aug 2001 13:13:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9348C5DDD3; Tue, 28 Aug 2001 13:13:30 -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 148095DDC4 for ; Tue, 28 Aug 2001 13:13:25 -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 f7SHDNv11819 for ; Tue, 28 Aug 2001 19:13:23 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id TAA15339; Tue, 28 Aug 2001 19:13:20 +0200 (MET DST) Message-ID: <3B8BD15C.6C7B40D9@rioja.ericsson.se> Date: Tue, 28 Aug 2001 19:14:04 +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] S/MIME precisions References: <3B8BD0AF.46051D98@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 Sorry, I missed the title: S/MIME precisions From owner-aaa-wg@merit.edu Tue Aug 28 19:22: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 TAA23764 for ; Tue, 28 Aug 2001 19:22:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 986DC9123D; Tue, 28 Aug 2001 19:23:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 625509125F; Tue, 28 Aug 2001 19:23: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 4FE179123D for ; Tue, 28 Aug 2001 19:23:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35BE05DDEA; Tue, 28 Aug 2001 19:23: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 C9A695DDE9 for ; Tue, 28 Aug 2001 19:23:01 -0400 (EDT) Received: (qmail 30627 invoked by uid 500); 28 Aug 2001 23:10:36 -0000 Date: Tue, 28 Aug 2001 16:10:36 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client Message-ID: <20010828161036.C30581@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8BA411.5422C361@rioja.ericsson.se> <20010828085646.C28427@charizard.diameter.org> <3B8BC695.5524E6EE@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: <3B8BC695.5524E6EE@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 06:28:05PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit yes, sounds good. I will close this issue. PatC On Tue, Aug 28, 2001 at 06:28:05PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > On Tue, Aug 28, 2001 at 04:00:49PM +0200, Miguel Ángel Monjas Llorente wrote: > > > Pat Calhoun wrote: > > > > > > > > ok, but the above no longer allows the proxy agent from using previous > > > > info from the DSAR, which it *could* use if it wanted to. There is no > > > > reason to prohibit it, no? > > > > > > No, of course not :-)) > > > > Then I am confused on what your position is. Could you rephrase the text > > that you believe is correct? > > > > confused :( > > Sorry. I didn't wanted to confuse you :-)) > > I just wanted to clarify the proxy behaviour when acting as a CMS > proxy. I've got no preference about it using cached data or not. What > about the following? > > If the access device determines that it is able to allow the proxy > agent to establish a DSA on its behalf, it would issue a Proxy > Diameter Security Association Request (PDSR). This request MUST > contain the realm with wich the access server wants the server to > establish a DSA. The proxy agent MAY use any of the parameters > provided by the access device in the previous DSA setup attempt to > establish the DSA. Once established the DSA, the proxy agent MUST > issue a Proxy Diameter Security Association Answer (PDSA). > > Is it a little bit clearer? > > // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 05:03: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 FAA18562 for ; Wed, 29 Aug 2001 05:03:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75E2891283; Wed, 29 Aug 2001 05:04:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 375B591284; Wed, 29 Aug 2001 05:04: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 150DF91283 for ; Wed, 29 Aug 2001 05:04:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAC915DDC1; Wed, 29 Aug 2001 05:04:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 26ADC5DDBE for ; Wed, 29 Aug 2001 05:04:53 -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 LAA13471; Wed, 29 Aug 2001 11:05:53 +0200 From: "Fredrik Johansson" To: "AAA Listan" Cc: "Pat Calhoun" Subject: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Wed, 29 Aug 2001 11:06:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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-08-29 Reference: Document: base Comment type: E Priority: 1 Section: Rationale/Explanation of issue: There are some missing states in the authorization session state machine. 1. It is optional to send a ASR when cleaning up a session on a home server, however there is no indication on what state to go to when doing so. My guess is that you should go to Disconnect and wait for a ASA. Since this is an optional feature I'm not sure it should be in the state machine. However, if you send an ASA there has to be a state indicating how to get from Disconnect to Closed. Requested Change: Add the following state Discon ASA Received Cleanup Closed BTW, it might just be a cut'n past error, the Open ASA Received Cleanup Closed state should not exist, if you have sent an ASR you should not be in Open, so replace the latter with the first state above. 2. There is no state where the home server can receive a service specific auth. request and extend access and stay in open. Requested Change: Add a the following state: Open Successful Service-Specific Extend Open Authorization Request received Access 3. There is no state where the home server can receive a STR send a STA and go to Closed Requested Change: Add the following state: Open receive STR send STA Closed 4. According to the following state: Open Authorization-Lifetime Send Open expires on access device service specific auth req It's not clear that an access device can not send a Service-Specific Auth. request on Authorization-Lifetime expiration unless it has received a MIP registration request or PPP request. Requested Change: Can it be made clearer that if no such message has been received it should send a STR and go to Disconnect? From owner-aaa-wg@merit.edu Wed Aug 29 05:51: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 FAA18952 for ; Wed, 29 Aug 2001 05:51:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CA4A91284; Wed, 29 Aug 2001 05:52:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3224C91285; Wed, 29 Aug 2001 05:52: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 EFA4191284 for ; Wed, 29 Aug 2001 05:52:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C873A5DDD1; Wed, 29 Aug 2001 05:52:13 -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 0E1BB5DDAB for ; Wed, 29 Aug 2001 05:52:13 -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 f7T9pUK21025 for ; Wed, 29 Aug 2001 11:52:11 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA03828; Wed, 29 Aug 2001 11:51:13 +0200 (MET DST) Message-ID: <3B8CBB41.BDFF6BD4@rioja.ericsson.se> Date: Wed, 29 Aug 2001 11:52: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: [AAA-WG]: [issue] Confusion between security services and techniques to achieve them 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-08-29 Reference: Document: CMS-02 Comment type: E Priority: S Section: abstract, 1.1, 3.1, 3.4, 5.0, 6.1, 6.2 Rationale/Explanation of issue: The purpose of Diameter CMS Security Application is to achieve some security services: [1] (data origin) authentication [2] confidentiality [3] integrity [4] non-repudiation (with proof of origin) To achieve them, some techniques are used: - digital signatures + digital certificates provide [1], [3] and [4] (though to achieve only [3] maybe MAC would be enough) - encryption (using asymmetric techniques to encrypt a content encryption key and this CEK for bulk encryption) provides just [2] - encryption + digital signatures + digital certificates provide [1], [2], [3] and [4] However, not all the security services are listed neither the specific techniques are linked with the services. Requested change: Replace the second paragraph of the abstract with the following text: This Diameter application describes how a security association is established by two peers through agents, and how authentication integrity, confidentiality and non-repudiation (with proof of origin) are achieved using a mixture of symmetric and asymmetric transforms, by encapsulating Cryptographic Message Syntax (CMS) data within AVPs. CMS is also used to carry X.509 certificates. Two main techniques are so that used. Digital signatures (along with digital certificates) provide authentication, integrity and non-repudiation. Encryption provides confidentiality (using asymmetric techniques to encrypt a content encryption key and this key for bulk encryption). Both techniques can be used together to provide all the specified security services. Replace the paragraph below the figure 2 (1.1) wiht the following: This document defines the Diameter commands that are used to establish a DSA through Diameter agents, and specifies how encapsulating CMS objects [3] in Diameter AVPs can provide authentication, integrity, confidentiality and non-repudiation. The CMS object MAY also be used to transport X.509 certificates and revocation lists. Replace the third paragraph in 3.1 with the following: We use Diameter Security Association Request (DSAR) and Diameter Security Association Answer (DSAA) messages to establish a DSA, which specifies which AVPs should be encrypted, signed, or both things, as well as which public key(s) to use. Replace the second last paragraph in 3.1 with the following: Depending on the security technique required (digital signature, encryption or both), then the originating node prepares the CMS related AVPs as required. Replace the second paragraph in 3.4 with the following: Note that though the use of symmetric encryption might be used to provide integrity or confidentiality but does not provide non-repudiation with proof of origin. Replace the second paragraph in 5.0 with the following: Although the example doesn't specifically use bi-directional digital signature and encryption, this feature is supported. Replace the first sentence of second last paragraph in 6.1 with the following: The eContent field of the EncapsulatedContentInfo structure MUST be absent since the digital signature covers data outside of the object. Replace the fourth paragraph in 6.2 with the following: When AVPs are to be both encrypted and signed, the CMS- Encrypted-Data AVP MUST be created first. Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 06:04:40 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 GAA19094 for ; Wed, 29 Aug 2001 06:04:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA0A391285; Wed, 29 Aug 2001 06:05:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73A8F91286; Wed, 29 Aug 2001 06:05: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 4F46F91285 for ; Wed, 29 Aug 2001 06:05:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2627B5DDD1; Wed, 29 Aug 2001 06:05:19 -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 504D05DDAB for ; Wed, 29 Aug 2001 06:05:18 -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 f7TA52K29742; Wed, 29 Aug 2001 12:05:03 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA04744; Wed, 29 Aug 2001 12:04:41 +0200 (MET DST) Message-ID: <3B8CBE54.F1D62CD9@rioja.ericsson.se> Date: Wed, 29 Aug 2001 12:05: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about AVPs occurrence References: <3B81265A.306918E0@rioja.ericsson.se> <20010820101404.H31100@charizard.diameter.org> <3B814C98.5FC57750@rioja.ericsson.se> <20010820165318.E1924@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: > > hmmmm..... well the message is used to setup the DSA, so I suppose I assumed > that the reader would understand that sending another message, for the purposes > of pushing certs, would cause a rekey to occur. > > Are you then stating that this isn't clear, and additional clarifying text > is required? Pat, have you got a proposal for this text? Is it necessary to write a formal issue to ask for a clarification text? Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 06:08: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 GAA19117 for ; Wed, 29 Aug 2001 06:08:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E42E91286; Wed, 29 Aug 2001 06:08:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5401391289; Wed, 29 Aug 2001 06:08: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 3BDB191286 for ; Wed, 29 Aug 2001 06:08:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E46F5DDD4; Wed, 29 Aug 2001 06:08: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 047B35DDAB for ; Wed, 29 Aug 2001 06:08: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 f7TA8sv20492; Wed, 29 Aug 2001 12:08:54 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA05011; Wed, 29 Aug 2001 12:08:52 +0200 (MET DST) Message-ID: <3B8CBF64.7AFB39B8@rioja.ericsson.se> Date: Wed, 29 Aug 2001 12:09: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 136: Proxy's DSAR on behalf of a client References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@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 are actually two scenarios regarding proxy agents and CMS: > > > > - The NAS hasn't got any cryptographic capability (or knows that > > there's a proxy in its route or has been configured for always issuing > > a PDSR to its aggregating proxy), so that it issues a PDSR. It's up to > > the proxy to choose a DSA-TTL, provide Local-CA-Info or request OCSP > > responses. > > correct. I believe this is the more common case. > > > - The NAS has cryptographic capabilities (and doesn't know whether > > there's a proxy in its route). If so, it issues a DSAR when he needs > > it (according to its policy). The proxy provides the appropriate > > result code and, if the NAS allows to use it as CMS proxy, it will > > issue a PDSR. However, the proxy doesn't maintain any data from > > previous DSA setup attempst, so that its own DSAR uses parameters > > according to its policy, not to previous DSA setup data. > > correct. Maybe you might consider to add these paragaphs (or a enhanced version of them) to the draft to make it clearer... Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 06:57: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 GAA19600 for ; Wed, 29 Aug 2001 06:57:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1895891289; Wed, 29 Aug 2001 06:58:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC77F9128B; Wed, 29 Aug 2001 06:58:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA16291289 for ; Wed, 29 Aug 2001 06:58:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CB315DDAB; Wed, 29 Aug 2001 06:58:08 -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 11A7A5DD9A for ; Wed, 29 Aug 2001 06:58:03 -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 f7TAvuv26179 for ; Wed, 29 Aug 2001 12:57:57 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA08330; Wed, 29 Aug 2001 12:57:53 +0200 (MET DST) Message-ID: <3B8CCAE1.B971663@rioja.ericsson.se> Date: Wed, 29 Aug 2001 12:58:41 +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] Key Length in CMS Security Application Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Miguel A. Monjas Submitter email address: ecemaml@rioja.es.eu.ericsson.se Date first submitted: 2001-08-29 Reference: Document: CMS-02 Comment type: T Priority: S Section: Rationale/Explanation of issue: Which key length is employed when RSA is used? I haven't seen any negociation schema. Requested change: Add clarifying text Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 07:50: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 HAA21220 for ; Wed, 29 Aug 2001 07:50:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B0539128C; Wed, 29 Aug 2001 07:51:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0493E9128D; Wed, 29 Aug 2001 07:51: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 DE8B89128C for ; Wed, 29 Aug 2001 07:51:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B63C05DDBD; Wed, 29 Aug 2001 07:51:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 36CDA5DD9A for ; Wed, 29 Aug 2001 07:51:16 -0400 (EDT) Received: (qmail 32451 invoked by uid 500); 29 Aug 2001 11:38:49 -0000 Date: Wed, 29 Aug 2001 04:38:49 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Questions about AVPs occurrence Message-ID: <20010829043849.A32443@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , Pat Calhoun , aaa-wg@merit.edu References: <3B81265A.306918E0@rioja.ericsson.se> <20010820101404.H31100@charizard.diameter.org> <3B814C98.5FC57750@rioja.ericsson.se> <20010820165318.E1924@charizard.diameter.org> <3B8CBE54.F1D62CD9@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: <3B8CBE54.F1D62CD9@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Wed, Aug 29, 2001 at 12:05:08PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Pat, have you got a proposal for this text? Is it necessary to write a > formal issue to ask for a clarification text? Here's the text that I have so far: 4.1 Diameter-Security-Association-Request The Diameter-Security-Association-Request command, indicated by the Command-Code field set to 304 and the 'R' bit set in the message flags field, is sent by a Diameter node to establish a Diameter Security Association. The DSAR message MUST NOT be used simply as a convenient certificate distribution protocol without establishing a DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the message has the 'P' bit set. PatC From owner-aaa-wg@merit.edu Wed Aug 29 08:02: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 IAA21726 for ; Wed, 29 Aug 2001 08:02:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A74A19128E; Wed, 29 Aug 2001 08:03:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62ABA91290; Wed, 29 Aug 2001 08:03:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4263F9128E for ; Wed, 29 Aug 2001 08:03:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 177535DDBD; Wed, 29 Aug 2001 08:03: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 8A2035DD9A for ; Wed, 29 Aug 2001 08:03:23 -0400 (EDT) Received: (qmail 32515 invoked by uid 500); 29 Aug 2001 11:50:57 -0000 Date: Wed, 29 Aug 2001 04:50:57 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 142: CEKMaxDecrypts value cs DSA length Message-ID: <20010829045057.D32443@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827134903.U23877@charizard.diameter.org> <3B8B49AC.BF0E9EA5@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: <3B8B49AC.BF0E9EA5@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 09:35:08AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yes. It's clear. That's what I thought but I just wanted to know > whether I was right. My basic pursose is to make the specification as > accurate as possible to prevent any possible error in > implementation... > > A paragraph similar to the previous by you would be very explicit (but > it's up to you). Added the following paragraph to the end of 3.4: " Note that the CEKMaxDecrypts value used does not affect the DSA-TTL. The DSA-TTL dictates the lifetime of the DSA, while the CEKMaxDecrypts dictates how often rekeying will occur within the CMS protocol." Is this sufficient? PatC From owner-aaa-wg@merit.edu Wed Aug 29 08:08: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 IAA21918 for ; Wed, 29 Aug 2001 08:08:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 376CD91290; Wed, 29 Aug 2001 08:09:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0918991291; Wed, 29 Aug 2001 08:09: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 ED39891290 for ; Wed, 29 Aug 2001 08:09:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C1A3F5DDE6; Wed, 29 Aug 2001 08:09: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 7E13D5DDBD for ; Wed, 29 Aug 2001 08:09:21 -0400 (EDT) Received: (qmail 32539 invoked by uid 500); 29 Aug 2001 11:56:55 -0000 Date: Wed, 29 Aug 2001 04:56:55 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 138: Signed DSA messages Message-ID: <20010829045655.E32443@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827094525.V23877@charizard.diameter.org> <3B8B6821.DE20965@rioja.ericsson.se> <20010828063823.C27840@charizard.diameter.org> <3B8BA6C2.42EE2EE@rioja.ericsson.se> <20010828091817.I28427@charizard.diameter.org> <3B8BCA3F.510D124D@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: <3B8BCA3F.510D124D@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Tue, Aug 28, 2001 at 06:43:43PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > Is anything else necessary? Doesn't the above pretty much state what > > you did above, or was there something else needed? > > No. It's OK. Just take into account that my proposal and your > statement belong to different parts of the draft (mine to 3.1 and > yours to 4.1). Both say the same, so if a paragraph describing the > signature "status" of DSAR is included in 3.1, it should be similar to > my paragraph (otherwise, that paragraph, and the one describing DSAA > should be dropped). Oh, I see that there is a similar sentence for the DSAA in 3.1, so how about I add the following: - the DSAR message MAY include the CMS-Signed-Data AVP. If the originating node has a private key, and it includes AVPs whose 'P' bit is enabled, the CMS-Signed-Data AVP MUST be present. PatC From owner-aaa-wg@merit.edu Wed Aug 29 08:15: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 IAA22345 for ; Wed, 29 Aug 2001 08:15:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F342191291; Wed, 29 Aug 2001 08:15:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BECA091293; Wed, 29 Aug 2001 08:15: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 A6B2291291 for ; Wed, 29 Aug 2001 08:15:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79D3A5DDBD; Wed, 29 Aug 2001 08:15:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id EB7FE5DD9A for ; Wed, 29 Aug 2001 08:15:42 -0400 (EDT) Received: (qmail 32588 invoked by uid 500); 29 Aug 2001 12:03:17 -0000 Date: Wed, 29 Aug 2001 05:03:17 -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 136: Proxy's DSAR on behalf of a client Message-ID: <20010829050317.F32443@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , Pat Calhoun , aaa-wg@merit.edu References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8CBF64.7AFB39B8@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: <3B8CBF64.7AFB39B8@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Wed, Aug 29, 2001 at 12:09:40PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, Aug 29, 2001 at 12:09:40PM +0200, Miguel Ángel Monjas Llorente wrote: > Pat Calhoun wrote: > > > > > There are actually two scenarios regarding proxy agents and CMS: > > > > > > - The NAS hasn't got any cryptographic capability (or knows that > > > there's a proxy in its route or has been configured for always issuing > > > a PDSR to its aggregating proxy), so that it issues a PDSR. It's up to > > > the proxy to choose a DSA-TTL, provide Local-CA-Info or request OCSP > > > responses. > > > > correct. I believe this is the more common case. > > > > > - The NAS has cryptographic capabilities (and doesn't know whether > > > there's a proxy in its route). If so, it issues a DSAR when he needs > > > it (according to its policy). The proxy provides the appropriate > > > result code and, if the NAS allows to use it as CMS proxy, it will > > > issue a PDSR. However, the proxy doesn't maintain any data from > > > previous DSA setup attempst, so that its own DSAR uses parameters > > > according to its policy, not to previous DSA setup data. > > > > correct. > > Maybe you might consider to add these paragaphs (or a enhanced version > of them) to the draft to make it clearer... Wait. I'd sent you the proposed text to close this issue yesterday, and you gave me thumbs up. Are you now asking for more text? Here's what I had sent in: " It is important to note that proxy agents establishing DSA's on behalf of a client will most likely need to reorder AVPs during the encryption process, in order to fit the encrypted AVPs within a CMS-Encrypted-Data AVP. This is contrary to the rule established in the Diameter base protocol [1], which states that proxy agents SHOULD NOT reorder AVPs." and the next paragraph was already in the draft: " 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." So both of these paragraphs appear to state what I had above. Is this sufficient? PatC From owner-aaa-wg@merit.edu Wed Aug 29 08:33: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 IAA23393 for ; Wed, 29 Aug 2001 08:33:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52BB891293; Wed, 29 Aug 2001 08:34:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A35A91294; Wed, 29 Aug 2001 08:34: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 EBFDE91293 for ; Wed, 29 Aug 2001 08:34:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C18AA5DDAD; Wed, 29 Aug 2001 08:34:37 -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 AC48C5DD9A for ; Wed, 29 Aug 2001 08:34:36 -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 f7TCYYv13078 for ; Wed, 29 Aug 2001 14:34:35 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA14358; Wed, 29 Aug 2001 14:34:26 +0200 (MET DST) Message-ID: <3B8CE183.A45BD91B@rioja.ericsson.se> Date: Wed, 29 Aug 2001 14:35: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 138: Signed DSA messages References: <20010827094525.V23877@charizard.diameter.org> <3B8B6821.DE20965@rioja.ericsson.se> <20010828063823.C27840@charizard.diameter.org> <3B8BA6C2.42EE2EE@rioja.ericsson.se> <20010828091817.I28427@charizard.diameter.org> <3B8BCA3F.510D124D@rioja.ericsson.se> <20010829045655.E32443@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: > > > > Is anything else necessary? Doesn't the above pretty much state what > > > you did above, or was there something else needed? > > > > No. It's OK. Just take into account that my proposal and your > > statement belong to different parts of the draft (mine to 3.1 and > > yours to 4.1). Both say the same, so if a paragraph describing the > > signature "status" of DSAR is included in 3.1, it should be similar to > > my paragraph (otherwise, that paragraph, and the one describing DSAA > > should be dropped). > > Oh, I see that there is a similar sentence for the DSAA in 3.1, so how about > I add the following: > > - the DSAR message MAY include the CMS-Signed-Data AVP. If the > originating node has a private key, and it includes AVPs whose > 'P' bit is enabled, the CMS-Signed-Data AVP MUST be present. Perfect!! // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 08:44: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 IAA23874 for ; Wed, 29 Aug 2001 08:44:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 825DD91296; Wed, 29 Aug 2001 08:45:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DB789129B; Wed, 29 Aug 2001 08:45:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C251691296 for ; Wed, 29 Aug 2001 08:45:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D57BD5DDAD; Wed, 29 Aug 2001 08:45: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 5BBC45DD9A for ; Wed, 29 Aug 2001 08:45:00 -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 f7TCisK01163; Wed, 29 Aug 2001 14:44:55 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA15117; Wed, 29 Aug 2001 14:44:50 +0200 (MET DST) Message-ID: <3B8CE3F3.81F77D3A@rioja.ericsson.se> Date: Wed, 29 Aug 2001 14:45: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: Pat Calhoun Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8CBF64.7AFB39B8@rioja.ericsson.se> <20010829050317.F32443@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: > > Wait. I'd sent you the proposed text to close this issue yesterday, and > you gave me thumbs up. Are you now asking for more text? > > Here's what I had sent in: > > " It is important to note that proxy agents establishing DSA's on > behalf of a client will most likely need to reorder AVPs during the > encryption process, in order to fit the encrypted AVPs within a > CMS-Encrypted-Data AVP. This is contrary to the rule established in > the Diameter base protocol [1], which states that proxy agents SHOULD > NOT reorder AVPs." > > and the next paragraph was already in the draft: > > " 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." > > So both of these paragraphs appear to state what I had above. Is this > sufficient? Of course it's sufficient. I've got an only purpose when proposing this new text: to make the draft cleared (what doesn't imply that now it's clear enough). IMHO some kind of information about the "scenarios" in which CMS Security is used will be useful for CMS Sec implementators. Just that. If you consider that doesn't add any additional info or that this information isn't suitable in a specification, no problem. I respect your opinion :-))) Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 08:46: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 IAA23985 for ; Wed, 29 Aug 2001 08:46:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59AEB9123D; Wed, 29 Aug 2001 08:47:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 279DB9129B; Wed, 29 Aug 2001 08:47: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 AF3799123D for ; Wed, 29 Aug 2001 08:47:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BB0B5DD9A; Wed, 29 Aug 2001 08:47: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 C32555DDAD for ; Wed, 29 Aug 2001 08:47:40 -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 f7TClYv23478 for ; Wed, 29 Aug 2001 14:47:35 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA15234; Wed, 29 Aug 2001 14:47:31 +0200 (MET DST) Message-ID: <3B8CE494.F3E661A2@rioja.ericsson.se> Date: Wed, 29 Aug 2001 14:48: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: Re: [AAA-WG]: Issue 142: CEKMaxDecrypts value cs DSA length References: <20010827134903.U23877@charizard.diameter.org> <3B8B49AC.BF0E9EA5@rioja.ericsson.se> <20010829045057.D32443@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: > > > Yes. It's clear. That's what I thought but I just wanted to know > > whether I was right. My basic pursose is to make the specification as > > accurate as possible to prevent any possible error in > > implementation... > > > > A paragraph similar to the previous by you would be very explicit (but > > it's up to you). > > Added the following paragraph to the end of 3.4: > > " Note that the CEKMaxDecrypts value used does not affect the DSA-TTL. > The DSA-TTL dictates the lifetime of the DSA, while the CEKMaxDecrypts > dictates how often rekeying will occur within the CMS protocol." > > Is this sufficient? I would add "A content encryption key MUST NOT be reused once the DSA has expired". Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 08:47: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 IAA24022 for ; Wed, 29 Aug 2001 08:47:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D59B9129B; Wed, 29 Aug 2001 08:48:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D0259129C; Wed, 29 Aug 2001 08:48: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 3AB779129B for ; Wed, 29 Aug 2001 08:48:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EDE55DDAD; Wed, 29 Aug 2001 08:48:55 -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 42EB75DD9A for ; Wed, 29 Aug 2001 08:48:54 -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 f7TCmqK04711 for ; Wed, 29 Aug 2001 14:48:52 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA15400; Wed, 29 Aug 2001 14:48:50 +0200 (MET DST) Message-ID: <3B8CE4E3.6DDEBCB7@rioja.ericsson.se> Date: Wed, 29 Aug 2001 14:49: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: Re: [AAA-WG]: Questions about AVPs occurrence References: <3B81265A.306918E0@rioja.ericsson.se> <20010820101404.H31100@charizard.diameter.org> <3B814C98.5FC57750@rioja.ericsson.se> <20010820165318.E1924@charizard.diameter.org> <3B8CBE54.F1D62CD9@rioja.ericsson.se> <20010829043849.A32443@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: > > > Pat, have you got a proposal for this text? Is it necessary to write a > > formal issue to ask for a clarification text? > > Here's the text that I have so far: > > 4.1 Diameter-Security-Association-Request > > The Diameter-Security-Association-Request command, indicated by the > Command-Code field set to 304 and the 'R' bit set in the message > flags field, is sent by a Diameter node to establish a Diameter > Security Association. The DSAR message MUST NOT be used simply as > a convenient certificate distribution protocol without establishing > a DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the > message has the 'P' bit set. Perfect. I just wanted to know whether a certificate can be pushed "outside" a DSA. Regards // M.A. From owner-aaa-wg@merit.edu Wed Aug 29 08:48: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 IAA24089 for ; Wed, 29 Aug 2001 08:48:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF0E79129C; Wed, 29 Aug 2001 08:49:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8973912A5; Wed, 29 Aug 2001 08:49: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 968E29129C for ; Wed, 29 Aug 2001 08:49:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74C075DDAD; Wed, 29 Aug 2001 08:49:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E79645DD9A for ; Wed, 29 Aug 2001 08:49:55 -0400 (EDT) Received: (qmail 380 invoked by uid 500); 29 Aug 2001 12:37:29 -0000 Date: Wed, 29 Aug 2001 05:37:29 -0700 From: Pat Calhoun To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 142: CEKMaxDecrypts value cs DSA length Message-ID: <20010829053729.M32443@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , aaa-wg@merit.edu References: <20010827134903.U23877@charizard.diameter.org> <3B8B49AC.BF0E9EA5@rioja.ericsson.se> <20010829045057.D32443@charizard.diameter.org> <3B8CE494.F3E661A2@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: <3B8CE494.F3E661A2@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Wed, Aug 29, 2001 at 02:48:20PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > Is this sufficient? > > I would add "A content encryption key MUST NOT be reused once the DSA > has expired". done. PatC From owner-aaa-wg@merit.edu Wed Aug 29 10:09:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28051 for ; Wed, 29 Aug 2001 10:09:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A860E91212; Wed, 29 Aug 2001 10:09:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73F0A912A5; Wed, 29 Aug 2001 10:09: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 3D83F91212 for ; Wed, 29 Aug 2001 10:09:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1162E5DDD3; Wed, 29 Aug 2001 10:09: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 5F73C5DDAA for ; Wed, 29 Aug 2001 10:09:46 -0400 (EDT) Received: (qmail 651 invoked by uid 500); 29 Aug 2001 13:57:19 -0000 Date: Wed, 29 Aug 2001 06:57:19 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: AAA Listan , Pat Calhoun Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010829065719.R32443@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , AAA Listan , Pat Calhoun References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Wed, Aug 29, 2001 at 11:06:08AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Aug 29, 2001 at 11:06:08AM +0200, Fredrik Johansson wrote: > Submitter name: Fredrik Johansson > Submitter email address: Fredrik@ipunplugged.com > Date first submitted: 2001-08-29 > Reference: > Document: base > Comment type: E > Priority: 1 > Section: > Rationale/Explanation of issue: > > There are some missing states in the authorization session state machine. > > 1. It is optional to send a ASR when cleaning up a session on a home server, > however there is no indication on what state to go to when doing so. My > guess is that you should go to Disconnect and wait for a ASA. Since this is > an optional feature I'm not sure it should be in the state machine. However, > if you send an ASA there has to be a state indicating how to get from > Disconnect to Closed. > > Requested Change: > > Add the following state > > Discon ASA Received Cleanup Closed > BTW, it might just be a cut'n past error, the > Open ASA Received Cleanup Closed > state should not exist, if you have sent an ASR you should not be in Open, > so replace the latter with the first state above. Actually, the following Open ASA Received Cleanup Closed should have been Discon ASA Received Cleanup Idle > > 2. There is no state where the home server can receive a service specific > auth. request and extend access and stay in open. > > Requested Change: > Add a the following state: > Open Successful Service-Specific Extend Open > Authorization Request received Access > but -07 already has this exact state. > 3. There is no state where the home server can receive a STR send a STA and > go to Closed > > Requested Change: > Add the following state: > Open receive STR send STA Closed Actually, it should be Open STR Received Send STA Discon > > 4. According to the following state: > Open Authorization-Lifetime Send Open > expires on access device service > specific > auth req > > It's not clear that an access device can not send a Service-Specific Auth. > request on Authorization-Lifetime expiration unless it has received a MIP > registration request or PPP request. > > Requested Change: > Can it be made clearer that if no such message has been received it should > send a STR and go to Disconnect? but this is service specific. If I was to add such language, it could break the state machine for future apps that don't operate this way. I will assume that the implementor knows that some access protocol interactions are necessary with the user, and leave it undefined. PatC From owner-aaa-wg@merit.edu Wed Aug 29 11:20:36 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00969 for ; Wed, 29 Aug 2001 11:20:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCAC8912BE; Wed, 29 Aug 2001 11:21:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98314912BF; Wed, 29 Aug 2001 11: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 80143912BE for ; Wed, 29 Aug 2001 11:21:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6889B5DDAD; Wed, 29 Aug 2001 11:21:16 -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 735315DDAA for ; Wed, 29 Aug 2001 11:21:15 -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 RAA22481; Wed, 29 Aug 2001 17:22:15 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Wed, 29 Aug 2001 17:22:31 +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: <20010829065719.R32443@charizard.diameter.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > >On Wed, Aug 29, 2001 at 11:06:08AM +0200, Fredrik Johansson wrote: >> Submitter name: Fredrik Johansson >> Submitter email address: Fredrik@ipunplugged.com >> Date first submitted: 2001-08-29 >> Reference: >> Document: base >> Comment type: E >> Priority: 1 >> Section: >> Rationale/Explanation of issue: >> >> There are some missing states in the authorization session state machine. >> >> 1. It is optional to send a ASR when cleaning up a session on a >home server, >> however there is no indication on what state to go to when doing so. My >> guess is that you should go to Disconnect and wait for a ASA. >Since this is >> an optional feature I'm not sure it should be in the state >machine. However, >> if you send an ASA there has to be a state indicating how to get from >> Disconnect to Closed. >> >> Requested Change: >> >> Add the following state >> >> Discon ASA Received Cleanup Closed >> BTW, it might just be a cut'n past error, the >> Open ASA Received Cleanup Closed >> state should not exist, if you have sent an ASR you should not >be in Open, >> so replace the latter with the first state above. > >Actually, the following > >Open ASA Received Cleanup Closed > >should have been > >Discon ASA Received Cleanup Idle why Idle?! the session has been killed, and confirmation has been received that it has been killed on the other end as well. > >> >> 2. There is no state where the home server can receive a service specific >> auth. request and extend access and stay in open. >> >> Requested Change: >> Add a the following state: >> Open Successful Service-Specific Extend Open >> Authorization Request received Access >> > >but -07 already has this exact state. where?!? I can only find Open Successful Service-Specific Extend Open Authrorizatio Answer received Access ^^^^^^ > >> 3. There is no state where the home server can receive a STR >send a STA and >> go to Closed >> >> Requested Change: >> Add the following state: >> Open receive STR >send STA Closed > >Actually, it should be > >Open STR Received Send STA Discon Why go to Discon, how do you get from Discon to Closed? > >> >> 4. According to the following state: >> Open Authorization-Lifetime Send Open >> expires on access device service >> specific >> auth req >> >> It's not clear that an access device can not send a >Service-Specific Auth. >> request on Authorization-Lifetime expiration unless it has received a MIP >> registration request or PPP request. >> >> Requested Change: >> Can it be made clearer that if no such message has been received >it should >> send a STR and go to Disconnect? > >but this is service specific. If I was to add such language, it could break >the state machine for future apps that don't operate this way. I >will assume >that the implementor knows that some access protocol interactions >are necessary >with the user, and leave it undefined. It does however break the two existing applications. is it that likely that there will be an application in the future that allows authentication that is not initated by the authenticated device. Would not such an application suffer from vulnerability to replay attacks? I beleive that the transition should be Open Authorization-Lifetime send STR Discon expires on access device since the authenticated device would have requested re-authentication before the auth-lifetime expires if it cares to continue the service. And the latter shoudl be covered by the following transition Open Client or Device Request access send Service-Spec Open auth req /Fredrik > >PatC From owner-aaa-wg@merit.edu Wed Aug 29 11:37:51 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01411 for ; Wed, 29 Aug 2001 11:37:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB313912CD; Wed, 29 Aug 2001 11:37:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ADC2912CE; Wed, 29 Aug 2001 11:37: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 B9C3B912CD for ; Wed, 29 Aug 2001 11:36:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D61A5DDEB; Wed, 29 Aug 2001 11:36:53 -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 7F8415DDAD for ; Wed, 29 Aug 2001 11:36:52 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA24370 for ; Wed, 29 Aug 2001 08:36:51 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA12575 for ; Wed, 29 Aug 2001 08:36:51 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 29 Aug 2001 10:36:50 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" , Fredrik Johansson Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Wed, 29 Aug 2001 10:36:47 -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 Most of my comments are in alignment with Fredrik's last message. > > Requested Change: > > Add the following state: > > Open receive STR send STA Closed > Actually, it should be > Open STR Received Send STA Discon How will the server ever get out of Discon? I think that it should be Open STR Received Send STA,Cleanup Closed > Actually, the following > Open ASA Received Cleanup Closed > should have been > Discon ASA Received Cleanup Idle What difference does it make to go to Idle instead of Closed? Also, as part of this issue, I'd like to request for some extra clarifications: 5. Client is in "Pending" and receives a failed Auth-Answer. ->goes to "Closed"? 6. Home Server is in "Idle", receives an Auth-Request and sends back a failed Auth-Answer. ->goes to "Closed"? 7. Home Server is in the "Open" and receives an Auth-Request ->sends an Auth-Answer and goes to "Open" if success, or "Closed" if failure? 8. Home Server wants to send an ASR -> goes to "Disconnect", right? and a minor one... "Pending Successful Service-Specific Grant Active Authorization answer received Access with Auth-Session-State set to NO_SESSION_MAINTAINED " s/NO_SESSION_MAINTAINED/NO_STATE_MAINTAINED -Panos -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, August 29, 2001 8:57 AM To: Fredrik Johansson Cc: AAA Listan; Pat Calhoun Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine On Wed, Aug 29, 2001 at 11:06:08AM +0200, Fredrik Johansson wrote: > Submitter name: Fredrik Johansson > Submitter email address: Fredrik@ipunplugged.com > Date first submitted: 2001-08-29 > Reference: > Document: base > Comment type: E > Priority: 1 > Section: > Rationale/Explanation of issue: > > There are some missing states in the authorization session state machine. > > 1. It is optional to send a ASR when cleaning up a session on a home server, > however there is no indication on what state to go to when doing so. My > guess is that you should go to Disconnect and wait for a ASA. Since this is > an optional feature I'm not sure it should be in the state machine. However, > if you send an ASA there has to be a state indicating how to get from > Disconnect to Closed. > > Requested Change: > > Add the following state > > Discon ASA Received Cleanup Closed > BTW, it might just be a cut'n past error, the > Open ASA Received Cleanup Closed > state should not exist, if you have sent an ASR you should not be in Open, > so replace the latter with the first state above. Actually, the following Open ASA Received Cleanup Closed should have been Discon ASA Received Cleanup Idle > > 2. There is no state where the home server can receive a service specific > auth. request and extend access and stay in open. > > Requested Change: > Add a the following state: > Open Successful Service-Specific Extend Open > Authorization Request received Access > but -07 already has this exact state. > 3. There is no state where the home server can receive a STR send a STA and > go to Closed > > Requested Change: > Add the following state: > Open receive STR send STA Closed Actually, it should be Open STR Received Send STA Discon > > 4. According to the following state: > Open Authorization-Lifetime Send Open > expires on access device service > specific > auth req > > It's not clear that an access device can not send a Service-Specific Auth. > request on Authorization-Lifetime expiration unless it has received a MIP > registration request or PPP request. > > Requested Change: > Can it be made clearer that if no such message has been received it should > send a STR and go to Disconnect? but this is service specific. If I was to add such language, it could break the state machine for future apps that don't operate this way. I will assume that the implementor knows that some access protocol interactions are necessary with the user, and leave it undefined. PatC From owner-aaa-wg@merit.edu Wed Aug 29 18:52: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 SAA12972 for ; Wed, 29 Aug 2001 18:52:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97568912F8; Wed, 29 Aug 2001 18:51:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C20091301; Wed, 29 Aug 2001 18:51:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D1F2912F8 for ; Wed, 29 Aug 2001 18:51:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42BEA5DDA9; Wed, 29 Aug 2001 18:51:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id B65595DD9B for ; Wed, 29 Aug 2001 18:51:44 -0400 (EDT) Received: (qmail 4686 invoked by uid 500); 29 Aug 2001 22:39:16 -0000 Date: Wed, 29 Aug 2001 15:39:16 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , AAA Listan Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010829153916.E4393@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , AAA Listan References: <20010829065719.R32443@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 Wed, Aug 29, 2001 at 05:22:31PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > >Actually, the following > > > >Open ASA Received Cleanup Closed > > > >should have been > > > >Discon ASA Received Cleanup Idle > > why Idle?! the session has been killed, and confirmation has been received > that it has been killed on the other end as well. all this was changed as a result of a previous issue. The term closed was strange, since it implied that the session control block would remain in memory and marked as closed. Further, the author of the issue, for which I posted proposed text, claimed that it was difficult to distinguish the difference between closed and discon. In any case, here is the latest state machine (in the soon to be -08): State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed answer Pending Successful Service-Specific Grant Open Authorization answer Access received with default Auth-Session-State value Pending Successful Service-Specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-Specific authorization answer Open Authorization-Lifetime send Open expires on access device service specific auth req Open Successful Service-Specific Extend Open Authorization answer Access received Open Accounting message sent or process Open received Open Failed Service-Specific Discon. Idle Authorization answer user/device received. Open Session-Timeout Expires on send STR Discon Access Device Open ASR Received send ASA, Discon STR Open Authorization-Lifetime (and Cleanup Discon Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Discon home server Open STR Received Send STA Discon Discon ASA Received Cleanup Idle Discon ASR Received None Discon Discon STR Received Send STA Idle Discon STA Received Discon. Idle user/device > >> Requested Change: > >> Add a the following state: > >> Open Successful Service-Specific Extend Open > >> Authorization Request received Access > >> > > > >but -07 already has this exact state. > > where?!? I can only find > Open Successful Service-Specific Extend Open > Authrorizatio Answer received Access > ^^^^^^ oops.... my eyeball diff obviously failed :( > > > > > >> 3. There is no state where the home server can receive a STR > >send a STA and > >> go to Closed > >> > >> Requested Change: > >> Add the following state: > >> Open receive STR > >send STA Closed > > > >Actually, it should be > > > >Open STR Received Send STA Discon > > Why go to Discon, how do you get from Discon to Closed? See above. > > > > > >> > >> 4. According to the following state: > >> Open Authorization-Lifetime Send Open > >> expires on access device service > >> specific > >> auth req > >> > >> It's not clear that an access device can not send a > >Service-Specific Auth. > >> request on Authorization-Lifetime expiration unless it has received a MIP > >> registration request or PPP request. > >> > >> Requested Change: > >> Can it be made clearer that if no such message has been received > >it should > >> send a STR and go to Disconnect? > > > >but this is service specific. If I was to add such language, it could break > >the state machine for future apps that don't operate this way. I > >will assume > >that the implementor knows that some access protocol interactions > >are necessary > >with the user, and leave it undefined. > > It does however break the two existing applications. > is it that likely that there will be an application in the future that > allows authentication that is not initated by the authenticated device. > Would not such an application suffer from vulnerability to replay attacks? I > beleive that the transition should be > > Open Authorization-Lifetime send STR Discon > expires on access device > > since the authenticated device would have requested re-authentication before > the auth-lifetime expires if it cares to continue the service. And the > latter shoudl be covered by the following transition > > Open Client or Device Request access send Service-Spec Open > auth req ok PatC From owner-aaa-wg@merit.edu Wed Aug 29 18:56: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 SAA13021 for ; Wed, 29 Aug 2001 18:56:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 63E83912F9; Wed, 29 Aug 2001 18:57:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 396C3912FA; Wed, 29 Aug 2001 18:57: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 33C39912F9 for ; Wed, 29 Aug 2001 18:57:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 120B65DDA9; Wed, 29 Aug 2001 18:57:07 -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 80AC75DD9B for ; Wed, 29 Aug 2001 18:57:06 -0400 (EDT) Received: (qmail 4718 invoked by uid 500); 29 Aug 2001 22:44:38 -0000 Date: Wed, 29 Aug 2001 15:44:38 -0700 From: Pat Calhoun To: Fredrik Johansson , Pat Calhoun , AAA Listan Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010829154438.F4393@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , AAA Listan References: <20010829065719.R32443@charizard.diameter.org> <20010829153916.E4393@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: <20010829153916.E4393@charizard.diameter.org>; from pcalhoun@diameter.org on Wed, Aug 29, 2001 at 03:39:16PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > It does however break the two existing applications. > > is it that likely that there will be an application in the future that > > allows authentication that is not initated by the authenticated device. > > Would not such an application suffer from vulnerability to replay attacks? I > > beleive that the transition should be > > > > Open Authorization-Lifetime send STR Discon > > expires on access device Actually, I believe that the correct state table entry is the following: Open Authorization-Lifetime + send STR Open Auth-Grace-Period expires on access device PatC From owner-aaa-wg@merit.edu Wed Aug 29 18:58: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 SAA13055 for ; Wed, 29 Aug 2001 18:58:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58F8F912FA; Wed, 29 Aug 2001 18:59:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2247C912FB; Wed, 29 Aug 2001 18: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 E212B912FA for ; Wed, 29 Aug 2001 18:59:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B83D55DDA9; Wed, 29 Aug 2001 18:59: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 6529F5DD9B for ; Wed, 29 Aug 2001 18:59:37 -0400 (EDT) Received: (qmail 4741 invoked by uid 500); 29 Aug 2001 22:47:09 -0000 Date: Wed, 29 Aug 2001 15:47:09 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , Fredrik Johansson , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010829154709.G4393@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , Fredrik Johansson , "'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 Wed, Aug 29, 2001 at 10:36:47AM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Aug 29, 2001 at 10:36:47AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > Most of my comments are in alignment with Fredrik's last > message. > Please take a look at the complete state table below (I just realized that I only sent a portion of it in my response to Fredrik). These changes were the result of issues that have since been closed. Any comments on this state table would be most appreciated: State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed answer Pending Successful Service-Specific Grant Open Authorization answer Access received with default Auth-Session-State value Pending Successful Service-Specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-Specific authorization answer Open user or client device send Open requests access to service service specific auth req Open Authorization-Lifetime + send STR Open Auth-Grace-Period expires on access device Open Successful Service-Specific Extend Open Authorization request or Access answer received Open Accounting message sent or process Open received Open Failed Service-Specific Discon. Idle Authorization answer user/device received. Open Session-Timeout Expires on send STR Discon Access Device Open ASR Received send ASA, Discon STR Open Authorization-Lifetime (and Cleanup Discon Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Discon home server Open STR Received Send STA Discon Discon ASA Received Cleanup Idle Discon ASR Received None Discon Discon STR Received Send STA Idle Discon STA Received Discon. Idle user/device The following state machine is used when state is not maintained on the server: State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed answer Pending Successful Service-Specific Grant Open Authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Open Accounting message sent or process Open received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device PatC From owner-aaa-wg@merit.edu Thu Aug 30 05:24: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 FAA08489 for ; Thu, 30 Aug 2001 05:24:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E0099130B; Thu, 30 Aug 2001 05:22:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C508A9130F; Thu, 30 Aug 2001 05:22: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 C31AA9130B for ; Thu, 30 Aug 2001 05:22:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A80295DDC7; Thu, 30 Aug 2001 05:22:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id DDBE75DDA9 for ; Thu, 30 Aug 2001 05:22:48 -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 LAA05997; Thu, 30 Aug 2001 11:23:37 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , "AAA Listan" Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Thu, 30 Aug 2001 11:23:53 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010829154438.F4393@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > >> > It does however break the two existing applications. >> > is it that likely that there will be an application in the future that >> > allows authentication that is not initated by the authenticated device. >> > Would not such an application suffer from vulnerability to >replay attacks? I >> > beleive that the transition should be >> > >> > Open Authorization-Lifetime send STR > Discon >> > expires on access device > >Actually, I believe that the correct state table entry is the following: > >Open Authorization-Lifetime + send STR Open > Auth-Grace-Period expires on > access device Why? First of all it seems strange to close try to close a session and still stay in open. And secondly, there is no transition from Open that receives a STA and goes to Idle. I believe it's more logical to go to Discon when sending STR and go from Discon to Idle when receiving STA. /Fredrik > > >PatC From owner-aaa-wg@merit.edu Thu Aug 30 06:01:38 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08824 for ; Thu, 30 Aug 2001 06:01:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98A9B9131C; Thu, 30 Aug 2001 06:01:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55B3A9131B; Thu, 30 Aug 2001 06:01: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 1C38291310 for ; Thu, 30 Aug 2001 06:00:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE46C5DD93; Thu, 30 Aug 2001 06:00:56 -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 1ADB65DDC7 for ; Thu, 30 Aug 2001 06:00:56 -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 LAA06720; Thu, 30 Aug 2001 11:51:49 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , "Thomas Panagiotis-PTHOMAS1" Cc: Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Thu, 30 Aug 2001 11:52:05 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010829154709.G4393@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I've a comment (apart from the one I just send about the send STR go to Open). from section 8.0 "An access device that does not expect to send a re-authorization or a session termination request to the server MAY include the Auth- Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint to the server. If the server accepts the hint, it agrees that since no session termination message will be received once service to the user is terminated, it cannot maintain state for the session. " according to the above paragraph there should be no state maintained. So why move to Open on the server if no state should be maintained? I believe that when receiving a Service Specific Auth Req/Ans with NO_STATE_MAINTAINED (and the server accepts this) it would be better to go to Idle? If it is because the server should be able to receive accounting messages for the session, then I don't see the meaning of NO_STATE_MAINTAINED. When is the NO_STATE_MAINTAINED used anyway? /Fredrik >-----Original Message----- >From: Pat Calhoun [mailto:pcalhoun@diameter.org] >Sent: den 30 augusti 2001 00:47 >To: Thomas Panagiotis-PTHOMAS1 >Cc: 'Pat Calhoun'; Fredrik Johansson; 'aaa-wg@merit.edu' >Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine > > >On Wed, Aug 29, 2001 at 10:36:47AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: >> Most of my comments are in alignment with Fredrik's last >> message. >> > >Please take a look at the complete state table below (I just realized that >I only sent a portion of it in my response to Fredrik). These changes were >the result of issues that have since been closed. Any comments on this >state table would be most appreciated: > >State Event Action New State >------------------------------------------------------------- >Idle Client or Device Requests send Pending > access service > specific > auth req > >Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed answer > >Pending Successful Service-Specific Grant Open > Authorization answer Access > received with default > Auth-Session-State value > >Pending Successful Service-Specific Sent STR Discon > authorization answer received > but service not provided > >Pending Error processing successful Sent STR Discon > Service-Specific authorization > answer > >Open user or client device send Open > requests access to service service > specific > auth req > >Open Authorization-Lifetime + send STR Open > Auth-Grace-Period expires on > access device > >Open Successful Service-Specific Extend Open > Authorization request or Access > answer received > >Open Accounting message sent or process Open > received > >Open Failed Service-Specific Discon. Idle > Authorization answer user/device > received. > >Open Session-Timeout Expires on send STR Discon > Access Device > >Open ASR Received send ASA, Discon > STR > >Open Authorization-Lifetime (and Cleanup Discon > Auth-Grace-Period) expires > on home server. > >Open Session-Timeout expires on Cleanup Discon > home server > >Open STR Received Send STA Discon > >Discon ASA Received Cleanup Idle > >Discon ASR Received None Discon > >Discon STR Received Send STA Idle > >Discon STA Received Discon. Idle > user/device > >The following state machine is used when state is not maintained >on the server: > >State Event Action New State >------------------------------------------------------------- >Idle Client or Device Requests send Pending > access service > specific > auth req > >Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed answer > >Pending Successful Service-Specific Grant Open > Authorization answer Access > received with Auth-Session- > State set to > NO_STATE_MAINTAINED > >Open Accounting message sent or process Open > received > >Open Session-Timeout Expires on Discon. Idle > Access Device user/device > >Open Service to user is terminated Discon. Idle > user/device > >PatC From owner-aaa-wg@merit.edu Thu Aug 30 09:31: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 JAA16315 for ; Thu, 30 Aug 2001 09:31:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C327E91293; Thu, 30 Aug 2001 09:31:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CA6B9129B; Thu, 30 Aug 2001 09:31: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 9B55291293 for ; Thu, 30 Aug 2001 09:31:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81CBA5DD93; Thu, 30 Aug 2001 09:31: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 F2BB75DDAE for ; Thu, 30 Aug 2001 09:31:19 -0400 (EDT) Received: (qmail 6809 invoked by uid 500); 30 Aug 2001 13:18:49 -0000 Date: Thu, 30 Aug 2001 06:18:49 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , AAA Listan Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010830061848.A6795@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , AAA Listan References: <20010829154438.F4393@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 Thu, Aug 30, 2001 at 11:23:53AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > >Actually, I believe that the correct state table entry is the following: > > > >Open Authorization-Lifetime + send STR Open > > Auth-Grace-Period expires on > > access device > > Why? mostly due to sleep deprivation. > First of all it seems strange to close try to close a session and still stay > in open. And secondly, there is no transition from Open that receives a STA > and goes to Idle. I believe it's more logical to go to Discon when sending > STR and go from Discon to Idle when receiving STA. Of course, the transition state should have been Discon. PatC From owner-aaa-wg@merit.edu Thu Aug 30 09:34: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 JAA16419 for ; Thu, 30 Aug 2001 09:34:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50B5891296; Thu, 30 Aug 2001 09:35:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C4D39129B; Thu, 30 Aug 2001 09:35: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 BB5A391296 for ; Thu, 30 Aug 2001 09:35:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A03485DDAE; Thu, 30 Aug 2001 09:35: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 4D53A5DD93 for ; Thu, 30 Aug 2001 09:35:24 -0400 (EDT) Received: (qmail 6850 invoked by uid 500); 30 Aug 2001 13:22:54 -0000 Date: Thu, 30 Aug 2001 06:22:54 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010830062254.B6795@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu References: <20010829154709.G4393@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 Thu, Aug 30, 2001 at 11:52:05AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Aug 30, 2001 at 11:52:05AM +0200, Fredrik Johansson wrote: > Pat, > > I've a comment (apart from the one I just send about the send STR go to > Open). > > from section 8.0 > "An access device that does not expect to send a re-authorization or a > session termination request to the server MAY include the Auth- > Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint > to the server. If the server accepts the hint, it agrees that since > no session termination message will be received once service to the > user is terminated, it cannot maintain state for the session. " > > according to the above paragraph there should be no state maintained. So why > move to Open on the server if no state should be maintained? I believe that > when receiving a Service Specific Auth Req/Ans with NO_STATE_MAINTAINED (and > the server accepts this) it would be better to go to Idle? If it is because > the server should be able to receive accounting messages for the session, > then I don't see the meaning of NO_STATE_MAINTAINED. > > When is the NO_STATE_MAINTAINED used anyway? So, if I was to modify the server side state to: Idle Service-Specific authorization send serv. Idle request received, and specific successfully processed answer that would satisfy your issue? The client side still remains in the open state since it has an active "connection" to the user. When the user goes away the state control block is moved to Idle. Is that ok? PatC From owner-aaa-wg@merit.edu Thu Aug 30 10:13: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 KAA17713 for ; Thu, 30 Aug 2001 10:13:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7369D91218; Thu, 30 Aug 2001 10:14:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B7EC9124E; Thu, 30 Aug 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 4543691218 for ; Thu, 30 Aug 2001 10:14:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25E255DDA8; Thu, 30 Aug 2001 10:14:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 361615DD93 for ; Thu, 30 Aug 2001 10:14:28 -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 QAA12675; Thu, 30 Aug 2001 16:15:25 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "Thomas Panagiotis-PTHOMAS1" , Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Thu, 30 Aug 2001 16:15:42 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010830062254.B6795@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit sounds good to me, might want to add that no state is maintained. Idle Service-Specific authorization send serv. Idle request received, and specific successfully processed, and answer NO_STATE_MAINTAINED Just out of curiosity, do you have an example on when one might use the NO_STATE_MAINTAINED? thanks /Fredrik >-----Original Message----- >From: Pat Calhoun [mailto:pcalhoun@diameter.org] >Sent: den 30 augusti 2001 15:23 >To: Fredrik Johansson >Cc: Pat Calhoun; Thomas Panagiotis-PTHOMAS1; aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine > > >On Thu, Aug 30, 2001 at 11:52:05AM +0200, Fredrik Johansson wrote: >> Pat, >> >> I've a comment (apart from the one I just send about the send STR go to >> Open). >> >> from section 8.0 >> "An access device that does not expect to send a re-authorization or a >> session termination request to the server MAY include the Auth- >> Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint >> to the server. If the server accepts the hint, it agrees that since >> no session termination message will be received once service to the >> user is terminated, it cannot maintain state for the session. " >> >> according to the above paragraph there should be no state >maintained. So why >> move to Open on the server if no state should be maintained? I >believe that >> when receiving a Service Specific Auth Req/Ans with >NO_STATE_MAINTAINED (and >> the server accepts this) it would be better to go to Idle? If it >is because >> the server should be able to receive accounting messages for the session, >> then I don't see the meaning of NO_STATE_MAINTAINED. >> >> When is the NO_STATE_MAINTAINED used anyway? > >So, if I was to modify the server side state to: > >Idle Service-Specific authorization send serv. Idle > request received, and specific > successfully processed answer > >that would satisfy your issue? The client side still remains in the open >state since it has an active "connection" to the user. When the user goes >away the state control block is moved to Idle. > >Is that ok? > >PatC From owner-aaa-wg@merit.edu Thu Aug 30 10:19: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 KAA17966 for ; Thu, 30 Aug 2001 10:19:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 571C091216; Thu, 30 Aug 2001 10:20:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20FC99124E; Thu, 30 Aug 2001 10:20:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 067E991216 for ; Thu, 30 Aug 2001 10:20:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC4B55DDA8; Thu, 30 Aug 2001 10:20:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 445035DD93 for ; Thu, 30 Aug 2001 10:20:41 -0400 (EDT) Received: (qmail 7077 invoked by uid 500); 30 Aug 2001 14:08:07 -0000 Date: Thu, 30 Aug 2001 07:08:07 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010830070807.D6795@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , Pat Calhoun , Thomas Panagiotis-PTHOMAS1 , aaa-wg@merit.edu References: <20010830062254.B6795@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 Thu, Aug 30, 2001 at 04:15:42PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Aug 30, 2001 at 04:15:42PM +0200, Fredrik Johansson wrote: > sounds good to me, might want to add that no state is maintained. > > Idle Service-Specific authorization send serv. Idle > request received, and specific > successfully processed, and answer > NO_STATE_MAINTAINED > > Just out of curiosity, do you have an example on when one might use the > NO_STATE_MAINTAINED? you mean an app? No, but 3GPP is getting one ready. So I can close the issue, then? PatC From owner-aaa-wg@merit.edu Thu Aug 30 10:25:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18172 for ; Thu, 30 Aug 2001 10:25:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D24969124E; Thu, 30 Aug 2001 10:26:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DFE9912CD; Thu, 30 Aug 2001 10:26: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 8BC809124E for ; Thu, 30 Aug 2001 10:26:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CB185DDA8; Thu, 30 Aug 2001 10:26:18 -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 9CED85DD93 for ; Thu, 30 Aug 2001 10:26:17 -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 QAA12958; Thu, 30 Aug 2001 16:27:10 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "Thomas Panagiotis-PTHOMAS1" , Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Thu, 30 Aug 2001 16:27:27 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010830070807.D6795@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks, yepp, please close this issue. One down not so many more to go (I hope), although it seems like there is an endless stream of issues. /Fredrik >-----Original Message----- >From: Pat Calhoun [mailto:pcalhoun@diameter.org] >Sent: den 30 augusti 2001 16:08 >To: Fredrik Johansson >Cc: Pat Calhoun; Thomas Panagiotis-PTHOMAS1; aaa-wg@merit.edu >Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine > > >On Thu, Aug 30, 2001 at 04:15:42PM +0200, Fredrik Johansson wrote: >> sounds good to me, might want to add that no state is maintained. >> >> Idle Service-Specific authorization send serv. Idle >> request received, and specific >> successfully processed, and answer >> NO_STATE_MAINTAINED >> >> Just out of curiosity, do you have an example on when one might use the >> NO_STATE_MAINTAINED? > >you mean an app? No, but 3GPP is getting one ready. > >So I can close the issue, then? > >PatC From owner-aaa-wg@merit.edu Thu Aug 30 10:30: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 KAA18343 for ; Thu, 30 Aug 2001 10:30:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D87B912F8; Thu, 30 Aug 2001 10:30:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10CF2912F9; Thu, 30 Aug 2001 10:30: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 739FE912F8 for ; Thu, 30 Aug 2001 10:30:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08A825DDA8; Thu, 30 Aug 2001 10:30: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 BC6885DD93 for ; Thu, 30 Aug 2001 10:30:34 -0400 (EDT) Received: (qmail 7186 invoked by uid 500); 30 Aug 2001 14:18:04 -0000 Date: Thu, 30 Aug 2001 07:18:04 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Last Call: Issue 123: Use of Application Identifiers in routing Message-ID: <20010830071804.E6795@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 authors of this issue have requested a change in the routing scheme, and an ongoing discussion transpired. The end result was that I wanted to know whether the WG felt we should adopt such a change. At this point, I am not seeing any support for this feature, but I would be REALLY interested in hearing at least one comment from the list. anyone out there? PatC From owner-aaa-wg@merit.edu Thu Aug 30 10:32: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 KAA18419 for ; Thu, 30 Aug 2001 10:32:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B8D99121C; Thu, 30 Aug 2001 10:33:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B7D6912CD; Thu, 30 Aug 2001 10:33:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B61B9121C for ; Thu, 30 Aug 2001 10:33:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1E5B5DDA8; Thu, 30 Aug 2001 10:33: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 9B0E95DD93 for ; Thu, 30 Aug 2001 10:33:52 -0400 (EDT) Received: (qmail 7218 invoked by uid 500); 30 Aug 2001 14:21:22 -0000 Date: Thu, 30 Aug 2001 07:21:21 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Last Call: Issue 128: duplicate packet detection failure case Message-ID: <20010830072121.G6795@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 author of this issue claims that the Diameter protocol doesn't have a good enough packet failure detection scheme, and proposes some radical changes to the protocol. I would really encourage folks to read the thread and respond with their comments. In order for me to have the Diameter specs out asap, I need to close these last remaining issues. My take on this one is to reject it, but I could be wrong. comments (both positive and negative) PatC From owner-aaa-wg@merit.edu Thu Aug 30 11:00:29 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18994 for ; Thu, 30 Aug 2001 11:00:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A85F6912CD; Thu, 30 Aug 2001 11:00:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75CB3912F9; Thu, 30 Aug 2001 11:00: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 53B1F912CD for ; Thu, 30 Aug 2001 11:00:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25DC85DDA8; Thu, 30 Aug 2001 11:00:34 -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 2AC745DD93 for ; Thu, 30 Aug 2001 11:00:33 -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 f7UF0x325881 for ; Thu, 30 Aug 2001 18:00:59 +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, 30 Aug 2001 18:00:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWALL6>; Thu, 30 Aug 2001 18:00:25 +0300 Message-ID: <9E3407CE45911B4097632389B77B202310780C@esebe014.NOE.Nokia.com> From: Adrian.Constantin@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: End-to-End Id in answer messages Date: Thu, 30 Aug 2001 18:00:15 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue: End-to-End Id in answer messages Submitter name: Adrian Constantin Submitter email address: adrian.constantin@nokia.com Date first submitted: Reference: Document: Base 07 Comment type: E Priority: 1 Section: 3.0 and 6.2 Rationale/Explanation of issue: There is a consensus about copying the end-to-end id from the request in the answer issued by a home server, but the specification doesn't clearly state it. Requested Change: In section 3.0, End-to-End Identifier paragraph, change from "Senders of request or answer messages MUST insert a unique identifier on each message, by incrementing the identifier by one (1)." to: "Senders of request messages MUST insert a unique identifier on each message, by incrementing the identifier by one (1). The originator of an Answer message MUST ensure that the End-to-End Identifier field contains the same value that was found in the corresponding request." In section 6.2 add the following text: "- The same End-to-End identifier in the request is used in the answer." Regards, Adrian Constantin ------------------------------ Adrian Constantin Software Engineer Nokia Networks, IP Mobility Networks Takomotie 1/1b22, 00380 Helsinki, Finland Phone +358 718061689 Mobile +358 40 8386127 Fax. +358 9 51168770 ------------------------------ Adrian Constantin Software Engineer Nokia Networks, IP Mobility Networks Takomotie 1/1b22, 00380 Helsinki, Finland Phone +358 718061689 Mobile +358 40 8386127 Fax. +358 9 51168770 From owner-aaa-wg@merit.edu Thu Aug 30 11:31: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 LAA19660 for ; Thu, 30 Aug 2001 11:31:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D33D3912F9; Thu, 30 Aug 2001 11:32:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A982912FA; Thu, 30 Aug 2001 11:32: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 6A992912F9 for ; Thu, 30 Aug 2001 11:32:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D94A5DDC7; Thu, 30 Aug 2001 11:32:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 8EEFF5DD93 for ; Thu, 30 Aug 2001 11:32:13 -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 RAA14393; Thu, 30 Aug 2001 17:33:06 +0200 From: "Fredrik Johansson" To: "Pat Calhoun" , Subject: RE: [AAA-WG]: Last Call: Issue 128: duplicate packet detection failure case Date: Thu, 30 Aug 2001 17:33:23 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010830072121.G6795@charizard.diameter.org> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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. I'd say, keep it as it is. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Pat Calhoun >Sent: den 30 augusti 2001 16:21 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Last Call: Issue 128: duplicate packet detection >failure case > > >All, > >The author of this issue claims that the Diameter protocol doesn't have a >good enough packet failure detection scheme, and proposes some radical >changes to the protocol. > >I would really encourage folks to read the thread and respond with their >comments. In order for me to have the Diameter specs out asap, I need to >close these last remaining issues. > >My take on this one is to reject it, but I could be wrong. > >comments (both positive and negative) > >PatC From owner-aaa-wg@merit.edu Thu Aug 30 11:32: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 LAA19691 for ; Thu, 30 Aug 2001 11:32:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA7E1912FA; Thu, 30 Aug 2001 11:33:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DFAC91312; Thu, 30 Aug 2001 11:33: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 8887E912FA for ; Thu, 30 Aug 2001 11:33:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 682245DDC7; Thu, 30 Aug 2001 11:33:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from newman.frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with ESMTP id 613105DD93 for ; Thu, 30 Aug 2001 11:33:44 -0400 (EDT) Received: (from chaos@localhost) by newman.frascone.com (8.11.2/8.11.2) id f7UFeBi09496; Thu, 30 Aug 2001 10:40:11 -0500 Date: Thu, 30 Aug 2001 10:40:11 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Last Call: Issue 128: duplicate packet detection failure case Message-ID: <20010830104011.S5934@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010830072121.G6795@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: <20010830072121.G6795@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Aug 30, 2001 at 07:21:21AM -0700 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I think the current protocol can adequately detect failures. My vote is to reject it. -Dave On Thu, Aug 30, 2001 at 07:21:21AM -0700, Pat Calhoun wrote: > All, > > The author of this issue claims that the Diameter protocol doesn't have a > good enough packet failure detection scheme, and proposes some radical > changes to the protocol. > > I would really encourage folks to read the thread and respond with their > comments. In order for me to have the Diameter specs out asap, I need to > close these last remaining issues. > > My take on this one is to reject it, but I could be wrong. > > comments (both positive and negative) > > PatC > From owner-aaa-wg@merit.edu Thu Aug 30 13:11: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 NAA22217 for ; Thu, 30 Aug 2001 13:11:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0C9C91203; Thu, 30 Aug 2001 13:11:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91F1191325; Thu, 30 Aug 2001 13:11:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91D6091203 for ; Thu, 30 Aug 2001 13:11:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D7D85DDC7; Thu, 30 Aug 2001 13:11:31 -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 262EA5DDA8 for ; Thu, 30 Aug 2001 13:11:31 -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 f7UHBUp19141; Thu, 30 Aug 2001 12:11:30 -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 f7UHBTg00163; Thu, 30 Aug 2001 12:11:30 -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 MAA00994; Thu, 30 Aug 2001 12:11:29 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA13744; Thu, 30 Aug 2001 12:11:24 -0500 (CDT) Message-ID: <3B8E71E4.5080700@ericsson.com> Date: Thu, 30 Aug 2001 10:03:32 -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: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Last Call: Issue 128: duplicate packet detection failure case References: <20010830072121.G6795@charizard.diameter.org> <20010830104011.S5934@newman.frascone.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 My comments are in line with David's and Fredrik's. I also believe that we don't need the dummy packets. The End-to-End Identifier seems enough to me. So I say reject it. That's my two cents. /Tony David Frascone wrote: >I think the current protocol can adequately detect failures. My vote is >to reject it. > >-Dave > >On Thu, Aug 30, 2001 at 07:21:21AM -0700, Pat Calhoun wrote: > >>All, >> >>The author of this issue claims that the Diameter protocol doesn't have a >>good enough packet failure detection scheme, and proposes some radical >>changes to the protocol. >> >>I would really encourage folks to read the thread and respond with their >>comments. In order for me to have the Diameter specs out asap, I need to >>close these last remaining issues. >> >>My take on this one is to reject it, but I could be wrong. >> >>comments (both positive and negative) >> >>PatC >> From owner-aaa-wg@merit.edu Thu Aug 30 13:58: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 NAA23490 for ; Thu, 30 Aug 2001 13:58:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18B3791217; Thu, 30 Aug 2001 13:59:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8B7891222; Thu, 30 Aug 2001 13:59:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE68A91217 for ; Thu, 30 Aug 2001 13:59:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B02025DDAE; Thu, 30 Aug 2001 13:59:04 -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 70DC95DDA8 for ; Thu, 30 Aug 2001 13:59:04 -0400 (EDT) Received: (qmail 8897 invoked by uid 500); 30 Aug 2001 17:46:33 -0000 Date: Thu, 30 Aug 2001 10:46:33 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 150: S/MIME precisions Message-ID: <20010830104633.B8794@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, Both Steven Farrell and I believe that it isn't necessary to get into a tutorial of CMS and S/MIME, and specifically how they interact. Given that an implementor will need to understand the intricacies of S/MIME and CMS to implement this application, we both feel that this isn't necessary. I would, of course, welcome your comments, PatC From owner-aaa-wg@merit.edu Thu Aug 30 14:00:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23549 for ; Thu, 30 Aug 2001 14:00:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E34591327; Thu, 30 Aug 2001 14:00:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4568591329; Thu, 30 Aug 2001 14:00: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 3DC1791327 for ; Thu, 30 Aug 2001 14:00:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 221E85DDA8; Thu, 30 Aug 2001 14:00: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 D39015DDCD for ; Thu, 30 Aug 2001 14:00:29 -0400 (EDT) Received: (qmail 8909 invoked by uid 500); 30 Aug 2001 17:47:58 -0000 Date: Thu, 30 Aug 2001 10:47:58 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 153: Key Length in CMS Security Application Message-ID: <20010830104758.C8794@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, Given that the RSA key length is encoded in the X.509 certificate, and no negotiation of key length is actually performed in CMS, we recommend rejecting this issue. PatC From owner-aaa-wg@merit.edu Thu Aug 30 16:13: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 QAA26988 for ; Thu, 30 Aug 2001 16:13:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E283491338; Thu, 30 Aug 2001 16:14:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABB6891339; Thu, 30 Aug 2001 16:14: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 AA32C91338 for ; Thu, 30 Aug 2001 16:14:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 801A75DDE3; Thu, 30 Aug 2001 16:14:49 -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 BD0F55DDDA for ; Thu, 30 Aug 2001 16:14:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA35607; Thu, 30 Aug 2001 13:06:39 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 30 Aug 2001 13:06:38 -0700 (PDT) From: Bernard Aboba To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Last Call: Issue 128: duplicate packet detection failure case In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I agree. The e-2-e identifier is sufficient. Let's not make this more complicated than it needs to be. On Thu, 30 Aug 2001, Fredrik Johansson wrote: > 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. > > I'd say, keep it as it is. > > /Fredrik > From owner-aaa-wg@merit.edu Thu Aug 30 17:37: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 RAA28574 for ; Thu, 30 Aug 2001 17:37:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 560CE91229; Thu, 30 Aug 2001 17:38:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25FA891339; Thu, 30 Aug 2001 17:38: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 4BF4A91229 for ; Thu, 30 Aug 2001 17:38:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22A7A5DDD9; Thu, 30 Aug 2001 17:38:32 -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 7E9015DDC8 for ; Thu, 30 Aug 2001 17:38:31 -0400 (EDT) Received: from gwzpc (sjc-vpn1-120.cisco.com [10.21.96.120]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA14100; Thu, 30 Aug 2001 14:37:28 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Bernard's implied issues Date: Thu, 30 Aug 2001 14:37:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > WEP reference is correct. Will try to find reference for WEP-128 (there is > no IEEE standard for this). AFAIK, aqll existing 128-bit WEP implementations are proprietary, so maybe we don't want to enshrine it in a standard... > RFC 3162 will issue soon. > > On Mon, 27 Aug 2001, Pat Calhoun wrote: > > > Bernard, > > > > You implied new issues in the following statement: > > > > "I also believe that the following issues need to be re-opened: > > > > nasreq-07: Issue #29 (need to substitute RFC 3162 attribute #s for > > TBD) > > Issue #36 (need to remove AES/OCB from list, change "WEP2" > > to WEP-128"). " > > > > I will create two new issues (easier to track than re-opening > the old ones). > > As far as the second issue, is the following the correct > reference for WEP? > > > > [22] Information technology - Telecommunications and information > > exchange between systems - Local and metropolitan area networks - > > Specific Requirements Part 11: Wireless LAN Medium Access Control > > (MAC) and Physical Layer (PHY) Specifications, IEEE Std. > > 802.11-1999, 1999. > > > > Thanks, > > > > PatC > > > > From owner-aaa-wg@merit.edu Thu Aug 30 18:13: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 SAA29090 for ; Thu, 30 Aug 2001 18:13:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAE979133C; Thu, 30 Aug 2001 18:14:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B425B9133D; Thu, 30 Aug 2001 18: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 A87999133C for ; Thu, 30 Aug 2001 18:14:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A58B5DDC8; Thu, 30 Aug 2001 18:14:33 -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 C88985DD95 for ; Thu, 30 Aug 2001 18:14:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id PAA35750; Thu, 30 Aug 2001 15:06:25 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 30 Aug 2001 15:06:25 -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 > AFAIK, all existing 128-bit WEP implementations are proprietary, so maybe > we don't want to enshrine it in a standard... > The idea of this was to enable sending of keys from AAA server to NAS, as a way to provide standard versions of the key attributes defined in RFC 2548, which defines separate Send-Key and Receive-Key attributes, which include a Salt and String, and can be of arbritrary length. Note that EAP methods derive a single master-key and so must provide a specification for how auth and encryption keys are derived from that master key in each direction. The keys send via AAA must match that derivation. Since the NAS is assumed EAP agnostic, rather than just sending the master key (and requiring the NAS to implement the logic to derive the other keys from that), the actual derived keys are sent. The Diameter Nasreq NAS-Session-Key Grouped AVP does contain NAS-Key, NAS-Key-Type, and NAS-Key-Direction AVPs. So far, so good. However, it also includes a NAS-Key-Binding AVP, which is what this discussion is about. The question is why NAS-Key-Binding AVP is needed at all. If we assume that the EAP method derives the same key regardless of ciphersuite, and that the ciphersuite defines the method in which the EAP key is translated to auth/encryption keys in each direction, then the ciphersuite is needed by the AAA server to send the right key set. However, if the EAP method determines the derivation (as RFC 2716 does), then the ciphersuite does not need to be known by the AAA server, and the NAS needs to build in the logic to derive ciphersuite-adjusted keys from those sent in the NAS-Session-Key Grouped AVP. In designing this Grouped AVP, we assumed that the ciphersuite might need to be known to do the right thing. That implies that the length and format of the NAS-Key AVP might differ depending on the ciphersuite, and also that the NAS-Key-Binding AVP is present in Requests, not just Responses (to serve as a guide). If the above is true, then I think we need to specify those ciphersuites that are in use, regardless of whether they are standard. Otherwise, those ciphersuites couldn't be made to work with Diameter. From owner-aaa-wg@merit.edu Thu Aug 30 18:23: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 SAA29262 for ; Thu, 30 Aug 2001 18:23:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9AD6E91247; Thu, 30 Aug 2001 18:24:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EB2A9133D; Thu, 30 Aug 2001 18:24:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A74691247 for ; Thu, 30 Aug 2001 18:24:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 312845DDC8; Thu, 30 Aug 2001 18:24: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 A1F0F5DDA8 for ; Thu, 30 Aug 2001 18:24:39 -0400 (EDT) Received: (qmail 13257 invoked by uid 500); 30 Aug 2001 22:12:08 -0000 Date: Thu, 30 Aug 2001 15:12:08 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Glen Zorn , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues Message-ID: <20010830151208.B13016@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Glen Zorn , Pat Calhoun , 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 aboba@internaut.com on Thu, Aug 30, 2001 at 03:06:25PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > If the above is true, then I think we need to specify those ciphersuites > that are in use, regardless of whether they are standard. Otherwise, those > ciphersuites couldn't be made to work with Diameter. ok, but I still need something to reference, or just leave WEP-128 with no reference. PatC From owner-aaa-wg@merit.edu Thu Aug 30 20:24: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 UAA01015 for ; Thu, 30 Aug 2001 20:24:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C86A891333; Thu, 30 Aug 2001 20:25:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95A5E9134A; Thu, 30 Aug 2001 20:25: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 9E53F91333 for ; Thu, 30 Aug 2001 20:25:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 732355DDD9; Thu, 30 Aug 2001 20:25:30 -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 449045DDCB for ; Thu, 30 Aug 2001 20:25:30 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7V0PT519381 for ; Thu, 30 Aug 2001 19:25:29 -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 f7V0PTX07267 for ; Thu, 30 Aug 2001 19:25:29 -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 TAA18072 for ; Thu, 30 Aug 2001 19:25:28 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA18943 for ; Thu, 30 Aug 2001 19:25:24 -0500 (CDT) Message-ID: <3B8ED79B.1070204@ericsson.com> Date: Thu, 30 Aug 2001 17:17:31 -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]: Diameter Bake-off test suite v1.0 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, A first version of the Diameter bake-off test specification is now available on http://standards.ericsson.net/diameter-bake-off/diameter_testspec.html Please, in order to improve the test suite, you are encouraged to contribute additional test cases or suggest improvements of existing test case. Regards, /Tony From owner-aaa-wg@merit.edu Thu Aug 30 22:22: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 WAA03236 for ; Thu, 30 Aug 2001 22:22:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 74ED891203; Thu, 30 Aug 2001 22:23:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B03791216; Thu, 30 Aug 2001 22:23: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 3491591203 for ; Thu, 30 Aug 2001 22:23:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08A6E5DDC7; Thu, 30 Aug 2001 22:23:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BD3C35DD94 for ; Thu, 30 Aug 2001 22:23:43 -0400 (EDT) Received: (qmail 15125 invoked by uid 500); 31 Aug 2001 02:11:12 -0000 Date: Thu, 30 Aug 2001 19:11:12 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 154: End-to-End Id in answer messages Message-ID: <20010830191112.A15109@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I've gone over the proposed changes, and I agree with the proposed text. I've made the changes to the draft, and closed the issue. Thanks, PatC From owner-aaa-wg@merit.edu Thu Aug 30 23:26: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 XAA04788 for ; Thu, 30 Aug 2001 23:26:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE48F9121C; Thu, 30 Aug 2001 23:27:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C2F69124E; Thu, 30 Aug 2001 23:27: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 8BCD09121C for ; Thu, 30 Aug 2001 23:27:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48E9A5DDD9; Thu, 30 Aug 2001 23:27:54 -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 BA5BB5DDC7 for ; Thu, 30 Aug 2001 23:27:53 -0400 (EDT) Received: (qmail 15886 invoked by uid 500); 31 Aug 2001 03:15:21 -0000 Date: Thu, 30 Aug 2001 20:15:21 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 149: Revalidation of certificates in cache Message-ID: <20010830201521.B15109@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 Miguel, I've read through this issue, and accept the text, with the following change: MIGHT -> SHOULD The term MIGHT is not defined in RFC 2119. I believe that the intent was a SHOULD NOT REQUIRED -> not required Again, NOT REQUIRED is not defined in RFC 2119, and I couldn't find an appropriate term from the RFC to use in this case. So I believe that just using not required in lower caps is fine. An alternative is to turn the sentence to be positive and state that implementations MAY do these checks. However, I think the language is fine. I will therefore close this issue. PatC From owner-aaa-wg@merit.edu Thu Aug 30 23:36: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 XAA05229 for ; Thu, 30 Aug 2001 23:36:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00BCA9124E; Thu, 30 Aug 2001 23:37:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C096191293; Thu, 30 Aug 2001 23:37:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A63E99124E for ; Thu, 30 Aug 2001 23:37:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 84E2F5DDC8; Thu, 30 Aug 2001 23:37:00 -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 648435DDC7 for ; Thu, 30 Aug 2001 23:36:59 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id UAA23234 for ; Thu, 30 Aug 2001 20:36:58 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id UAA17683 for ; Thu, 30 Aug 2001 20:28:44 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 30 Aug 2001 22:36:53 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" Cc: Fredrik Johansson , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Date: Thu, 30 Aug 2001 22:36:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Pat, please consider my suggestions below. State Machine - state maintained: ----------------------------------------------------- Add the following transitions: Pending Failed serv. specific Cleanup Idle auth-answer received Open Authorization-Lifetime send serv. Open expires on access specific device Auth-Request Open Home server wants to send ASR Discon terminate the service Replace, > Idle Service-Specific send serv. Open > authorization request specific > received, and answer > successfully processed with, Idle serv. specific auth- send Successful Open request received, and serv. specific user is authorized Auth-Answer Idle Service-Specific auth- send Failed Idle request received, and serv. specific user is not authorized Auth-Answer Replace, > Open Successful Service-Specific Extend Open > Authorization request or Access > answer received with, Open serv. specific auth- send Successful Open request received, and serv. specific user is authorized Auth-Answer Open serv. specific auth- send Failed Idle request received, and serv. specific user is not authorized Auth-Answer, Cleanup Open Successful serv. specific Extend Access Open auth-answer received State Machine - no state maintained: ------------------------------------------------------------ Add the following transition: Pending Failed serv. specific Cleanup Idle auth-answer received. Thanks, -Panos -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Wednesday, August 29, 2001 5:47 PM To: Thomas Panagiotis-PTHOMAS1 Cc: 'Pat Calhoun'; Fredrik Johansson; 'aaa-wg@merit.edu' Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine On Wed, Aug 29, 2001 at 10:36:47AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > Most of my comments are in alignment with Fredrik's last > message. > Please take a look at the complete state table below (I just realized that I only sent a portion of it in my response to Fredrik). These changes were the result of issues that have since been closed. Any comments on this state table would be most appreciated: State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed answer Pending Successful Service-Specific Grant Open Authorization answer Access received with default Auth-Session-State value Pending Successful Service-Specific Sent STR Discon authorization answer received but service not provided Pending Error processing successful Sent STR Discon Service-Specific authorization answer Open user or client device send Open requests access to service service specific auth req Open Authorization-Lifetime + send STR Open Auth-Grace-Period expires on access device Open Successful Service-Specific Extend Open Authorization request or Access answer received Open Accounting message sent or process Open received Open Failed Service-Specific Discon. Idle Authorization answer user/device received. Open Session-Timeout Expires on send STR Discon Access Device Open ASR Received send ASA, Discon STR Open Authorization-Lifetime (and Cleanup Discon Auth-Grace-Period) expires on home server. Open Session-Timeout expires on Cleanup Discon home server Open STR Received Send STA Discon Discon ASA Received Cleanup Idle Discon ASR Received None Discon Discon STR Received Send STA Idle Discon STA Received Discon. Idle user/device The following state machine is used when state is not maintained on the server: State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed answer Pending Successful Service-Specific Grant Open Authorization answer Access received with Auth-Session- State set to NO_STATE_MAINTAINED Open Accounting message sent or process Open received Open Session-Timeout Expires on Discon. Idle Access Device user/device Open Service to user is terminated Discon. Idle user/device PatC From owner-aaa-wg@merit.edu Thu Aug 30 23:41: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 XAA05318 for ; Thu, 30 Aug 2001 23:41:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB83691293; Thu, 30 Aug 2001 23:42:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7912C91296; Thu, 30 Aug 2001 23:42: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 6F1F291293 for ; Thu, 30 Aug 2001 23:42:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A8B55DD8D; Thu, 30 Aug 2001 23:42: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 A0E945DDFA for ; Thu, 30 Aug 2001 23:42:41 -0400 (EDT) Received: (qmail 15960 invoked by uid 500); 31 Aug 2001 03:30:09 -0000 Date: Thu, 30 Aug 2001 20:30:09 -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 136: Proxy's DSAR on behalf of a client Message-ID: <20010830203009.C15109@charizard.diameter.org> Mail-Followup-To: =?iso-8859-1?Q?Miguel_=C1ngel_Monjas_Llorente?= , Pat Calhoun , aaa-wg@merit.edu References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8CBF64.7AFB39B8@rioja.ericsson.se> <20010829050317.F32443@charizard.diameter.org> <3B8CE3F3.81F77D3A@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: <3B8CE3F3.81F77D3A@rioja.ericsson.se>; from ecemaml@rioja.es.eu.ericsson.se on Wed, Aug 29, 2001 at 02:45:39PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Wed, Aug 29, 2001 at 02:45:39PM +0200, Miguel Ángel Monjas Llorente wrote: > Of course it's sufficient. I've got an only purpose when proposing > this new text: to make the draft cleared (what doesn't imply that now > it's clear enough). IMHO some kind of information about the > "scenarios" in which CMS Security is used will be useful for CMS Sec > implementators. Just that. If you consider that doesn't add any > additional info or that this information isn't suitable in a > specification, no problem. I respect your opinion :-))) Since this is purely for clarification purposes, I will accept this issue. I've added the following text to 4.3 to further explain when this message is used. I was going to add it to 1.2, but it would require some major surgery to the text, and I don't feel comfortable doing that at this time (of course, if you can think of a great way to add this text in the existing framework, and it would read well, then I'd welcome some input). Here's the proposed text: The PDSR is used for the following reasons: - 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 is 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. Comments appreciated. PatC From owner-aaa-wg@merit.edu Thu Aug 30 23:42: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 XAA05335 for ; Thu, 30 Aug 2001 23:42:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA54291296; Thu, 30 Aug 2001 23:43:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BFBD912CD; Thu, 30 Aug 2001 23:43: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 71C0691296 for ; Thu, 30 Aug 2001 23:43:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5546E5DDC7; Thu, 30 Aug 2001 23:43:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 8E7905DD8D for ; Thu, 30 Aug 2001 23:43:52 -0400 (EDT) Received: (qmail 15976 invoked by uid 500); 31 Aug 2001 03:31:20 -0000 Date: Thu, 30 Aug 2001 20:31:20 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , Fredrik Johansson , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010830203120.D15109@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , Fredrik Johansson , "'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, Aug 30, 2001 at 10:36:52PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Those are reasonable changes. I will make the necessary changes. PatC On Thu, Aug 30, 2001 at 10:36:52PM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > Pat, please consider my suggestions below. > > State Machine - state maintained: > ----------------------------------------------------- > Add the following transitions: > > Pending Failed serv. specific Cleanup Idle > auth-answer received > > Open Authorization-Lifetime send serv. Open > expires on access specific > device Auth-Request > > Open Home server wants to send ASR Discon > terminate the service > > Replace, > > > Idle Service-Specific send serv. Open > > authorization request specific > > received, and answer > > successfully processed > > with, > > Idle serv. specific auth- send Successful Open > request received, and serv. specific > user is authorized Auth-Answer > > Idle Service-Specific auth- send Failed Idle > request received, and serv. specific > user is not authorized Auth-Answer > > Replace, > > > Open Successful Service-Specific Extend Open > > Authorization request or Access > > answer received > > with, > > Open serv. specific auth- send Successful Open > request received, and serv. specific > user is authorized Auth-Answer > > Open serv. specific auth- send Failed Idle > request received, and serv. specific > user is not authorized Auth-Answer, > Cleanup > > Open Successful serv. specific Extend Access Open > auth-answer received > > > State Machine - no state maintained: > ------------------------------------------------------------ > > Add the following transition: > > Pending Failed serv. specific Cleanup Idle > auth-answer received. > > > Thanks, > > -Panos > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, August 29, 2001 5:47 PM > To: Thomas Panagiotis-PTHOMAS1 > Cc: 'Pat Calhoun'; Fredrik Johansson; 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine > > > On Wed, Aug 29, 2001 at 10:36:47AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > > Most of my comments are in alignment with Fredrik's last > > message. > > > > Please take a look at the complete state table below (I just realized that > I only sent a portion of it in my response to Fredrik). These changes were > the result of issues that have since been closed. Any comments on this > state table would be most appreciated: > > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed answer > > Pending Successful Service-Specific Grant Open > Authorization answer Access > received with default > Auth-Session-State value > > Pending Successful Service-Specific Sent STR Discon > authorization answer received > but service not provided > > Pending Error processing successful Sent STR Discon > Service-Specific authorization > answer > > Open user or client device send Open > requests access to service service > specific > auth req > > Open Authorization-Lifetime + send STR Open > Auth-Grace-Period expires on > access device > > Open Successful Service-Specific Extend Open > Authorization request or Access > answer received > > Open Accounting message sent or process Open > received > > Open Failed Service-Specific Discon. Idle > Authorization answer user/device > received. > > Open Session-Timeout Expires on send STR Discon > Access Device > > Open ASR Received send ASA, Discon > STR > > Open Authorization-Lifetime (and Cleanup Discon > Auth-Grace-Period) expires > on home server. > > Open Session-Timeout expires on Cleanup Discon > home server > > Open STR Received Send STA Discon > > Discon ASA Received Cleanup Idle > > Discon ASR Received None Discon > > Discon STR Received Send STA Idle > > Discon STA Received Discon. Idle > user/device > > The following state machine is used when state is not maintained > on the server: > > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed answer > > Pending Successful Service-Specific Grant Open > Authorization answer Access > received with Auth-Session- > State set to > NO_STATE_MAINTAINED > > Open Accounting message sent or process Open > received > > Open Session-Timeout Expires on Discon. Idle > Access Device user/device > > Open Service to user is terminated Discon. Idle > user/device > > PatC From owner-aaa-wg@merit.edu Thu Aug 30 23:47: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 XAA05440 for ; Thu, 30 Aug 2001 23:47:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58E42912CD; Thu, 30 Aug 2001 23:48:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A23D912F8; Thu, 30 Aug 2001 23: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 0638F912CD for ; Thu, 30 Aug 2001 23:48:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEB665DD9F; Thu, 30 Aug 2001 23:48: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 748B05DDC7 for ; Thu, 30 Aug 2001 23:48:26 -0400 (EDT) Received: (qmail 16007 invoked by uid 500); 31 Aug 2001 03:35:54 -0000 Date: Thu, 30 Aug 2001 20:35:54 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , Fredrik Johansson , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue: 8.1 Authorization Session State Machine Message-ID: <20010830203554.E15109@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , Fredrik Johansson , "'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, Aug 30, 2001 at 10:36:52PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Wait - ignore my acceptance of this issue. see comments below. > Pending Failed serv. specific Cleanup Idle > auth-answer received ok > > Open Authorization-Lifetime send serv. Open > expires on access specific > device Auth-Request I had this, and this issue was a request to change the above to: Open user or client device send Open requests access to service service specific auth req and Open Authorization-Lifetime + send STR Discon Auth-Grace-Period expires on access device The reasoning is that the user must request access to the network, which initiates the auth request. Then, if the user doesn't request access, and the auth-lifetime expires, the STR is sent to the server. Your request to make the above change contradicts the above text, and I feel more comfortable with the existing text. The rest I feel comfortable with. PatC From owner-aaa-wg@merit.edu Fri Aug 31 00:08:30 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05609 for ; Fri, 31 Aug 2001 00:08:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 74638912F8; Fri, 31 Aug 2001 00:09:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3796A912F9; Fri, 31 Aug 2001 00:09: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 27BE1912F8 for ; Fri, 31 Aug 2001 00:09:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 001235DD9F; Fri, 31 Aug 2001 00:09: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 A0DD65DD8D for ; Fri, 31 Aug 2001 00:09:09 -0400 (EDT) Received: (qmail 16097 invoked by uid 500); 31 Aug 2001 03:56:37 -0000 Date: Thu, 30 Aug 2001 20:56:37 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: The Remaining Issues Message-ID: <20010830205637.G15109@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 believe that we are nearly done! Here's an update on the remaining issues: Issue 94: I am not the editor of this spec, so once I hear from Bernard on whether he's accepted or rejected the issue I will formally close this one. Issue 123: My current inclination is to reject this issue, but I am waiting for WG input before proceeding Issue 147: This issue has been accepted, but I am waiting for a reference to WEP-128. If I cannot get this before I wish to submit, my goal is to take care of this during the 48 hour last call I will get from the RFC editor. However, I will keep this issue open as a reminder. 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. Issue 153: Steven and I both agree that the RSA key length is encoded in the certificate, and therefore doesn't need to be mentioned in this spec. Diameter CMS implementations should be able to handle existing cert formats, which have a set of acceptable RSA key lengths. I am waiting for the author of this issue to get back to me on whether or not he agrees. So, in order for me to go ahead with submitting the I-Ds to the secretariat, I need some guidance from the WG on issues 147 and 150. As I previously stated, my inclination is to reject them, but I am not in a position to reject them without input from the WG. So please help me get this documents out, and send e-mail. Thanks, PatC From owner-aaa-wg@merit.edu Fri Aug 31 00:38: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 AAA08165 for ; Fri, 31 Aug 2001 00:38:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA499912F9; Fri, 31 Aug 2001 00:39:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83A4C912FA; Fri, 31 Aug 2001 00: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 73C4B912F9 for ; Fri, 31 Aug 2001 00:39:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 408DA5DDC7; Fri, 31 Aug 2001 00:39:13 -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 660555DD9F for ; Fri, 31 Aug 2001 00:39:12 -0400 (EDT) Received: from jariws1 ([62.248.154.197]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010831043911.QOHU15145.fep07-app.kolumbus.fi@jariws1>; Fri, 31 Aug 2001 07:39:11 +0300 Message-ID: <00c501c131d6$f1223dc0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Bernard Aboba" , "Glen Zorn" Cc: "Pat Calhoun" , References: Subject: Re: [AAA-WG]: Bernard's implied issues Date: Fri, 31 Aug 2001 07:38:17 +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 > If the above is true, then I think we need to specify those ciphersuites > that are in use, regardless of whether they are standard. Otherwise, those > ciphersuites couldn't be made to work with Diameter. It's also possible for the vendors to get a new IANA number allocation, when they need it for their ciphersuite. Will that help? Will they need their own informational RFC, or just the IANA allocation? Jari From owner-aaa-wg@merit.edu Fri Aug 31 03:23: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 DAA26243 for ; Fri, 31 Aug 2001 03:23:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D0E791229; Fri, 31 Aug 2001 03:24:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BDF59122A; Fri, 31 Aug 2001 03:24:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2C5791229 for ; Fri, 31 Aug 2001 03:24:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88C0B5DD9D; Fri, 31 Aug 2001 03:24:53 -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 C00445DD92 for ; Fri, 31 Aug 2001 03:24:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA36272; Fri, 31 Aug 2001 00:16:36 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 31 Aug 2001 00:16:35 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Glen Zorn , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues In-Reply-To: <00c501c131d6$f1223dc0$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > It's also possible for the vendors to get a new IANA number allocation, > when they need it for their ciphersuite. Will that help? Will they need > their own informational RFC, or just the IANA allocation? > IANA allocation should be fine. From owner-aaa-wg@merit.edu Fri Aug 31 03:31: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 DAA26329 for ; Fri, 31 Aug 2001 03:31:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28C4B9122A; Fri, 31 Aug 2001 03:32:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D89929122B; Fri, 31 Aug 2001 03:32: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 130139122A for ; Fri, 31 Aug 2001 03:32:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8E175DD9D; Fri, 31 Aug 2001 03:32: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 CF3165DD92 for ; Fri, 31 Aug 2001 03:32: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 f7V7WNv02984 for ; Fri, 31 Aug 2001 09:32:23 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA00306; Fri, 31 Aug 2001 09:32:21 +0200 (MET DST) Message-ID: <3B8F3DC2.B94F6A49@rioja.ericsson.se> Date: Fri, 31 Aug 2001 09:33:22 +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> 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, > > Both Steven Farrell and I believe that it isn't necessary to get into a > tutorial of CMS and S/MIME, and specifically how they interact. Given > that an implementor will need to understand the intricacies of S/MIME > and CMS to implement this application, we both feel that this isn't > necessary. Hi Pat, 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. 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. 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). BTW, where are the MIME encoding rules specified "below"? - The second quote is very low-level, in the sense that even the MIME type is mentioned (I've got no problem with that). Not being a S/MIME expert, I'd help a such specific indication about the way of including several EnvelopedData in one CMS-Encrypted-Data (even off-line). I've been browsing S/MIME spec and ESS draft and I haven't found any indication of such procedure (maybe a deeper reading would help, but I'd be grateful with some clue). Regards // M.A. From owner-aaa-wg@merit.edu Fri Aug 31 03: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 DAA26360 for ; Fri, 31 Aug 2001 03:36:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D1499122B; Fri, 31 Aug 2001 03:37:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4F939122F; Fri, 31 Aug 2001 03:37:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C25A89122B for ; Fri, 31 Aug 2001 03:37:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A023E5DD9D; Fri, 31 Aug 2001 03:37:51 -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 C415B5DD92 for ; Fri, 31 Aug 2001 03:37:50 -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 f7V7bmK22363 for ; Fri, 31 Aug 2001 09:37:49 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA00707; Fri, 31 Aug 2001 09:37:45 +0200 (MET DST) Message-ID: <3B8F3F06.C0727DD6@rioja.ericsson.se> Date: Fri, 31 Aug 2001 09:38: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: Re: [AAA-WG]: Issue 149: Revalidation of certificates in cache References: <20010830201521.B15109@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: > > Miguel, > > I've read through this issue, and accept the text, with the following > change: Changes are fine (I wrote so fast that I didn't check the terminology to make it compliant with RFC 2119). > MIGHT -> SHOULD > The term MIGHT is not defined in RFC 2119. I believe that the intent > was a SHOULD My intention was actually closer to a MAY than to a SHOULD. But I just wanted clarification, so that it's OK. > NOT REQUIRED -> not required > Again, NOT REQUIRED is not defined in RFC 2119, and I couldn't find > an appropriate term from the RFC to use in this case. So I believe > that just using not required in lower caps is fine. > > An alternative is to turn the sentence to be positive and state > that implementations MAY do these checks. However, I think the > language is fine. I prefer the second option (positive sentence) Regards // M.A. From owner-aaa-wg@merit.edu Fri Aug 31 03:51: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 DAA26476 for ; Fri, 31 Aug 2001 03:51:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E228C9122F; Fri, 31 Aug 2001 03:52:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A702D91247; Fri, 31 Aug 2001 03:52: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 54A169122F for ; Fri, 31 Aug 2001 03:52:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 284AA5DDD9; Fri, 31 Aug 2001 03:52:34 -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 535F85DD9D for ; Fri, 31 Aug 2001 03:52:33 -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 f7V7qVK03349 for ; Fri, 31 Aug 2001 09:52:32 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA02117; Fri, 31 Aug 2001 09:52:29 +0200 (MET DST) Message-ID: <3B8F427A.649E9F54@rioja.ericsson.se> Date: Fri, 31 Aug 2001 09:53: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: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 136: Proxy's DSAR on behalf of a client References: <20010827090152.Q23877@charizard.diameter.org> <3B8B9F3B.58A0B79@rioja.ericsson.se> <20010828063528.A27840@charizard.diameter.org> <3B8CBF64.7AFB39B8@rioja.ericsson.se> <20010829050317.F32443@charizard.diameter.org> <3B8CE3F3.81F77D3A@rioja.ericsson.se> <20010830203009.C15109@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: > > Since this is purely for clarification purposes, I will accept this issue. Yes. After reading for first time the draft, I had the feeling that a previous DSA setup attempt was necessary to issue a PDSR. Just for the second I noticed that there was other possibilities.... > I've added the following text to 4.3 to further explain when > this message is used. I was going to add it to 1.2, but it would require > some major surgery to the text, and I don't feel comfortable doing that > at this time (of course, if you can think of a great way to add this > text in the existing framework, and it would read well, then I'd welcome > some input). If you don't feel comfortable with this surgery task, you will be able how I feel :-)) > Here's the proposed text: > > The PDSR is used for the following reasons: > - 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 is the values only this........................................................^^ > 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. > > Comments appreciated. It's OK for me. Regards // M.A. From owner-aaa-wg@merit.edu Fri Aug 31 04:24: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 EAA26683 for ; Fri, 31 Aug 2001 04:24:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B105E9124A; Fri, 31 Aug 2001 04:25:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78AC29124B; Fri, 31 Aug 2001 04: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 626289124A for ; Fri, 31 Aug 2001 04:25:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EC895DD9D; Fri, 31 Aug 2001 04:25:26 -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 0690D5DD92 for ; Fri, 31 Aug 2001 04:25:21 -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 f7V8Pg320251 for ; Fri, 31 Aug 2001 11:25:42 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Aug 2001 11:25:15 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWA5KV>; Fri, 31 Aug 2001 11:25:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF2FBA08@esebe004.NOE.Nokia.com> From: john.loughney@nokia.com To: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: Small editorial comment on section 5.5.4 Date: Fri, 31 Aug 2001 11:25:03 +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, A minor editorial nit, in section 5.5.4, 3rd paragraph, 2nd sentence: When a transport failure is detected, all messages in the queue are sent to an alternate agent, if possible. An example of a case where it is not possible for forward the message to an alternate server is when the message has a fixed destination, and the unavailable peer is the message's final destination (see Destination-Host AVP). The sentence isn't so clear - do you mean this (changed text in CAPS): An example of a case where it is not possible TO forward the message to an alternate server is when the message has a fixed destination, - or it could be stated as: An example of a case where it is not possible for FORWARDING the message to an alternate server is when the message has a fixed destination, John From owner-aaa-wg@merit.edu Fri Aug 31 09:46: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 JAA05370 for ; Fri, 31 Aug 2001 09:46:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07CAD91252; Fri, 31 Aug 2001 09:47:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDE9E91253; Fri, 31 Aug 2001 09:47: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 A478291252 for ; Fri, 31 Aug 2001 09:47:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D96F5DDA1; Fri, 31 Aug 2001 09:47:04 -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 726E85DD9D for ; Fri, 31 Aug 2001 09:47:03 -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 f7VDksv27980 for ; Fri, 31 Aug 2001 15:46:55 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA05697; Fri, 31 Aug 2001 15:46:50 +0200 (MET DST) Message-ID: <3B8F958A.2EAA7C1E@rioja.ericsson.se> Date: Fri, 31 Aug 2001 15:47: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: Re: [AAA-WG]: Issue 153: Key Length in CMS Security Application References: <20010830104758.C8794@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, > > Given that the RSA key length is encoded in the X.509 > certificate, and no negotiation of key length is actually > performed in CMS, we recommend rejecting this issue. OK. No comments from me. Regards // M.A. From owner-aaa-wg@merit.edu Fri Aug 31 10:03:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05982 for ; Fri, 31 Aug 2001 10:03:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2515891233; Fri, 31 Aug 2001 10:04:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E71E991255; Fri, 31 Aug 2001 10:04: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 CEA4D91233 for ; Fri, 31 Aug 2001 10:04:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B63D75DDA4; Fri, 31 Aug 2001 10:04:04 -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 637E65DDA1 for ; Fri, 31 Aug 2001 10:03:59 -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 f7VE3vv12251 for ; Fri, 31 Aug 2001 16:03:58 +0200 (MEST) Received: from rioja.ericsson.se by rioja.ericsson.se (8.8.8+Sun/SMI-SVR4) id QAA06776; Fri, 31 Aug 2001 16:03:54 +0200 (MET DST) Message-ID: <3B8F998A.9E85D1E4@rioja.ericsson.se> Date: Fri, 31 Aug 2001 16:04:58 +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]: Last question: DSA setup failure? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just an only question (I don't dare to raise an issue so that I'm not sure). What happens if any of the checks listed in page 11 fails? Which Result-Code must be included? I've found the following error codes: In the Base Protocol draft (7.1.3): DIAMETER_INVALID_CMS_DATA 3006 The Request did not contain a valid CMS-Data [11] AVP. In the CMS Security draft (7.2) DIAMETER_INVALID_CMS_DATA 5019 This error code is returned when a CMS-Data AVP is received with an invalid ContentInfo object. Several questions: - Why aren't they the same? The definition is slightly different (and also the type of error). I understand that the first definition must be dropped from the Base Protocol - Which is the right definition? The first is wider than the second, so that the problem of not failing the verification can be put into it. Not in the second occasion which only alludes to the syntax of the AVP. Comments? Regards // M.A. From owner-aaa-wg@merit.edu Fri Aug 31 11:21: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 LAA07687 for ; Fri, 31 Aug 2001 11:21:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A272791276; Fri, 31 Aug 2001 11:22:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7030091277; Fri, 31 Aug 2001 11:22: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 5BF1591276 for ; Fri, 31 Aug 2001 11:22:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B6955DDDE; Fri, 31 Aug 2001 11:22:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BF8BE5DDA1 for ; Fri, 31 Aug 2001 11:22:31 -0400 (EDT) Received: (qmail 21626 invoked by uid 500); 31 Aug 2001 15:09:54 -0000 Date: Fri, 31 Aug 2001 08:09:54 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Jari Arkko , Glen Zorn , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues Message-ID: <20010831080954.B21508@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Jari Arkko , Glen Zorn , Pat Calhoun , aaa-wg@merit.edu References: <00c501c131d6$f1223dc0$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 Fri, Aug 31, 2001 at 12:16:35AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Aug 31, 2001 at 12:16:35AM -0700, Bernard Aboba wrote: > > It's also possible for the vendors to get a new IANA number allocation, > > when they need it for their ciphersuite. Will that help? Will they need > > their own informational RFC, or just the IANA allocation? > > > > IANA allocation should be fine. So are you stating that I should remove WEP-128 from the spec? PatC From owner-aaa-wg@merit.edu Fri Aug 31 12:03: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 MAA08767 for ; Fri, 31 Aug 2001 12:03:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE7A49122A; Fri, 31 Aug 2001 12:04:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B07039122B; Fri, 31 Aug 2001 12: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 AE52D9122A for ; Fri, 31 Aug 2001 12:04:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 92A445DDA4; Fri, 31 Aug 2001 12:04: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 D5FFE5DE14 for ; Fri, 31 Aug 2001 12:04:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA36915; Fri, 31 Aug 2001 08:56:20 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 31 Aug 2001 08:56:20 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: Jari Arkko , Glen Zorn , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues In-Reply-To: <20010831080954.B21508@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Should I remove WEP-128 from the spec? Ys, you can go ahead and do that. From owner-aaa-wg@merit.edu Fri Aug 31 13:19:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11046 for ; Fri, 31 Aug 2001 13:19:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 36A619122F; Fri, 31 Aug 2001 13:20:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 089F091233; Fri, 31 Aug 2001 13:20: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 046D39122F for ; Fri, 31 Aug 2001 13:20:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D967C5DDDE; Fri, 31 Aug 2001 13:20: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 52D675DDA4 for ; Fri, 31 Aug 2001 13:20:30 -0400 (EDT) Received: (qmail 22174 invoked by uid 500); 31 Aug 2001 17:07:56 -0000 Date: Fri, 31 Aug 2001 10:07:56 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Update: The Remaining Issues Message-ID: <20010831100756.C22080@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010830205637.G15109@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: <20010830205637.G15109@charizard.diameter.org>; from pcalhoun@diameter.org on Thu, Aug 30, 2001 at 08:56:37PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Here's an update on the remaining issues: > > Issue 94: I am not the editor of this spec, so once I hear from Bernard > on whether he's accepted or rejected the issue I will formally > close this one. > > Issue 123: My current inclination is to reject this issue, but I am waiting > for WG input before proceeding > > 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. > > So, in order for me to go ahead with submitting the I-Ds to the secretariat, > I need some guidance from the WG on issue 150. As I previously > stated, my inclination is to reject it, but I am not in a position to > reject them without input from the WG. > > So please help me get this documents out, and send e-mail. > > Thanks, > > PatC From owner-aaa-wg@merit.edu Fri Aug 31 14:26: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 OAA12897 for ; Fri, 31 Aug 2001 14:26:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C2D491233; Fri, 31 Aug 2001 14:27:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 060599124A; Fri, 31 Aug 2001 14:27: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 05EC191233 for ; Fri, 31 Aug 2001 14:27:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DBE195DE17; Fri, 31 Aug 2001 14:27:49 -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 082305DE13 for ; Fri, 31 Aug 2001 14:27:49 -0400 (EDT) Received: from jariws1 ([212.54.16.198]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010831182747.LQJV11276.fep01-app.kolumbus.fi@jariws1>; Fri, 31 Aug 2001 21:27:47 +0300 Message-ID: <008201c1324a$a365a1c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat Calhoun" , References: <20010830205637.G15109@charizard.diameter.org> <20010831100756.C22080@charizard.diameter.org> Subject: Re: [AAA-WG]: Update: The Remaining Issues Date: Fri, 31 Aug 2001 21:27:49 +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 > 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? ;-) 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)." Jari From owner-aaa-wg@merit.edu Fri Aug 31 17:44:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16684 for ; Fri, 31 Aug 2001 17:44:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3BA359124A; Fri, 31 Aug 2001 17:45:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B66DD9124E; Fri, 31 Aug 2001 17:45: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 7997A9124A for ; Fri, 31 Aug 2001 17:44:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D80E5DDAE; Fri, 31 Aug 2001 17:44:59 -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 D5AEE5DDA1 for ; Fri, 31 Aug 2001 17:44:58 -0400 (EDT) Received: from gwzpc (sjc-vpn1-238.cisco.com [10.21.96.238]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA00864; Fri, 31 Aug 2001 14:43:08 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: "Pat Calhoun" , Subject: RE: [AAA-WG]: Bernard's implied issues Date: Fri, 31 Aug 2001 14:42:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > AFAIK, all existing 128-bit WEP implementations are > proprietary, so maybe > > we don't want to enshrine it in a standard... > > > > The idea of this was to enable sending of keys from AAA server to > NAS, as a way to provide standard versions of the key attributes defined > in RFC 2548, which defines separate Send-Key and Receive-Key attributes, > which include a Salt and String, and can be of arbritrary length. > > Note that EAP methods derive a single master-key and so must provide a > specification for how auth and encryption keys are derived from that > master key in each direction. The keys send via AAA must match that > derivation. Since the NAS is assumed EAP agnostic, rather than just > sending the master key (and requiring the NAS to implement the logic to > derive the other keys from that), the actual derived keys are sent. > > The Diameter Nasreq NAS-Session-Key Grouped AVP does contain > NAS-Key, NAS-Key-Type, and NAS-Key-Direction AVPs. So far, so good. > However, it also includes a NAS-Key-Binding AVP, which is what this > discussion is about. > > The question is why NAS-Key-Binding AVP is needed at all. If we assume > that the EAP method derives the same key regardless of ciphersuite, and > that the ciphersuite defines the method in which the EAP key is translated > to auth/encryption keys in each direction, then the ciphersuite is needed > by the AAA server to send the right key set. However, if the EAP method > determines the derivation (as RFC 2716 does), then the ciphersuite does > not need to be known by the AAA server, and the NAS needs to build in the > logic to derive ciphersuite-adjusted keys from those sent in the > NAS-Session-Key Grouped AVP. > > In designing this Grouped AVP, we assumed that the ciphersuite might need > to be known to do the right thing. That implies that the length and format > of the NAS-Key AVP might differ depending on the ciphersuite, and also > that the NAS-Key-Binding AVP is present in Requests, not just Responses > (to serve as a guide). > > If the above is true, then I think we need to specify those ciphersuites > that are in use, regardless of whether they are standard. Otherwise, those > ciphersuites couldn't be made to work with Diameter. No argument there; I would dispute that WEP constitutes a ciphersuite however. Perhaps just RC4-128? > > From owner-aaa-wg@merit.edu Fri Aug 31 19:55:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17887 for ; Fri, 31 Aug 2001 19:55:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC3B991205; Fri, 31 Aug 2001 19:57:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B82279124E; Fri, 31 Aug 2001 19:57: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 A7CB191205 for ; Fri, 31 Aug 2001 19:57:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C5615DDD5; Fri, 31 Aug 2001 19:57:03 -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 C0AB45DDBA for ; Fri, 31 Aug 2001 19:57:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA37411; Fri, 31 Aug 2001 16:48:49 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 31 Aug 2001 16:48:49 -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 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 Fri Aug 31 20:22: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 UAA18128 for ; Fri, 31 Aug 2001 20:22:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5912291224; Fri, 31 Aug 2001 20:23:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2507C9124F; Fri, 31 Aug 2001 20:23: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 18A7591224 for ; Fri, 31 Aug 2001 20:23:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC6ED5DDBA; Fri, 31 Aug 2001 20:23:35 -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 5E95F5DDAE for ; Fri, 31 Aug 2001 20:23:35 -0400 (EDT) Received: from gwzpc (sjc-vpn1-238.cisco.com [10.21.96.238]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA00813; Fri, 31 Aug 2001 17:22:22 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: "Pat Calhoun" , Subject: RE: [AAA-WG]: Bernard's implied issues Date: Fri, 31 Aug 2001 17:19:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > >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. 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 ;-)? > > From owner-aaa-wg@merit.edu Fri Aug 31 23:25: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 XAA22839 for ; Fri, 31 Aug 2001 23:25:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E5A19127A; Fri, 31 Aug 2001 23:24:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 316F991276; Fri, 31 Aug 2001 23: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 45D0F91255 for ; Fri, 31 Aug 2001 23:24:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 292555DE1C; Fri, 31 Aug 2001 23:24:03 -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 A0D9B5DDAE for ; Fri, 31 Aug 2001 23:24:02 -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 UAA25600; Fri, 31 Aug 2001 20:22:59 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Pat Calhoun" Cc: Subject: RE: [AAA-WG]: Bernard's implied issues Date: Fri, 31 Aug 2001 20: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > WEP reference is correct. Will try to find reference for WEP-128 (there is > no IEEE standard for this). RFC 3162 will issue soon. FYI, it is available now: ftp://ftp.isi.edu/in-notes/rfc3162.txt From owner-aaa-wg@merit.edu Fri Aug 31 23:32:17 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23318 for ; Fri, 31 Aug 2001 23:32:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A321391255; Fri, 31 Aug 2001 23:30:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14D2591276; Fri, 31 Aug 2001 23:30: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 C432291255 for ; Fri, 31 Aug 2001 23:30:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8EFA25DDC0; Fri, 31 Aug 2001 23:30: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 35D895DDAE for ; Fri, 31 Aug 2001 23:30:21 -0400 (EDT) Received: (qmail 24642 invoked by uid 500); 1 Sep 2001 03:17:45 -0000 Date: Fri, 31 Aug 2001 20:17:45 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Glen Zorn , Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Bernard's implied issues Message-ID: <20010831201745.A24625@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Glen Zorn , Pat Calhoun , 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 aboba@internaut.com on Fri, Aug 31, 2001 at 04:48:49PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk 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'm not sure I'm too crazy on this. I MUCH prefer keeping the draft as-is. 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. >