From mailman-admin@ietf.org Sat Feb 1 10:01:08 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 KAA07492 for ; Sat, 1 Feb 2003 10:01:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11F59J32193 for ; Sat, 1 Feb 2003 10:05:09 -0500 Date: Sat, 01 Feb 2003 10:05:09 -0500 Message-ID: <20030201150509.8821.71789.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 Sun Feb 2 10:40: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 KAA07294 for ; Sun, 2 Feb 2003 10:40:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E14D09121D; Sun, 2 Feb 2003 10:43:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A90BB91222; Sun, 2 Feb 2003 10:43:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B12019121D for ; Sun, 2 Feb 2003 10:43:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id A05F85DE40; Sun, 2 Feb 2003 10:43:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1DC185DDD4 for ; Sun, 2 Feb 2003 10:43:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h12EW7O16672 for ; Sun, 2 Feb 2003 06:32:07 -0800 Date: Sun, 2 Feb 2003 06:32:07 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Internet Draft cutoff (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21,2003) -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21,2003) From: Internet-Drafts Administrator Date: Fri, 31 Jan 2003 09:51:02 -0500 Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- NOTE: There are two(2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents). All initial submissions (00.txt) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions receieved after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prioir to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submission received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF Meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html From owner-aaa-wg@merit.edu Sun Feb 2 12:06:27 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 MAA08672 for ; Sun, 2 Feb 2003 12:06:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7722091222; Sun, 2 Feb 2003 12:09:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40EEA91277; Sun, 2 Feb 2003 12:09:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03F8291222 for ; Sun, 2 Feb 2003 12:09:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id E215C5DEFB; Sun, 2 Feb 2003 12:09:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1367F5DD8E for ; Sun, 2 Feb 2003 12:09:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h12FwEA21293 for ; Sun, 2 Feb 2003 07:58:14 -0800 Date: Sun, 2 Feb 2003 07:58:14 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 399: NASREQ Security Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: February 2, 2003 Document: NASREQ-10 Comment type: T Priority: S Section: 6.2 In Diameter NASREQ as well as in RADIUS, it is possible for a rogue NAS to send forged AVPs. For example, NAS A could send an Origin-Host, NAS-Identifier or NAS-IP-Address AVP with information corresponding to NAS B, and could even forge AVPs relating to the client such as the Called-Station-Id or Calling-Station-Id. In RADIUS shared secret checks are done based on the Source Address, not the NAS-Identifier/NAS-IP-Address, since the message could have been forwarded by a proxy. This means that the RADIUS server may not have the means to verify that the NAS-Identifier or NAS-IP-Address is correct. We can and should do better in Diameter. In particular, we have the Route-Record AVP, in which a Diameter agent will store information about the previous hop before forwarding the packet to the Diameter server. This means that a forgery of NAS-Identifier/NAS-IP-Address AVPs can be detected by a Diameter agent before it even gets to the Diameter server, by checking for a match between the Route-Record AVP and the NAS-Identifier/NAS-IP-Address AVPs. In Diameter Base 6.1.8 it is stated: "A relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer the request was received from." In Figure 7, a sample Route-Record AVP is included, with FQDNs as entries. In Section 6.7.1 it is stated: "The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The identity added in this AVP MUST be the same as the one received in the Origin-Host of the Capabilities Exchange message." I interpret this to mean that the Origin-Host AVP must contain the FQDN of the NAS, and that there must be a A & PTR RRs in the DNS corresponding to this, so that the Diameter agent can take the source IP address, do a PTR RR query, insert the result in the Route-Record AVP, and check it against the Origin-Host AVP. In order to be able to verify the contents of the NAS-Identifier or NAS-IP-Address AVPs, we need for the Diameter Agent to check whether the contents of those AVPs corresponds to any existing entry in the Route-Record AVP. This means doing a PTR RR query on the NAS-IP-Address and checking for a match within the Record-Route AVP. For NAS-Identifier AVP, a check may not be possible unless this AVP contains an FQDN, in which case an entry in the Route-Record AVP can also be searched for. If there is no match, then the Diameter Client must be a first hop, in which case, the NAS-IP-Address AVP should match the Source Address of the packet, and a PTR RR on this address should correspond to the Origin-Host AVP and can be entered in the Route-Record AVP. With NAS-Identifier, it is not clear how a check can be done unless this is assumed to contain an FQDN. In that case, the NAS-Identifier AVP can be checked against the Origin-Host AVP and an A RR query can be made on the FQDN and the resulting IP address can be compared against the Source Address. Since the Diameter agent cannot independently verify the Called-Station-Id or Calling-Station-Id, there are no checks that can be done to prevent forgery of those AVPs; however, it is conceivable that an EAP method could include those values in a MIC so as to allow the Diameter Server to verify them. Please insert the following text in Section 6.2.1 (NAS-IP-Address AVP): "In RADIUS it is possible for a rogue NAS to forge the NAS-IP-Address attribute. Diameter/RADIUS translation agents MUST check a received NAS-IP-Address attribute against the source address of the RADIUS packet. If they do not match, and the Diameter/RADIUS translation agent does not know whether the packet was sent by a RADIUS proxy or NAS (e.g. no Proxy-State attribute) then by default it is assumed that the source address corresponds to a RADIUS proxy, and that the NAS-IP-Address is behind that proxy, potentially with some additional RADIUS proxies in between. The Diameter/RADIUS translation agent MUST insert entries in the Route-Record AVP corresponding to the apparent route. This implies doing a reverse lookup on the source address and NAS-IP-Address attributes in order to determine the corresponding FQDNs. If the source address and the NAS-IP-Address do not match, and the Diameter/RADIUS translation agent knows that it is talking directly to the NAS (e.g. no RADIUS proxies between it and the NAS), then the error should be logged, and the packet MUST be discarded. Diameter agents and servers MUST check whether the NAS-IP-Address AVP corresponds to an entry in the Record-Route AVP. This is done by doing a reverse lookup (PTR RR) for the NAS-IP-Address to retrieve the corresponding FQDN, and checking for a match with the Record-Route AVP. If no match is found, then an error is logged, but no other action is taken." Please insert the following text in Section 6.2.2 (NAS-IPv6-Address AVP): "In RADIUS it is possible for a rogue NAS to forge the NAS-IPv6-Address attribute. Diameter/RADIUS translation agents MUST check a received NAS-IPv6-Address attribute against the source address of the RADIUS packet. If they do not match, and the Diameter/RADIUS translation agent does not know whether the packet was sent by a RADIUS proxy or NAS (e.g. no Proxy-State attribute) then by default it is assumed that the source address corresponds to a RADIUS proxy, and that the NAS-IP-Address is behind that proxy, potentially with some additional RADIUS proxies in between. The Diameter/RADIUS translation agent MUST insert entries in the Route-Record AVP corresponding to the apparent route. This implies doing a reverse lookup on the source address and NAS-IP-Address attributes in order to determine the corresponding FQDNs. If the source address and the NAS-IP-Address do not match, and the Diameter/RADIUS translation agent knows that it is talking directly to the NAS (e.g. no RADIUS proxies between it and the NAS), then the error should be logged, and the packet MUST be discarded. Diameter agents and servers MUST check whether the NAS-IPv6-Address AVP corresponds to an entry in the Record-Route AVP. This is done by doing a reverse lookup (PTR RR) for the NAS-IPv6-Address to retrieve the corresponding FQDN, and checking for a match with the Record-Route AVP. If no match is found, then an error is logged, but no other action is taken." Please insert the following text in Section 6.2.3 (NAS-Identifier AVP): "In RADIUS it is possible for a rogue NAS to forge the NAS-Identifier attribute. Diameter/RADIUS translation agents SHOULD attempt to check a received NAS-Identifier attribute against the source address of the RADIUS packet, by doing an A/AAAA RR query. If the NAS-Identifier attribute contains an FQDN, then such a query would resolve to an IP address matching the source address. However, the NAS-Identifier attribute is not required to contain an FQDN, so such a query could fail. In this case, an error should be logged, but no other action taken, other than doing a reverse lookup on the source address and inserting the resulting FQDN into the Route-Record AVP. Diameter agents and servers SHOULD check whether a NAS-Identifier AVP corresponds to an entry in the Record-Route AVP. If no match is found, then an error is logged, but no other action is taken." From owner-aaa-wg@merit.edu Sun Feb 2 16:01:01 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 QAA11851 for ; Sun, 2 Feb 2003 16:01:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4F0E91225; Sun, 2 Feb 2003 16:04:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B6049121F; Sun, 2 Feb 2003 16:04:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D96E91208 for ; Sun, 2 Feb 2003 16:03:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 28DEF5DDA1; Sun, 2 Feb 2003 16:03:40 -0500 (EST) 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 E3D925DD8E for ; Sun, 2 Feb 2003 16:03:39 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CE3276A901; Sun, 2 Feb 2003 23:03:32 +0200 (EET) Message-ID: <3E3D8754.9020407@kolumbus.fi> Date: Sun, 02 Feb 2003 23:02:12 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 399: NASREQ Security Issues References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > "In RADIUS it is possible for a rogue NAS to forge the > NAS-IP-Address attribute. Diameter/RADIUS translation agents > MUST check a received NAS-IP-Address attribute against the source address > of the RADIUS packet. If they do not match, and the Diameter/RADIUS > translation agent does not know whether the packet was sent by > a RADIUS proxy or NAS (e.g. no Proxy-State attribute) then > by default it is assumed that the source address corresponds > to a RADIUS proxy, and that the NAS-IP-Address is behind that > proxy, potentially with some additional RADIUS proxies in between. > The Diameter/RADIUS translation agent MUST insert entries > in the Route-Record AVP corresponding to the apparent route. > This implies doing a reverse lookup on the source address and > NAS-IP-Address attributes in order to determine the corresponding > FQDNs. I'm OK with this otherwise, but are you adding exactly two entries, one for the proxy and one for the NAS? I don't see what else you would be doing, but the language above isn't exact on this. > If the source address and the NAS-IP-Address do not match, > and the Diameter/RADIUS translation agent knows that it is > talking directly to the NAS (e.g. no RADIUS proxies between > it and the NAS), then the error should be logged, and the > packet MUST be discarded. Ok. > Diameter agents and servers MUST check whether the > NAS-IP-Address AVP corresponds to an entry in the Record-Route AVP. > This is done by doing a reverse lookup (PTR RR) for the NAS-IP-Address > to retrieve the corresponding FQDN, and checking for a match > with the Record-Route AVP. If no match is found, then an error > is logged, but no other action is taken." Hmm... care to explain why we couldn't drop the message? Also, what happens if there was a NAT or private DNS at some point in the path? Jari From owner-aaa-wg@merit.edu Sun Feb 2 17:05: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 RAA12666 for ; Sun, 2 Feb 2003 17:05:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16A9F91208; Sun, 2 Feb 2003 17:08:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE85691209; Sun, 2 Feb 2003 17:08:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC6BE91208 for ; Sun, 2 Feb 2003 17:08:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAF155DE60; Sun, 2 Feb 2003 17:08:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3AA105DDC3 for ; Sun, 2 Feb 2003 17:08:48 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h12KvB505227; Sun, 2 Feb 2003 12:57:12 -0800 Date: Sun, 2 Feb 2003 12:57:11 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 399: NASREQ Security Issues In-Reply-To: <3E3D8754.9020407@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I'm OK with this otherwise, but are you adding exactly two > entries, one for the proxy and one for the NAS? I don't see > what else you would be doing, but the language above isn't > exact on this. Yes, that's the intent. > Hmm... care to explain why we couldn't drop the message? We could do that. > Also, what happens if there was a NAT or private DNS at > some point in the path? Then the proposed text won't work. Care to suggest an alternative? From owner-aaa-wg@merit.edu Sun Feb 2 17:06: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 RAA12692 for ; Sun, 2 Feb 2003 17:06:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3DE991209; Sun, 2 Feb 2003 17:09:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67A519120D; Sun, 2 Feb 2003 17:09:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77C1A91209 for ; Sun, 2 Feb 2003 17:09:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65FB45DE60; Sun, 2 Feb 2003 17:09:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E71795DDC3 for ; Sun, 2 Feb 2003 17:09:53 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h12KwKP05306 for ; Sun, 2 Feb 2003 12:58:20 -0800 Date: Sun, 2 Feb 2003 12:58:19 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: RFC 2869bis "pseudo WG last call" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk RFC 2869bis IETF last call will be occurring soon. To give AAA WG participants an opportunity to comment on the draft prior to IETF last call, we are going to hold a week-long "pseudo WG last call" prior to submitting a final -08 draft to the IETF archive on 2/9/03 and beginning a two week IETF last call. A copy of the strawman -08 draft is available here: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt Please send any issues to the AAA WG mailing list, using the format described below: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Mon Feb 3 11:13: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 LAA11735 for ; Mon, 3 Feb 2003 11:13:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8702791205; Mon, 3 Feb 2003 11:16:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 523E491220; Mon, 3 Feb 2003 11:16:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 514C991205 for ; Mon, 3 Feb 2003 11:16:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CC485DF99; Mon, 3 Feb 2003 11:16:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by segue.merit.edu (Postfix) with SMTP id 1C03F5DDDC for ; Mon, 3 Feb 2003 11:16:23 -0500 (EST) Received: (cpmta 21450 invoked from network); 3 Feb 2003 08:16:21 -0800 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.64) with SMTP; 3 Feb 2003 08:16:21 -0800 X-Sent: 3 Feb 2003 16:16:21 GMT Message-Id: <5.2.0.9.2.20030203111318.03390ce0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Feb 2003 11:16:02 -0500 To: Bernard Aboba , aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Issue 399: NASREQ Security Issues In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 2/2/2003 07:58 AM -0800, Bernard Aboba wrote: >Submitter name: Bernard Aboba >Submitter email address: aboba@internaut.com >Date first submitted: February 2, 2003 >Document: NASREQ-10 >Comment type: T >Priority: S >Section: 6.2 > >In Diameter NASREQ as well as in RADIUS, it is possible for a >rogue NAS to send forged AVPs. For example, NAS A could >send an Origin-Host, NAS-Identifier or NAS-IP-Address AVP with information >corresponding to NAS B, and could even forge AVPs relating >to the client such as the Called-Station-Id or Calling-Station-Id. <..snip...> I have added the suggested text to Diameter NAS draft 11. If there are any desired changes to the suggested text, let me know. Dave. From owner-aaa-wg@merit.edu Mon Feb 3 13:37: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 NAA16675 for ; Mon, 3 Feb 2003 13:37:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DACB89122A; Mon, 3 Feb 2003 13:40:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEB039122B; Mon, 3 Feb 2003 13:40:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77E1E9122A for ; Mon, 3 Feb 2003 13:40:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FD6F5DF97; Mon, 3 Feb 2003 13:40:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 295C35DDDC for ; Mon, 3 Feb 2003 13:40:32 -0500 (EST) Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h13IeIZ19144; Mon, 3 Feb 2003 12:40:20 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DDKD1AL; Mon, 3 Feb 2003 12:40:18 -0600 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.30]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DD8M9ZB; Mon, 3 Feb 2003 12:40:19 -0600 Message-ID: <3E3EB662.5080405@iqmail.net> Date: Mon, 03 Feb 2003 12:35:14 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Mitton Cc: aaa-wg@merit.edu, Bernard Aboba Subject: Re: [AAA-WG]: Issue 395: NASREQ-10 comments References: <5.2.0.9.2.20030131094717.042d71b0@getmail.mitton.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, I understand your point on the ABNF grammar now, thanks for the clarification. It will help me explain to anyone who also might be confused by this. I think you declined/commented on the ABNF grammar portion of my comment. What about the first part of my comment? That is: "We should not talk about CHAP-Response AVP in the CHAP-Algorithm AVP section." I don't mind, if we decide to leave it as is, but it looks odd when I read the draft to see text, even requirement such as: The CHAP-Response AVP MUST be present in the CHAP-Auth AVP, in the CHAP-Algorithm AVP section of the draft. Regards, Kuntal David Mitton wrote: >> ---------------------------------------------------------------- >> >> Description of issue >> Submitter name: Kuntal Chowdhury >> Submitter email address: chowdury@nortelnetworks.com >> Date first submitted: 12/28/02 >> Reference: >> Document: nasreq >> Comment type: T >> Priority: 1 >> Section: 4.2.6 >> Rationale/Explanation of issue: >> >> CHAP with MD5 5 >> The CHAP response is computed using the procedure described in >> [PPPCHAP]. The CHAP-Response AVP MUST be present in the CHAP- >> Auth AVP. >> >> Comment: We should not talk about CHAP-Response AVP in the CHAP-Algorithm >> AVP section. Also according to the ABNF grammar, the CHAP-Response AVP is >> not mandatory in CHAP-Auth AVP. >> >> Proposal: Delete the paragraph below CHAP with MD5 5. > > > >> declined - The CHAP-Auth grouping was designed to allow a number of > different CHAP algorithms, each with seperate AVP constraints. Because > only one has been defined, it looks a little odd. The CHAP-Response AVP > is grammarically optional, but required by the specification of CHAP > with MD5. > Other algorithms may require other AVPs and not CHAP-Response. > From owner-aaa-wg@merit.edu Wed Feb 5 18:38:05 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 SAA15443 for ; Wed, 5 Feb 2003 18:38:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC74D91288; Wed, 5 Feb 2003 18:41:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5F099128B; Wed, 5 Feb 2003 18:41:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83B2891288 for ; Wed, 5 Feb 2003 18:41:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5ACBE5DE14; Wed, 5 Feb 2003 18:41:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id CB8BF5DEC1 for ; Wed, 5 Feb 2003 18:41:29 -0500 (EST) Received: (cpmta 29495 invoked from network); 5 Feb 2003 15:41:28 -0800 Received: from 24.147.218.40 (HELO dmitton.mitton.com) by smtp.mitton.com (209.228.32.65) with SMTP; 5 Feb 2003 15:41:28 -0800 X-Sent: 5 Feb 2003 23:41:28 GMT Message-Id: <5.2.0.9.2.20030205181727.04c99250@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Feb 2003 18:33:38 -0500 To: Kuntal Chowdhury From: David Mitton Subject: Re: [AAA-WG]: Issue 395: NASREQ-10 comments Cc: aaa-wg@merit.edu, Bernard Aboba In-Reply-To: <3E3EB662.5080405@iqmail.net> References: <5.2.0.9.2.20030131094717.042d71b0@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Ummm... I don't see why not. Note the description of the CHAP-Auth grouping clearly sets us up for this breakdown of the description. Section 4.2.4 sentence 3 > The AVP containing the CHAP response depends upon the value of > the CHAP-Algorithm AVP. [In the next draft; I have changed "AVP" to "AVPs", "depends" to "depend" and arranged the order of the AVPs to agree with the ABNF] The Algorithm value sets the requirements for the other optional AVPs in the group. Each AVP may be required differently for other algorithms. Dave. On 2/3/2003 12:35 PM -0600, Kuntal Chowdhury wrote: >Hi David, > >I understand your point on the ABNF grammar now, thanks for the >clarification. It will help me explain to anyone who also might be >confused by this. > >I think you declined/commented on the ABNF grammar portion of my comment. >What about the first part of my comment? That is: > >"We should not talk about CHAP-Response AVP in the CHAP-Algorithm AVP >section." > >I don't mind, if we decide to leave it as is, but it looks odd when I read >the draft to see text, even requirement such as: The CHAP-Response AVP >MUST be present in the CHAP-Auth AVP, in the CHAP-Algorithm AVP section of >the draft. > >Regards, >Kuntal > > >David Mitton wrote: > >>>---------------------------------------------------------------- >>> >>>Description of issue >>>Submitter name: Kuntal Chowdhury >>>Submitter email address: chowdury@nortelnetworks.com >>>Date first submitted: 12/28/02 >>>Reference: >>>Document: nasreq >>>Comment type: T >>>Priority: 1 >>>Section: 4.2.6 >>>Rationale/Explanation of issue: >>> >>> CHAP with MD5 5 >>> The CHAP response is computed using the procedure described in >>> [PPPCHAP]. The CHAP-Response AVP MUST be present in the CHAP- >>> Auth AVP. >>> >>>Comment: We should not talk about CHAP-Response AVP in the CHAP-Algorithm >>>AVP section. Also according to the ABNF grammar, the CHAP-Response AVP is >>>not mandatory in CHAP-Auth AVP. >>> >>>Proposal: Delete the paragraph below CHAP with MD5 5. >> >> >> declined - The CHAP-Auth grouping was designed to allow a number of >> different CHAP algorithms, each with seperate AVP constraints. Because >> only one has been defined, it looks a little odd. The CHAP-Response AVP >> is grammarically optional, but required by the specification of CHAP with MD5. >>Other algorithms may require other AVPs and not CHAP-Response. > > > > > From owner-aaa-wg@merit.edu Mon Feb 10 08:05: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 IAA07779 for ; Mon, 10 Feb 2003 08:05:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CC8F91232; Mon, 10 Feb 2003 08:08:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5487E91234; Mon, 10 Feb 2003 08:08:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4B4491232 for ; Mon, 10 Feb 2003 08:08:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id A0E585E00B; Mon, 10 Feb 2003 08:08:49 -0500 (EST) 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 B233D5DD8C for ; Mon, 10 Feb 2003 08:08:48 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1AD7c220674 for ; Mon, 10 Feb 2003 15:07:38 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Feb 2003 15:08:46 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 15:08:45 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 15:08:45 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 15:08:45 +0200 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]: FW: New version of the SIP-AAA reqs draft Date: Mon, 10 Feb 2003 15:08:43 +0200 Message-ID: Thread-Topic: New version of the SIP-AAA reqs draft Thread-Index: AcLQ+hytq5KQ+EOQRSOrVoXu1wM+3wAC0vNg From: To: Cc: X-OriginalArrivalTime: 10 Feb 2003 13:08:45.0380 (UTC) FILETIME=[8AD12840:01C2D105] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA07779 FYI -----Original Message----- From: ext Gonzalo Camarillo [mailto: Sent: 10 February, 2003 13:47 To: sipping Cc: Loughney John (NRC/Helsinki) Subject: New version of the SIP-AAA reqs draft Hi, we have released a new version of the SIP-AAA requirements draft. Based on the feedback we have received, it seems that the draft now includes all the requirements people had in mind. (Although further comments are, of course, always welcome). We will now try to get the work on the diameter-based solution going. Regards, Gonzalo -------- Original Message -------- Subject: [Sipping] I-D ACTION:draft-ietf-sipping-aaa-req-02.txt,.pdf Date: Thu, 06 Feb 2003 09:30:09 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: sipping@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol Author(s) : J. Loughney, G. Camarillo Filename : draft-ietf-sipping-aaa-req-02.txt,.pdf Pages : 14 Date : 2003-2-5 As SIP services are deployed on the Internet, there is a need for authentication, authorization and accounting of SIP sessions. This document sets out the basic requirements for this work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-02.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-ietf-sipping-aaa-req-02.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-ietf-sipping-aaa-req-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-5140318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-aaa-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-aaa-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From owner-aaa-wg@merit.edu Wed Feb 12 19:10: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 TAA19367 for ; Wed, 12 Feb 2003 19:10:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 042FD91267; Wed, 12 Feb 2003 19:13:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C80B091269; Wed, 12 Feb 2003 19:13:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5A9F91267 for ; Wed, 12 Feb 2003 19:13:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8FDD05DECF; Wed, 12 Feb 2003 19:13:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EBB515DE2F for ; Wed, 12 Feb 2003 19:13:43 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1CN1Fq25360 for ; Wed, 12 Feb 2003 15:01:15 -0800 Date: Wed, 12 Feb 2003 15:01:15 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Roadmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've gotten a number of questions relating to the AAA WG roadmap over the last few weeks, so that it's probably worthwhile to review where we are. As many of you know, Diameter Base and Transport specifications have passed IESG review and are now awaiting publication by the RFC Editor. Diameter MIPv4 has completed IESG review, but is currently blocked pending resolution of IESG comments on MIPv4/AAA keys. My expectation is that this will get unblocked at some point in the next few months (don't have more precise info to impart at the moment). NASREQ has completed AAA WG last call, and is being revised for what we hope is the one of the final times before sending that to the IESG. Expect to see NASREQ-11 show up on the IETF archive within the next week. Next on the agenda is Diameter EAP. Now that RFC 2869bis has gone to IETF last call, we have a roadmap to completing this, which is as follows: a. Make sure that RFC 2869bis is carefully reviewed before publication as an RFC. b. Incorporate the fixes from RFC 2869 into Diameter EAP. c. Bring Diameter EAP to AAA WG last call. As noted below, IETF last call has begun on RFC 2869bis and will complete by 3-11-03. So a) is underway. An important goal is to get an EAP-01 draft out, incorporating the items in b) for discussion at IETF 56, so that we can move forward on c) by June 2003, roughly synchronous with the EAP Keying Framework document. By then, the goal is to have completed the lions share of the current WG charter, so that additional WG work items can be considered, such as the ones that 3GPP has been asking for. So the overall message is that we have some very short term goals to keep focussed on, namely finishing NASREQ and EAP. We are expecting substantial progress on both those items in the next few weeks. And once those items have progressed, we will be able to move on to the next phase. ================================================================================ Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to Informational From: The IESG Date: Wed, 12 Feb 2003 13:39:41 -0500 Reply-to: iesg@ietf.org Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- The IESG has received a request to consider RADIUS Support For Extensible Authentication Protocol (EAP) as an Informational RFC. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-11. Files can be obtained via http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt From owner-aaa-wg@merit.edu Thu Feb 13 01:00:50 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 BAA25407 for ; Thu, 13 Feb 2003 01:00:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7AF491208; Thu, 13 Feb 2003 01:04:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 559F79120F; Thu, 13 Feb 2003 01:04:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFAF791208 for ; Thu, 13 Feb 2003 01:03:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id D32C75DEE0; Thu, 13 Feb 2003 01:03:33 -0500 (EST) 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 96C245DEDB for ; Thu, 13 Feb 2003 01:03:33 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E20A06A906; Thu, 13 Feb 2003 08:03:26 +0200 (EET) Message-ID: <3E4B351B.7030709@kolumbus.fi> Date: Thu, 13 Feb 2003 08:03:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA WG Roadmap References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the update. A few comments inline: > a. Make sure that RFC 2869bis is carefully reviewed before publication > as an RFC. > > b. Incorporate the fixes from RFC 2869 into Diameter EAP. > > c. Bring Diameter EAP to AAA WG last call. Sounds good. > As noted below, IETF last call has begun on RFC 2869bis and will complete > by 3-11-03. So a) is underway. > > An important goal is to get an EAP-01 draft out, incorporating the items > in b) for discussion at IETF 56, so that we can move forward on c) by > June 2003, roughly synchronous with the EAP Keying Framework document. That reminds me: does the final Diameter EAP contain the key transport attributes? Or will they be done separately? Will CMS be required at some point? Jari From owner-aaa-wg@merit.edu Thu Feb 13 02:10: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 CAA06095 for ; Thu, 13 Feb 2003 02:10:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A43669120F; Thu, 13 Feb 2003 02:14:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67FD291212; Thu, 13 Feb 2003 02:14:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FCBA9120F for ; Thu, 13 Feb 2003 02:14:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40ACF5E027; Thu, 13 Feb 2003 02:14:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id AEA2F5DE84 for ; Thu, 13 Feb 2003 02:14:16 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1D61iZ15778; Wed, 12 Feb 2003 22:01:44 -0800 Date: Wed, 12 Feb 2003 22:01:44 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: AAA WG Roadmap In-Reply-To: <3E4B351B.7030709@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > That reminds me: does the final Diameter EAP contain the key transport > attributes? Or will they be done separately? Will CMS be required at some > point? That is a good question. My personal advice would be to handle the definition of the Diameter Keying AVPs in a separate document, which would be referenced non-normatively in Diameter EAP. My take is that we could get Diameter EAP done by June 2003 if we did that, without a lot of risk. Since there *are* some issues to work through in Diameter EAP outside of keys (witness the discussion on RFC 2869bis), I believe this would allow us to focus on the protocol aspects of Diameter EAP and bring it to completion quickly. Then once RFC 2869bis, Diameter EAP and RFC 2284bis are done, we can move our attention to the EAP Keying Framework and the corresponding Diameter Keying AVPs (I believe they go together because the first will justify the second). At this point, after the analysis of the "rogue NAS" attack in RFC 2869bis, I believe we have a better handle on the binding problem that Jesse Walker was talking about. The problem is most apparent when fast handoff is involved and a rogue NAS can cause MSKs to be generated and sent anywhere at will. However, this will only result in leaking of information on the MK if the MSK derivation mechanism is weak in some way. While we have some functionality in Diameter that isn't present in RADIUS that is relevant to the problem (Route-Record AVP), if there is an untrusted proxy in the system, then keys can be compromised. Fixing this requires both CMS as well as the right Grouped Key AVP, binding the MSK to parameters relating to its use. The construction also needs to be live so as to protect against cut and paste attack. However, I don't believe that this issue exists for direct NAS-AAA server scenarios, and so one could argue that IPsec or TLS key wrap w/mutual authentication is sufficient. If there is a counter-example, I would like to see it -- but I haven't been able to come up with one, after a year of trying. From owner-aaa-wg@merit.edu Sat Feb 15 12:43: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 MAA05317 for ; Sat, 15 Feb 2003 12:43:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DEC391254; Sat, 15 Feb 2003 12:46:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEA4F91255; Sat, 15 Feb 2003 12:46:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62A1191254 for ; Sat, 15 Feb 2003 12:45:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5FA15DF33; Sat, 15 Feb 2003 12:45:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from shardagate2.mahindrabt.com (shardagate2.mahindrabt.com [203.124.158.3]) by segue.merit.edu (Postfix) with ESMTP id 1EACB5DDB7 for ; Sat, 15 Feb 2003 12:45:35 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate2.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA05948 for ; Sat, 15 Feb 2003 23:15:00 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Sat, 15 Feb 2003 23:03:31 +0530 Date: Sat, 15 Feb 2003 23:03:31 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: skawade@mahindrabt.com Received: from dscp01801 ([10.5.4.5]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id XAA21030 for ; Sat, 15 Feb 2003 23:15:15 +0530 X-MSReally-From: skawade@mahindrabt.com Message-ID: <002901c2d51a$c2bfa240$0504050a@mahindrabt.com> From: "Santosh Kawade" To: Subject: [AAA-WG]: Radius - Mobility Agents Date: Sat, 15 Feb 2003 23:20:42 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C2D548.DBE25500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C2D548.DBE25500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Can one use Radius server as AAA server for mobile agents ( HA, = FA , MN ) ?. If yes can any one point some open source of radius+mobile. Regards, Santosh ********************************************************* Disclaimer This message (including any attachments) contains=20 confidential information intended for a specific=20 individual and purpose, and is protected by law.=20 If you are not the intended recipient, you should=20 delete this message and are hereby notified that=20 any disclosure, copying, or distribution of this message, or the taking of any action based on it,=20 is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com ------=_NextPart_000_0026_01C2D548.DBE25500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
        = Can one use=20 Radius server as AAA server for mobile agents ( HA, FA , MN ) ?. If yes = can any=20 one point some open source of radius+mobile.
 
Regards,
Santosh

*********************************************************
Disclaimer

This message (including any attachments) contains
confidential information intended for a specific
individual and purpose, and is protected by law.
If you are not the intended recipient, you should
delete this message and are hereby notified that
any disclosure, copying, or distribution of this
message, or the taking of any action based on it,
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

------=_NextPart_000_0026_01C2D548.DBE25500-- From owner-aaa-wg@merit.edu Sat Feb 15 21:10:12 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 VAA09948 for ; Sat, 15 Feb 2003 21:10:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C01F91277; Sat, 15 Feb 2003 21:13:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3F4491279; Sat, 15 Feb 2003 21:13:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CC3691277 for ; Sat, 15 Feb 2003 21:13:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72DF95DF1B; Sat, 15 Feb 2003 21:13:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id E75B65DDBF for ; Sat, 15 Feb 2003 21:13:40 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1G2CqY07001; Sat, 15 Feb 2003 20:12:53 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LNXFK7N; Sat, 15 Feb 2003 20:12:53 -0600 Received: from iqmail.net (archt4zf.us.nortel.com [47.102.193.28]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1DD8N1AQ; Sat, 15 Feb 2003 20:12:53 -0600 Message-ID: <3E4EF251.1060103@iqmail.net> Date: Sat, 15 Feb 2003 20:07:13 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Santosh Kawade Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Radius - Mobility Agents References: <002901c2d51a$c2bfa240$0504050a@mahindrabt.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 Most of the 3gpp2 spec based networks use RADIUS as AAA for Mobile IPv4 deployment. The relevant spec (P.S0001-B) can be found at www.3gpp2.org. Hope this helps. Kuntal Santosh Kawade wrote: > Hi All, > Can one use Radius server as AAA server for mobile agents ( HA, > FA , MN ) ?. If yes can any one point some open source of radius+mobile. > > Regards, > Santosh > > ********************************************************* > Disclaimer > > This message (including any attachments) contains > confidential information intended for a specific > individual and purpose, and is protected by law. > If you are not the intended recipient, you should > delete this message and are hereby notified that > any disclosure, copying, or distribution of this > message, or the taking of any action based on it, > is strictly prohibited. > > ********************************************************* > Visit us at http://www.mahindrabt.com > From owner-aaa-wg@merit.edu Tue Feb 18 19:30:36 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 TAA12662 for ; Tue, 18 Feb 2003 19:30:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A4AA9124A; Tue, 18 Feb 2003 19:33:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D816E9124F; Tue, 18 Feb 2003 19:33:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 914929124A for ; Tue, 18 Feb 2003 19:33:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B6E05DF81; Tue, 18 Feb 2003 19:33:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from halt-in.cisco.com (halt-in.cisco.com [171.70.144.185]) by segue.merit.edu (Postfix) with ESMTP id 3299A5DE41 for ; Tue, 18 Feb 2003 19:33:25 -0500 (EST) Received: from cisco.com (171.70.156.17) by halt-in.cisco.com with ESMTP; 18 Feb 2003 16:33:40 -0800 Received: from gwzw2k (sjc-vpn1-68.cisco.com [10.21.96.68]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id QAA21063; Tue, 18 Feb 2003 16:33:24 -0800 (PST) Reply-To: From: "Glen Zorn" To: "AAA WG" Cc: Subject: [AAA-WG]: Issue 397 Date: Tue, 18 Feb 2003 16:33:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C2D76B.74597F10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C2D76B.74597F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It's not clear to me what this issue has to do w/EAP, aside from the fact that the key distributed might be used w/EAP. ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 ------=_NextPart_000_0019_01C2D76B.74597F10 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Disposition: attachment; filename="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0019_01C2D76B.74597F10-- From owner-aaa-wg@merit.edu Wed Feb 19 13:34:03 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 NAA04245 for ; Wed, 19 Feb 2003 13:33:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21B1A91238; Wed, 19 Feb 2003 13:37:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5B9A9126F; Wed, 19 Feb 2003 13:37:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D978D91238 for ; Wed, 19 Feb 2003 13:37:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF64F5E0FC; Wed, 19 Feb 2003 13:37:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 199005DFE2 for ; Wed, 19 Feb 2003 13:37:29 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1JHNRM14837; Wed, 19 Feb 2003 09:23:27 -0800 Date: Wed, 19 Feb 2003 09:23:27 -0800 (PST) From: Bernard Aboba To: Glen Zorn Cc: AAA WG , Subject: Re: [AAA-WG]: Issue 397 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The issue appears to be whether some portion of the MSK needs to be Reserved. Today my understanding is that only the first 64B of the MSK is sent from AAA server to NAS [RFC2548], even though 192B of MSK are defined in [RFC2716]. Note that the last 64B of the MSK defined in [RFC2716] are a known quantity (the IV); this is an artifact of US Export regulations which I believe are no longer in effect. This leaves the following situation: MSK(0,63) Sent from AAA server to NAS. MSK(64,127) Not currently transported from AAA server to NAS. MSK(128,192) Known quantity. Not currently transported from AAA server to NAS. Here MSK(X,Y) = portion of the MSK from bytes X to Y inclusive. MSK(0,31) is known in IEEE 802.11i as the PMK. Some Fast Handoff proposals are attempting to achieve Perfect Forward Secrecy (PFS). The idea here is for the keying material sent to NAS1 to be cryptographically independent of the keying material sent to NAS2. In order to enable PFS, the keying material sent must be derived from a quantity not known by NASes. In some of the existing proposals, it has been suggested that this material be derived from the EAP Master Key (MK). The problem with this is that the formulas typically assume a single PRF (e.g. TLS PRF). This implies that the schemes will only work with selected EAP methods (EAP TLS, PEAP, EAP TTLS, etc.), because in some EAP methods (EAP SIM), it is not possible to export the Master Key and plug it into a PRF other than that for which the protocol was designed. To make the schemes more general, it is necessary for them to use a quantity that is exported by all EAP Methods -- namely the MSK. However, in examining the MSK it becomes clear that only MSK(64,127) could qualify for such usage. MSK(128,192) may be a known quantity, so this won't do. MSK(0,63) also won't work, because the goal is to enable PFS. That means that the keying material for NAS2 can't depend on the keying material for the previous NAS. If it does, then if that NAS were compromised, then it would also compromise the next NAS. So the only quantity left that would work is MSK(64,127). Some of the questions this raises are: a. Is 64B of keying material transported between AAA server and NAS *always* sufficient? b. Does it make sense to reserve some portion of the MSK (64B?) to be generated by the EAP method, but *not* sent to the NAS? c. In order to compensate for MSK(128,192) potentially being a known quantity, should EAP methods generate more than 192B of MSK? From owner-aaa-wg@merit.edu Wed Feb 19 13:40: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 NAA04379 for ; Wed, 19 Feb 2003 13:40:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD15191271; Wed, 19 Feb 2003 13:43:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8AD191273; Wed, 19 Feb 2003 13:43:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9284691271 for ; Wed, 19 Feb 2003 13:43:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81D8D5E05C; Wed, 19 Feb 2003 13:43:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 07EF25E039 for ; Wed, 19 Feb 2003 13:43:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1JHUZd15280 for ; Wed, 19 Feb 2003 09:30:35 -0800 Date: Wed, 19 Feb 2003 09:30:35 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ-11 arrives... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk NASREQ-10 has now completed AAA WG last call, and the comments have been incorporated into -11, which is now on the IETF archive. We are now getting down to the wire -- this is your last chance to read and comment on this draft before it goes to the IESG. If you haven't looked it over carefully yet, you owe it to yourself (and the WG) to read it. Here is where you can find NASREQ-11: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-11.txt From owner-aaa-wg@merit.edu Thu Feb 20 08:02:29 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 IAA11294 for ; Thu, 20 Feb 2003 08:02:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D757291231; Thu, 20 Feb 2003 08:06:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A115391234; Thu, 20 Feb 2003 08:06:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C15091231 for ; Thu, 20 Feb 2003 08:06:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4218E5DE2D; Thu, 20 Feb 2003 08:06:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from shardagate.mahindrabt.com (shardagate.mahindrabt.com [203.124.158.2]) by segue.merit.edu (Postfix) with ESMTP id 828F15E12E for ; Thu, 20 Feb 2003 08:05:56 -0500 (EST) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA28264 for ; Thu, 20 Feb 2003 18:35:48 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Thu, 20 Feb 2003 18:23:47 +0530 Date: Thu, 20 Feb 2003 18:23:47 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: arunks@mahindrabt.com Received: from dscp00968 ([10.5.4.7]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA24110 for ; Thu, 20 Feb 2003 18:35:39 +0530 Message-ID: <004a01c2d8e1$9f5e3df0$0704050a@mahindrabt.com> From: "arun" To: Subject: [AAA-WG]: Session State and failover Date: Thu, 20 Feb 2003 18:41:46 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, When a client or agent is failing over to the secondary peer, it passes over the pending request queue to the secondary peer. But is it not essential for the secondary server to know about the session state in which the primary was in ? Things like the number of sessions established and the state of these sessions. arun. ------------------------------------------------------------------------- We have begun to contemplate our origins; starstuff pondering the stars. ...Carl Sagan ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com From owner-aaa-wg@merit.edu Thu Feb 20 10:20:41 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 KAA17349 for ; Thu, 20 Feb 2003 10:20:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ECBA291267; Thu, 20 Feb 2003 10:24:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA5A89126B; Thu, 20 Feb 2003 10:24:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B9CB91267 for ; Thu, 20 Feb 2003 10:24:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D4945E06D; Thu, 20 Feb 2003 10:24:17 -0500 (EST) 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 8D7145E063 for ; Thu, 20 Feb 2003 10:24:16 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1KFN3201154 for ; Thu, 20 Feb 2003 17:23:03 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Feb 2003 17:24:14 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 17:24:14 +0200 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]: Redirect host Date: Thu, 20 Feb 2003 17:24:14 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023018702E4@esebe014.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 398: Fixes for the RFC Editor Thread-Index: AcLEAWYJxWyJHvg0SPqulYOOm/I7XADAYhUwBHpFGyA= From: To: X-OriginalArrivalTime: 20 Feb 2003 15:24:14.0818 (UTC) FILETIME=[20787420:01C2D8F4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17349 Hi, Sorry to raise this issue so late and at a wrong time. Description of issue : Redirect-host AVP Submitter name: Ghadiyaram Venkata Kishore Submitter email address: ext-venkata.ghadiyaram@nokia.com Date first submitted: 20-02-2003 Document: base Comment type: T & E Priority: 1 Rationale/Explanation of issue: 1. Redirected-host, Redirected-Host-Usage and Redirected-Host-Cache-Time are used instead of Redirect-Host, Redirect-Host-Usage and Redirect-Host-Cache-Time in sections 8.3.2 and 8.5.2 where RAA and ASA messages are defined respectively. 2. Since DiameterIdentity is FQDN can the identity of the server be derived from its DiameterURI? If yes please ignore the following text in the message. Redirect-host AVP is of type DiameterURI, which tells the transport information of the server to be contacted, but not the identity of the server. The identity of the server is required, to know whether a Diameter connection already exists between the client and the server. With the current specification during redirection, the client is provided with the DiameterURI of the server, and the client has to initiate a capabilities-exchange with the server. If the connection with the server already exists, it rejects the connection and the message could not be forwarded. Proposed change : Change Redirect-host type to Gouped as follows. Redirect-host ::= < AVP Header: 292 > { Redirect-Identity } { Redirect-URI } Redirect-Identity - The server identity of type DiameterIdentity. Redirect-URI - The URI of the server of type DiameterURI. From owner-aaa-wg@merit.edu Fri Feb 21 01:00: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 BAA10367 for ; Fri, 21 Feb 2003 01:00:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4972D9121E; Fri, 21 Feb 2003 01:03:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 133819123A; Fri, 21 Feb 2003 01:03:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30BFD9121E for ; Fri, 21 Feb 2003 01:03:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 01D0C5DF77; Fri, 21 Feb 2003 01:03:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from web20711.mail.yahoo.com (web20711.mail.yahoo.com [66.163.169.152]) by segue.merit.edu (Postfix) with SMTP id 081635DF1B for ; Fri, 21 Feb 2003 01:02:59 -0500 (EST) Message-ID: <20030221060258.82339.qmail@web20711.mail.yahoo.com> Received: from [203.124.158.2] by web20711.mail.yahoo.com via HTTP; Thu, 20 Feb 2003 22:02:58 PST Date: Thu, 20 Feb 2003 22:02:58 -0800 (PST) From: arun kumar Subject: [AAA-WG]: Session State and failover To: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-631248056-1045807378=:81217" Sender: owner-aaa-wg@merit.edu Precedence: bulk --0-631248056-1045807378=:81217 Content-Type: text/plain; charset=us-ascii Hello, When a client or agent is failing over to the secondary peer, it passes over the pending request queue to the secondary peer. But is it not essential for the secondary server to know about the session state in which the primary was in ? Things like the number of sessions established and the state of these sessions. arun. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-631248056-1045807378=:81217 Content-Type: text/html; charset=us-ascii Hello,

When a client or agent is failing over to the secondary peer, it passes over
the pending request queue to the secondary peer. But is it not essential for
the secondary server to know about the session state in which the primary
was in ? Things like the number of sessions established and the state of
these sessions.

arun.


Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-631248056-1045807378=:81217-- From owner-aaa-wg@merit.edu Fri Feb 21 10:12:39 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 KAA02858 for ; Fri, 21 Feb 2003 10:12:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 394969129C; Fri, 21 Feb 2003 10:15:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0ACE89129E; Fri, 21 Feb 2003 10:15:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3EB59129C for ; Fri, 21 Feb 2003 10:15:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEB6E5E16F; Fri, 21 Feb 2003 10:15:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2B3485E14B for ; Fri, 21 Feb 2003 10:15:21 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1LE26A00472 for ; Fri, 21 Feb 2003 06:02:06 -0800 Date: Fri, 21 Feb 2003 06:02:06 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 401: No security considerations section Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 401: No Security Considerations Section Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 02-19-2003 Reference: Document: EAP-00 Comment type: Technical Priority: S Section: Rationale/Explanation of issue: The draft currently has no security considerations section. Find enclosed a contribution filling this need: 4. Security Considerations 4.1. Security requirements Diameter/EAP is used in order to provide authentication and authorization for network access. As a result, both the Diameter and EAP portions of the conversation are open to attack. Examples include: [1] An adversary may attempt to acquire confidential data and identities by snooping Diameter/EAP packets. [2] An adversary may attempt to modify packets containing Diameter messages. [3] An adversary may attempt to inject packets into a Diameter conversation. [4] An adversary may attempt to replay a Diameter exchange. [5] An adversary may attempt to disrupt the EAP negotiation, in order to weaken the authentication, or gain access to user passwords. [6] An authenticated NAS may attempt to forge attributes, including NAS-IP-Address, NAS-Identifier, Called-Station-Id, or Calling-Station-Id. [7] A rogue (unauthenticated) NAS may attempt to impersonate a legitimate NAS. [8] An attacker may attempt to act as a man-in-the-middle. To address these threats, it is necessary to support confidentiality, data origin authentication, integrity, and replay protection on a per- packet basis. Bi-directional authentication between the Diameter client and server also needs to be provided. There is no requirement that the identities of Diameter clients and servers be kept confidential (e.g., from a passive eavesdropper). Diameter Base protocol [BASE] provides support for both IPsec and TLS transmission layer security, addressing threats 1-4. The other security issues are discussed below. 4.2. Security issues This section provides more detail on the vulnerabilities identified in above, and how they may be mitigated. Vulnerabilities include: Privacy issues Connection hijacking Replay attacks Negotiation attacks Impersonation Man in the middle attacks Multiple databases 4.3.1. Privacy issues Since Diameter messages may contain the User-Name attribute as well as NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on Diameter traffic may be able to determine the geographic location of users in real time. In wireless networks, it is often assumed that Diameter traffic is physically secure, since it typically travels over the wired network and that this limits the release of location information. However, it is possible for an authenticated attacker to spoof ARP packets from another Access Point so as to cause diversion of Diameter traffic onto the wireless network. In this way an attacker may obtain Diameter packets from which it can glean location information. To address this vulnerability, IPsec or TLS can be used to provide per-packet authentication, integrity protection, confidentiality and replay protection of Diameter messages, as specified in [BASE]. 4.3.2. Connection hijacking An attacker may attempt to inject packets into the conversation between the NAS and the Diameter server, or between the Diameter server and the security server. To address this vulnerability, IPsec or TLS can be used to provide per-packet authentication, integrity protection, confidentiality and replay protection of Diameter messages, as specified in [BASE]. 4.3.3. Replay attacks The Diameter protocol relies upon IPsec or TLS transmission layer security to prevent replay. However, where untrusted proxies are present, this is not sufficient to prevent replay of CMS-protected objects. These objects, when included in Diameter EAP messages, MUST contain sufficient liveness to address replay attacks. 4.3.4. Negotiation attacks In a negotiation attack, a rogue NAS, tunnel server, Diameter agent or Diameter server causes the authenticating peer to choose a less secure authentication method so as to make it easier to obtain the user's password. For example, a session that would normally be authenticated with EAP would instead authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via one EAP type occurs via a less secure EAP type, such as MD5-Challenge. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those described in [Masters]. Protection against negotiation attacks requires the elimination of downward negotiations. This can be achieved by protecting the Diameter exchange using IPsec or TLS as described in [BASE]. Alternatively, the vulnerability can be mitigated via implementation of per-connection policy on the part of the authenticating peer, and per-user policy on the part of the Diameter server. For the authenticating peer, authentication policy should be set on a per- connection basis. Per-connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service. With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, there is a presumption that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, it is likely that there is some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such as CHAP or PAP. In wireless networks, the service advertisement itself may be spoof- able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network. For a NAS, it may not be possible to determine whether a peer is required to authenticate with EAP until the peer's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. Alternatively, some peer might be authenticated locally by the NAS while other peers are authenticated via Diameter. In such cases, if any peers of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every session. This avoids forcing an EAP-capable client to support more than one authentication type, which could weaken security. If CHAP is negotiated, the NAS will pass the User-Name and CHAP- Password attributes to the Diameter server in an Access-Request packet. If the user is not required to use EAP, then the Diameter server will respond with an Access-Accept or Access-Reject packet as appropriate. However, if CHAP has been negotiated but EAP is required, the Diameter server MUST respond with an Access-Reject, rather than an Access- Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP. If EAP is negotiated but is not supported by the Diameter agent or server, then the server or agent MUST respond with an Access-Reject. In these cases, a PPP NAS MUST send an LCP-Terminate and disconnect the user. This is the correct behavior since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be fulfilled. An EAP- capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable Diameter proxy could prove difficult to diagnose, since a user connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user connecting at another location (and encountering an EAP- incapable proxy) might be consistently disconnected. 4.3.5. Impersonation When Diameter requests are forwarded by an agent, the NAS-IP-Address or NAS-IPv6-Address attributes may not correspond to the source address. Since the NAS-Identifier attribute need not contain an FQDN, it also may not correspond to the source address, even indirectly. This implies that it is possible for a rogue NAS to forge NAS-IP- Address, NAS-IPv6-Address or NAS-Identifier AVPs in order to impersonate another NAS. This could result in Diameter messages, including Grouped Key AVPs, being sent to the wrong NAS. ALthough the rogue NAS is authenticated by the Diameter agent or server within TLS or IKE, this authentication information may not be accessible to the Diameter agent or server, making it unable to detect the forgery. In addition, it is possible for attributes such as the Called-Station-Id and Calling-Station-Id to be forged as well. To address these vulnerabilities it is necessary for the Grouped Key AVP to contain enough information to "bind" the key to the NAS and client with which it is to be used. For example, AVPs identifying the NAS (Origin-Host, NAS-IPV6-Address, NAS-IP-Address, NAS-Port, etc.) can be included as well as attributes identifying the client (Calling-Station-Id, Framed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id, Session-Id, etc.). Diameter servers SHOULD check whether NAS-Identifier, Origin-Host, NAS-IP-Address or NAS-IPv6-Address AVPs match an entry in the Route-Record AVP. If the NAS-Identifier AVP is present, such a check may not be possible since the NAS-Identifier may not correspond to an FQDN. Similarly, where a PTR RR does not exist corresponding to the NAS-IP-Address or NAS-IPv6-Address, determination of the FQDN may not be possible. Also, where a NAT exists between the Diameter client and server, checking the NAS-IP-Address or NAS-IPv6-Address attributes may not be feasible. To allow verification of session parameters such as the Called-Station- Id and Calling-Station-Id, they can be sent by the EAP peer to the EAP server, and covered by an EAP method-specific message integrity check. The Diameter server can then check the parameters sent by the EAP client against those claimed by the NAS. If a discrepancy is found, an error can be logged. 4.3.6. Man in the middle attacks As a result, attackers gaining control of a Diameter agent will be able to modify EAP packets in transit. This is the case even where IPsec or TLS is used to protect Diameter messages, as described in [BASE]. To protect against this vulnerability, object security mechanisms SHOULD be used wherever untrusted Diamter agents are present. These include Diameter CMS [CMS], a work in progress. 4.3.7. Multiple databases In many cases a security server will be deployed along with a Diameter server in order to provide EAP services. Unless the security server also functions as a Diameter server, two separate user databases will exist, each containing information about the security requirements for the user. This represents a weakness, since security may be compromised by a successful attack on either of the servers, or their databases. With multiple user databases, adding a new user may require multiple operations, increasing the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In this case, three stores of user information may exist. In order to address these threats, consolidation of databases is recommended. This can be achieved by having both the Diameter server and security server store information in the same database; by having the security server provide a full Diameter implementation; or by consolidating both the security server and the Diameter server onto the same machine. From owner-aaa-wg@merit.edu Fri Feb 21 10:15: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 KAA02957 for ; Fri, 21 Feb 2003 10:15:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D1C5B912A0; Fri, 21 Feb 2003 10:16:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1B7A912A9; Fri, 21 Feb 2003 10:16:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4933A912B2 for ; Fri, 21 Feb 2003 10:16:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E1605E191; Fri, 21 Feb 2003 10:16:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9FB4D5E18F for ; Fri, 21 Feb 2003 10:16:42 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1LE3RE00555 for ; Fri, 21 Feb 2003 06:03:27 -0800 Date: Fri, 21 Feb 2003 06:03:27 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Rewrite of Issue 397: No MSK Reservation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I've rewritten this one, to improve clarity. Issue 397: MSK Reservation Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: February 19, 2002 Reference: http://mmlab.snu.ac.kr/research/publication/docs/pwc2002_shpack.pdf Document: EAP-00 Comment type: Technical Priority: S Section: The NASREQ-09 keying attributes allow keying material to be sent to the NAS that may be needed to be kept on the AAA Server. In RFC 2548, only 64 Bytes of the 128 Byte MSK are transported. The rest remains on the AAA server. One question is how much keying material is needed to be transported to provide keying material for the link layer ciphersuite, and how much is exported by the EAP method, but not transported. If MSK(0,31) and MSK(32,63) are transported, then MSK(64,127) is the only keying material exported by an EAP method that is known only by the EAP client and server. All the fast handoff proposals under discussion so far require a "roaming key". The cryptographic properties of the roaming key vary between proposals, but proposals providing Perfect Forward Secrecy (PFS) require inputs that are known only by the EAP client and server. As noted above, the only keying material exported by an EAP method that meets this requirement is MSK (64,127). While it's not the purpose of Diameter EAP to decide how fast handoff is done, it is a relevant question as to whether MSK (64,127) needs to be "Reserved" for some reason, remaining known only by the EAP client and server or whether this should also be transported to the NAS. From owner-aaa-wg@merit.edu Fri Feb 21 10:30: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 KAA03529 for ; Fri, 21 Feb 2003 10:30:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C135A91263; Fri, 21 Feb 2003 10:33:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9304C9129E; Fri, 21 Feb 2003 10:33:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0288591263 for ; Fri, 21 Feb 2003 10:31:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE1E45E173; Fri, 21 Feb 2003 10:31:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5A2DA5DEB5 for ; Fri, 21 Feb 2003 10:31:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1LEIi001409 for ; Fri, 21 Feb 2003 06:18:44 -0800 Date: Fri, 21 Feb 2003 06:18:44 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: [Issue 294]: NASREQ Key Distribution Insecure Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk A concrete example of an attack that takes advantage of lack of key binding has been found in Diameter NASREQ. This involves one NAS impersonating another. If the Route-Record AVP isn't checked carefully by each Diameter agent along the path, by the time the Request reaches the Diameter Server, it will be unable to verify the Origin-Host AVP. As a result, it may send keys to the wrong NAS. Even with the text suggested for resolution of Issue 399, it isn't entirely clear whether the problem is fixable. If the proper DNS RRs aren't installed, it may not be possible to verify an Origin-Host or Route-Record AVP against a NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier AVP. The proposed resolution is to bind the key to the NAS and client for which it is to be used, so that the impersonated NAS can detect a mismatch. It is also necessary for some "liveness" to be incorporated into the package so that keys cannot be replayed. From owner-aaa-wg@merit.edu Fri Feb 21 20:15: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 UAA20367 for ; Fri, 21 Feb 2003 20:15:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2FCC912D0; Fri, 21 Feb 2003 20:18:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF5DA912D1; Fri, 21 Feb 2003 20:18:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7085912D0 for ; Fri, 21 Feb 2003 20:17:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A3225DE74; Fri, 21 Feb 2003 20:17:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1AF5A5E197 for ; Fri, 21 Feb 2003 20:17:55 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1M04bH01040 for ; Fri, 21 Feb 2003 16:04:37 -0800 Date: Fri, 21 Feb 2003 16:04:37 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Last Call: IANA Considerations for RADIUS to Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Last Call: IANA Considerations for RADIUS to Proposed Standard -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: Last Call: IANA Considerations for RADIUS to Proposed Standard From: The IESG Date: Fri, 21 Feb 2003 10:46:12 -0500 Reply-to: iesg@ietf.org Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- The IESG has received a request to consider IANA Considerations for RADIUS as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-3-21. Files can be obtained via http://www.ietf.org/internet-drafts/draft-aboba-radius-iana-01.txt -------------------------------------------------------------------------------- Prev by Date: I-D ACTION:draft-culley-iwarp-mpa-02.txt,.pdf Next by Date: Last Call: Advice for Internet Subnetwork Designers to BCP Previous by thread: I-D ACTION:draft-culley-iwarp-mpa-02.txt,.pdf Next by thread: Last Call: Advice for Internet Subnetwork Designers to BCP Index(es): Date Thread From owner-aaa-wg@merit.edu Mon Feb 24 08:52:51 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 IAA14598 for ; Mon, 24 Feb 2003 08:52:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C25F69123D; Mon, 24 Feb 2003 08:56:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 861319123E; Mon, 24 Feb 2003 08:56:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4514C9123D for ; Mon, 24 Feb 2003 08:56:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 369FE5E1A9; Mon, 24 Feb 2003 08:56:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id B676C5E114 for ; Mon, 24 Feb 2003 08:56:27 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1ODuQKV020151 for ; Mon, 24 Feb 2003 14:56:26 +0100 (MET) Received: from wadias.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.22.253]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDV2BYLA; Mon, 24 Feb 2003 14:56:25 +0100 Received: from madrid.ericsson.se ([159.107.27.5]) by wadias.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id h1ODuOgf024353 for ; Mon, 24 Feb 2003 14:56:24 +0100 (MET) Message-ID: <3E5A2487.7B8E8F1B@madrid.ericsson.se> Date: Mon, 24 Feb 2003 14:56:23 +0100 X-Sybari-Trust: d3d1a212 9ffcebbb 7a95d2f4 00000138 From: Maria-Carmen Belinchon Reply-To: emecbv@madrid.es.eu.ericsson.se X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Fwd: I-D ACTION:draft-belinchon-aaa-diameter-mm-app-00.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, This is an update of draft-johansson-aaa-diameter-mm-app-02.txt for the Diameter Multimedia Application. The main updates are the alignment with Diameterv17, a more clear description of the commands, how to use them, the errors to be reported and the meaning of the AVPs. The command codes are now aligned with the draft-loughney-aaa-cc-3gpp-02.txt In the Atlanta meeting there was an approval hum to accept this. Since the draft needs to be chartered, we are looking for comments. Bernard, is this way correct to handle this? br, MCarmen Internet-Drafts@ietf.org wrote: > 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-00.txt > Pages : 37 > Date : 2003-2-21 > > This document specifies a Diameter application that supports the > authentication, authorization, and collection of accounting > information for Session Initiation Protocol (SIP) services rendered > to a client node. This application, combined with the base Diameter > protocol and appropriate SIP extensions, allows SIP User Agents (UAs) > to obtain services from SIP servers that are connected to a Diameter > infrastructure. When combined with the Inter-Domain capability of > the base protocol, service may even be obtained from SIP servers that > belong to foreign domains, as would be encountered by roaming mobile > nodes. > Note that the specification defined here may be used independently of > the authentication technique used for authenticating a node's link > layer or network-layer access. In particular, we do not require the > client node to be authenticated for access with the use of either the > Mobile IP [3] or NASREQ [11] Diameter application. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-belinchon-aaa-diameter-mm-app-00.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-00.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-00.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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <2003-2-21160912.I-D@ietf.org> From owner-aaa-wg@merit.edu Mon Feb 24 10:24:59 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 KAA16562 for ; Mon, 24 Feb 2003 10:24:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5037591244; Mon, 24 Feb 2003 10:28:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D9A49124A; Mon, 24 Feb 2003 10:28:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 019C691244 for ; Mon, 24 Feb 2003 10:28:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF02B5DF3B; Mon, 24 Feb 2003 10:28:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 794755DDB6 for ; Mon, 24 Feb 2003 10:28:32 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1OEF0O14755 for ; Mon, 24 Feb 2003 06:15:01 -0800 Date: Mon, 24 Feb 2003 06:15:00 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Agenda items for IETF 56 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you have an agenda item for the AAA WG meeting at IETF 56, please email it to the chairs. From owner-aaa-wg@merit.edu Mon Feb 24 21:33: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 VAA03465 for ; Mon, 24 Feb 2003 21:33:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31ACC9122E; Mon, 24 Feb 2003 21:36:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB87491233; Mon, 24 Feb 2003 21:36:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E19E9122E for ; Mon, 24 Feb 2003 21:36:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6860C5DDC0; Mon, 24 Feb 2003 21:36:44 -0500 (EST) 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 910475DDAD for ; Mon, 24 Feb 2003 21:36:43 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1P2dnm12664 for ; Tue, 25 Feb 2003 04:39:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Feb 2003 04:36:42 +0200 Received: from beebh001.NOE.Nokia.com ([172.28.19.38]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 04:36:42 +0200 Received: from beebe003.NOE.Nokia.com ([172.28.19.30]) by beebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 10:36:36 +0800 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]: FW: I-D ACTION:draft-liu-aaa-diameter-session-mobility-00.txt Date: Tue, 25 Feb 2003 10:36:37 +0800 Message-ID: Thread-Topic: [AAA-WG]: Agenda items for IETF 56 Thread-Index: AcLcGXGbZ5kEYgMlQkyoZ2UEXDoihQAV35IQ From: To: X-OriginalArrivalTime: 25 Feb 2003 02:36:36.0996 (UTC) FILETIME=[B7EF4C40:01C2DC76] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA03465 Hi all, This is a new Diameter application, and it can be used to enrich the standard Diameter user session management so that the Diameter user session of a mobile node can be handled within its local domain. Your comments are welcome. Best regards, roger -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: I-D ACTION:draft-liu-aaa-diameter-session-mobility-00.txt From: Internet-Drafts@ietf.org Date: Mon, 24 Feb 2003 06:44:02 -0500 Reply-to: Internet-Drafts@ietf.org Sender: owner-ietf-announce@ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter User Session Mobility Application Author(s) : Q. Liu et al. Filename : draft-liu-aaa-diameter-session-mobility-00.txt Pages : 16 Date : 2003-2-21 A mobile node will change its access router frequently during a Diameter session and the relevant AAA parameters may also be transferred between the access routers. However, the home AAA server does not know the movement of the mobile node before the mobile node re-authenticates, and a request from the home AAA server will always be forwarded to the former realm. Therefore, an efficient way is needed to forward the request to the new access router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liu-aaa-diameter-session-mobility-00.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-liu-aaa-diameter-session-mobility-00.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-liu-aaa-diameter-session-mobility-00.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. From owner-aaa-wg@merit.edu Fri Feb 28 04:50:57 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 EAA18815 for ; Fri, 28 Feb 2003 04:50:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 753359125B; Fri, 28 Feb 2003 04:54:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44BFB91276; Fri, 28 Feb 2003 04:54:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34D149125B for ; Fri, 28 Feb 2003 04:54:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 209945DE0D; Fri, 28 Feb 2003 04:54:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id A0E0E5DE05 for ; Fri, 28 Feb 2003 04:54:36 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1S9sZnS003363 for ; Fri, 28 Feb 2003 10:54:35 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Feb 2003 10:54:34 +0100 Message-ID: From: "Harri Hakala (LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-hakala-diameter-credit-control-06.txt Date: Fri, 28 Feb 2003 10:54:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi All, We have submitted a new version of the Diameter credit control draft to the IETF archive. Until it shows up in the archive, it can be found: http://standards.ericsson.net/harri/draft-hakala-diameter-credit-control-06.txt Here is a list of updates compared to draft -05: 1. A server or client is not required to implement all functionality in the CCA. The optionality has been clarified in the draft, the modified AVPs are the following: 1a. Unknown/unsupported value responded with error: - Subscription-Id-Type 1b. Unknown AVP ignored, i.e. 'M'-bit removed from AVP Flag table - Accounting-Correlation-Id - Abnormal-Termination-Reason - Cost-Information 2. New Result-Code value 'DIAMETER_RATING_FAILED'. We would appreciate if you can read it and provide your comments. Regards.......Harri From owner-aaa-wg@merit.edu Fri Feb 28 05:52: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 FAA20018 for ; Fri, 28 Feb 2003 05:52:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7486F91266; Fri, 28 Feb 2003 05:56:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4017991276; Fri, 28 Feb 2003 05:56:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13A8A91266 for ; Fri, 28 Feb 2003 05:56:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8B145DE1D; Fri, 28 Feb 2003 05:56:17 -0500 (EST) 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 1D8C85DE15 for ; Fri, 28 Feb 2003 05:56:17 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1SAxQm13287 for ; Fri, 28 Feb 2003 12:59:26 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 12:56:15 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 12:56:14 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 12:56:14 +0200 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]: FW: WGLC on draft-ietf-sipping-aaa-req-02.txt Date: Fri, 28 Feb 2003 12:56:13 +0200 Message-ID: Thread-Topic: WGLC on draft-ietf-sipping-aaa-req-02.txt Thread-Index: AcLfFjDRAdrEm/9FR/y1Fpz6RcTDDAAAa7EA From: To: Cc: X-OriginalArrivalTime: 28 Feb 2003 10:56:14.0403 (UTC) FILETIME=[0319D930:01C2DF18] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA20018 Folks, we have had some discussions about the SIP-AAA work in the SIPPING mailing list lately. In order to take advantage of this interest, I would like to WGLC the SIP-AAA requirements draft. http://www.ietf.org/internet-drafts/draft-ietf-sipping-aaa-req-02.txt By last calling this document, we want to try to keep the focus of the WG on the requirements, before we jump into discussing solutions. This WGLC will end on April 4th. Please send comments to the authors or the SIPPING WG. Thanks, Gonzalo & John