From mailman-admin@ietf.org Sun Jun 1 10:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11448 for ; Sun, 1 Jun 2003 10:12:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51ECNB04961 for ; Sun, 1 Jun 2003 10:12:23 -0400 Date: Sun, 01 Jun 2003 10:12:23 -0400 Message-ID: <20030601141223.11734.75747.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From owner-aaa-wg@merit.edu Mon Jun 2 00:57:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11907 for ; Mon, 2 Jun 2003 00:57:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70D1E9122A; Mon, 2 Jun 2003 00:57:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 449749122F; Mon, 2 Jun 2003 00:57: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 46CAF9122A for ; Mon, 2 Jun 2003 00:57:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 279975E86E; Mon, 2 Jun 2003 00:57:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from HYUNMI (unknown [203.235.193.97]) by segue.merit.edu (Postfix) with ESMTP id 70E005E879 for ; Mon, 2 Jun 2003 00:57:28 -0400 (EDT) From: To: Subject: [AAA-WG]: Re: Approved Date: Mon, 2 Jun 2003 13:57:27 +0900 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_01017C6C" Message-Id: <20030602045728.70E005E879@segue.merit.edu> Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_01017C6C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_01017C6C-- From owner-aaa-wg@merit.edu Mon Jun 2 06:16:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00529 for ; Mon, 2 Jun 2003 06:16:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 989D49122B; Mon, 2 Jun 2003 06:16:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB1BF9122C; Mon, 2 Jun 2003 06:16: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 23F949122B for ; Mon, 2 Jun 2003 06:16:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC8945E924; Mon, 2 Jun 2003 06:16:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ZHUTIANQUAN_OFF (unknown [218.244.39.97]) by segue.merit.edu (Postfix) with ESMTP id 703155E925 for ; Mon, 2 Jun 2003 06:16:04 -0400 (EDT) From: To: Subject: [AAA-WG]: Re: Submited (004756-3463) Date: Mon, 2 Jun 2003 18:16:03 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0201979D" Message-Id: <20030602101604.703155E925@segue.merit.edu> Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_0201979D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_0201979D-- From owner-aaa-wg@merit.edu Mon Jun 2 14:40:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18541 for ; Mon, 2 Jun 2003 14:40:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 57BE79123A; Mon, 2 Jun 2003 14:39:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 297459123C; Mon, 2 Jun 2003 14:39: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 DED7A9123A for ; Mon, 2 Jun 2003 14:39:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3D045EAD1; Mon, 2 Jun 2003 14:39:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from www.mobile-ip.de (www.mobile-ip.de [195.37.77.211]) by segue.merit.edu (Postfix) with ESMTP id 8E5825EA9D for ; Mon, 2 Jun 2003 14:39:49 -0400 (EDT) Received: by www.mobile-ip.de (Postfix, from userid 766) id 03CBD23F05; Mon, 2 Jun 2003 20:32:08 +0200 (CEST) Date: Mon, 2 Jun 2003 20:32:07 +0200 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Message-ID: <20030602183207.GD25669@www.mobile-ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="aaa_security.txt" User-Agent: Mutt/1.3.28i From: jfl@mobile-ip.de (Floroiu John) Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, AAA infrastructures exhibit an obvious vulnerability to connection depletion attacks and in this context authenticating mobile hosts in a wireless hotspot, for instance, rises serious security concerns. The cause as well as a possible solution are briefly described below. Any comments would be greatly appreeciated. John. AAA clients, typically running on network access routers, create an AAA session for each authentication request they send to an AAA server. This contradicts the basic requirement an authentication protocol should meet, namely, avoiding as much as possible any resource (memory, CPU) to be allocated until the client is proved to be authentic. The connection depletion problem is even more general because it ultimately affects all AAA agents located along the path between an AAA client and an AAA server. The reason is that all intervening AAA agents (even relay agents) are required to match the AAA answers against AAA requests (draft-ietf-aaa-diameter-12.txt section 6.2.2). Since no solution is provided to this problem in the current Diameter specification, here is the one I suggest. For AAA clients, the solution would be to create a AAA session only as result to receiving an (positive) AAA answer. Additionaly, * the AAA server must include in the answer all those attributes specified in the request the AAA client requires in order to consistently setup the AAA session; * the AAA client must compute a hash over those fields contained in the request that uniquely and consistently identify a session and a local timestamp, using a local key. The hash must be appended to the request and the AAA server is required to echo the hash along with the answer. (see also "Stateless connections", T. Aura, P. Nikander, ICIS 1997). AAA agents, in turn, would route the answers only based on the Route-Record AVPs, which must be appended by all relay and proxy agents (draft-ietf-aaa-diameter-12.txt 6.1.8), without matching the answers against the requests. This task will be accomplished by the AAA client (and AAA server implicitly). --- From owner-aaa-wg@merit.edu Mon Jun 2 16:28:25 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22726 for ; Mon, 2 Jun 2003 16:28:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F69C9123D; Mon, 2 Jun 2003 16:25:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F2EF9123E; Mon, 2 Jun 2003 16:25: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 BFCC09123D for ; Mon, 2 Jun 2003 16:25:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A654E5E3D4; Mon, 2 Jun 2003 16:25:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 0ED945E9B5 for ; Mon, 2 Jun 2003 16:25:22 -0400 (EDT) Received: (cpmta 5406 invoked from network); 2 Jun 2003 13:25:19 -0700 Received: from 24.61.72.177 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 2 Jun 2003 13:25:19 -0700 X-Sent: 2 Jun 2003 20:25:19 GMT Message-Id: <5.2.1.1.2.20030602160508.02fb2c50@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 02 Jun 2003 16:25:02 -0400 To: jfl@mobile-ip.de (Floroiu John), aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks In-Reply-To: <20030602183207.GD25669@www.mobile-ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Comments are embedded: On 6/2/2003 08:32 PM +0200, Floroiu John wrote: >Hi, > >AAA infrastructures exhibit an obvious vulnerability to connection >depletion attacks and in this context authenticating mobile hosts in a >wireless hotspot, for instance, rises serious security concerns. > >The cause as well as a possible solution are briefly described below. > >Any comments would be greatly appreeciated. > >John. > > >AAA clients, typically running on network access routers, create an AAA >session for each authentication request they send to an AAA server. This >contradicts the basic requirement an authentication protocol should >meet, namely, avoiding as much as possible any resource (memory, CPU) to >be allocated until the client is proved to be authentic. This is not true. Diameter clients should only create one transport session for any given authentication server. Diameter sessions should be multiplexed over that session. Section 2.5 of the Base explains some of this, Section 5 explains how peer connections are established. >The connection depletion problem is even more general because it >ultimately affects all AAA agents located along the path between an AAA >client and an AAA server. The reason is that all intervening AAA agents >(even relay agents) are required to match the AAA answers against AAA >requests (draft-ietf-aaa-diameter-12.txt section 6.2.2). > >Since no solution is provided to this problem in the current Diameter >specification, here is the one I suggest. You have overlooked the transport method as described. >For AAA clients, the solution would be to create a AAA session only as >result to receiving an (positive) AAA answer. The AAA client still must hold the context of any AAA attempt, or it won't know what to do with the response when it receives it. The request will///must be attempted via a real resource, it that resource will be held during the resolution of this request. For example a NAS has a port. An 802.1x client has a virtual or physical port. >Additionaly, >* the AAA server must include in the answer all those attributes > specified in the request the AAA client requires in order to > consistently setup the AAA session; huh? too vague >* the AAA client must compute a hash over those fields contained in the > request that uniquely and consistently identify a session and a local > timestamp, using a local key. The hash must be appended to the request > and the AAA server is required to echo the hash along with the answer. >(see also "Stateless connections", T. Aura, P. Nikander, ICIS 1997). This is beginning to sound like a RADIUS authenticator. >AAA agents, in turn, would route the answers only based on the >Route-Record AVPs, which must be appended by all relay and proxy agents >(draft-ietf-aaa-diameter-12.txt 6.1.8), without matching the answers >against the requests. This task will be accomplished by the AAA client >(and AAA server implicitly). > >--- John, All said, any AAA client or like implementation will have a finite set or resources and, yes, they can be exhausted. This is a real world implementation concern, but I'm not sure that's a wire protocol issue, but more of a memory size and admission rate control issue. Wireless access points have limits on the number of associated stations that would have to be factored into any robust implementation. The AID table is so large, and there are errors for too busy or resources exceeded. I'm not sure I'm convinced there is a problem here to be solved at the protocol level. Dave. From owner-aaa-wg@merit.edu Tue Jun 3 05:06:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23761 for ; Tue, 3 Jun 2003 05:06:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19FB49123B; Tue, 3 Jun 2003 05:05:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF90C91247; Tue, 3 Jun 2003 05:05: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 5E1279123B for ; Tue, 3 Jun 2003 05:05:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4A915EE2F; Tue, 3 Jun 2003 05:03:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from www.mobile-ip.de (www.mobile-ip.de [195.37.77.211]) by segue.merit.edu (Postfix) with ESMTP id 22A1C5EE2E for ; Tue, 3 Jun 2003 05:03:35 -0400 (EDT) Received: by www.mobile-ip.de (Postfix, from userid 766) id 1D48A2400E; Tue, 3 Jun 2003 10:55:53 +0200 (CEST) Date: Tue, 3 Jun 2003 10:55:53 +0200 To: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Message-ID: <20030603085553.GA29366@www.mobile-ip.de> References: <20030602183207.GD25669@www.mobile-ip.de> <5.2.1.1.2.20030602160508.02fb2c50@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.1.1.2.20030602160508.02fb2c50@getmail.mitton.com> User-Agent: Mutt/1.3.28i From: jfl@mobile-ip.de (Floroiu John) Sender: owner-aaa-wg@merit.edu Precedence: bulk David, Thanks for the reply! I actually used the term "connection depletion" in a more general context, it is my fault for not being more specific. I didn't necessarily refer to TCP related connection depletion attacks (I fully agree with your comment regarding "connections vs. sessions"), but to whatever requires a state to be maintained at a stage when the client hasn't been yet authenticated. And this is demonstrated throughout section 8.1 by the presence of state "Pending" in the client's state machine (both stateless and stateful). More comments inline... [...] > >The connection depletion problem is even more general because it > >ultimately affects all AAA agents located along the path between an AAA > >client and an AAA server. The reason is that all intervening AAA agents > >(even relay agents) are required to match the AAA answers against AAA > >requests (draft-ietf-aaa-diameter-12.txt section 6.2.2). > > > >Since no solution is provided to this problem in the current Diameter > >specification, here is the one I suggest. > > You have overlooked the transport method as described. (Pls. also see my comment above). This assertion regarding the AAA agents was justified in particular by the fact that the hop-by-hop identifier (on the incoming TCP connection) must be stored for each request that is forwarded, and restored in the corresponding answer. > >For AAA clients, the solution would be to create a AAA session only as > >result to receiving an (positive) AAA answer. > > The AAA client still must hold the context of any AAA attempt, or it won't > know what to do with the response when it receives it. The request > will///must be attempted via a real resource, it that resource will be held > during the resolution of this request. For example a NAS has a port. An > 802.1x client has a virtual or physical port. This kind of information is what the AAA client must append to request and the AAA server must echo back in the answer, see first bullet below. > >Additionaly, > >* the AAA server must include in the answer all those attributes > > specified in the request the AAA client requires in order to > > consistently setup the AAA session; > > huh? too vague Well, this really depends on the application. The NAS port you mentioned above is one example. In Mobile IP for instance it may be the care-of address. The Session-Id, App-Id, Origin Host/Realm, Destination host/Realm are also part of the context but these will be included anyway. > >* the AAA client must compute a hash over those fields contained in the > > request that uniquely and consistently identify a session and a local > > timestamp, using a local key. The hash must be appended to the request > > and the AAA server is required to echo the hash along with the answer. > >(see also "Stateless connections", T. Aura, P. Nikander, ICIS 1997). > > This is beginning to sound like a RADIUS authenticator. Possibly, I am not aware about how Radius authenticators are computed. This technique is however widely spread. JFK for instance also uses it and the authors of the above mentioned paper proposed it to be extended to ISAKMP as well (ISAKMP doen't use it though, and this is the reason why some people consider it "harmful"). > All said, any AAA client or like implementation will have a finite set or > resources and, yes, they can be exhausted. This is a real world > implementation concern, but I'm not sure that's a wire protocol issue, but > more of a memory size and admission rate control issue. > > Wireless access points have limits on the number of associated stations > that would have to be factored into any robust implementation. The AID > table is so large, and there are errors for too busy or resources exceeded. I agree there might be physical limitations and I am not aware how different wireless technologies allocate "channels" or "ports" (and especially whether they are bound to the MAC address, for instance). The problem as I see it, however, is that one won't be confronted with thousands of attackers trying to attach to an access point, but with only one, that uses one physical access port but injects thousands of faked authentication requests (possibly spoofing MAC and IP addresses) > I'm not sure I'm convinced there is a problem here to be solved at the > protocol level. Myself I would incline to design authentication protocols as robust as possible and ensure that at least all currently known threats are somehow addressed. Anyway, thanks a lot for your comments. John. From owner-aaa-wg@merit.edu Tue Jun 3 09:40:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04139 for ; Tue, 3 Jun 2003 09:40:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E7C791253; Tue, 3 Jun 2003 09:40:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17AC991250; Tue, 3 Jun 2003 09:40: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 A6D2E912F1 for ; Tue, 3 Jun 2003 09:40:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8BD35EFB8; Tue, 3 Jun 2003 09:39:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 0336B5EF8E for ; Tue, 3 Jun 2003 09:39:48 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h53DdlW06271 for ; Tue, 3 Jun 2003 16:39:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Jun 2003 16:39:47 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 16:39:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 16:39:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Date: Tue, 3 Jun 2003 16:39:35 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB14@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Thread-Index: AcMpNmix5VBupaoUQZyV9KXVu8/JmgAnZqPA From: To: , X-OriginalArrivalTime: 03 Jun 2003 13:39:36.0020 (UTC) FILETIME=[92902940:01C329D5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04139 Floroiu John wrote: > For AAA clients, the solution would be to create a AAA session only > as result to receiving an (positive) AAA answer. Additionaly, > > * the AAA server must include in the answer all those attributes > specified in the request the AAA client requires in order to > consistently setup the AAA session; > > * the AAA client must compute a hash over those fields contained in > the request that uniquely and consistently identify a session and a > local timestamp, using a local key. The hash must be appended to the > request and the AAA server is required to echo the hash along with > the answer. > (see also "Stateless connections", T. Aura, P. Nikander, ICIS 1997). > > AAA agents, in turn, would route the answers only based on the > Route-Record AVPs, which must be appended by all relay and proxy > agents (draft-ietf-aaa-diameter-12.txt 6.1.8), without matching the > answers against the requests. This task will be accomplished by the > AAA client (and AAA server implicitly). Diameter already includes an AVP that can be used to accomplish what you want: Proxy-Info/Proxy-State. The AAA client can store whatever state it needs to process the answer in the Proxy-State AVP (possibly encrypted and MAC'd, if considered necessary), and get it back in the server's answer. However, I tend to agree with David Mitton's answer, that avoiding this type of DoS is an implementation issue. Besides, such "stateless operation" is not without problems: for instance, failover that retransmits the request to an alternative server is not possible without per-session state. Best regards, Pasi From owner-aaa-wg@merit.edu Tue Jun 3 10:29:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06999 for ; Tue, 3 Jun 2003 10:29:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2D8691255; Tue, 3 Jun 2003 10:29:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7064E912EC; Tue, 3 Jun 2003 10:29: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 113A891255 for ; Tue, 3 Jun 2003 10:29:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB15C5EF95; Tue, 3 Jun 2003 10:29:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id AFD965EF1E for ; Tue, 3 Jun 2003 10:29:39 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jun 2003 10:29:39 -0400 Message-ID: From: Avi Lior To: "'jfl@mobile-ip.de'" , "'David Mitton'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Date: Tue, 3 Jun 2003 10:29:38 -0400 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 Hi, It seems to me that you are talking about two issues relating to DoS. One is a TCP connection attack, the other is a depletion of resources due to the information that is stored by the AAA server. The first issue is a TCP issue and not a AAA issue. A Server can not tell what the IP address is until the socket is established. Therefore any TCP based server is suceptible to this attack. Therefore, you have to use something like a firewall to protect against that type of attack. The second issue is about how much information is kept in the server during each transaction. You can certainly design a protocol that minimize or even elliminates the need to keep any information in memory. However, that comes at a price. You either have to give up functionality, or have message bloat. For example, in AAA we belive that an intermediary AAA server should be able to detect a timeout and act on that timeout for each transaction. Therefore it must as a minimum store each message, as well as an associated timer, and where it sent that message. You can do away with this memory burden but then how would you meet this requirement? You certainly can't store information in the message to solve this problem. There are other examples such as above relating to security contexts etc.. To support the type of systems we want, I think its inevitable that we keep transaction state at each AAA server. > -----Original Message----- > From: jfl@mobile-ip.de [mailto:jfl@mobile-ip.de] > Sent: June 3, 2003 4:56 AM > To: David Mitton; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter vulnerability to connection > depletion DoS attacks > > > David, > > Thanks for the reply! > > I actually used the term "connection depletion" in a more > general context, it is my fault for not being more specific. > I didn't necessarily refer to TCP related connection > depletion attacks (I fully agree with your comment regarding > "connections vs. sessions"), but to whatever requires a state > to be maintained at a stage when the client hasn't been yet > authenticated. And this is demonstrated throughout section > 8.1 by the presence of state "Pending" in the client's state > machine (both stateless and stateful). > > More comments inline... > > [...] > > >The connection depletion problem is even more general because it > > >ultimately affects all AAA agents located along the path > between an > > >AAA client and an AAA server. The reason is that all > intervening AAA > > >agents (even relay agents) are required to match the AAA answers > > >against AAA requests (draft-ietf-aaa-diameter-12.txt > section 6.2.2). > > > > > >Since no solution is provided to this problem in the > current Diameter > > >specification, here is the one I suggest. > > > > You have overlooked the transport method as described. > > (Pls. also see my comment above). This assertion regarding > the AAA agents was justified in particular by the fact that > the hop-by-hop identifier (on the incoming TCP connection) > must be stored for each request that is forwarded, and > restored in the corresponding answer. > > > >For AAA clients, the solution would be to create a AAA > session only > > >as result to receiving an (positive) AAA answer. > > > > The AAA client still must hold the context of any AAA > attempt, or it > > won't > > know what to do with the response when it receives it. The request > > will///must be attempted via a real resource, it that > resource will be held > > during the resolution of this request. For example a NAS > has a port. An > > 802.1x client has a virtual or physical port. > > This kind of information is what the AAA client must append > to request and the AAA server must echo back in the answer, > see first bullet below. > > > >Additionaly, > > >* the AAA server must include in the answer all those attributes > > > specified in the request the AAA client requires in order to > > > consistently setup the AAA session; > > > > huh? too vague > > Well, this really depends on the application. The NAS port > you mentioned above is one example. In Mobile IP for instance > it may be the care-of address. The Session-Id, App-Id, Origin > Host/Realm, Destination host/Realm are also part of the > context but these will be included anyway. > > > >* the AAA client must compute a hash over those fields > contained in > > >the > > > request that uniquely and consistently identify a > session and a local > > > timestamp, using a local key. The hash must be appended > to the request > > > and the AAA server is required to echo the hash along > with the answer. > > >(see also "Stateless connections", T. Aura, P. Nikander, > ICIS 1997). > > > > This is beginning to sound like a RADIUS authenticator. > > Possibly, I am not aware about how Radius authenticators are > computed. This technique is however widely spread. JFK for > instance also uses it and the authors of the above mentioned > paper proposed it to be extended to ISAKMP as well (ISAKMP > doen't use it though, and this is the reason why some people > consider it "harmful"). > > > All said, any AAA client or like implementation will have a > finite set > > or > > resources and, yes, they can be exhausted. This is a real world > > implementation concern, but I'm not sure that's a wire > protocol issue, but > > more of a memory size and admission rate control issue. > > > > Wireless access points have limits on the number of associated > > stations > > that would have to be factored into any robust > implementation. The AID > > table is so large, and there are errors for too busy or > resources exceeded. > > I agree there might be physical limitations and I am not > aware how different wireless technologies allocate "channels" > or "ports" (and especially whether they are bound to the MAC > address, for instance). The problem as I see it, however, is > that one won't be confronted with thousands of attackers > trying to attach to an access point, but with only one, that > uses one physical access port but injects thousands of faked > authentication requests (possibly spoofing MAC and IP addresses) > > > I'm not sure I'm convinced there is a problem here to be > solved at the > > protocol level. > > Myself I would incline to design authentication protocols as > robust as possible and ensure that at least all currently > known threats are somehow addressed. Anyway, thanks a lot for > your comments. > > John. > From owner-aaa-wg@merit.edu Tue Jun 3 10:57:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07948 for ; Tue, 3 Jun 2003 10:57:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E8D391256; Tue, 3 Jun 2003 10:56:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E389912EC; Tue, 3 Jun 2003 10:56: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 2FB3691256 for ; Tue, 3 Jun 2003 10:56:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BCC45E791; Tue, 3 Jun 2003 10:56:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 66F2F5EFA4 for ; Tue, 3 Jun 2003 10:56:50 -0400 (EDT) Received: from tari.research.telcordia.com (tari.research.telcordia.com [207.3.232.66]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id h53Eujej014162; Tue, 3 Jun 2003 10:56:45 -0400 (EDT) Received: from localhost (tari.research.telcordia.com [207.3.232.66]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA27023; Tue, 3 Jun 2003 10:57:11 -0400 (EDT) Date: Tue, 3 Jun 2003 07:53:20 -0400 To: Floroiu John Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Message-ID: <20030603115210.GA4646@catfish> References: <20030602183207.GD25669@www.mobile-ip.de> <5.2.1.1.2.20030602160508.02fb2c50@getmail.mitton.com> <20030603085553.GA29366@www.mobile-ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20030603085553.GA29366@www.mobile-ip.de> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 42 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, On Tue, Jun 03, 2003 at 10:55:53AM +0200, Floroiu John wrote: > > All said, any AAA client or like implementation will have a finite set or > > resources and, yes, they can be exhausted. This is a real world > > implementation concern, but I'm not sure that's a wire protocol issue, but > > more of a memory size and admission rate control issue. > > > > Wireless access points have limits on the number of associated stations > > that would have to be factored into any robust implementation. The AID > > table is so large, and there are errors for too busy or resources exceeded. > > I agree there might be physical limitations and I am not aware how > different wireless technologies allocate "channels" or "ports" (and > especially whether they are bound to the MAC address, for instance). > The problem as I see it, however, is that one won't be confronted with > thousands of attackers trying to attach to an access point, but with > only one, that uses one physical access port but injects thousands of > faked authentication requests (possibly spoofing MAC and IP addresses) draft-ietf-pana-pana-00.txt is taking this attack into account by using a stateless cookie mechanism, and a different mechanism is also being discussed in the PANA WG. You may want to check http://danforsberg.info:8080/pana-issues/issue15. I think dealing with this kind of attack is a design or implementation issue of any AAA front-end protocol such as 802.1X and PANA, but not necessarily an issue of Diameter or RADIUS. > > > I'm not sure I'm convinced there is a problem here to be solved at the > > protocol level. > > Myself I would incline to design authentication protocols as robust as > possible and ensure that at least all currently known threats are somehow > addressed. Anyway, thanks a lot for your comments. > > John. > > Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue Jun 3 14:01:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17098 for ; Tue, 3 Jun 2003 14:01:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3733191254; Tue, 3 Jun 2003 14:00:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00BF891257; Tue, 3 Jun 2003 14: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 D082B91254 for ; Tue, 3 Jun 2003 14:00:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CDF05DDAB; Tue, 3 Jun 2003 14:00:17 -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 11B405DD9C for ; Tue, 3 Jun 2003 14:00:16 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h53I0ED11442 for ; Tue, 3 Jun 2003 21:00:14 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Jun 2003 21:00:13 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 21:00:14 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 3 Jun 2003 21:00:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Date: Tue, 3 Jun 2003 21:00:12 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Thread-Index: AcMp4G2dFWpBCZKRTf2LfnNbomqNkwAGXDYw From: To: , Cc: , X-OriginalArrivalTime: 03 Jun 2003 18:00:13.0037 (UTC) FILETIME=[FAF399D0:01C329F9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, > draft-ietf-pana-pana-00.txt is taking this attack into account by > using a stateless cookie mechanism, and a different mechanism is also > being discussed in the PANA WG. You may want to check > http://danforsberg.info:8080/pana-issues/issue15. > > I think dealing with this kind of attack is a design or implementation > issue of any AAA front-end protocol such as 802.1X and PANA, but not > necessarily an issue of Diameter or RADIUS. Also note that SCTP has a similar mechanism built-in, to protect against TCP syn flooding attacks. John From owner-aaa-wg@merit.edu Wed Jun 4 07:05:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11135 for ; Wed, 4 Jun 2003 07:05:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD47491201; Wed, 4 Jun 2003 07:04:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76F649126F; Wed, 4 Jun 2003 07:04:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0563C91201 for ; Wed, 4 Jun 2003 07:04:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2ED35DE49; Wed, 4 Jun 2003 07:04:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from www.mobile-ip.de (www.mobile-ip.de [195.37.77.211]) by segue.merit.edu (Postfix) with ESMTP id 7C5115DE35 for ; Wed, 4 Jun 2003 07:04:48 -0400 (EDT) Received: by www.mobile-ip.de (Postfix, from userid 766) id 8BBA3240A5; Wed, 4 Jun 2003 12:57:03 +0200 (CEST) Date: Wed, 4 Jun 2003 12:57:03 +0200 To: Avi Lior Cc: "'David Mitton'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Message-ID: <20030604105703.GB3545@www.mobile-ip.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: jfl@mobile-ip.de (Floroiu John) Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks everybody for your answers, I will merge my comments into this reply. > The second issue is about how much information is kept in the server during > each transaction. You can certainly design a protocol that minimize or even > elliminates the need to keep any information in memory. However, that comes > at a price. You either have to give up functionality, or have message > bloat. I perfectly agree with that. Myself, however I regarded Diameter primarly as an authentication protocol and there are examples of protocols that require participants neither to perform expensive computations nor to create state unless the peer is known to be legitimate. > For example, in AAA we belive that an intermediary AAA server should be able > to detect a timeout and act on that timeout for each transaction. Therefore > it must as a minimum store each message, as well as an associated timer, and > where it sent that message. You can do away with this memory burden but > then how would you meet this requirement? You certainly can't store > information in the message to solve this problem. I agree with that, too: one cannot perform retransimissions based on the information contained in a lost packet (and if the packet is not lost then one doesn't need that information anyway). But on the other hand if an AAA server retransimits forged requests, then this aggravates the impact of any potential DoS attack. As another message in this thread has suggested, the matter could be delegated to the AAA front-end protocols (such as PANA). However, in the case of inter-domain roaming scenarios, for instance, when the mobile users and the NASs do not share any pre-existent trust relationship, such protocols cannot prevent forged authentication requests from entering the AAA infrastructure. Cookies can only protect against blind attacks. Relevant to http://danforsberg.info:8080/pana-issues/issue15, client puzzles are also ineffective because malicious nodes may pose as NASs and perform computational DoS against legitimate nodes by proposing "difficult" puzzles. Since there is no pre-existent trust relationship between "pac" and "paa" puzzle proposals may only be authenticated using asymmetric cryptography ([1]), which is however also a source of computational DoS attacks. Maybe the safest approach would be to provide a real stateless AAA client operation and support more features (retransimissions, security contexts, just to refer to those already mentioned in this context) after the client has been successfully authenticated. Just an opinion... John. [1] T. Aura, P. Nikander, J. Leiwo - DoS-resistant Authentication with Client Puzzles From owner-aaa-wg@merit.edu Thu Jun 5 05:40:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12698 for ; Thu, 5 Jun 2003 05:40:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DD939129D; Thu, 5 Jun 2003 05:40:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F08D9129E; Thu, 5 Jun 2003 05:40: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 BA85E9129D for ; Thu, 5 Jun 2003 05:40:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A9795DEF9; Thu, 5 Jun 2003 05:40:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from www.mobile-ip.de (www.mobile-ip.de [195.37.77.211]) by segue.merit.edu (Postfix) with ESMTP id 64D245DEF8 for ; Thu, 5 Jun 2003 05:40:16 -0400 (EDT) Received: by www.mobile-ip.de (Postfix, from userid 766) id A86E323F05; Thu, 5 Jun 2003 11:32:29 +0200 (CEST) Date: Thu, 5 Jun 2003 11:32:29 +0200 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Message-ID: <20030605093229.GC3545@www.mobile-ip.de> References: <052E0C61B69C3741AFA5FE88ACC775A608BB14@esebe023.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB14@esebe023.ntc.nokia.com> User-Agent: Mutt/1.3.28i From: jfl@mobile-ip.de (Floroiu John) Sender: owner-aaa-wg@merit.edu Precedence: bulk Pasi, > Diameter already includes an AVP that can be used to accomplish > what you want: Proxy-Info/Proxy-State. The AAA client can store > whatever state it needs to process the answer in the Proxy-State > AVP (possibly encrypted and MAC'd, if considered necessary), > and get it back in the server's answer. Just a small comment on that: the AVP you mention provides the support to operate truly stateless, but the protocol still requires states to be maintained (see the definition of the state machines), therefore the AVP alone is not of real help! Anyway, I got an understanding on the "stateless AAA" issue. John. From owner-aaa-wg@merit.edu Fri Jun 6 10:18:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25630 for ; Fri, 6 Jun 2003 10:18:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3483912B1; Fri, 6 Jun 2003 10:16:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82646912B2; Fri, 6 Jun 2003 10:16: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 AD894912B1 for ; Fri, 6 Jun 2003 10:16:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B3715DED3; Fri, 6 Jun 2003 10:16:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id C61D35DEA4 for ; Fri, 6 Jun 2003 10:16:41 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 10:16:40 -0400 Message-ID: From: Avi Lior To: "'jfl@mobile-ip.de'" , Avi Lior Cc: "'David Mitton'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks Date: Fri, 6 Jun 2003 10:16:31 -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 > -----Original Message----- > From: jfl@mobile-ip.de [mailto:jfl@mobile-ip.de] > Sent: Wednesday, June 04, 2003 6:57 AM > To: Avi Lior > Cc: 'David Mitton'; 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: Diameter vulnerability to connection > depletion DoS attacks > > > Thanks everybody for your answers, I will merge my comments > into this reply. > > > The second issue is about how much information is kept in > the server > > during each transaction. You can certainly design a protocol that > > minimize or even elliminates the need to keep any information in > > memory. However, that comes at a price. You either have > to give up > > functionality, or have message bloat. > > I perfectly agree with that. Myself, however I regarded > Diameter primarly as an authentication protocol and there are > examples of protocols that require participants neither to > perform expensive computations nor to create state unless the > peer is known to be legitimate. Hmmmm Diameter is an authentication protocol but that doesn't mean that it can't be sophisticated to address real world problems. Diameter's complexity, comes from years of experience in the real world. You want something simpler, stick with RADIUS. > > For example, in AAA we belive that an intermediary AAA > server should > > be able to detect a timeout and act on that timeout for each > > transaction. Therefore it must as a minimum store each message, as > > well as an associated timer, and where it sent that > message. You can > > do away with this memory burden but then how would you meet this > > requirement? You certainly can't store information in the > message to > > solve this problem. > > I agree with that, too: one cannot perform retransimissions > based on the information contained in a lost packet (and if > the packet is not lost then one doesn't need that information > anyway). Those laws of physics get in the way again. >But on the other hand if an AAA server retransimits > forged requests, then this aggravates the impact of any > potential DoS attack. So you are stuck between a rock and a hard place. If you have any ideas about how to fix this we would love to hear them. > > As another message in this thread has suggested, the matter > could be delegated to the AAA front-end protocols (such as > PANA). However, in the case of inter-domain roaming > scenarios, for instance, when the mobile users and the NASs > do not share any pre-existent trust relationship, such > protocols cannot prevent forged authentication requests from > entering the AAA infrastructure. Cookies can only protect > against blind attacks. > > Relevant to http://danforsberg.info:8080/pana-issues/issue15, > client puzzles are also ineffective because malicious nodes > may pose as NASs and perform computational DoS against > legitimate nodes by proposing "difficult" puzzles. Since > there is no pre-existent trust relationship between "pac" and > "paa" puzzle proposals may only be authenticated using > asymmetric cryptography ([1]), which is however also a source > of computational DoS attacks. > > Maybe the safest approach would be to provide a real > stateless AAA client operation and support more features > (retransimissions, security contexts, just to refer to those > already mentioned in this context) after the client has been > successfully authenticated. Just an opinion... This is exactly what is done. Session state is only established after we validate the client. What we were talking about was short lived communication state that is required in order to provide capabilities such as retransmission at the intermediary nodes, and security context for establishing the authenticity of a client, which may require more then one Authentication transcation. You can reduce your short live communication state by giving up on these "features". But do you want to? > John. > > > [1] T. Aura, P. Nikander, J. Leiwo - DoS-resistant > Authentication with Client Puzzles > From owner-aaa-wg@merit.edu Mon Jun 9 15:00:30 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16751 for ; Mon, 9 Jun 2003 15:00:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E65B9124E; Mon, 9 Jun 2003 14:58:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3A379124C; Mon, 9 Jun 2003 14:58: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 88BB49124A for ; Mon, 9 Jun 2003 14:58:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CC945DDD9; Mon, 9 Jun 2003 14:58:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by segue.merit.edu (Postfix) with ESMTP id B1BD05DDC6 for ; Mon, 9 Jun 2003 14:58:28 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h59IwQms012084 for ; Mon, 9 Jun 2003 11:58:27 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-68.cisco.com [128.107.166.68]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHY09313; Mon, 9 Jun 2003 11:53:46 -0700 (PDT) Message-ID: <3EE4D8D7.1060207@cisco.com> Date: Mon, 09 Jun 2003 11:58:31 -0700 From: "Murtaza S. Chiba" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: No value strings 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 Hello, The current version of the base protocol defines that an attribute may have 0 or more data bytes. Wanted to understand the need for an attribute with no value and should it be a new type something other than string? Is an attribute with no data still a string? Maybe it is better to define a new type for no data? Thanks, Murtaza From owner-aaa-wg@merit.edu Mon Jun 9 16:26:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20069 for ; Mon, 9 Jun 2003 16:26:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7D03C9124A; Mon, 9 Jun 2003 16:26:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4697F9124B; Mon, 9 Jun 2003 16:26: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 1C1B69124A for ; Mon, 9 Jun 2003 16:26:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F17AA5DDC6; Mon, 9 Jun 2003 16:26:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id B14555DDB1 for ; Mon, 9 Jun 2003 16:26:02 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 16:26:02 -0400 Message-ID: From: Avi Lior To: "'Murtaza S. Chiba'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: No value strings Date: Mon, 9 Jun 2003 16:25:53 -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 Hi, Perhaps I can give you one repsonse to this. In RADIUS RFCs there are no attributes that have zero length. However, there are some vendors that we know of that have zero length vendor attributes. Therefore, to provide backwards compatiblity with RADIUS, I would think we would need to support such a concept. As of being a new type, no sure. It would appear that these attributes act as a indication (or a flag). The presence of an attribute is sufficient to indicate something. This may suggest a "flag" type or a zero length boolean not sure. But there could be other uses. Perhaps when sent by the server it indicates something to the NAS such as measure volume. The NAS would then return the attribute with some value say in this case the number of octets. Does this help? > -----Original Message----- > From: Murtaza S. Chiba [mailto:mchiba@cisco.com] > Sent: Monday, June 09, 2003 2:59 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: No value strings > > > Hello, > The current version of the base protocol defines that > an attribute may > have 0 or more data bytes. Wanted to understand the need for an > attribute with no value and should it be a new type something > other than > string? Is an attribute with no data still a string? Maybe it is > better to define a new type for no data? > > Thanks, > Murtaza > > From owner-aaa-wg@merit.edu Mon Jun 9 16:35:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20282 for ; Mon, 9 Jun 2003 16:35:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E21279124B; Mon, 9 Jun 2003 16:34:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1BDF9124C; Mon, 9 Jun 2003 16: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 A9C479124B for ; Mon, 9 Jun 2003 16:34:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 923E05DDDA; Mon, 9 Jun 2003 16:34:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 568BC5DDD9 for ; Mon, 9 Jun 2003 16:34:48 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5192F6A901; Mon, 9 Jun 2003 23:34:46 +0300 (EEST) Message-ID: <3EE4EF00.3060102@kolumbus.fi> Date: Mon, 09 Jun 2003 23:33:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Murtaza S. Chiba" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: No value strings References: <3EE4D8D7.1060207@cisco.com> In-Reply-To: <3EE4D8D7.1060207@cisco.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 Murtaza S. Chiba wrote: > Hello, > The current version of the base protocol defines that an attribute > may have 0 or more data bytes. Wanted to understand the need for an > attribute with no value and should it be a new type something other than > string? Is an attribute with no data still a string? Maybe it is > better to define a new type for no data? Well, none of the attributes in the base spec make much sense with zero bytes. (You could perhaps argue that Error-Message might appear as an empty string.) Still, I think its right to define the String data type as something that can even be an empty string. The specific text for the attribute in question will say more about the contents of the expected string, often more structure is expected than just a string. Empty values may make sense in some cases, we don't know all the possible attributes that folks will define in the future. --Jari From owner-aaa-wg@merit.edu Mon Jun 9 17:09:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21483 for ; Mon, 9 Jun 2003 17:09:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2849191254; Mon, 9 Jun 2003 17:06:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9AC291255; Mon, 9 Jun 2003 17:06: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 7C28791254 for ; Mon, 9 Jun 2003 17:06:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 322605DD8E; Mon, 9 Jun 2003 17:06:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by segue.merit.edu (Postfix) with ESMTP id B52445DDBB for ; Mon, 9 Jun 2003 17:06:22 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h59L6BCL004670; Mon, 9 Jun 2003 14:06:11 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-68.cisco.com [128.107.166.68]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHY23620; Mon, 9 Jun 2003 14:01:31 -0700 (PDT) Message-ID: <3EE4F6C8.3080906@cisco.com> Date: Mon, 09 Jun 2003 14:06:16 -0700 From: "Murtaza S. Chiba" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: No value strings References: In-Reply-To: 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 Not really, my problem is how to ensure a correct value is being sent as opposed to a missing value? Maybe a distinction between 0+ and 1+? Avi Lior wrote: > Hi, > Perhaps I can give you one repsonse to this. In RADIUS RFCs there are no > attributes that have zero length. However, there are some vendors that we > know of that have zero length vendor attributes. Therefore, to provide > backwards compatiblity with RADIUS, I would think we would need to support > such a concept. > > As of being a new type, no sure. It would appear that these attributes act > as a indication (or a flag). The presence of an attribute is sufficient to > indicate something. This may suggest a "flag" type or a zero length boolean > not sure. > > But there could be other uses. Perhaps when sent by the server it indicates > something to the NAS such as measure volume. The NAS would then return the > attribute with some value say in this case the number of octets. > > Does this help? > > >>-----Original Message----- >>From: Murtaza S. Chiba [mailto:mchiba@cisco.com] >>Sent: Monday, June 09, 2003 2:59 PM >>To: aaa-wg@merit.edu >>Subject: [AAA-WG]: No value strings >> >> >>Hello, >> The current version of the base protocol defines that >>an attribute may >>have 0 or more data bytes. Wanted to understand the need for an >>attribute with no value and should it be a new type something >>other than >>string? Is an attribute with no data still a string? Maybe it is >>better to define a new type for no data? >> >>Thanks, >>Murtaza >> >> > > From owner-aaa-wg@merit.edu Mon Jun 9 17:14:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21641 for ; Mon, 9 Jun 2003 17:14:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6789391255; Mon, 9 Jun 2003 17:14:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 352BD91256; Mon, 9 Jun 2003 17:14:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3964F91255 for ; Mon, 9 Jun 2003 17:14:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23BDD5DDC6; Mon, 9 Jun 2003 17:14:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id D0DF45DDC5 for ; Mon, 9 Jun 2003 17:14:04 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6FF4D6A901; Tue, 10 Jun 2003 00:14:03 +0300 (EEST) Message-ID: <3EE4F835.8050101@kolumbus.fi> Date: Tue, 10 Jun 2003 00:12:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Murtaza S. Chiba" Cc: Avi Lior , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: No value strings References: <3EE4F6C8.3080906@cisco.com> In-Reply-To: <3EE4F6C8.3080906@cisco.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 Murtaza S. Chiba wrote: > > Not really, my problem is how to ensure a correct value is being sent as > opposed to a missing value? Maybe a distinction between 0+ and 1+? That, and following the content rules for the given attribute. --Jari From owner-aaa-wg@merit.edu Mon Jun 9 17:29:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21961 for ; Mon, 9 Jun 2003 17:29:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B58191256; Mon, 9 Jun 2003 17:29:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58FB391257; Mon, 9 Jun 2003 17:29:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2869B91256 for ; Mon, 9 Jun 2003 17:29:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CEEF5DDE8; Mon, 9 Jun 2003 17:29:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id ADE9D5DDE9 for ; Mon, 9 Jun 2003 17:29:23 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 17:29:23 -0400 Message-ID: From: Avi Lior To: "'Murtaza S. Chiba'" , Avi Lior Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: No value strings Date: Mon, 9 Jun 2003 17:29:18 -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 To me 0+ means the presence of zero or more instances of a given attribute regardless of what value is assigned to that attribute. So I don't see any confusion. > -----Original Message----- > From: Murtaza S. Chiba [mailto:mchiba@cisco.com] > Sent: Monday, June 09, 2003 5:06 PM > To: Avi Lior > Cc: 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: No value strings > > > > Not really, my problem is how to ensure a correct value is > being sent as > opposed to a missing value? Maybe a distinction between 0+ and 1+? > > > Avi Lior wrote: > > Hi, > > Perhaps I can give you one repsonse to this. In RADIUS RFCs > there are > > no attributes that have zero length. However, there are > some vendors > > that we know of that have zero length vendor attributes. > Therefore, > > to provide backwards compatiblity with RADIUS, I would > think we would > > need to support such a concept. > > > > As of being a new type, no sure. It would appear that these > > attributes act as a indication (or a flag). The presence of an > > attribute is sufficient to indicate something. This may suggest a > > "flag" type or a zero length boolean not sure. > > > > But there could be other uses. Perhaps when sent by the server it > > indicates something to the NAS such as measure volume. The > NAS would > > then return the attribute with some value say in this case > the number > > of octets. > > > > Does this help? > > > > > >>-----Original Message----- > >>From: Murtaza S. Chiba [mailto:mchiba@cisco.com] > >>Sent: Monday, June 09, 2003 2:59 PM > >>To: aaa-wg@merit.edu > >>Subject: [AAA-WG]: No value strings > >> > >> > >>Hello, > >> The current version of the base protocol defines that > >>an attribute may > >>have 0 or more data bytes. Wanted to understand the need for an > >>attribute with no value and should it be a new type something > >>other than > >>string? Is an attribute with no data still a string? Maybe it is > >>better to define a new type for no data? > >> > >>Thanks, > >>Murtaza > >> > >> > > > > > > From owner-aaa-wg@merit.edu Thu Jun 12 07:08:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03218 for ; Thu, 12 Jun 2003 07:08:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2DB2691264; Thu, 12 Jun 2003 07:07:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E955A91265; Thu, 12 Jun 2003 07:07: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 B6C9A91264 for ; Thu, 12 Jun 2003 07:07:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 950475DDF6; Thu, 12 Jun 2003 07:07:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from web41803.mail.yahoo.com (web41803.mail.yahoo.com [66.218.93.137]) by segue.merit.edu (Postfix) with SMTP id EEC2D5DDE6 for ; Thu, 12 Jun 2003 07:07:56 -0400 (EDT) Message-ID: <20030612110756.65326.qmail@web41803.mail.yahoo.com> Received: from [203.124.156.98] by web41803.mail.yahoo.com via HTTP; Thu, 12 Jun 2003 04:07:56 PDT Date: Thu, 12 Jun 2003 04:07:56 -0700 (PDT) From: Harold Hunt Subject: [AAA-WG]: Diameter and mobile ip registration To: jfl@mobile-ip.de Cc: aaa-wg@merit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2116551613-1055416076=:64832" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-2116551613-1055416076=:64832 Content-Type: text/plain; charset=us-ascii Hello, I have a query regarding mobile ip registation and diameter server.How does the mobile node register itself in the home network? Though the registration request(AMR) in the foreign network reaches the Home Server via Foreign Server and Foreign Agent, nothing is mentioned about the start of a session in the home network. Through the home agent perhaps ?? regards, Harold --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). --0-2116551613-1055416076=:64832 Content-Type: text/html; charset=us-ascii

Hello,

I have a query regarding mobile ip registation and diameter server.How does the mobile node register itself in the home network? Though the registration request(AMR) in the foreign network reaches the Home Server via Foreign Server and Foreign Agent, nothing is mentioned about the start of a session in the home network. Through the home agent perhaps ??

regards,

Harold

 

 

 

Do you Yahoo!?
Free online calendar with sync to Outlook(TM). --0-2116551613-1055416076=:64832-- From owner-aaa-wg@merit.edu Mon Jun 16 09:33:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13377 for ; Mon, 16 Jun 2003 09:33:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34178912A6; Mon, 16 Jun 2003 09:33:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05B2A912A7; Mon, 16 Jun 2003 09:33: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 83519912A6 for ; Mon, 16 Jun 2003 09:32:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 66CF35DDF2; Mon, 16 Jun 2003 09:32:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E20035DDED for ; Mon, 16 Jun 2003 09:32:57 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5GD8b004063 for ; Mon, 16 Jun 2003 06:08:41 -0700 Date: Mon, 16 Jun 2003 06:08:37 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: EAP WG last call on RFC 2284bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of EAP WG last call on RFC 2284bis, prior to sending it on to the IESG for consideration as an IETF Proposed Standard. The draft is not yet available on the IETF archive, but should be there by Wednesday or Thursday at the latest. Until then, it is available for examination here: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.e.txt When it arrives on the archive, the document will be available for examination here: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP WG last call will last until July 7, 2003. Please send comments to the EAP WG mailing list (eap@frascone.com) in the format specified on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From owner-aaa-wg@merit.edu Mon Jun 16 19:01:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07829 for ; Mon, 16 Jun 2003 19:01:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1634E91212; Mon, 16 Jun 2003 19:00:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07B339125B; Mon, 16 Jun 2003 19:00: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 DF4AE91212 for ; Mon, 16 Jun 2003 19:00:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADC225DF56; Mon, 16 Jun 2003 19:00:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id E6B525DEC7 for ; Mon, 16 Jun 2003 19:00:17 -0400 (EDT) Received: (cpmta 17528 invoked from network); 16 Jun 2003 16:00:16 -0700 Received: from 24.61.72.177 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 16 Jun 2003 16:00:16 -0700 X-Sent: 16 Jun 2003 23:00:16 GMT Message-Id: <5.2.1.1.2.20030616185908.03e00100@mail.attbi.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 16 Jun 2003 19:00:07 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Test Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Test message to prove the list works, and I can send, but my other messages must be failing based on something else, perhaps content. Dave. From owner-aaa-wg@merit.edu Tue Jun 17 11:00:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21050 for ; Tue, 17 Jun 2003 11:00:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0DAA2912D9; Tue, 17 Jun 2003 10:59:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F036912DE; Tue, 17 Jun 2003 10:59: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 A096B912D9 for ; Tue, 17 Jun 2003 10:59:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F17B5E03D; Tue, 17 Jun 2003 10:59:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from falcon.al.sw.ericsson.se (falcon.ericsson.se [193.180.251.52]) by segue.merit.edu (Postfix) with ESMTP id E100E5E02C for ; Tue, 17 Jun 2003 10:59:46 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HF0Ucv003884; Tue, 17 Jun 2003 17:00:30 +0200 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYG2GZ2N; Tue, 17 Jun 2003 17:01:28 +0200 Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA09674; Tue, 17 Jun 2003 16:59:29 +0200 Message-ID: <3EEF2CD0.2080601@ericsson.com> Date: Tue, 17 Jun 2003 17:59:28 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: =?ISO-8859-1?Q?Mari_Carmen_Belinch=F3n?= , miguel.pallares@ericsson.com, carolina.canales-valenzuela@ece.ericsson.se, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: A new version of the Diameter Multimedia Application draft is available in the IETF repository. As you may recall, the document describes a new Diameter application that is designed to interact with SIP (Session Initiation Protocol). We have been re-writing several parts of the draft to add a better wording and understanding. We still are aware that work is needed in several areas: e.g., adding a Radius compatibility discussion, or adding more a better support on many other scenarios, particularly those not related to 3GPP. At this stage, we are looking for volunteers that will be have time to read the document and provided guidance and comments as for to progress the work. If you are interested in reviewing the draft, please drop me an e-mail with copy to the chairs or send an e-mail to the list. The timescales for this review are not critical, but I would expect to finish the review around the time of IETF 57. Even if you are not committed to be a reviewer, I will invite you to take a look at some part of the draft and provide comments. /Miguel -------- Original Message -------- Subject: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt Date: Tue, 17 Jun 2003 07:56:08 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: aaa-wg@merit.edu A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Multimedia Application Author(s) : M. Belinchon et al. Filename : draft-belinchon-aaa-diameter-mm-app-01.txt Pages : 49 Date : 2003-6-16 This document specifies the Diameter Multimedia Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with the Session Initiation Protocol (SIP), and provides a Diameter client in a SIP server with the ability to request a Diameter server the authentication of users and authorization of SIP resources usage. This application does not require or is not related to other authentication services provided by the Mobile IP Diameter [7] or the Network Access Server Diameter [8] applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-belinchon-aaa-diameter-mm-app-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Tue Jun 17 11:22:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22388 for ; Tue, 17 Jun 2003 11:22:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8BC3912D0; Tue, 17 Jun 2003 11:22:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F675912D7; Tue, 17 Jun 2003 11:22: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 AB7F1912D0 for ; Tue, 17 Jun 2003 11:21:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96B865E032; Tue, 17 Jun 2003 11:21:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 4D74C5DDDE for ; Tue, 17 Jun 2003 11:21:51 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Jun 2003 11:21:50 -0400 Message-ID: From: Avi Lior To: "'Miguel A. Garcia'" , "'aaa-wg@merit.edu'" , "'Bernard Aboba'" Cc: =?iso-8859-1?Q?=27Mari_Carmen_Belinch=F3n=27?= , "'miguel.pallares@ericsson.com'" , "'carolina.canales-valenzuela@ece.ericsson.se'" , "'mccap@lucent.com'" , "'jaakko.rajaniemi@nokia.com'" , "'kalle.tammi@nokia.com'" Subject: RE: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-ap p-01.txt] Date: Tue, 17 Jun 2003 11:21:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22388 If you want I will be glad to review this document. However, I will not have any cycles until after June 30th. Please let me know. > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: June 17, 2003 10:59 AM > To: aaa-wg@merit.edu > Cc: Mari Carmen Belinchón; miguel.pallares@ericsson.com; > carolina.canales-valenzuela@ece.ericsson.se; > mccap@lucent.com; jaakko.rajaniemi@nokia.com; kalle.tammi@nokia.com > Subject: [AAA-WG]: [Fwd: I-D > ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt] > > > Hi: > > A new version of the Diameter Multimedia Application draft is > available in > the IETF repository. > > As you may recall, the document describes a new Diameter > application that > is designed to interact with SIP (Session Initiation Protocol). > > We have been re-writing several parts of the draft to add a > better wording > and understanding. We still are aware that work is needed in > several areas: > e.g., adding a Radius compatibility discussion, or adding > more a better > support on many other scenarios, particularly those not > related to 3GPP. > > At this stage, we are looking for volunteers that will be > have time to read > the document and provided guidance and comments as for to > progress the > work. If you are interested in reviewing the draft, please drop me an > e-mail with copy to the chairs or send an e-mail to the list. The > timescales for this review are not critical, but I would > expect to finish > the review around the time of IETF 57. > > Even if you are not committed to be a reviewer, I will invite > you to take a > look at some part of the draft and provide comments. > > /Miguel > > > > -------- Original Message -------- > Subject: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt > Date: Tue, 17 Jun 2003 07:56:08 -0400 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > CC: aaa-wg@merit.edu > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Diameter Multimedia Application > Author(s) : M. Belinchon et al. > Filename : draft-belinchon-aaa-diameter-mm-app-01.txt > Pages : 49 > Date : 2003-6-16 > > This document specifies the Diameter Multimedia Application. > This is a Diameter application that allows a Diameter client > to request authentication and authorization information. This > application is designed to be used in conjunction with the > Session Initiation Protocol (SIP), and provides a Diameter > client in a SIP server with the ability to request a Diameter > server the authentication of users and authorization of SIP > resources usage. This application does not require or is not > related to other authentication services provided by the > Mobile IP Diameter [7] or the Network Access Server Diameter > [8] applications. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diamet > er-mm-app-01.txt > > To remove yourself from the IETF Announcement list, send a > message to ietf-announce-request with the word unsubscribe in > the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username "anonymous" and a password of your e-mail > address. After logging in, type "cd internet-drafts" and then > "get draft-belinchon-aaa-diameter-mm-app-01.txt". > > A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Tue Jun 17 12:05:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24632 for ; Tue, 17 Jun 2003 12:05:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 155A6912C5; Tue, 17 Jun 2003 12:05:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4AA8912C6; Tue, 17 Jun 2003 12: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 04CB5912C5 for ; Tue, 17 Jun 2003 12:03:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAB765E016; Tue, 17 Jun 2003 12:03:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 360AA5DF0B for ; Tue, 17 Jun 2003 12:03:52 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5HG3XG5022423; Tue, 17 Jun 2003 18:03:33 +0200 (MEST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGLLMB6; Tue, 17 Jun 2003 18:03:28 +0200 Received: from ericsson.com by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA09906; Tue, 17 Jun 2003 18:03:23 +0200 Message-ID: <3EEF3BCB.8060808@ericsson.com> Date: Tue, 17 Jun 2003 19:03:23 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" Organization: Ericsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: es,en MIME-Version: 1.0 To: Avi Lior Cc: "'aaa-wg@merit.edu'" , "'Bernard Aboba'" , =?ISO-8859-1?Q?=27Mari_Carmen_Belinch=F3n=27?= , "'miguel.pallares@ericsson.com'" , "'carolina.canales-valenzuela@ece.ericsson.se'" , "'mccap@lucent.com'" , "'jaakko.rajaniemi@nokia.com'" , "'kalle.tammi@nokia.com'" Subject: Re: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-ap p-01.txt] References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi Avi: Thanks for volunteering as a reviewer, and welcome. Don't worry if you can't start the review until June 30th, it is not a problem. Regards, Miguel Avi Lior wrote: > If you want I will be glad to review this document. However, I will not > have any cycles until after June 30th. Please let me know. > > >>-----Original Message----- >>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: June 17, 2003 10:59 AM >>To: aaa-wg@merit.edu >>Cc: Mari Carmen Belinchón; miguel.pallares@ericsson.com; >>carolina.canales-valenzuela@ece.ericsson.se; >>mccap@lucent.com; jaakko.rajaniemi@nokia.com; kalle.tammi@nokia.com >>Subject: [AAA-WG]: [Fwd: I-D >>ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt] >> >> >>Hi: >> >>A new version of the Diameter Multimedia Application draft is >>available in >>the IETF repository. >> >>As you may recall, the document describes a new Diameter >>application that >>is designed to interact with SIP (Session Initiation Protocol). >> >>We have been re-writing several parts of the draft to add a >>better wording >>and understanding. We still are aware that work is needed in >>several areas: >>e.g., adding a Radius compatibility discussion, or adding >>more a better >>support on many other scenarios, particularly those not >>related to 3GPP. >> >>At this stage, we are looking for volunteers that will be >>have time to read >>the document and provided guidance and comments as for to >>progress the >>work. If you are interested in reviewing the draft, please drop me an >>e-mail with copy to the chairs or send an e-mail to the list. The >>timescales for this review are not critical, but I would >>expect to finish >>the review around the time of IETF 57. >> >>Even if you are not committed to be a reviewer, I will invite >>you to take a >> look at some part of the draft and provide comments. >> >>/Miguel >> >> >> >>-------- Original Message -------- >>Subject: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-01.txt >>Date: Tue, 17 Jun 2003 07:56:08 -0400 >>From: Internet-Drafts@ietf.org >>Reply-To: Internet-Drafts@ietf.org >>To: IETF-Announce: ; >>CC: aaa-wg@merit.edu >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >> >> >> Title : Diameter Multimedia Application >> Author(s) : M. Belinchon et al. >> Filename : draft-belinchon-aaa-diameter-mm-app-01.txt >> Pages : 49 >> Date : 2003-6-16 >> >>This document specifies the Diameter Multimedia Application. >>This is a Diameter application that allows a Diameter client >>to request authentication and authorization information. This >>application is designed to be used in conjunction with the >>Session Initiation Protocol (SIP), and provides a Diameter >>client in a SIP server with the ability to request a Diameter >>server the authentication of users and authorization of SIP >>resources usage. This application does not require or is not >>related to other authentication services provided by the >>Mobile IP Diameter [7] or the Network Access Server Diameter >>[8] applications. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diamet >>er-mm-app-01.txt >> >>To remove yourself from the IETF Announcement list, send a >>message to ietf-announce-request with the word unsubscribe in >>the body of the message. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username "anonymous" and a password of your e-mail >>address. After logging in, type "cd internet-drafts" and then >> "get draft-belinchon-aaa-diameter-mm-app-01.txt". >> >>A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 From owner-aaa-wg@merit.edu Wed Jun 18 05:56:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25507 for ; Wed, 18 Jun 2003 05:56:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DFADF91225; Wed, 18 Jun 2003 05:56:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB7309122A; Wed, 18 Jun 2003 05:56: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 5C44091225 for ; Wed, 18 Jun 2003 05:56:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40A705E08E; Wed, 18 Jun 2003 05:56:23 -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 8E60E5E08D for ; Wed, 18 Jun 2003 05:56:22 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5I9uL917268 for ; Wed, 18 Jun 2003 12:56:21 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Jun 2003 12:56:21 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:56:20 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:56:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue: Accounting-EAP-Auth-Method and expanded types Date: Wed, 18 Jun 2003 12:56:19 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB2B@esebe023.ntc.nokia.com> Thread-Topic: Issue: Accounting-EAP-Auth-Method and expanded types Thread-Index: AcM1f92qtESNH6N1R/eKkgGlWLOl/A== From: To: X-OriginalArrivalTime: 18 Jun 2003 09:56:20.0330 (UTC) FILETIME=[DE4E54A0:01C3357F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA25507 Accounting-EAP-Auth-Method and expanded types Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 18 Jun 2003 Reference: Document: EAP-01 Comment type: T Priority: 1 Section: 4.1.2 Rationale/Explanation of issue: Accounting-EAP-Auth-Method AVP is defined as Enumerated type. This is OK for normal EAP types (0-253,255), but it's not enough for Expanded types (see 2284bis, section 5.7). Proposed change: Change AVP type to Integer64, with Vendor-Type stored in least significant 32 bits, and Vendor-Id in the next 24 bits. Another possibility would be to simply ignore the existence of Expanded types, and just use "254" for them. Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jun 18 05:57:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25565 for ; Wed, 18 Jun 2003 05:57:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AA509122A; Wed, 18 Jun 2003 05:57:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 128D99122B; Wed, 18 Jun 2003 05:57: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 BFAC09122A for ; Wed, 18 Jun 2003 05:57:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF8345E09B; Wed, 18 Jun 2003 05:57:31 -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 CEEEC5DE35 for ; Wed, 18 Jun 2003 05:57:30 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5I9vU918766 for ; Wed, 18 Jun 2003 12:57:30 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Jun 2003 12:57:28 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:57:29 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:57:28 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:57:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue: How NAS sets Accounting-EAP-Auth-Method? Date: Wed, 18 Jun 2003 12:57:28 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB2C@esebe023.ntc.nokia.com> Thread-Topic: Issue: How NAS sets Accounting-EAP-Auth-Method? Thread-Index: AcM1gAa6pc1IOpeMT2KP4R5rPuOzVQ== From: To: X-OriginalArrivalTime: 18 Jun 2003 09:57:28.0686 (UTC) FILETIME=[070CA0E0:01C33580] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA25565 How NAS sets Accounting-EAP-Auth-Method? Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 18 Jun 2003 Reference: Document: EAP-01 Comment type: T Priority: 1 Section: - Rationale/Explanation of issue: Currently a pass-through NAS inspects only the Code, Identifier, and Length fields of EAP messages. If the NAS has to include the EAP authentication method in accounting messages, it has to also inspect the Type field. Also, since a typical EAP conversation will include at least two different types (Identity and something else), we need to specify how the value is chosen. Proposed change: One possible solution would be that the Accounting-EAP-Auth-Method AVP will be equal to the Type (or Expanded Type) field in the last Diameter-EAP-Request's EAP-Payload AVP. Or the Diameter server could give the value to use in the last (success) Diameter-EAP-Answer. Any other ideas? Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jun 18 05:58:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25588 for ; Wed, 18 Jun 2003 05:58:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E74AF9122B; Wed, 18 Jun 2003 05:58:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB3679122E; Wed, 18 Jun 2003 05:58: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 8110A9122B for ; Wed, 18 Jun 2003 05:58:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 613615E09B; Wed, 18 Jun 2003 05:58:02 -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 AF3D15E08D for ; Wed, 18 Jun 2003 05:58:01 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5I9w0919238 for ; Wed, 18 Jun 2003 12:58:00 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Jun 2003 12:57:59 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:57:59 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:57:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue: Maximum size of EAP messages Date: Wed, 18 Jun 2003 12:57:57 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB2D@esebe023.ntc.nokia.com> Thread-Topic: Issue: Maximum size of EAP messages Thread-Index: AcM1gBgJqO4yXSeLQyGoznxc5Z8gsw== From: To: X-OriginalArrivalTime: 18 Jun 2003 09:57:59.0280 (UTC) FILETIME=[1948E700:01C33580] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA25588 Maximum size of EAP messages Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 18 Jun 2003 Reference: Document: EAP-01 Comment type: T Priority: S Section: - Rationale/Explanation of issue: The EAP server may need to know the maximum size of EAP payload it can send, in order to produce fragments of correct size. Proposed change: Add new EAP-MTU AVP, sent in Diameter-EAP-Requests (I think we shouldn't re-use Framed-MTU AVP for this; the "framed MTU" of the link isn't necessarily the same as the maximum size of EAP message). Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jun 18 05:59:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25651 for ; Wed, 18 Jun 2003 05:59:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 099869122E; Wed, 18 Jun 2003 05:59:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B23F491278; Wed, 18 Jun 2003 05: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 733D99122E for ; Wed, 18 Jun 2003 05:59:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 662AD5E09B; Wed, 18 Jun 2003 05:59:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id B54B85E08E for ; Wed, 18 Jun 2003 05:59:03 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5I9x2a18312 for ; Wed, 18 Jun 2003 12:59:02 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Jun 2003 12:59:02 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:59:01 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:59:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue: How to signal invalid packets? Date: Wed, 18 Jun 2003 12:58:55 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB2E@esebe023.ntc.nokia.com> Thread-Topic: Issue: How to signal invalid packets? Thread-Index: AcM1gDpiaJ8PnI7wRHiJRb9D2+pd+g== From: To: X-OriginalArrivalTime: 18 Jun 2003 09:59:00.0747 (UTC) FILETIME=[3DEC05B0:01C33580] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA25651 How to signal invalid packets? Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 18 Jun 2003 Reference: Document: EAP-01 Comment type: T Priority: S Section: - Rationale/Explanation of issue: We need some way for the Diameter server to signal that "the EAP packet was invalid, please send the next one", similar to Error-Cause 202 "Invalid EAP Packet (Ignored)" in 2869bis. Diameter-EAP-Answer with an empty EAP-Payload AVP could be one choice. It would be sort of logical; Result-Code DIAMETER_MULTI_ROUND_AUTH means "authentication continues", and empty EAP-Payload would mean "I don't have anything new to send". However, then RADIUS->Diameter translation agents must keep a copy of the previous EAP Request... Another possibility would be to add a new AVP, say, EAP-Packet-Ignored (with empty data field). Any comments or ideas on this one? Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jun 18 06:05:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25807 for ; Wed, 18 Jun 2003 06:05:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1105A91227; Wed, 18 Jun 2003 06:02:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4CFD91278; Wed, 18 Jun 2003 06:02: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 6DB0C91227 for ; Wed, 18 Jun 2003 06:02:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 473EC5DF9A; Wed, 18 Jun 2003 06:02:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 985315DE74 for ; Wed, 18 Jun 2003 06:02:49 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5IA2ma22978 for ; Wed, 18 Jun 2003 13:02:48 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Jun 2003 12:55:25 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:55:25 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 12:55:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue: EAP-Payload AVP vs. EAP-Message attribute? Date: Wed, 18 Jun 2003 12:55:24 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB2A@esebe023.ntc.nokia.com> Thread-Topic: Issue: EAP-Payload AVP vs. EAP-Message attribute? Thread-Index: AcM1f7z2Iuo0cj6qROS+bH1VdNLFgQ== From: To: X-OriginalArrivalTime: 18 Jun 2003 09:55:25.0162 (UTC) FILETIME=[BD6C5CA0:01C3357F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA25807 (More issues to come -- I'm sending each issue in a separate message so as to make follow-ups easier) EAP-Payload AVP vs. EAP-Message attribute? Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 18 Jun 2003 Reference: Document: EAP-01 Comment type: T Priority: 2 Section: 4.1.1 Rationale/Explanation of issue: Is there some particular reason the Diameter AVP "EAP-Payload" has a different name and code than the RADIUS "EAP-Message" attribute? Or could we simply use the same name and code? (And specify that when translating RADIUS->Diameter, multiple attributes are concatenated to one AVP, and when doing Diameter->RADIUS, long AVP values are split to multiple attributes). Best regards, Pasi From owner-aaa-wg@merit.edu Wed Jun 18 12:59:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16032 for ; Wed, 18 Jun 2003 12:59:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0EBF9127E; Wed, 18 Jun 2003 12:59:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E8B59127F; Wed, 18 Jun 2003 12:59: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 8F30B9127E for ; Wed, 18 Jun 2003 12:59:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E25F5E0DA; Wed, 18 Jun 2003 12:59:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id DDAFC5E0D8 for ; Wed, 18 Jun 2003 12:59:02 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5IGYV914722; Wed, 18 Jun 2003 09:34:31 -0700 Date: Wed, 18 Jun 2003 09:34:30 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: EAP-Payload AVP vs. EAP-Message attribute? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB2A@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB2A@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Is there some particular reason the Diameter AVP "EAP-Payload" > has a different name and code than the RADIUS "EAP-Message" > attribute? Or could we simply use the same name and code? I think the reason that the code is different is because in RADIUS an attribute has very limited length and this is inconvenient for EAP since it requires the EAP packet to be broken up into multiple attributes. Therefore it would probably be better for Diameter to be able to include the entire EAP packet in one AVP. In general, if the RADIUS codes are reused then the attribute is assumed to be defined identically to RADIUS. From owner-aaa-wg@merit.edu Wed Jun 18 13:00:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16117 for ; Wed, 18 Jun 2003 13:00:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A420791281; Wed, 18 Jun 2003 12:59:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C621891282; Wed, 18 Jun 2003 12:59:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C40D69127F for ; Wed, 18 Jun 2003 12:59:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B37715E0D8; Wed, 18 Jun 2003 12:59:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 3BF725E0DA for ; Wed, 18 Jun 2003 12:59:44 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5IGZDX14757; Wed, 18 Jun 2003 09:35:13 -0700 Date: Wed, 18 Jun 2003 09:35:13 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: How to signal invalid packets? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB2E@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB2E@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Another possibility would be to add a new AVP, say, > EAP-Packet-Ignored (with empty data field). > > Any comments or ideas on this one? Could we use a Diameter Error message, and include no EAP-Payload AVP? From owner-aaa-wg@merit.edu Wed Jun 18 13:01:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16252 for ; Wed, 18 Jun 2003 13:01:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67825912D2; Wed, 18 Jun 2003 13:00:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD778912D3; Wed, 18 Jun 2003 13:00: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 C018291282 for ; Wed, 18 Jun 2003 13:00:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FB265E096; Wed, 18 Jun 2003 13:00:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 2BA585E0D7 for ; Wed, 18 Jun 2003 13:00:05 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5IGZZn14792; Wed, 18 Jun 2003 09:35:35 -0700 Date: Wed, 18 Jun 2003 09:35:35 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Accounting-EAP-Auth-Method and expanded types In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB2B@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB2B@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Proposed change: Change AVP type to Integer64, with > Vendor-Type stored in least significant 32 bits, and > Vendor-Id in the next 24 bits. This makes the most sense to me. From owner-aaa-wg@merit.edu Wed Jun 18 13:05:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16398 for ; Wed, 18 Jun 2003 13:05:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6936591283; Wed, 18 Jun 2003 13:05:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F177691285; Wed, 18 Jun 2003 13:05: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 52FF691283 for ; Wed, 18 Jun 2003 13:03:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D2285E05A; Wed, 18 Jun 2003 13:03:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 9D5F65DE0C for ; Wed, 18 Jun 2003 13:03:47 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5IGdGJ14978; Wed, 18 Jun 2003 09:39:17 -0700 Date: Wed, 18 Jun 2003 09:39:16 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: How NAS sets Accounting-EAP-Auth-Method? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB2C@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB2C@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Currently a pass-through NAS inspects only the Code, Identifier, > and Length fields of EAP messages. I think it might be more precise to say that it "only checks correctness and forwards based on the Code, Identifier and Length fields." > Also, since a typical EAP > conversation will include at least two different types (Identity > and something else), we need to specify how the value is chosen. Yes. > (or Expanded Type) field in the last Diameter-EAP-Request's > EAP-Payload AVP. Unfortunately, that would be likely to be EAP Success (no Type). > Or the Diameter server could give the value > to use in the last (success) Diameter-EAP-Answer. Any other ideas? I'd suggest that perhaps the Type is determined from the method in progress at the time the EAP Success was determined. The equivalent functionality is in RADIUS (See RFC 2548) so there must be a reliable way to do it somehow... From owner-aaa-wg@merit.edu Wed Jun 18 14:27:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19908 for ; Wed, 18 Jun 2003 14:27:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0BBB91284; Wed, 18 Jun 2003 14:27:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA30791287; Wed, 18 Jun 2003 14:27: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 D00F991284 for ; Wed, 18 Jun 2003 14:27:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A10CB5DD97; Wed, 18 Jun 2003 14:27:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 06AB65DDA6 for ; Wed, 18 Jun 2003 14:27:27 -0400 (EDT) Received: (cpmta 20040 invoked from network); 18 Jun 2003 11:27:24 -0700 Received: from 24.61.72.177 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 18 Jun 2003 11:27:24 -0700 X-Sent: 18 Jun 2003 18:27:24 GMT Message-Id: <5.2.1.1.2.20030618142539.03b14ec0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 18 Jun 2003 14:27:11 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: RE: Issue 402: NASREQ-11 Comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Note: This was posted by me originally on 5/11/2003 1:28am, between the notice on NASreq 12a updates, and the discussion of Issue 403. I didn't notice it missing until recently.... It was not being forwarded to the list because of a 50K size limit on forwarding. The list people have raised the limit to 100K. This is a revised repost. I've tried to shorten it anyways. Dave. ---------------- JARI: Comments marked with "JARI:" DJM: Responses marked with "DJM:" major snips to document marked with "..." Some more work is required, but I will whittle further discussions down to active paragraphs. JARI: We are nearing a state where this draft can be made an RFC. However, some work still remains. Some of the main comments: - Some keyword issues in, e.g., advertising, sending acct messages, ... - Some clarifications, e.g., should service still be provided while re-auth is going on, Accounting-Realtime-Required effects, Auth-Request default values, optionality of some AVPs in AAA/AAR requests, EVENT_RECORD, ... - Normative/informative nature of the old RADIUS AVP semantics needs clarification. - Some question marks on the semantics of the AVPs, but I'm not sure we can do much if the old RADIUS specifications apply in any case. - I'd prefer sections 9.1 and 9.1.1 to be more in the usual keyword style than in the current "example of steps that may be followed format". - AVP table inconsistencies wrt base. - Some additions to the security considerations may be needed, e.g. RADIUS translation. - Editorial corrections AAA Working Group Pat R. Calhoun Internet-Draft Black Storm Networks Category: Standards Track Glen Zorn Cisco Systems, Inc. David Spence Interlink Networks, Inc. David Mitton Circular Logic February 2003 Diameter Network Access Server Application draft-ietf-aaa-diameter-nasreq-11.txt Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 1.2. Advertising Application Support . . . . . . . . . . . . . . . 6 JARI: A terms section might be useful. NAS, ARAP, IPX, CHAP, PAP etc. DJM: Not sure it's necessary. Maybe at end. 2. NAS Calls, Ports, and Sessions . . . . . . . . . . . . . . . . . 6 JARI: Looking at the contents list, it might make sense to change the section titles from "NAS " to simply ""? What do you think? DJM: Current is a simplification from previous, every thing was NASREQ. JARI: And I still think the contents list should be more readable... oh well, maybe the RFC editor has to generate the contents list anyway and maybe they use some tool that generates nice looking, indented contents lists... Ok, I'll send you the script for that... DJM: received... Used this with winawk on the 12a draft. ... 1. Introduction This document describes Diameter applications that are used for AAA in the Network Access Server (NAS) environment. The Diameter NAS application, when combined with the Diameter base protocol [Base], Transport Profile [DiamTrans] EAP [DiamEAP], and CMS Security [DiamCMS] specifications, satisfies NAS-related requirements defined in RFC2989 [AAACriteria] and RFC3169 [NASCriteria]. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application was carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space, and eliminating the need to perform many attribute translations. This document first describes the operation of a Diamter NAS application. Then it defines the Diameter message Command-Codes. The following sections enumerate the AVPs used in these messages grouped by common usage. These are Session Identification, Authentication, Authorization, and Accounting. The Authorization JARI: s/, and/, Tunneling, and/ DJM: done JARI: An overall comment: Does it make sense to capitalize words like Authorization? I think the text would read better if it was just "authorization". But this is not my native language... DJM: done AVPs are further broken down by service type. Interaction and backwards compatibility issues with RADIUS are discussed in later sections. 1.1. Requirements Language In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [Keywords]. 1.2. Advertising Application Support Diameter nodes conforming to this specification MAY advertise support by including the value of one (1) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [Base]. JARI: Why is this a MAY? I realize that the support for NASREQ is a MAY, but if you support it why do we allow not advertising this fact? Or is this a configuration issue? DJM: Changed (also Bernard Issue 404, second item) I did not write this requirement, so I'm curious why it may have been this way for so long. 2. NAS Calls, Ports, and Sessions The arrival of a new call or service connection at a port of a Network Access Server (NAS) starts a Diameter NAS message exchange. Information about the call, the identity of the user, and his JARI: s/his/the user's/? - DJM:done authentication information are packaged into a Diameter AA-Request (AAR) message and sent to a server. ... 2.1. Diameter Session Establishment When the authentication or authorization exchange completes successfully, the NAS application SHOULD start a session context, and MAY send an Accounting START_RECORD message [Base]. The failure to JARI: The MAY above is a bit weak? Is this a configuration issue again, or are NASes generally allowed to skip accounting if they feel like it? ;-) DJM: Yes, I've reworded this per your later comments. Accounting should not be skipped if implemented, but the spec doesn't require the capability either. start a session SHOULD cause an Accounting EVENT_RECORD message. JARI: Is there an AVP which holds the type of failure? Or are all EVENT_RECORD messages for this particular error? DJM: It depends on the error. At this point I am worrying about message flow. Not AVP content. 2.2. Diameter Session Re-Authentication or Re-Authorization The Diameter protocol allows for users to be periodically re- authenticated and/or re-authorized. In such instances, the Session-Id AVP in the AAR message MUST be the same as the one present in the original authentication/authorization message. A Diameter server informs the NAS of the maximum time allowed before re-authentication or re-authorization via the Authorization-Lifetime AVP [Base]. Note, however, that the Authorization-Lifetime AVP SHOULD NOT be used if the AAR message contained a NAS-IP-Address, NAS-IPv6-Address, or NAS- Identifier AVP since this would mean that the NAS is using RADIUS which does not support server-initiated re-authentication or re- authorization. A NAS MUST re-authenticate and/or authorize after the period provided by the server. Furthermore, it is possible for Diameter servers to issue an unsolicited re-authentication and/or re-authorization by issuing an Re-Auth-Request message to the NAS. Upon receipt of such a message, the NAS is instructed to issue a request to re-authenticate and/or re-authorize the client. JARI: Is this always possible? I think it is possible on PPP, but perhaps there are other access types for which it might not be possible. Is re-auth possible on all types of WLAN links? DJM: Yes, this is weakly described. And yes it varies. Open issue JARI: While re-auth is going on, can service still be provided? DJM: Good question. I think it will be service specific. 2.3. Diameter Session Termination When a NAS receives an indication that a user's session is being disconnected (e.g. LCP Terminate is received), the NAS MUST issue a Session-Termination-Request (STR) [Base] to its Diameter Server. This will ensure that any resources maintained on the servers is freed appropriately. Further, a NAS that receives a Abort-Session-Request (ASR) [Base] MUST issue an STR if the session requested is active, and disconnect the PPP (or tunneling) session. Termination of the session context, MUST cause the sending of an Accounting STOP_RECORD message [Base], if accounting is active. JARI: Compare the above text to the MAY for sending the START_RECORD! Perhaps the above is the right text and something similar should be written also for START_RECORD. DJM: Done JARI: Shouldn't we somehow take in account also Accounting-Realtime-Required AVP from base? DJM: hmm... where is that AVP described? Base? More information on Diameter Session Termination is in [Base] section 8.4. ... 3.1. AA-Request (AAR) Command The AA-Request message (AAR), indicated by the Command-Code field set to 265 and the 'R' bit set in the Command Flags field, is used in order to request authentication and/or authorization for a given NAS user. The type of request is identified through the Auth-Request-Type AVP, and the default mode is both authentication and authorization. JARI: Default... hmm... does this mean Auth-Request-Type AVP is optional? Base 8.7 does not talk about this. Please clarify. Suggestion: don't talk about defaults. DJM: needs work/input - Still open If Authentication is requested the User-Name attribute SHOULD be present, as well as any additional authentication AVPs that would carry the password information. A request for authorization only SHOULD include the information from which the authorization will be performed, such as the User-Name, Called-Station-Id, or Calling- Station-Id AVPs. All requests SHOULD contain AVPs uniquely identifing JARI: s/identifing/identifying/ - DJM: done the source of the call, such as Origin-Host, and NAS-Port. Certain networks MAY use different AVPs for authorization purposes. A request for authorization will include some AVPs defined in section 6. ... 3.2. AA-Answer (AAA) Command The AA-Answer (AAA) message, is indicated by the Command-Code field set to 265 and the 'R' bit cleared in the Command Flags field, is sent in response to the AA-Request message. If authorization was requested, a successful response will include the authorization AVPs appropriate for the service being provided, as defined in section 6. For authentication exchanges that require more than a single round trip, the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY include one or more Reply-Message and MAY include zero or one State AVPs. If the Reply-Message AVP was present, the access device SHOULD display the text message to the user, and MUST prompt the user for a response. If the access device is unable to prompt the user for a new response, which could be achieved via PAP, it MUST treat this answer as an error, and deny access. JARI: s/access device/network access server/g ? (the term appears just in two places) - DJM: Rewritten JARI: In any case, the above paragraph is pretty confusing. At first, I read it as if the access device was the user's equipment, but it can't be because its the NAS that should be doing the access denial and other tasks. I believe what is meant here is that the NAS must be able to send a protocol message to the user's device which would result in a text message. Suggested rewrite: "If the Reply-Message AVP was present, the NAS SHOULD send a message to the client, instructing it to prompt the user for a response. This can be achieved via PAP in PPP, for instance. If the NAS is unable to achieve this, it MUST treat the AA-Answer with the Reply-Message AVP as an error, and deny access." DJM: done. Message Format ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Service-Type ] JARI: I don't understand how some of this information can be optional. How come Service-Type, for instance, is not always necessary? Or is the optionality due to the original RADIUS specifications? This comment may apply to AAR as well. DJM: Good observation, unfortunately it's due to the multiple uses of these messages. We don't segregate final from interim or partial, and some information is not appropriate in all situations. ... 4. NAS Session AVPs Diameter reserves the AVP Codes 0-255 for RADIUS functions that are implemented in Diameter. AVPs new to Diameter have code values 256 and greater. A Diameter message that includes one of these AVPs MAY cause interoperability JARI: s/AVPs MAY/AVPs represent functionality not present in RADIUS, and may/ DJM: ummm... well the RADIUS implementation may have the function, just in a different representation. Also at this time, it may be conceivable to have Diameter aware RADIUS implementations. I have "improved" this sentence along your suggestion. issues should the request traverse a AAA node that only supports the RADIUS protocol. However, the Diameter protocol should not be hampered from future developments due to the existing installed base. JARI: Delete the last sentence. DJM: well... I was looking at fixing it, but might as well - done. There are some RADIUS attributes that are not allowed or supported directly in Diameter. See section 9 below for more information. 4.1. Call and Session Information This section contains the NAS unique AVPs that are needed to identify JARI: s/NAS unique AVPs/AVPs specific to the NAS Diameter extension/ DJM: done. call and session context information, and allows the server to set constraints on a session. ... 4.4. NAS-Port-Type AVP The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and contains the type of the port on which the NAS is authenticating the user. This AVP SHOULD be present if the NAS uses the same NAS-Port number ranges for different service types concurrently. The supported values are defined in [RADIUSTypes]. The following list is informational: JARI: An overall comment on all old RADIUS attributes. Its good that the list below is marked as informational and the reference to the normative information is given. However, there seems to values and rules in this document that do not say this. E.g. connectinfo slash rules in 4.7. What is their status? Should we say somewhere that for any semantics about the RADIUS attributes, this document is informational and the normative definition can be found from the RADIUS specifications? Or is the intention that this specification too is normative here and we just have verified that there are no differences? DJM: Over the life of this document, there has been schizophrenic efforts to either include everything and ignore the past documents. Or defer everything to past documents. The former means that we duplicate everything (warts and all) and attempt to set the new bar. Problems of combatibility will result. The latter approach leaves a document full of pointers and difficultly in patching any of the old problems. The Normative/non-normative/Standards-Track/Informational wrinkles pop up here too. I have been attempting to balance the work, but pulling things forward but leaving pointers to where they came from. ... 4.7. Connect-Info AVP The Connect-Info AVP (AVP Code 77) is of type UTF8String and is sent in the AA-Request message, and indicates the nature of the user's connection. The connection speed SHOULD be included at the beginning of the first Connect-Info AVP in the message. If the transmit and receive connection speeds differ, they may both be included in the first AVP with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information. JARI: Is the space mandatory separator for the optional other information? DJM: ??? no ikling. The text is straight out of RFC2869 Actually not all of the original was lifted. I've added some more because of the 253+ attribute issue. This is one. For example, "28800 V42BIS/LAPM" or "52000/31200 V90" ... 5.2. Password-Retry AVP The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be included in the AA-Answer if the Result-Code indicates an authentication failure. The value of this AVP indicates how many authentication attempts a user may be permitted before being disconnected. This AVP is primarily intended for use when the Framed- Protocol AVP (see Section 6.9.1) is set to ARAP. JARI: I don't understand why Pwd-Rtr is related to ARAP only. DJM: This attribute was defined in sect 5.9 of RFC2869 for ARAP. We could generalize it, are you making a request? 5.3. Prompt AVP The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be present in the AA-Answer message. When present, it is used by the NAS to determine whether the user's response, when entered, should be echoed. The supported values are listed in [RADIUSTypes]. The following list is informational: 0 No Echo 1 Echo JARI: Hmm... this doesn't seem to apply to all service types. Or? DJM: This section doesn't segregate by service types or give all possible combinations. ... 6.1. Service-Type AVP The Service-Type AVP (AVP Code 6) is of type Enumerated and contains the type of service the user has requested, or the type of service to be provided. One such AVP MAY be present in an authentication and/or authorization request or response. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though a response with a Result-Code other than Diameter-SUCCESS had been received instead. JARI: s/Diameter-SUCCESS/DIAMETER_SUCCESS/g DJM: Done. 2 Occurances found When used in a request, the Service-Type AVP SHOULD be considered to be a hint to the server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint. The following values have been defined for the Service-Type AVP: JARI: Question: If the user connects through some protocol, such as PPP, how can it be changed to something else if the server decides to send back something else? I think it is possible in some cases, but not in general. Perhaps some words are needed to explain that the NAS may disconnect the user if it can't start the service in the given situation, even if it does support it. DJM: Not sure. The situation you describe is more of a configuration/situation error. If the service only supports particular methods of connection, then using others should not be assumed to be successful. If a mode shift is not possible, then the service should fail the connection, and that is the disconnect mechanism. In any case, I have added the following: Furthermore, if the service specified by the server is supported, but not compatible with the current mode of access, the NAS MUST fail to start the session. It must also generate the appropriate error message(s). The complete list of defined values can be found in [RADIUS] and [RADIUSTypes]. The following list is informational: ... 6.2. Callback-Number AVP The Callback-Number AVP (AVP Code 19) is of type UTF8String, and contains a dialing string to be used for callback. It MAY be used in an authentication and/or authorization request as a hint to the server that a Callback service is desired, but the server is not required to honor the hint in the corresponding response. JARI: I don't understand how the client would know the callback number. Or is this a copy of the calling number avp? DJM: There are many (too many!) types of callback. Some clients know the desired number (it may not to be initiating system!) and some callback servers allow this. The codification of the range of allowed usage of this field is outside the scope of this specification. ... 6.4. Idle-Timeout AVP The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. It MAY be used in an authentication and/or authorization request (or challenge) as a hint to the server that an idle timeout is desired, but the server is not required to honor the hint in the corresponding response. JARI: Default is? DJM: The default is none, or system specific. ... 6.10. IP Access The AVPs defined in this section are used when the user requests, or is being granted, access to IP. They are only present if the Framed- Protocol AVP (see Section 6.9.1) is set to PPP, SLIP, Gandalf proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. JARI: Add space after "proprietary" - DJM: Done. ... 7.3. Tunnel-Client-Endpoint AVP ... If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST JARI: s/Conformant/Conforming/? DJM: delete the word, "Implementations MUST..." support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag referring to configuration data local to the Diameter client that describes the interface and medium-specific address to use. 7.4. Tunnel-Server-Endpoint AVP The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String, and contains the address of the server end of the tunnel. It MAY be used in an authorization request as a hint to the server that a specific endpoint is desired, but the server is not required to honor the hint in the corresponding response. This AVP SHOULD be included in the corresponding Accounting-Request messages, in which case it indicates the address from which the tunnel was initiated. This AVP, along with the Tunnel-Client-Endpoint and Session-Id AVP [Base], MAY be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. JARI: I find the SHOULD troubling for interoperability. If a NAS gets the TSE AVP from the server in FQDN format, what should it do? DJM: there was a time when a lightweight NAS may not implement a DNS client. If it cannot support it, it barfs (in the technical sense). The Session setup fails, the service is not provided, errors are logged. Users curse and admins figure how to to provision so it works within the capabilities of the NAS. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag referring to configuration data local to the Diameter client that describes the interface and medium-specific address to use. ... 7.6. Tunnel-Private-Group-Id AVP The Tunnel-Private-Group-Id AVP (AVP Code 81) is of type UTF8String, and contains the group Id for a particular tunneled session. The Tunnel-Private-Group-Id AVP MAY be included in an authorization request if the tunnel initiator can pre-determine the group resulting from a particular connection and SHOULD be included in the authorization response if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it MAY be used to facilitate routing of unregistered IP addresses through a particular interface. This AVP SHOULD be included in the Accounting-Request messages which pertain to the tunneled session. JARI: I understand the treatment at DIAMETER level for this AVP, but I couldn't implement anything based on the above explanation for actually using the group information. A particular interface may be used but is not required, for instance. DJM: ummm... and your point? ;-) This attribute comes from RFC 2868 and is used to (excuse me if I don't get it technically right) to join individual links into an existing or desired group, via a specified connection point. Not all tunnel implementations or configurations, support this concept or capability, hence it's non-requiredness. I'm fairly certain that there are running uses of this (but I didn't write one either). ... 8. NAS Accounting Applications implementing this specification use Diameter Accounting as defined in the Base [Base] with the addition of the AVPs in the following section. Accounting Request messages (ACR) SHOULD be sent after any JARI: Earlier in the document there was some confusion about when accounting messages should be sent. DJM: this requires a bit more work, more comments below. This stems from the lack of desire or work wanting to be put into an overall description of A//accounting. Authentication or Authorization transaction and at the end of a Session. The Accounting-Record-Type value indicates the type of event. All other AVPs identify the session and provide additional information relevant to the event. If Authentication and Authorization are contained in one message (typical case), then one START_RECORD should be sent. If Authentication and Authorization occur in seperate transactions, the JARI: s/seperate/separate/g - DJM: done. first message should generate a START_RECORD, and the later, an INTERIM_RECORD. For a given session, there should only be one set of matching START and STOP records, with any number of INTERIM_RECORDS in between, or one EVENT_RECORD. JARI: Compare to Section 2.1. I'm not sure I understand what "failure to start a session" exactly means, but let's assume we do a successful authentication, successful authorization, and the "fail to start a session". It would be incorrect in this case to send START_RECORD, INTERIM_RECORD, EVENT_RECORD, as seems to be indicated by 2.1. Suggestion: make 2.1 inline with the text here. DJM: Okay, it's sort of fuzzy, as you're beginning to see. Most NAS type applications do Authentication/Authorization in one exchange. So a session "starts" cleanly on receipt of the AAA. But thanks to the flexibility of Diameter this can get drawn out. In practice, we have a session context that is initialized at the time of the call "pickup" and it gets filled in as we progress, until we have enough to deliver the service or not. It's at that point that we fail or "start" service. We got in trouble in RADIUS because some NASes would issue a Acct-Start on a PPP session before NCP finished, and could not tell you the IP addr of the user system. Others would delay for that, which in turn drives the real-time people crazy. So I agree, we should define Accounting messages linked to specific protocol events to eliminate some implementation confusion. (there will be other forms of confusion that arise) This will take some more wordsmithing and proper sequence construction. -- Open Issue ... 9. RADIUS/Diameter Protocol Interactions This section describes some basic guidelines that may be used by servers that act as AAA Translation Agents. A complete description of all the differences between RADIUS and Diameter is beyond the scope of this section and document. Note that this document does not restrict implementations from creating additional methods, as long as the translation function doesn't violate the RADIUS or the Diameter protocols. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| NAS-Identifier 32 9.2.1 UTF8String | M | P | | V | Y | NAS-IP-Address 4 9.2.2 OctetString| M | P | | V | Y | NAS-IPv6-Address 95 9.2.3 OctetString| M | P | | V | Y | State 24 9.2.4 OctetString| M | P | | V | Y | Termination- 295 9.2.5 Enumerated | M | P | | V | Y | Cause | | | | | | -----------------------------------------|----+-----+----+-----|----| JARI: This table is not explained by the nearby text. DJM: Every major section has a table of Diameter AVPs in it. I will add this sentence: The following Diameter AVPs pertain to RADIUS interactions and are described in this section: There are primarily two different situations that must be handled; one where a RADIUS request is received that must be forwarded as a Diameter request, and the inverse. RADIUS does not support a peer- to-peer architecture and server initiated operations are generally not supported. See [RADDynAuth] for an alternative. Some RADIUS attributes are encrypted. RADIUS security and encryption techniques are applied on a hop-per-hop basis. A Diameter agent will have to decrypt RADIUS attribute data entering the Diameter system and if that information is forwarded, MUST secure it using Diameter specific techniques. Note that this section uses the two terms; AVP and attribute in a consise manner. The former is used to signify a Diameter AVP, while JARI: Replace the first sentence with "Note that this section uses two different terms, AVP and attribute." DJM: Not sure the improvement you were after. How about this: Note that this section uses the two terms; "AVP" and "attribute" in a concise and specific manner. The former is used to signify a Diameter AVP,... the latter is used to signify a RADIUS attribute. ... The corresponding Diameter response is always guaranteed to be received by the same Translation Agent that translated the original request, due to the contents of the Origin-Host AVP in the Diameter request. The following steps are applied to the response message during the Diameter to RADIUS translation: - If the Diameter Command-Code is set to AA-Answer and the Result- Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must send a RADIUS Access-Challenge with the Diameter Session-Id and the Origin-Host AVPs encapsulated in the RADIUS State attribute, with the prefix "Diameter/". This is necessary in order to ensure that the Translation Agent that will receive the subsequent RADIUS Access-Request will have access to the Session Identifier, and be able to set the Destination-Host to the correct value. If the Multi-Round-Time-Out AVP is present, the value of the AVP MUST be inserted in the RADIUS Session-Timeout AVP. - If the Command-Code is set to AA-Answer, the Diameter Session-Id AVP is saved in a new RADIUS Class attribute, whose format consists of the string "Diameter/" followed by the Diameter Session Identifier. This will ensure that the subsequent Accounting messages, which could be received by any Translation Agent, would have access to the original Diameter Session Identifier. - If a Proxy-State attribute was present in the RADIUS request, the same attribute is added in the response. This information may be found in the Proxy-Info AVP group, or in a local state table. - If state information regarding the RADIUS request was saved in a Proxy-Info AVP or local state table, the RADIUS Identifier and UDP IP Address and port number are extracted and used in issuing the RADIUS reply. JARI: Question: Does the above rules work even in a situation where there's been a change to another translation agent due to load balancing or a fault? DJM: Groan... I don't know, I didn't design this part - Open Issue 9.1.1. Diameter Request Forwarded as RADIUS Request JARI: This should be 9.2 not a subsection of RADIUS->DIAMETER! DJM: whoops, must fix table or two and some cross references then When a server receives a Diameter request that is to be forwarded to a RADIUS entity, the following steps are an example of the steps that may be followed: JARI: "... example of the steps that may be followed... " are we sure that we can't create normative keyword language for these operations? - The Origin-Host AVP's value is inserted in the NAS-Identifier attribute. - The following information MUST be present in the corresponding Diameter response, and therefore MUST be saved either in a local state table, or it MAY be encoded in a RADIUS Proxy-State attribute: 1. Origin-Host AVP 2. Session-Id AVP 3. Proxy-Info AVP 4. Route-Record AVPs (in the proper order) 5. Any other AVP that MUST be present in the response, and has no corresponding RADIUS attribute. - If the CHAP-Auth AVP is present, the grouped AVPs are used to create the RADIUS CHAP-Password attribute data. - If the User-Password AVP is present, the data should be encrypted using RADIUS rules. Likewise for any other encrypted attribute values. - AVPs that are of the type Address, must be translated to the corresponding RADIUS attribute. - If the Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets or Accounting-Output-Packets AVPs are present, these must be translated to the corresponding RADIUS attributes. Further, the value of the Diameter AVPs do not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input- Gigawords and Acct-Output-Gigawords must be used. - If the RADIUS link supports the Message-Authenticator attribute [RADIUSExt] it SHOULD be generated and added to the request. When the corresponding response is received by the Translation Agent, which is guaranteed in the RADIUS protocol, the following steps may be followed: - If the RADIUS code is set to Access-Challenge, a Diameter AA- Answer message is created with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present in the RADIUS message, its value is inserted in the Multi-Round- Time-Out AVP. - If a Proxy-State attribute is present, extract the encoded information, otherwise retrieve the original Proxy-Info AVP group information from the local state table. - The request's Origin-Host information is added to the Destination-Host AVP. - The Acct-Session-Id information is added to the Session-Id AVP. - The Route-Record AVPs MUST be added to the Diameter message, in the same order they were present in the request. - If a Proxy-Info AVP was present in the request, the same AVP MUST be added to the response. - If the RADIUS State attributes are present, these attributes must be present in the Diameter response. - Any other AVPs that were saved, and MUST be present in the response, are added to the message. 9.2. AVPs Used Only for Compatibility ... 9.2.4. State AVP The State AVP (AVP Code 24) [RADIUS] is of type OctetString and has two uses in the Diameter NAS application. The State AVP MAY be sent by a Diameter Server to a NAS in an AA- Response command that contains a Result-Code of DIAMETER_MULTI_ROUND_AUTH. If so, the NAS MUST return it unmodified in the subsquent AA-Request command. JARI: s/subsquent/subsequent/g - DJM: done. ... 9.3. Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT be transfered to a Diameter message. Many of these are discussed in section 9.1. JARI: I spent some time reading the previous sections and trying to figure out what "transferred" meant above. Apparently, it means that they must not appear in a diameter message and must be translated instead to some other Diameter AVPs. They are not completely forbidden. Suggested reformulation: "The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1 and 9.5." DJM: Excellent, done. modulo section reference changes Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets ... 10.1. AA-Request/Answer AVP Table The table in this section is limited to the Command Codes defined in this specification. JARI: I don't understand the above comment. Remove? DJM: Sorry, had to add that to fend off someone else's problem with this table. Perhaps I need to spend more/different text on this. ... 10.2.1. Accounting Framed Access AVP Table The table in this section is used when the Service-Type specifies Framed Access. +-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-Application-Id | 0-1 | 0-1 | JARI: No such AVP in base or nasreq... DJM: Yes, but there probably was at one time, and there is an Acct-Application-Id also listed below. Seems to be an editing error. Most Diameter Accounting AVPs spell out "Accounting" but this one is of the few exceptions. Accounting-Input-Octets | 1 | 0 | Accounting-Input-Packets | 1 | 0 | Accounting-Output-Octets | 1 | 0 | Accounting-Output-Packets | 1 | 0 | Accounting-Record-Type | 1 | 1 | Accounting-Record-Number | 0-1 | 0-1 | Accounting-Realtime-Required | 0-1 | 0 | Accounting-Sub-Session-Id | 0-1 | 0-1 | Acct-Application-Id | 0-1 | 0-1 | JARI: I don't fully understand the construction of this table vs. the one in the base spec. The above attribute, for instance, is included but not discussed in this specification. But some other base attributes such as Auth-Application-Id are not included. Is this an old version of the base table, with the NASREQ additions? May I suggest taking a new version from base-17...? DJM: ...moving targets aren't always hit. (or stay hit) I checked everything against Base-16? at the time. If there are further changes, I need to know. The BASE does not describe this application, I must. This application uses Base AVPs, how it uses them (not what they are) must be described here, even if it's just an inclusion that says it's allowable. I guess more verbage is required to make these tables self explanatory. ... 11.2. AVP Codes This specification assigns the values 363-366 and 400-405 from the AVP Code namespace defined in [Base]. See sections 4, and 5 for the assignment of the namespace in this specification. Note that the values 363-366 are jointly, but consistently, assigned in [DiamMIP]. This specification also specifies the use of AVPs in the 0-255 range, which are defined in [RADIUSTypes]. These values are assigned by the policy in RFC 2865 Section 6. [RADIUS] JARI: I can't find a statement either in this document or in the base that would say something about the attribute lengths for the 0-255 AVPs. Presumably, 253 bytes may not be exceeded, or at least if it is, translation agents will fail? No wait... 9.4 has some text. But unfortunately it doesn't describe for which attributes the concatenation approach is possible. Add a list there. DJM: grrr... okay, but this is getting near exceding the scope of this document. I cannot re-document RADIUS. 11.3. Application Identifier ... 12. Security Considerations The security considerations of the Diameter protocol itself have been discussed in [Base]. This document does not contain a security protocol, but does discuss how PPP authentication protocols can be carried within the Diameter protocol. The PPP authentication protocols that are described are PAP and CHAP. The use of PAP SHOULD be discouraged, since it exposes user's passwords to possibly non-trusted entities. However, PAP is also frequently used for use with One-Time Passwords (OTP), which do not expose a security risk. This document also describes how CHAP can be carried within the Diameter protocol, which is required for RADIUS backward compatibility. The CHAP protocol, as used in a RADIUS environment, facilitates authentication replay attacks. JARI: Any references to the attacks discussed above? JARI: Maybe there should be some discussion of what it implies if authorization-only AAA requests are made, and in which cases such usage is safe. DJM: Submissions are welcome. JARI: What are the security impacts of RADIUS-DIAMETER translation? Are all or only some of the known radius vulnerabilities carried onto DIAMETER in such a setup? See reference "Joshua Hill. An Analysis of the RADIUS Authentication Protocol. http://www.untruth.org/~josh/security/radius/, 2001." DJM: I have read that document in the past, however, we have tried to document the Diameter NAS Application protocol in this document, and avoided including a full treatis on Diameter/RADIUS how-to build a gateway. This really requires another document. If I could make it relate to my job (what's that?) I'd write it myself. ... Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to per- tain to the implementation or use of the technology described in this JARI: Why does this section have hyphenation on??? DJM: It does not. However, the source text was cut and pasted from another document which had the one split word. Identification of the source is an exercise left to the reviewer. (hint: ends in -17) ((and certainly don't look at the Full Copyright statement in that document, it has 3 hypenated split words) ... From owner-aaa-wg@merit.edu Wed Jun 18 14:51:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20941 for ; Wed, 18 Jun 2003 14:51:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E280F91287; Wed, 18 Jun 2003 14:50:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABF5291288; Wed, 18 Jun 2003 14:50: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 756A591287 for ; Wed, 18 Jun 2003 14:50:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E65F5DDB2; Wed, 18 Jun 2003 14:50:54 -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 6EE565DD9F for ; Wed, 18 Jun 2003 14:50:53 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5IIoq922238 for ; Wed, 18 Jun 2003 21:50:52 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 21:50:52 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 21:50:52 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 21:50:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue: How NAS sets Accounting-EAP-Auth-Method? Date: Wed, 18 Jun 2003 21:50:50 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222A4@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: How NAS sets Accounting-EAP-Auth-Method? Thread-Index: AcM1u5X4rxQMJI7kS3GqgbZSIUR08QADNx0g From: To: Cc: X-OriginalArrivalTime: 18 Jun 2003 18:50:51.0492 (UTC) FILETIME=[8A354A40:01C335CA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20941 Bernard Aboba wrote: > > (or Expanded Type) field in the last Diameter-EAP-Request's > > EAP-Payload AVP. > > Unfortunately, that would be likely to be EAP Success (no Type). The last Diameter-EAP-Answer of course contains an EAP Success, but the last Diameter-EAP-Request probably contains an EAP Response of the correct type, right? > > Or the Diameter server could give the value > > to use in the last (success) Diameter-EAP-Answer. Any other ideas? > > I'd suggest that perhaps the Type is determined from the method in > progress at the time the EAP Success was determined. The equivalent > functionality is in RADIUS (See RFC 2548) so there must be a > reliable way to do it somehow... Thanks for the pointer, I hadn't noticed that RFC 2548 includes a similar attribute (MS-Acct-EAP-Type). Best regards, Pasi From aaa-admin@ietf.org Thu Jun 19 09:44:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17640 for ; Thu, 19 Jun 2003 09:44:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szho-0000zT-Ky; Thu, 19 Jun 2003 09:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szh9-0000up-RL for aaa@optimus.ietf.org; Thu, 19 Jun 2003 09:43:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17583 for ; Thu, 19 Jun 2003 09:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szeq-0004Gi-00 for aaa@ietf.org; Thu, 19 Jun 2003 09:40:56 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19Szep-0004Ga-00 for aaa@ietf.org; Thu, 19 Jun 2003 09:40:55 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 683ED33F79 for ; Thu, 19 Jun 2003 15:42:44 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 92B563F423 for ; Thu, 19 Jun 2003 15:52:31 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003061915424332611 for ; Thu, 19 Jun 2003 15:42:43 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id 76AF53F423 for ; Thu, 19 Jun 2003 15:52:31 +0200 (CEST) Received: from PAT3976 (unknown [157.159.100.238]) by molure.int-evry.fr (Postfix) with SMTP id 2E448C217C for ; Thu, 19 Jun 2003 15:42:44 +0200 (CEST) Message-ID: <003d01c33668$d362c4b0$ee649f9d@intevry.fr> From: "wassef louati" To: Date: Thu, 19 Jun 2003 15:43:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C33679.96E700D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Aaa] Diameter Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C33679.96E700D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm working in Diameter Protocol. I use this protocol to make = communication between 2 Diffserv domain,that's way I was defined a new = Diameter Application that I was named 'Diameter Diffserv Application'. So,can you help me to developp this idea. thanks wassef ------=_NextPart_000_003A_01C33679.96E700D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I'm working in = Diameter=20 Protocol. I use this protocol to make communication between 2 Diffserv=20 domain,that's way I was defined a new Diameter Application that I was = named=20 'Diameter Diffserv Application'.

So,can you help = me to=20 developp this idea.

thanks

wassef
------=_NextPart_000_003A_01C33679.96E700D0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Jun 19 09:44:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17654 for ; Thu, 19 Jun 2003 09:44:46 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDiJU03907 for aaa-archive@odin.ietf.org; Thu, 19 Jun 2003 09:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szi7-00010v-1c for aaa-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 09:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17611 for ; Thu, 19 Jun 2003 09:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szfo-0004HK-00 for aaa-web-archive@ietf.org; Thu, 19 Jun 2003 09:41:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Szfn-0004HF-00 for aaa-web-archive@ietf.org; Thu, 19 Jun 2003 09:41:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szho-0000zT-Ky; Thu, 19 Jun 2003 09:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Szh9-0000up-RL for aaa@optimus.ietf.org; Thu, 19 Jun 2003 09:43:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17583 for ; Thu, 19 Jun 2003 09:43:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Szeq-0004Gi-00 for aaa@ietf.org; Thu, 19 Jun 2003 09:40:56 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19Szep-0004Ga-00 for aaa@ietf.org; Thu, 19 Jun 2003 09:40:55 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 683ED33F79 for ; Thu, 19 Jun 2003 15:42:44 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 92B563F423 for ; Thu, 19 Jun 2003 15:52:31 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003061915424332611 for ; Thu, 19 Jun 2003 15:42:43 +0200 Received: from molure.int-evry.fr (molure.int-evry.fr [157.159.10.18]) by sparte.int-evry.fr (Postfix) with ESMTP id 76AF53F423 for ; Thu, 19 Jun 2003 15:52:31 +0200 (CEST) Received: from PAT3976 (unknown [157.159.100.238]) by molure.int-evry.fr (Postfix) with SMTP id 2E448C217C for ; Thu, 19 Jun 2003 15:42:44 +0200 (CEST) Message-ID: <003d01c33668$d362c4b0$ee649f9d@intevry.fr> From: "wassef louati" To: Date: Thu, 19 Jun 2003 15:43:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C33679.96E700D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Aaa] Diameter Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C33679.96E700D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm working in Diameter Protocol. I use this protocol to make = communication between 2 Diffserv domain,that's way I was defined a new = Diameter Application that I was named 'Diameter Diffserv Application'. So,can you help me to developp this idea. thanks wassef ------=_NextPart_000_003A_01C33679.96E700D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I'm working in = Diameter=20 Protocol. I use this protocol to make communication between 2 Diffserv=20 domain,that's way I was defined a new Diameter Application that I was = named=20 'Diameter Diffserv Application'.

So,can you help = me to=20 developp this idea.

thanks

wassef
------=_NextPart_000_003A_01C33679.96E700D0-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Thu Jun 19 10:11:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19867 for ; Thu, 19 Jun 2003 10:11:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 711FE9121E; Thu, 19 Jun 2003 10:11:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36DEE91233; Thu, 19 Jun 2003 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 BD5219121E for ; Thu, 19 Jun 2003 10:11:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A15495DF34; Thu, 19 Jun 2003 10:11:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id BDFC35DEFF for ; Thu, 19 Jun 2003 10:11:40 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5JEBda25752 for ; Thu, 19 Jun 2003 17:11:39 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 19 Jun 2003 17:11:38 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 17:11:38 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 17:11:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue: Key AVPs + security considerations Date: Thu, 19 Jun 2003 17:11:37 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB34@esebe023.ntc.nokia.com> Thread-Topic: Issue: Key AVPs + security considerations Thread-Index: AcM2bLLUEPzDT7fISmy5y4Dy1NFB2Q== From: To: X-OriginalArrivalTime: 19 Jun 2003 14:11:38.0344 (UTC) FILETIME=[B2F78680:01C3366C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19867 Hi, Here's an issue related to keying AVPs. I'm working on the security considerations section, and will post something here early next week. However, it seems that many (most?) of the security considerations are not actually EAP-specific but apply also to NASREQ. How should this be handled? (NASREQ-11 doesn't have much security considerations) BTW, if somebody is interested in intermediate versions, I'm posting them on a web page every now and then: http://www.cs.hut.fi/~peronen/eap/diameter_eap.html Best regards, Pasi Key AVPs Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: 19 Jun 2003 Reference: Document: EAP-01 Comment type: T Priority: 1 Section: various Rationale/Explanation of issue: What should the AVPs for transporting keys look like? Here are some alternatives for starting a discussion: Alternative 1: EAP-Master-Session-Key (OctetString) Pros/cons: + Simple + Does not try to solve all keying problems forever, but just enough for EAP. + Consistent with 2284bis + The Diameter server doesn't have to know what the key is used for - The Diamater server doesn't know what the key is used for - New AVPs may be needed for more complex needs in the future (but if we don't know them yet, we can define them later). Alternative 2: From old NASREQ-09: NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key-Data } { NAS-Key-Binding } | [ NAS-Key-Lifetime ] [ NAS-IV ] * [ AVP ] NAS-Key-Direction: (BIDIRECTIONAL, UPLINK, DOWNLINK) NAS-Key-Type: (CIPHER_KEY, INTEGRITY_KEY, MASTER_CIPHER_KEY, MASTER_INTEGRITY_KEY, MASTER_KEY) NAS-Key-Binding: (DES, 3DES, RC4-40, RC4-128) Pros/cons. - The Key-Type/Binding is complex, but it still can't specify even something simple like "use this key for 802.11i PMK" -- a BIDIRECTIONAL,MASTER_KEY could be used for some other purpose! - Including a list of ciphers here is probably not a good idea. Alternative 3: EAP-Session-Key ::= < AVP Header: TBD > { EAP-Key-Type } 1* { EAP-Key-Data } * [ AVP ] EAP-Key-Type is of type Enumerated, with the following values assigned: IEEE_802_11I_PAIRWISE_MASTER_KEY (1) A single EAP-Key-Data AVP contains the Pairwise Master Key to be used in 802.11i four-way handshake. IEEE_802_11_WEP_KEY (2) A single EAP-Key-Data AVP contains the 802.11 WEP key (TBD: is this correct?). MS_MPPE_KEYS (3) Two EAP-Key-Data AVPs included, first containing the downlink (send) key, and the second the uplink (recv) key. IKE_V2_AUTH_KEY (4) A single EAP-Key-Data AVP contains the MSK for IKEv2 authentication. PANA_something (5) To be defined when PANA progresses. Pros/cons: + Simple binding, extensible - ? Alternative 4: Like 3, but instead of creating a new Enumeration namespace, just use the AVP namespace. That is, create four new AVPs: IEEE-802-11i-Pairwise-Master-Key IEEE-802-11-WEP-Key MS-MPPE-Keys IKEv2-Auth-Key Pros/cons: + Grouped AVPs can include other stuff, like encryption policies for MPPE, or allowed cipher algorithms, etc. + Any new use for EAP will probably require a spec saying how it is used with RADIUS/Diameter anyway (e.g. we will soon need a "IKEv2 RADIUS/Diameter Usage Guidelines" document, similar to the existing "IEEE 802.1X RADIUS Usage Guidelines") + New keying AVPs can be defined using the normal ABNF syntax. + New AVP required for new key uses -- it's a good thing if they keys can't be used for other purposes too easily. - New AVP required for new key uses. From aaa-admin@ietf.org Thu Jun 19 10:59:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22982 for ; Thu, 19 Jun 2003 10:59:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sP-0005Tk-D1; Thu, 19 Jun 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sF-0005SZ-Cx for aaa@optimus.ietf.org; Thu, 19 Jun 2003 10:58:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22887 for ; Thu, 19 Jun 2003 10:58:47 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0pv-00058T-00 for aaa@ietf.org; Thu, 19 Jun 2003 10:56:28 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19T0pv-00058Q-00 for aaa@ietf.org; Thu, 19 Jun 2003 10:56:27 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5JEwk920954 for ; Thu, 19 Jun 2003 17:58:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 17:58:43 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 17:58:45 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 17:58:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Aaa] Diameter Date: Thu, 19 Jun 2003 17:58:40 +0300 Message-ID: Thread-Topic: [Aaa] Diameter Thread-Index: AcM2cntWlv3EAnO2QFKX/KA9AIHZXQAAIztg To: , X-OriginalArrivalTime: 19 Jun 2003 14:58:41.0130 (UTC) FILETIME=[457A7CA0:01C33673] Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22982 Hi Wassef, This sounds close to what some people have proposed in the NSIS working group. I wonder how much your needs are really related to AAA but more some sort of SLA negotiation protocol (which some people in the NSIS working group are interested in. John -----Original Message----- From: ext wassef louati [mailto:wassef.louati@int-evry.fr] Sent: 19 June, 2003 16:44 To: aaa@ietf.org Subject: [Aaa] Diameter Hi, I'm working in Diameter Protocol. I use this protocol to make communication between 2 Diffserv domain,that's way I was defined a new Diameter Application that I was named 'Diameter Diffserv Application'. So,can you help me to developp this idea. thanks wassef _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Thu Jun 19 10:59:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22997 for ; Thu, 19 Jun 2003 10:59:37 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JExBS21211 for aaa-archive@odin.ietf.org; Thu, 19 Jun 2003 10:59:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sZ-0005W2-A2 for aaa-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 10:59:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22906 for ; Thu, 19 Jun 2003 10:59:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0qF-000593-00 for aaa-web-archive@ietf.org; Thu, 19 Jun 2003 10:56:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T0qF-000590-00 for aaa-web-archive@ietf.org; Thu, 19 Jun 2003 10:56:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sP-0005Tk-D1; Thu, 19 Jun 2003 10:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0sF-0005SZ-Cx for aaa@optimus.ietf.org; Thu, 19 Jun 2003 10:58:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22887 for ; Thu, 19 Jun 2003 10:58:47 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0pv-00058T-00 for aaa@ietf.org; Thu, 19 Jun 2003 10:56:28 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19T0pv-00058Q-00 for aaa@ietf.org; Thu, 19 Jun 2003 10:56:27 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5JEwk920954 for ; Thu, 19 Jun 2003 17:58:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 17:58:43 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 17:58:45 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 17:58:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Aaa] Diameter Date: Thu, 19 Jun 2003 17:58:40 +0300 Message-ID: Thread-Topic: [Aaa] Diameter Thread-Index: AcM2cntWlv3EAnO2QFKX/KA9AIHZXQAAIztg To: , X-OriginalArrivalTime: 19 Jun 2003 14:58:41.0130 (UTC) FILETIME=[457A7CA0:01C33673] Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22997 Hi Wassef, This sounds close to what some people have proposed in the NSIS working group. I wonder how much your needs are really related to AAA but more some sort of SLA negotiation protocol (which some people in the NSIS working group are interested in. John -----Original Message----- From: ext wassef louati [mailto:wassef.louati@int-evry.fr] Sent: 19 June, 2003 16:44 To: aaa@ietf.org Subject: [Aaa] Diameter Hi, I'm working in Diameter Protocol. I use this protocol to make communication between 2 Diffserv domain,that's way I was defined a new Diameter Application that I was named 'Diameter Diffserv Application'. So,can you help me to developp this idea. thanks wassef _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Tue Jun 24 06:07:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08901 for ; Tue, 24 Jun 2003 06:07:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E17A49125E; Tue, 24 Jun 2003 06:06:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B13099125F; Tue, 24 Jun 2003 06:06: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 6631C9125E for ; Tue, 24 Jun 2003 06:06:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DA025DE1D; Tue, 24 Jun 2003 06:06:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B0A2E5DE03 for ; Tue, 24 Jun 2003 06:06:49 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 99EE16A902; Tue, 24 Jun 2003 13:06:47 +0300 (EEST) Message-ID: <3EF82231.80208@kolumbus.fi> Date: Tue, 24 Jun 2003 13:04:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com, aboba@mail.internaut.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: How NAS sets Accounting-EAP-Auth-Method? References: <052E0C61B69C3741AFA5FE88ACC775A61222A4@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222A4@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi wrote: > One possible solution would be that the > Accounting-EAP-Auth-Method AVP will be equal to the Type > (or Expanded Type) field in the last Diameter-EAP-Request's > EAP-Payload AVP. Or the Diameter server could give the value > to use in the last (success) Diameter-EAP-Answer. Bernard wrote: > I'd suggest that perhaps the Type is determined from the method in > progress at the time the EAP Success was determined. Pasi wrote: > The last Diameter-EAP-Answer of course contains an EAP Success, > but the last Diameter-EAP-Request probably contains an EAP Response > of the correct type, right? I would actually like to use the Diameter server approach that Pasi outlined above. The main reason for this is that it is the only entity in the AAA chain that actually knows all the details associated with the authentication. For instance, if and when we will have tunneled authentication, the NAS will not be able to see inside the tunnel for what's happening there. So I'd like the server to return an AVP to the NAS, which can then use it on an accounting message. In addition, I'd like to allow more than one instance of this AVP, to cater for the case where there indeed has been multiple authentication methods. Finally, backwards compatibility with RADIUS needs to be dealt with. I don't think RFC 2869bis had this attribute so we only need to deal with vendor specific attribute in RFC 2548. Here's suggested text: (1) Change Diameter-EAP-Answer BNF to have zero or more EAP-Auth-Method AVPs. (2) Section 4.1.2 (EAP-Auth-Method AVP) The EAP-Auth-Method AVP (AVP Code 401) is of type Enumerated and uses the EAP Type name space defined in [EAPTYP]. The Diameter server MAY return zero or more instances of this attribute in the last Diameter-EAP-Answer message it sends for a given session. The value given for the AVP is the EAP method used in the authentication of the session. In case tunneled authentication is used, there may more than one such method, and all of them MAY be included. The Diameter client SHOULD copy the received EAP-Auth-Method AVPs to the Diameter-Accounting-Request messages it sends. The order of the AVPs MUST be retained. (3) Change 5.1 by adding this: EAP-Auth-Method | 0 | 0+ | (4) Change 5.2 by replacing this Accounting-EAP-Auth-Method | 1 | 0-1 | with EAP-Auth-Method | 0+ | 0 | (5) We have earlier talked about the need for text that describes RADIUS interoperability. You could add this there: There is no standard attribute corresponding to EAP-Auth-Method AVP in RADIUS. When translating a Diameter message to a RADIUS message, all EAP-Auth-Method AVPs are in general discarded. When translating a RADIUS message to a DIAMETER message, the translation agent is also unable to add any EAP-Auth-Method AVPs to the Diameter message. Note that vendor-specific RADIUS attributes related to the EAP-Auth-Method AVP exist, for instance in [RFC 2548]. Typically, these attributes can be translated to the EAP-Auth-Method AVP no accounting messages, but since they are not used in the authentication and authorization messages, such translations require support in the RADIUS-based NAS for determining the used authentication methods. > The equivalent functionality is in RADIUS so there must be a > reliable way to do it somehow... Since when has that been a proof of the existence of a reliable way? ;-) --Jari From owner-aaa-wg@merit.edu Tue Jun 24 06:18:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09046 for ; Tue, 24 Jun 2003 06:18:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1EE691260; Tue, 24 Jun 2003 06:18:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8995891261; Tue, 24 Jun 2003 06:18: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 838C191260 for ; Tue, 24 Jun 2003 06:18:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C1935DE0F; Tue, 24 Jun 2003 06:18:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 30E085DE03 for ; Tue, 24 Jun 2003 06:18:28 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 846726A902; Tue, 24 Jun 2003 13:18:27 +0300 (EEST) Message-ID: <3EF824ED.5010504@kolumbus.fi> Date: Tue, 24 Jun 2003 13:16:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Maximum size of EAP messages References: <052E0C61B69C3741AFA5FE88ACC775A608BB2D@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB2D@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Maximum size of EAP messages > Submitter name: Pasi Eronen > Submitter email address: pasi.eronen@nokia.com > Date first submitted: 18 Jun 2003 > Reference: > Document: EAP-01 > Comment type: T > Priority: S > Section: - > Rationale/Explanation of issue: > > The EAP server may need to know the maximum size of EAP payload > it can send, in order to produce fragments of correct size. > > Proposed change: Add new EAP-MTU AVP, sent in > Diameter-EAP-Requests (I think we shouldn't re-use Framed-MTU > AVP for this; the "framed MTU" of the link isn't necessarily > the same as the maximum size of EAP message). Ok. We should have a section that describes how RADIUS EAP and DIAMETER EAP map to each other, and explain there that RADIUS Framed-MTU maps into both Framed-MTU and EAP-MTU AVPs... --Jari From owner-aaa-wg@merit.edu Tue Jun 24 06:20:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09092 for ; Tue, 24 Jun 2003 06:20:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E22D391261; Tue, 24 Jun 2003 06:20:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1AC691262; Tue, 24 Jun 2003 06:20: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 979BD91261 for ; Tue, 24 Jun 2003 06:20:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83C895DE1E; Tue, 24 Jun 2003 06:20:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 48CB65DE0F for ; Tue, 24 Jun 2003 06:20:24 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9A5326A902; Tue, 24 Jun 2003 13:20:23 +0300 (EEST) Message-ID: <3EF82561.9020009@kolumbus.fi> Date: Tue, 24 Jun 2003 13:18:09 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: EAP-Payload AVP vs. EAP-Message attribute? References: <052E0C61B69C3741AFA5FE88ACC775A608BB2A@esebe023.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>Is there some particular reason the Diameter AVP "EAP-Payload" >>has a different name and code than the RADIUS "EAP-Message" >>attribute? Or could we simply use the same name and code? > > > I think the reason that the code is different is because in RADIUS an > attribute has very limited length and this is inconvenient for EAP since > it requires the EAP packet to be broken up into multiple attributes. > Therefore it would probably be better for Diameter to be able to include > the entire EAP packet in one AVP. > > In general, if the RADIUS codes are reused then the attribute is assumed > to be defined identically to RADIUS. Yes. If the intention is that in Diameter you'll have just one copy of this AVP, then I think the semantics are different enough to warrant a new code/name. But yes, this translation too needs to be described somewhere. --Jari From owner-aaa-wg@merit.edu Tue Jun 24 07:03:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11553 for ; Tue, 24 Jun 2003 07:03:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6399C91264; Tue, 24 Jun 2003 07:03:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3968A91265; Tue, 24 Jun 2003 07: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 DC76791264 for ; Tue, 24 Jun 2003 07:03:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFF5C5DE10; Tue, 24 Jun 2003 07:03:15 -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 17A605DDBC for ; Tue, 24 Jun 2003 07:03:15 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5OB3E916778 for ; Tue, 24 Jun 2003 14:03:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 14:03:13 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 14:03:13 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 14:03:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 14:03:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Issue: Maximum size of EAP messages Date: Tue, 24 Jun 2003 14:03:10 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB3C@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue: Maximum size of EAP messages Thread-Index: AcM6OfUwmtBN4kaPSI6wYtTB5+OkJwABa0lw From: To: Cc: X-OriginalArrivalTime: 24 Jun 2003 11:03:11.0928 (UTC) FILETIME=[33E21B80:01C33A40] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > > The EAP server may need to know the maximum size of EAP payload > > it can send, in order to produce fragments of correct size. > >=20 > > Proposed change: Add new EAP-MTU AVP, sent in > > Diameter-EAP-Requests (I think we shouldn't re-use Framed-MTU > > AVP for this; the "framed MTU" of the link isn't necessarily=20 > > the same as the maximum size of EAP message). >=20 > Ok. >=20 > We should have a section that describes how RADIUS EAP > and DIAMETER EAP map to each other, and explain there > that RADIUS Framed-MTU maps into both Framed-MTU and > EAP-MTU AVPs... I have a sketch of Diameter-RADIUS translation section in http://www.cs.hut.fi/~peronen/eap/draft-ietf-aaa-eap-02.c.txt. But is mapping a RADIUS Framed-MTU attribute to both EAP-MTU AVP and Framed-MTU AVP actually necessary? RFC2865 says that Framed-MTU may be used as a hint in Access-Request messages. But do existing RADIUS implementations that use EAP actually interprete the same Framed-MTU value both as MTU for EAP and "link MTU hint"? My guess would be that if EAP is used, the value is not used as a "link MTU" hint at all, but then, I'm not an expert on existing=20 RADIUS implementations. (RADIUS implementations without EAP may,=20 of course, use this value as link MTU hint.) If this is the case, then we can just map Framed-MTU in RADIUS Access-Request to EAP-MTU AVP (the Diameter-EAP-Request won't have any Framed-MTU AVPs), and when mapping Diameter-EAP-Request to RADIUS Access-Request, just drop all Framed-MTU AVPs present in the Diameter request. Best regards, Pasi From owner-aaa-wg@merit.edu Tue Jun 24 07:41:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12432 for ; Tue, 24 Jun 2003 07:41:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BED1191267; Tue, 24 Jun 2003 07:40:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9287F91268; Tue, 24 Jun 2003 07:40: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 7E69E91267 for ; Tue, 24 Jun 2003 07:40:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60F395DE40; Tue, 24 Jun 2003 07:40:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 24B345DE25 for ; Tue, 24 Jun 2003 07:40:55 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3B3686A902; Tue, 24 Jun 2003 14:40:54 +0300 (EEST) Message-ID: <3EF8383F.40204@kolumbus.fi> Date: Tue, 24 Jun 2003 14:38:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Maximum size of EAP messages References: <052E0C61B69C3741AFA5FE88ACC775A608BB3C@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB3C@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > I have a sketch of Diameter-RADIUS translation section in > http://www.cs.hut.fi/~peronen/eap/draft-ietf-aaa-eap-02.c.txt. Yes. I saw it later, comments coming up... > But is mapping a RADIUS Framed-MTU attribute to both EAP-MTU AVP and > Framed-MTU AVP actually necessary? RFC2865 says that Framed-MTU may > be used as a hint in Access-Request messages. But do existing RADIUS > implementations that use EAP actually interprete the same > Framed-MTU value both as MTU for EAP and "link MTU hint"? > > My guess would be that if EAP is used, the value is not used as a > "link MTU" hint at all, but then, I'm not an expert on existing > RADIUS implementations. (RADIUS implementations without EAP may, > of course, use this value as link MTU hint.) Good questions. No, I don't have the answers either... --Jari From owner-aaa-wg@merit.edu Tue Jun 24 08:15:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13489 for ; Tue, 24 Jun 2003 08:15:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F34191268; Tue, 24 Jun 2003 08:14:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E517E91269; Tue, 24 Jun 2003 08:14:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B509E91268 for ; Tue, 24 Jun 2003 08:14:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BDC75DE3E; Tue, 24 Jun 2003 08:14:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 15F715DE3C for ; Tue, 24 Jun 2003 08:14:50 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5OBnjq18293; Tue, 24 Jun 2003 04:49:45 -0700 Date: Tue, 24 Jun 2003 04:49:45 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Maximum size of EAP messages In-Reply-To: <3EF8383F.40204@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB3C@esebe023.ntc.nokia.com> <3EF8383F.40204@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > My guess would be that if EAP is used, the value is not used as a > > "link MTU" hint at all, but then, I'm not an expert on existing > > RADIUS implementations. (RADIUS implementations without EAP may, > > of course, use this value as link MTU hint.) Perhaps we should post the question to the EAP WG mailing list to see what implementors do. I know that some ignore it entirely (with disasterous results). From owner-aaa-wg@merit.edu Tue Jun 24 08:21:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13625 for ; Tue, 24 Jun 2003 08:21:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E2CB79126A; Tue, 24 Jun 2003 08:21:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8C879126B; Tue, 24 Jun 2003 08:21: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 741F69126A for ; Tue, 24 Jun 2003 08:21:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA4645DE3C; Tue, 24 Jun 2003 08:21:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 575BE5DE34 for ; Tue, 24 Jun 2003 08:21:16 -0400 (EDT) Received: from localhost (aboba@localhost) by mail.internaut.com (8.10.2/8.10.2) with ESMTP id h5OBuCv18623; Tue, 24 Jun 2003 04:56:12 -0700 Date: Tue, 24 Jun 2003 04:56:11 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Maximum size of EAP messages In-Reply-To: Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A608BB3C@esebe023.ntc.nokia.com> <3EF8383F.40204@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > > My guess would be that if EAP is used, the value is not used as a > > > "link MTU" hint at all, but then, I'm not an expert on existing > > > RADIUS implementations. (RADIUS implementations without EAP may, > > > of course, use this value as link MTU hint.) This reminds me. I wonder whether AAA implementations are really prepared for any legal value of Framed-MTU. After all, this could be as low as 256 octets -- and there are some methods not supporting fragmentation that could generate packets larger than this. It seems like an issue that needs further clarification in RFC 2284bis -- for example, there are EAP method specifications that claim that they can never fragment. From owner-aaa-wg@merit.edu Tue Jun 24 09:00:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14377 for ; Tue, 24 Jun 2003 09:00:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3F4491275; Tue, 24 Jun 2003 08:41:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ADF191277; Tue, 24 Jun 2003 08:41: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 E224491275 for ; Tue, 24 Jun 2003 08:41:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D23035DE3C; Tue, 24 Jun 2003 08:41:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 91F6C5DDF7 for ; Tue, 24 Jun 2003 08:41:14 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B6AE46A902; Tue, 24 Jun 2003 15:41:13 +0300 (EEST) Message-ID: <3EF84662.7070901@kolumbus.fi> Date: Tue, 24 Jun 2003 15:38:58 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue: Maximum size of EAP messages References: <052E0C61B69C3741AFA5FE88ACC775A608BB3C@esebe023.ntc.nokia.com> <3EF8383F.40204@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>>>My guess would be that if EAP is used, the value is not used as a >>>>"link MTU" hint at all, but then, I'm not an expert on existing >>>>RADIUS implementations. (RADIUS implementations without EAP may, >>>>of course, use this value as link MTU hint.) > > > This reminds me. I wonder whether AAA implementations are really prepared > for any legal value of Framed-MTU. After all, this could be as low as 256 > octets -- and there are some methods not supporting fragmentation that > could generate packets larger than this. It seems like an issue that > needs further clarification in RFC 2284bis -- for example, there are EAP > method specifications that claim that they can never fragment. > Maybe add a "Fragmentation Behaviour" description for all methods? State the maximum message size, and whether the method supports fragmentation or not. Then in the general part of 2284bis, we can say that methods that do not support fragmentation may not work in case the MTU value on the given link is too small. --Jari From owner-aaa-wg@merit.edu Thu Jun 26 16:14:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19595 for ; Thu, 26 Jun 2003 16:14:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7BC5291220; Thu, 26 Jun 2003 16:13:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3555091208; Thu, 26 Jun 2003 16:13: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 3133691220 for ; Thu, 26 Jun 2003 16:13:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12B035DE2A; Thu, 26 Jun 2003 16:13:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 860FB5DE29 for ; Thu, 26 Jun 2003 16:13:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h5QJmY513254 for ; Thu, 26 Jun 2003 12:48:34 -0700 Date: Thu, 26 Jun 2003 12:48:34 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Strawman Agenda for IETF 57 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here is a strawman Agenda for the AAA-WG meeting at IETF 57. Comments/additions welcome. Authentication, Authorization and Accounting WG (AAA) Wednesday, July 16, 2003 1300-1500 Afternoon Sessions I ============================= CHAIRS: Bernard Aboba David Mitton AGENDA: Preliminaries (10 minutes) Bluesheets Minutes Agenda Bashing Document Status Diameter MIPv4 (15 minutes), Tom Hiller http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-15.txt Diameter NASREQ (15 minutes), David Mittonhttp://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-12.txt Diameter EAP (15 minutes), Pasi Eronen http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-02.txt Diameter Credit Control Application (15 minutes), John Loughney http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-00.txt Diameter Multimedia Application (15 minutes), M. Belinchon http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-01.txt Roadmap (15 minutes) WG Chairs and ADs From owner-aaa-wg@merit.edu Thu Jun 26 16:22:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19874 for ; Thu, 26 Jun 2003 16:22:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F168291208; Thu, 26 Jun 2003 16:21:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C13D191230; Thu, 26 Jun 2003 16:21: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 A0BBE91208 for ; Thu, 26 Jun 2003 16:21:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85B805DE27; Thu, 26 Jun 2003 16:21:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id 36AF25DE24 for ; Thu, 26 Jun 2003 16:21:47 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5QKJvt25434; Thu, 26 Jun 2003 15:19:57 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h5QKJtY20498; Thu, 26 Jun 2003 15:19:55 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HH3V55-0001N8-00; Thu, 26 Jun 2003 16:19:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16123.21862.945025.92159@gargle.gargle.HOWL> Date: Thu, 26 Jun 2003 15:19:50 -0500 From: Pete McCann To: nsis@ietf.org, aaa-wg@merit.edu Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt In-Reply-To: <200306251452.KAA12886@ietf.org> References: <200306251452.KAA12886@ietf.org> X-Mailer: VM 7.14 under 21.5 (beta13) "cauliflower" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We hope everyone who is interested in QoS/AAA has a chance to read the draft we have just submitted. Our work is definitely related to the 2 drafts-tschofenig that have been posted on the NSIS group (apologies for not acknowledging this explicitly in the draft, but we found them only recently and are still reading them). However, our work focuses more on the requirements for a AAA protocol rather than requirements for NSIS. Also, we are trying to set forth in our draft what we think is the proper relationship between NSIS/RSVP, AAA, and call control protocols like SIP. Please read/comment! -Pete Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Requirements for a QoS AAA Protocol > Author(s) : F. Alfano et al. > Filename : draft-alfano-aaa-qosreq-00.txt > Pages : 16 > Date : 2003-6-24 > > This document describes requirements for a protocol that would > perform Authentication, Authorization, and Accounting for Quality-of- > Service reservations. This protocol would be used by elements along > the path of a given application flow to authenticate a reservation > request, ensure that the reservation is authorized, and to account > for resources used during the life of the application flow. A QoS > AAA protocol should also support dynamic authorization of QoS as a > function of application and account state. While we assume the > existence of some QoS reservation protocol to allow endpoints to > request QoS from network elements, complete requirements for such a > protocol are outside the scope of this document and a QoS AAA > protocol could be used to support more than one kind of reservation > protocol. A QoS AAA protocol could be used between any bearer-level > network element that lies along the path of an application flow and > an application server that lies anywhere in the network, allowing for > a wide variety of flexible service deployment models. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt From owner-aaa-wg@merit.edu Sat Jun 28 02:45:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16861 for ; Sat, 28 Jun 2003 02:45:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A473D9120A; Sat, 28 Jun 2003 02:33:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 785FB9120F; Sat, 28 Jun 2003 02:33: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 2D3B19120A for ; Sat, 28 Jun 2003 02:33:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14A495DE6C; Sat, 28 Jun 2003 02:33:10 -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 654C15DE7D for ; Sat, 28 Jun 2003 02:33:09 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5S6X8917278 for ; Sat, 28 Jun 2003 09:33:08 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 28 Jun 2003 09:33:09 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 28 Jun 2003 09:33:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 28 Jun 2003 09:33:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Date: Sat, 28 Jun 2003 09:33:06 +0300 Message-ID: Thread-Topic: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Thread-Index: AcM8IKDXdfTnPACfRI2stmw1UCY3pABHhauA From: To: , , X-OriginalArrivalTime: 28 Jun 2003 06:33:06.0831 (UTC) FILETIME=[228B89F0:01C33D3F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pete, Question for you - NSIS will obviously need some AAA interaction, not just for QoS, but for middle box traversal (note, new NSIS charter has been announced). It might be interesting to discuss this work in both AAA & NSIS, but my feeling is that the AAA WG already has a lot to do. Perhaps you could work with Hannes to incorporate aspects of the drafts together. =20 thanks, John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 26 June, 2003 23:20 > To: nsis@ietf.org; aaa-wg@merit.edu > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt >=20 >=20 >=20 > Hi, >=20 > We hope everyone who is interested in QoS/AAA has a chance to read the > draft we have just submitted. >=20 > Our work is definitely related to the 2 drafts-tschofenig that have > been posted on the NSIS group (apologies for not acknowledging this > explicitly in the draft, but we found them only recently and are still > reading them). However, our work focuses more on the requirements for > a AAA protocol rather than requirements for NSIS. Also, we are trying > to set forth in our draft what we think is the proper relationship > between NSIS/RSVP, AAA, and call control protocols like SIP. >=20 > Please read/comment! >=20 > -Pete >=20 > Internet-Drafts@ietf.org writes: > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > >=20 > >=20 > > Title : Requirements for a QoS AAA Protocol > > Author(s) : F. Alfano et al. > > Filename : draft-alfano-aaa-qosreq-00.txt > > Pages : 16 > > Date : 2003-6-24 > > =09 > > This document describes requirements for a protocol that would=20 > > perform Authentication, Authorization, and Accounting for=20 > Quality-of- > > Service reservations. This protocol would be used by=20 > elements along=20 > > the path of a given application flow to authenticate a reservation=20 > > request, ensure that the reservation is authorized, and to account=20 > > for resources used during the life of the application flow. A QoS=20 > > AAA protocol should also support dynamic authorization of QoS as a=20 > > function of application and account state. While we assume the=20 > > existence of some QoS reservation protocol to allow endpoints to=20 > > request QoS from network elements, complete requirements=20 > for such a=20 > > protocol are outside the scope of this document and a QoS AAA=20 > > protocol could be used to support more than one kind of=20 > reservation=20 > > protocol. A QoS AAA protocol could be used between any=20 > bearer-level=20 > > network element that lies along the path of an application=20 > flow and=20 > > an application server that lies anywhere in the network,=20 > allowing for=20 > > a wide variety of flexible service deployment models. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt >=20 >=20 >=20 From aaa-admin@ietf.org Mon Jun 30 03:22:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03420 for ; Mon, 30 Jun 2003 03:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WszC-0006t1-0a; Mon, 30 Jun 2003 03:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wsyk-0006pQ-Nw for aaa@optimus.ietf.org; Mon, 30 Jun 2003 03:21:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03369 for ; Mon, 30 Jun 2003 03:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WsyT-0004Aj-00 for aaa@ietf.org; Mon, 30 Jun 2003 03:21:17 -0400 Received: from wire.cs.nthu.edu.tw ([140.114.79.60]) by ietf-mx with esmtp (Exim 4.12) id 19WsyI-0004AH-00 for aaa@ietf.org; Mon, 30 Jun 2003 03:21:06 -0400 Received: from timl (gnat.cs.nthu.edu.tw [140.114.79.182]) by wire.cs.nthu.edu.tw (Postfix) with SMTP id 4CE4818243 for ; Mon, 30 Jun 2003 15:20:16 +0800 (CST) Message-ID: <004801c33ed7$cc474760$b64f728c@timl> From: "Yi-Wen Liu" To: Date: Mon, 30 Jun 2003 15:18:26 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C33F1A.DA59BE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Aaa] WIRE1x - free software of 802.1x supplicant] Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C33F1A.DA59BE80 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable We are pleased to announce the release of WIRE1x Version 0.1. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/ What is WIRE1x? The WIRE1x is an implementation of IEEE 802.1x client (supplicant) developed by the Wireless Internet Research & Engineering (WIRE) Lab. The IEEE 802.1x standard defines a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. IEEE 802.11i also incorporates 802.1x as its authentication solution for 802.11 wireless LANs. The implementation of WIRE1x is based on the Open1x. Open1x supports MacOS X, FreeBSD, OpenBSD, and Linux. Many users at National Tsing Hua University however are using MS Windows. They need a 802.1x client software to access to the campus wireless LANs. We therefore develop = the WIRE1x to support various versions of MS Windows. Currently, the WIRE1x supports Windows XP (without service pack and with service pack 1) and Windows 2000. It provides EAP MD5-Challenge. It works with freeRADIUS. It now supports several WLAN cards including Avaya, 3com, PCI, and = ZyXel cards. We will upgrade the program to support more WLAN cards, more authentication mechanisms, and more (especially earlier) versions of MS Windows. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/. ------=_NextPart_000_0045_01C33F1A.DA59BE80 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
 We are pleased to announce the = release of=20 WIRE1x Version 0.1.
 Both source code and executable code can be = downloaded from
 http://wire.cs.nthu.edu.tw/wire1x/

 What is WIRE1x?

 The WIRE1x is an = implementation of=20 IEEE 802.1x client (supplicant)
 developed by the Wireless = Internet=20 Research & Engineering (WIRE) Lab.
 The IEEE 802.1x standard = defines=20 a port-based network access control to
 authenticate and  = authorize=20 devices interconnected by various IEEE 802
 LANs. IEEE 802.11i = also=20 incorporates 802.1x as its authentication
 solution for 802.11 = wireless=20 LANs.

 The implementation of WIRE1x is based on the Open1x. = Open1x=20 supports
 MacOS X, FreeBSD, OpenBSD, and Linux. Many users at = National=20 Tsing Hua
 University however are using MS Windows. They need a = 802.1x=20 client
 software to access to the campus wireless LANs. We = therefore=20 develop the
 WIRE1x to support various versions of MS Windows.=20 Currently, the WIRE1x
 supports Windows XP (without service pack = and=20 with service pack 1) and
 Windows 2000. It provides EAP = MD5-Challenge.=20 It works with freeRADIUS.
 It now supports several WLAN cards = including=20 Avaya, 3com, PCI, and ZyXel
 cards. We will upgrade the program = to=20 support more WLAN cards, more
 authentication mechanisms, and = more=20 (especially earlier) versions of MS
 Windows. Both source code = and=20 executable code can be downloaded from
 http://wire.cs.nthu.edu.tw/wire1x/.

------=_NextPart_000_0045_01C33F1A.DA59BE80-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From exim@www1.ietf.org Mon Jun 30 03:23:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03477 for ; Mon, 30 Jun 2003 03:23:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U7Mh126683 for aaa-archive@odin.ietf.org; Mon, 30 Jun 2003 03:22:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wszr-0006wI-D1 for aaa-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 03:22:43 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03419 for ; Mon, 30 Jun 2003 03:22:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WszC-0006t1-0a; Mon, 30 Jun 2003 03:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wsyk-0006pQ-Nw for aaa@optimus.ietf.org; Mon, 30 Jun 2003 03:21:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03369 for ; Mon, 30 Jun 2003 03:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WsyT-0004Aj-00 for aaa@ietf.org; Mon, 30 Jun 2003 03:21:17 -0400 Received: from wire.cs.nthu.edu.tw ([140.114.79.60]) by ietf-mx with esmtp (Exim 4.12) id 19WsyI-0004AH-00 for aaa@ietf.org; Mon, 30 Jun 2003 03:21:06 -0400 Received: from timl (gnat.cs.nthu.edu.tw [140.114.79.182]) by wire.cs.nthu.edu.tw (Postfix) with SMTP id 4CE4818243 for ; Mon, 30 Jun 2003 15:20:16 +0800 (CST) Message-ID: <004801c33ed7$cc474760$b64f728c@timl> From: "Yi-Wen Liu" To: Date: Mon, 30 Jun 2003 15:18:26 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C33F1A.DA59BE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Aaa] WIRE1x - free software of 802.1x supplicant] Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C33F1A.DA59BE80 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable We are pleased to announce the release of WIRE1x Version 0.1. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/ What is WIRE1x? The WIRE1x is an implementation of IEEE 802.1x client (supplicant) developed by the Wireless Internet Research & Engineering (WIRE) Lab. The IEEE 802.1x standard defines a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. IEEE 802.11i also incorporates 802.1x as its authentication solution for 802.11 wireless LANs. The implementation of WIRE1x is based on the Open1x. Open1x supports MacOS X, FreeBSD, OpenBSD, and Linux. Many users at National Tsing Hua University however are using MS Windows. They need a 802.1x client software to access to the campus wireless LANs. We therefore develop = the WIRE1x to support various versions of MS Windows. Currently, the WIRE1x supports Windows XP (without service pack and with service pack 1) and Windows 2000. It provides EAP MD5-Challenge. It works with freeRADIUS. It now supports several WLAN cards including Avaya, 3com, PCI, and = ZyXel cards. We will upgrade the program to support more WLAN cards, more authentication mechanisms, and more (especially earlier) versions of MS Windows. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/. ------=_NextPart_000_0045_01C33F1A.DA59BE80 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
 We are pleased to announce the = release of=20 WIRE1x Version 0.1.
 Both source code and executable code can be = downloaded from
 http://wire.cs.nthu.edu.tw/wire1x/

 What is WIRE1x?

 The WIRE1x is an = implementation of=20 IEEE 802.1x client (supplicant)
 developed by the Wireless = Internet=20 Research & Engineering (WIRE) Lab.
 The IEEE 802.1x standard = defines=20 a port-based network access control to
 authenticate and  = authorize=20 devices interconnected by various IEEE 802
 LANs. IEEE 802.11i = also=20 incorporates 802.1x as its authentication
 solution for 802.11 = wireless=20 LANs.

 The implementation of WIRE1x is based on the Open1x. = Open1x=20 supports
 MacOS X, FreeBSD, OpenBSD, and Linux. Many users at = National=20 Tsing Hua
 University however are using MS Windows. They need a = 802.1x=20 client
 software to access to the campus wireless LANs. We = therefore=20 develop the
 WIRE1x to support various versions of MS Windows.=20 Currently, the WIRE1x
 supports Windows XP (without service pack = and=20 with service pack 1) and
 Windows 2000. It provides EAP = MD5-Challenge.=20 It works with freeRADIUS.
 It now supports several WLAN cards = including=20 Avaya, 3com, PCI, and ZyXel
 cards. We will upgrade the program = to=20 support more WLAN cards, more
 authentication mechanisms, and = more=20 (especially earlier) versions of MS
 Windows. Both source code = and=20 executable code can be downloaded from
 http://wire.cs.nthu.edu.tw/wire1x/.

------=_NextPart_000_0045_01C33F1A.DA59BE80-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Mon Jun 30 04:01:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04615 for ; Mon, 30 Jun 2003 04:01:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9EBC291237; Mon, 30 Jun 2003 03:38:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 607A691255; Mon, 30 Jun 2003 03:38: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 00EDB91237 for ; Mon, 30 Jun 2003 03:38:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D98BE5E055; Mon, 30 Jun 2003 03:38:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from wire.cs.nthu.edu.tw (wire.cs.nthu.edu.tw [140.114.79.60]) by segue.merit.edu (Postfix) with ESMTP id 6F5375E048 for ; Mon, 30 Jun 2003 03:38:01 -0400 (EDT) Received: from timl (gnat.cs.nthu.edu.tw [140.114.79.182]) by wire.cs.nthu.edu.tw (Postfix) with SMTP id B74C518243 for ; Mon, 30 Jun 2003 15:37:59 +0800 (CST) Message-ID: <005401c33eda$4635f600$b64f728c@timl> From: "Yi-Wen Liu" To: Subject: [AAA-WG]: [Aaa] WIRE1x - free software of 802.1x supplicant] Date: Mon, 30 Jun 2003 15:36:09 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C33F1D.544B0530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C33F1D.544B0530 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable We are pleased to announce the release of WIRE1x Version 0.1. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/ What is WIRE1x? The WIRE1x is an implementation of IEEE 802.1x client (supplicant) developed by the Wireless Internet Research & Engineering (WIRE) Lab. The IEEE 802.1x standard defines a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. IEEE 802.11i also incorporates 802.1x as its authentication solution for 802.11 wireless LANs. The implementation of WIRE1x is based on the Open1x. Open1x supports MacOS X, FreeBSD, OpenBSD, and Linux. Many users at National Tsing Hua University however are using MS Windows. They need a 802.1x client software to access to the campus wireless LANs. We therefore develop = the WIRE1x to support various versions of MS Windows. Currently, the WIRE1x supports Windows XP (without service pack and with service pack 1) and Windows 2000. It provides EAP MD5-Challenge. It works with freeRADIUS. It now supports several WLAN cards including Avaya, 3com, PCI, and = ZyXel cards. We will upgrade the program to support more WLAN cards, more authentication mechanisms, and more (especially earlier) versions of MS Windows. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/. ------=_NextPart_000_0051_01C33F1D.544B0530 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
 
 We are pleased to announce the = release of=20 WIRE1x Version 0.1.
 Both source code and executable code can be = downloaded from
 http://wire.cs.nthu.edu.tw/wire1x/

 What is WIRE1x?

 The WIRE1x is an = implementation of=20 IEEE 802.1x client (supplicant)
 developed by the Wireless = Internet=20 Research & Engineering (WIRE) Lab.
 The IEEE 802.1x standard = defines=20 a port-based network access control to
 authenticate and  = authorize=20 devices interconnected by various IEEE 802
 LANs. IEEE 802.11i = also=20 incorporates 802.1x as its authentication
 solution for 802.11 = wireless=20 LANs.

 The implementation of WIRE1x is based on the Open1x. = Open1x=20 supports
 MacOS X, FreeBSD, OpenBSD, and Linux. Many users at = National=20 Tsing Hua
 University however are using MS Windows. They need a = 802.1x=20 client
 software to access to the campus wireless LANs. We = therefore=20 develop the
 WIRE1x to support various versions of MS Windows.=20 Currently, the WIRE1x
 supports Windows XP (without service pack = and=20 with service pack 1) and
 Windows 2000. It provides EAP = MD5-Challenge.=20 It works with freeRADIUS.
 It now supports several WLAN cards = including=20 Avaya, 3com, PCI, and ZyXel
 cards. We will upgrade the program = to=20 support more WLAN cards, more
 authentication mechanisms, and = more=20 (especially earlier) versions of MS
 Windows. Both source code = and=20 executable code can be downloaded from
 http://wire.cs.nthu.edu.tw/wire1x/.

------=_NextPart_000_0051_01C33F1D.544B0530--