From mailman-bounces@ietf.org Fri Oct 1 06:30:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14957 for ; Fri, 1 Oct 2004 06:30:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKp5-0003oy-3E for mip4-web-archive@ietf.org; Fri, 01 Oct 2004 06:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJfu-0001uS-IP for mip4-web-archive@ietf.org; Fri, 01 Oct 2004 05:26:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mip4-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:10:25 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mip4-web-archive@ietf.org: List Password // URL ---- -------- mip4@ietf.org imreeb https://www1.ietf.org/mailman/options/mip4/mip4-web-archive%40ietf.org From mip4-bounces@ietf.org Fri Oct 1 17:17:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22079 for ; Fri, 1 Oct 2004 17:17:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDUv7-0001Nk-9g for mip4-web-archive@ietf.org; Fri, 01 Oct 2004 17:26:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTmw-0007nN-DM; Fri, 01 Oct 2004 16:13:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTQs-0002wb-AJ; Fri, 01 Oct 2004 15:51:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11105; Fri, 1 Oct 2004 15:51:08 -0400 (EDT) Message-Id: <200410011951.PAA11105@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 01 Oct 2004 15:51:08 -0400 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dynamic-assignment-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Dynamic Home Agent Assignment Author(s) : M. Kulkarni, et al. Filename : draft-ietf-mip4-dynamic-assignment-03.txt Pages : 22 Date : 2004-10-1 Mobile IP (RFC 3344) uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). This draft proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-dynamic-assignment-03.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-mip4-dynamic-assignment-03.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: <2004-10-1153627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-dynamic-assignment-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-dynamic-assignment-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-1153627.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon Oct 4 17:03:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21897 for ; Mon, 4 Oct 2004 17:03:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEa8s-0005xL-6Y for mip4-web-archive@ietf.org; Mon, 04 Oct 2004 17:13:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ2O-0007Uz-26; Mon, 04 Oct 2004 16:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYmZ-0008GH-05; Mon, 04 Oct 2004 15:46:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08755; Mon, 4 Oct 2004 15:46:00 -0400 (EDT) Message-Id: <200410041946.PAA08755@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:46:00 -0400 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-vpn-problem-solution-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Traversal Across IPsec-based VPN Gateways Author(s) : S. Vaarala Filename : draft-ietf-mip4-vpn-problem-solution-00.txt Pages : 44 Date : 2004-10-4 This document outlines the proposed solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec are not required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-solution-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-vpn-problem-solution-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-ietf-mip4-vpn-problem-solution-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. --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: <2004-10-4152654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-solution-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-solution-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152654.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon Oct 4 17:57:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00899 for ; Mon, 4 Oct 2004 17:57:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEayW-0000ou-Iv for mip4-web-archive@ietf.org; Mon, 04 Oct 2004 18:06:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEanu-0003dT-9V; Mon, 04 Oct 2004 17:55:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEak7-00025N-7N for mip4@megatron.ietf.org; Mon, 04 Oct 2004 17:51:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00382 for ; Mon, 4 Oct 2004 17:51:36 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEatF-000869-Vm for mip4@ietf.org; Mon, 04 Oct 2004 18:01:07 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i94Lp6lS019235 for ; Mon, 4 Oct 2004 16:51:06 -0500 (CDT) Message-ID: <4161C5CA.5D53828A@alcatel.com> Date: Mon, 04 Oct 2004 16:51:06 -0500 From: Tim Ozugur X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Subject: [Mip4] BroadNets 2004: Early Registration extended to Oct. 10, 2004 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit (Apologies if you are receiving this message more than once) ----------------------------------------------------------------------- CALL FOR PARTICIPATION BroadNets 2004 First International Conference on Broadband Networking Technically Co-Sponsored by IEEE Communications Society In-Cooperation with ACM SIGMOBILE Co-sponsored by: CreateNet, Inc. ICST National Science Foundation (Student Travel Awards) Philips, Inc. (Bronze Level Sponsor; Student Best Paper Awards) Hilton San Jose and Towers San Jose, California, USA October 25 - 29, 2004 http://www.broadnets.org Early Registration Deadline: Oct. 10, 2004 Discounted Hotel Reservation Deadline: Oct. 4, 2004 ----------------------------------------------------------------------- BroadNets 2004 is a new conference focusing on broadband networking and covers the entire gamut of next generation networks with ultra-high bandwidth available all the way from access networks (xDSL, Cable, EPON, Broadband Wireless, multi-Gigabit uplinks), to regional and metropolitan networks to wide-area core networks. Keynote speakers include: * Vinton Cerf, Senior Vice President of Technology Strategy for MCI * Dr. Lawrence G. Roberts, CEO of Anagran and Founder and Vice Chairman of Caspian Networks The conference will consist of two symposia, panels, six tutorials and seven workshops: * Broadband Optical Symposium includes 32 papers covering topics such as optical burst and packet switching, IP over optical networks, survivability, routing and wavelength assignment, traffic and wavelength grooming, switching and routing, and optical network design and resource allocation. * Broadband Wireless Symposium includes 38 papers covering topics such as 802.11 networks, UWB and 802.15 based networks, performance analysis, wireless multimedia, resource management, multimedia transport, contention and media access, routing in ad hoc networks, and sensor networks. * TUTORIALS (on Oct 25 and Oct 29): - Broadband Metro and Access Networks (Full-day), Dr. Raj Jain - Optical Mesh Survivability (Half-day), Dr. Suresh Subramaniam and Dr. Srinivasan Ramasubramanian - Advancements in Metro Optical Network Architecture and Technologies (Half-day) Dr. Loukas Paraschis - Wireless Broadband: Services, Networks, and Management (Full-day), Dr. Mani Subramanian - Multimedia Transmission over Spectrum Agile Radio Wireless Networks (Half-day) Dr. Mihaela van der Schaar - A Practical Perspective on the Role of Optical Layer Protection (Half-day) Dr. Ori Gerstel WORKSHOPS co-located with BroadNets 2004: - Broadband Wireless Multimedia (BroadWim) - Broadband Advanced Sensor Networks (BaseNets) - Broadband Wireless Services and Applications (BroadWise) - Networks for Grid Applications (GridNets) - Optical Burst Switching (OBS) - Provisioning and Transport for Hybrid Networks (PathNets) - Traffic Grooming Workshops will be held on Monday, October 25 and Friday, October 29. For the advance program of BroadNets 2004, as well as registration and travel information, please visit: http://www.broadnets.org. CONFERENCE ORGANIZING COMMITTEE ------------------------------- BroadNets Conference General Chair: Dr. Raj Jain, Nayna Networks/Ohio State University, raj@nayna.com _________________________________ Broadband Optical Networking Symposium Co-Chairs: Dr. Ori Gerstel, Cisco Systems, ogerstel@cisco.com Dr. Jason Jue, University of Texas at Dallas, jjue@utdallas.edu Technical Program Co-Chairs: Dr. Galen Sasaki, University of Hawaii, sasaki@spectra.eng.hawaii.edu Dr. Suresh Subramaniam, George Washington University, suresh@gwu.edu __________________________________ Broadband Wireless Networking Symposium Chair: Dr. Zhensheng Zhang, San Diego Research Center, zzhang@ieee.org Technical Program Co-Chairs: Dr. Parameswaran Ramanathan, University of Wisconsin-Madison, parmesh@ece.wisc.edu Dr. Thomas Hou, Virginia Tech, thou@vt.edu _____________________________ Panels Co-Chairs: Dr. Byrav Ramamurthy, University of Nebraska - Lincoln, byrav@cse.unl.edu Dr. Loukas Paraschis, Cisco Systems, loukas@cisco.com Dr. Mohammed Atiquzzaman, University of Oklahoma, atiq@ou.edu Tutorials Co-Chairs: Dr. Hakki Candan Cankaya, Alcatel USA, hakki.cankaya@alcatel.com Dr. Surendar Chandra, Univ of Notre Dame, surendar@cse.nd.edu Workshops Chair: Dr. Nasir Ghani, Tennessee Tech University, nghani@ieee.org Dr. Rajeev Shorey, National University of Singapore and IBM Research India, rajeev@comp.nus.edu.sg Exhibits and Sponsorships Chairs: Dr. Samrat Ganguly, NEC Labs, samrat@nec-labs.com Dr. Javier Aracil, Universidad Publica de Navarra, Spain, javier.aracil@unavarra.es Publicity Co-Chairs: Dr. Tim Ozugur, Alcatel USA, tim.ozugur@alcatel.com Dr. Gaoxi Xiao, Nanyang Technological Univ. Singapore, egxxiao@ntu.edu.sg Dr. Marcos Rogerio Salvador, CPqD Telecom & IT Solutions, marcosrs@cpqd.com.br Local Arrangements Chair: Dr. Subhankar Dhar, San Jose State University, dhar_s@cob.sjsu.edu Sukesh Pai, Microsoft Corp. sukeshp@microsoft.com Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, University of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 6 12:47:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11762 for ; Wed, 6 Oct 2004 12:47:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFF6G-0006i5-NQ for mip4-web-archive@ietf.org; Wed, 06 Oct 2004 12:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEw9-0001pd-DS; Wed, 06 Oct 2004 12:46:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFDrF-00051C-IL for mip4@megatron.ietf.org; Wed, 06 Oct 2004 11:37:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07376 for ; Wed, 6 Oct 2004 11:37:34 -0400 (EDT) Received: from imail.nextel.com ([168.73.245.115] helo=atlhpmx4.nextel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFE0l-0002CR-2m for mip4@ietf.org; Wed, 06 Oct 2004 11:47:28 -0400 Received: from NXCLMXS1.us.nextel.com (nxclmxs1.nextel.com [10.9.8.241]) by atlhpmx4.nextel.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id LAA22495 for ; Wed, 6 Oct 2004 11:37:05 -0400 (EDT) Received: from nxclmex04.us.nextel.com ([10.9.8.19]) by NXCLMGW1.us.nextel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Oct 2004 11:36:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2004 11:36:22 -0400 Message-ID: <9D9ABBE39A7DD84C9B39BBDFFDCD9666E50D01@nxclmex04.us.nextel.com> Thread-Topic: Conformance test suite for mobileipv4 agents Thread-Index: AcSrsE/wJyXghbEwSri4d9IGjH/qNgABN/3AAAE+RWA= From: "Zhou, Yong" To: X-OriginalArrivalTime: 06 Oct 2004 15:36:22.0786 (UTC) FILETIME=[3BBF0E20:01C4ABBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 06 Oct 2004 12:46:44 -0400 Subject: [Mip4] Conformance test suite for mobileipv4 agents X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Hi there, I am trying to find a conformance test suite for Mobile-IP-v4 agents. I noticed that there is one called "basic Conformance tests for mobileip agents" by Sun Microsystems, which had been presented at cthon2002. Any information about this particular test suite or any other conformance test suite will be appreciated. Thanks, -Yong Yong Zhou 703-433-4797 [O] 703-930-3677 [M] yong.zhou@nextel.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 6 16:29:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06377 for ; Wed, 6 Oct 2004 16:29:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFIZh-00066E-G1 for mip4-web-archive@ietf.org; Wed, 06 Oct 2004 16:39:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHlv-0007AO-N2; Wed, 06 Oct 2004 15:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHdo-0003Ro-4x; Wed, 06 Oct 2004 15:40:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27352; Wed, 6 Oct 2004 15:39:57 -0400 (EDT) Message-Id: <200410061939.PAA27352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 06 Oct 2004 15:39:57 -0400 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-vpn-problem-statement-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Problem Statement: Mobile IPv4 Traversal of VPN Gateways Author(s) : F. Adrangi, H. Levkowetz Filename : draft-ietf-mip4-vpn-problem-statement-03.txt Pages : 19 Date : 2004-10-6 Deploying Mobile-IP v4 in networks which are connected to the Internet through a VPN (Virtual Private Network) gateway presents some problems which do not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-statement-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-vpn-problem-statement-03.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-mip4-vpn-problem-statement-03.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: <2004-10-6152743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6152743.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed Oct 6 18:27:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25144 for ; Wed, 6 Oct 2004 18:27:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKP4-0007sP-0A for mip4-web-archive@ietf.org; Wed, 06 Oct 2004 18:36:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKEA-0004Ea-HF; Wed, 06 Oct 2004 18:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKCa-000419-QY; Wed, 06 Oct 2004 18:24:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24967; Wed, 6 Oct 2004 18:24:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKMB-0007nl-2n; Wed, 06 Oct 2004 18:33:59 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CFKC4-0003SD-1x; Wed, 06 Oct 2004 18:23:32 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 06 Oct 2004 18:23:32 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mip4@ietf.org Subject: [Mip4] Last Call: 'Experimental Message, Extension and Error Codes for Mobile IPv4' to Proposed Standard X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The IESG has received a request from the Mobility for IPv4 WG to consider the following document: - 'Experimental Message, Extension and Error Codes for Mobile IPv4 ' as a Proposed Standard 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 2004-10-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip4-experimental-messages-02.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 11 15:19:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06788 for ; Mon, 11 Oct 2004 15:19:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5sS-00071n-7o for mip4-web-archive@ietf.org; Mon, 11 Oct 2004 15:30:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH5ZO-00064f-LH; Mon, 11 Oct 2004 15:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH5Wf-0004jz-Qf for mip4@megatron.ietf.org; Mon, 11 Oct 2004 15:08:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05119 for ; Mon, 11 Oct 2004 15:08:04 -0400 (EDT) Received: from av5-2-sn3.vrr.skanova.net ([81.228.9.114]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5hF-0006q7-8A for mip4@ietf.org; Mon, 11 Oct 2004 15:19:02 -0400 Received: by av5-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 76C90380A9; Mon, 11 Oct 2004 21:07:32 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av5-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6744038096 for ; Mon, 11 Oct 2004 21:07:32 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 50D3738015 for ; Mon, 11 Oct 2004 21:07:32 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CH5W8-0001Sh-5b for mip4@ietf.org; Mon, 11 Oct 2004 21:07:32 +0200 Message-ID: <416AD9F0.2030504@levkowetz.com> Date: Mon, 11 Oct 2004 21:07:28 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Mip4] IANA numbers for AAA-Key X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi, IANA number assignment for the 4 messages described in RFC-to-be draft-ietf-mip4-aaa-key has now been proposed. As there are implementations of earlier versions of this specification out in the wild, and as the numbering space for subtypes was collapsed from 4 individual subtype spaces to one common subtype space, we would like to verify that the assignments make sense to all of you who have earlier implementations. Extension numbers: Value Name ------- ---------------------------------------- 40 MN-FA-KeyGen Request 41 MN-FA-KeyGen Reply 42 MN-HA-KeyGen Request 43 MN-HA-KeyGen Reply KeyGen subtypes per [RFC-ietf-mip4-aaa-key-06.txt] Subtype Value Name ------- ---------------------------------------- 1 KeyGen Request/Reply from AAA 7 Not to be allocated - used by early implementations Replay Method Identifier - per [RFC-ietf-mip4-aaa-key-06.txt] Replay Method Name -------------- ---------------------------------- 0-1 Reserved 2 Timestamps 3 Nonces 4-65535 Unallocated Please comment to the list. Regards, Henrik and Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 13 18:57:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22580 for ; Wed, 13 Oct 2004 18:57:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHsF4-0002Xe-Pb for mip4-web-archive@ietf.org; Wed, 13 Oct 2004 19:09:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHrwS-0004WD-I3; Wed, 13 Oct 2004 18:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHrqd-0002Q9-Uq for mip4@megatron.ietf.org; Wed, 13 Oct 2004 18:43:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21859 for ; Wed, 13 Oct 2004 18:43:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHs1g-0002HD-BE for mip4@ietf.org; Wed, 13 Oct 2004 18:55:20 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9DMFIP17295; Wed, 13 Oct 2004 15:15:18 -0700 X-mProtect: <200410132215> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtwKYNR; Wed, 13 Oct 2004 15:15:16 PDT Message-ID: <416DAFA2.6D4E363C@iprg.nokia.com> Date: Wed, 13 Oct 2004 15:43:46 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung Subject: Re: [Mip4] Request to consider "faerr" specification as a working group document References: <4.3.2.7.2.20040316121552.02ce1920@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hello Kent, Thanks for your suggestions in this e-mail from March 16. I have created a new Internet Draft with the following changes according to your comments. Kent Leung wrote: > 1) In section 4, should the allowable code be just generically in > the range of 64-127 (Error Codes from the Foreign Agent)? > This avoids having to selectively choose which defined error > code is admissible in this extension? Does it make sense > for any code that exists today or will be added in the future > to not be carried in the extension? What happens when > event happens with error code that is not allowed, should FA > not add the extension or map to some allowable code? My proposed text comes in two parts. First, in section 4 just before the list of allowable status codes: Status codes allowable for use within the FA Error Extension are within the range 64-127. The currently specified codes are as follows: And, in the IANA considerations: The status codes which are allowable in the FA error extension are a subset of the status codes defined in the specification for Mobile IPv4 [2]. If, in the future, additional status codes are defined for Mobile IPv4, the definition for each new status code must indicate whether or not the new status code is allowable for use in the FA Error extension. The implication of these sentences is that the specified codes are the only ones valid today, and that new codes in the future that are added need to be intentionally made available for use in the new FA Error extension. > 2) Should there be a MN Considerations section to specify that > MN should deregister an accepted registration (status code > 0 or 1 from HA) which contains this FA error extension? This > would clean up such condition when HA thinks everything > is OK but FA disagree. Silence by MN provides implicit > acknowledgement to HA that FA and MN are OK with the > accepted registration reply. Else MN would notify the HA > that FA had problem with the reply. Here is some proposed text for the new section: 5. Mobile Node Considerations If a mobile node receives a successful Registration Reply (status code 0 or 1), with a FA Error extension indicating that the foreign agent is not honoring Registration Reply, the mobile node SHOULD then send a deregistration message to the home agent. In this way, the home agent will not maintain a registration status that is inconsistent with the status maintained by the foreign agent. > Should the specifics of the > FA error code be conveyed to HA by MN? This would allow MN, > FA, and HA to log the same error condition. This might be overkill. The information is available, and probably would be transferred out of band somehow. I didn't think it was worth defining yet another extension to the Registration Request to carry the foreign agent's status code, but it could certainly be done. I believe these were the only open issues relevant to the FA Error Extension Internet Draft. If there are any others, please let me know right away. Or, if I need to write some text to specify the abovementioned extension to the Registration Request, I can give it a try. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 18 14:34:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10433 for ; Mon, 18 Oct 2004 14:34:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJcXN-0006ck-L3 for mip4-web-archive@ietf.org; Mon, 18 Oct 2004 14:47:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbyj-0001U4-C7; Mon, 18 Oct 2004 14:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbfU-0006y4-7F for mip4@megatron.ietf.org; Mon, 18 Oct 2004 13:51:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06269 for ; Mon, 18 Oct 2004 13:51:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbrQ-0005cI-3E for mip4@ietf.org; Mon, 18 Oct 2004 14:03:57 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9IHNjg10308 for ; Mon, 18 Oct 2004 10:23:45 -0700 X-mProtect: <200410181723> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFwjvZA; Mon, 18 Oct 2004 10:23:43 PDT Message-ID: <417402E0.9EACD2C9@iprg.nokia.com> Date: Mon, 18 Oct 2004 10:52:32 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Mip4] Foreign Agent Error Extension available X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hello folks, I have submitted an Internet Draft for the abovementioned extension, and copied it over to my mostly-neglected website at the following URL: http://people.nokia.net/charliep/txt/mobilefaerr/faerr.txt Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 18 16:22:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19870 for ; Mon, 18 Oct 2004 16:22:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeDi-0000ew-R7 for mip4-web-archive@ietf.org; Mon, 18 Oct 2004 16:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdd0-0006wo-FS; Mon, 18 Oct 2004 15:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdU1-0004P4-8T; Mon, 18 Oct 2004 15:47:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17363; Mon, 18 Oct 2004 15:47:46 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJdfw-0008Ao-Jv; Mon, 18 Oct 2004 16:00:16 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9IJK0w18079; Mon, 18 Oct 2004 12:20:00 -0700 X-mProtect: <200410181920> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdK55IR1; Mon, 18 Oct 2004 12:19:59 PDT Message-ID: <41741E20.4078E966@iprg.nokia.com> Date: Mon, 18 Oct 2004 12:48:48 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: MIPv6 Signaling and Handoff Optimization Working Group Mailing List , Rajeev Koodli Subject: [Mip4] Proposed fast handover specification for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hello folks, We've built and tested an alternative scheme for fast handovers for Mobile IPv4. It is adapted from FMIPv6, and works well. The document has been submitted as an individual contribution, but we would like to see it adopted as a working group document within the [mipv4] working group if there is interest. The -00 draft is available at: http://people.nokia.net/charliep/txt/fmipv4/fmipv4.txt I'm not sure if there would be any interest on the [mipshop] mailing list; if not, please excuse the unnecessary distribution. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 18 22:00:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17968 for ; Mon, 18 Oct 2004 22:00:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjUd-0008A0-8U for mip4-web-archive@ietf.org; Mon, 18 Oct 2004 22:12:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJj6m-00041l-6L; Mon, 18 Oct 2004 21:48:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJitf-0000Wq-Gi; Mon, 18 Oct 2004 21:34:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15459; Mon, 18 Oct 2004 21:34:36 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJj5d-0007U0-Mk; Mon, 18 Oct 2004 21:47:09 -0400 Message-ID: <006601c4b57b$e2837f50$426015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Charles E.Perkins" , "Mobile IPv4 Mailing List" References: <41741E20.4078E966@iprg.nokia.com> Date: Mon, 18 Oct 2004 18:35:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: MIPv6 Signaling and Handoff Optimization Working Group Mailing List , Rajeev Koodli Subject: [Mip4] Re: [Mipshop] Proposed fast handover specification for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Charlie, In the absence of any vendor interest in implementing this and operator interest in deploying it, I think this draft belongs in MOBOPTS. I don't believe the charter is restricted to IPv6. jak ----- Original Message ----- From: "Charles E.Perkins" To: "Mobile IPv4 Mailing List" Cc: "MIPv6 Signaling and Handoff Optimization Working Group Mailing List" ; "Rajeev Koodli" Sent: Monday, October 18, 2004 12:48 PM Subject: [Mipshop] Proposed fast handover specification for Mobile IPv4 > > Hello folks, > > We've built and tested an alternative scheme for > fast handovers for Mobile IPv4. It is adapted > from FMIPv6, and works well. > > The document has been submitted as an individual > contribution, but we would like to see it adopted > as a working group document within the [mipv4] > working group if there is interest. > > The -00 draft is available at: > http://people.nokia.net/charliep/txt/fmipv4/fmipv4.txt > > I'm not sure if there would be any interest on > the [mipshop] mailing list; if not, please excuse > the unnecessary distribution. > > Regards, > Charlie P. > > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 18 22:48:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22397 for ; Mon, 18 Oct 2004 22:48:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJkFF-0000l0-JS for mip4-web-archive@ietf.org; Mon, 18 Oct 2004 23:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJjqA-0003lU-BG; Mon, 18 Oct 2004 22:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJjje-00039Y-6x; Mon, 18 Oct 2004 22:28:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20656; Mon, 18 Oct 2004 22:28:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjvd-0000Km-25; Mon, 18 Oct 2004 22:40:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9J20UE05237; Mon, 18 Oct 2004 19:00:30 -0700 X-mProtect: <200410190200> Nokia Silicon Valley Messaging Protection Received: from danira-pool049137.americas.nokia.com (10.241.49.137, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmEY7Tk; Mon, 18 Oct 2004 19:00:29 PDT Message-ID: <41747B92.3020908@iprg.nokia.com> Date: Mon, 18 Oct 2004 19:27:30 -0700 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf References: <41741E20.4078E966@iprg.nokia.com> <006601c4b57b$e2837f50$426015ac@dcml.docomolabsusa.com> In-Reply-To: <006601c4b57b$e2837f50$426015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: MIPv6 Signaling and Handoff Optimization Working Group Mailing List , Mobile IPv4 Mailing List , Rajeev Koodli Subject: [Mip4] Re: [Mipshop] Proposed fast handover specification for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Hello Jim, I never heard of a rule that restricted discussion within a working group to only those topics specified by ?operators? and ?vendors? (Whatever happened to IETF being composed of individuals??) Besides that, there's only been a few hours since I submitted my e-mail to the working group. I didn't expect to generate any noticeable support in that amount of time...?? It might take a little bit longer. People might be interested to take a look, and decide for themselves whether further action is at all warranted. I submitted the e-mail to [mipshop], because the protocol resembles a protocol of interest there. I submitted the e-mail to [mip4], because I thought there might be some interested parties. I agree that [mobopts] might be a good discussion forum also, but I'm not used to sending out messages to so many mailing lists at once. Regards, Charlie P. James Kempf wrote: >Charlie, > >In the absence of any vendor interest in implementing this and operator >interest in deploying it, I think this draft belongs in MOBOPTS. I don't >believe the charter is restricted to IPv6. > > jak > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 18 23:52:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27235 for ; Mon, 18 Oct 2004 23:52:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJlFI-00020A-Tf for mip4-web-archive@ietf.org; Tue, 19 Oct 2004 00:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkcL-0002r6-UA; Mon, 18 Oct 2004 23:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJkHA-0007yA-Ax; Mon, 18 Oct 2004 23:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23226; Mon, 18 Oct 2004 23:02:46 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJkT1-0000zS-A9; Mon, 18 Oct 2004 23:15:20 -0400 Message-ID: <00a801c4b588$399d3400$426015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Charles E. Perkins" References: <41741E20.4078E966@iprg.nokia.com> <006601c4b57b$e2837f50$426015ac@dcml.docomolabsusa.com> <41747B92.3020908@iprg.nokia.com> Date: Mon, 18 Oct 2004 20:01:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: MIPv6 Signaling and Handoff Optimization Working Group Mailing List , Mobile IPv4 Mailing List , Rajeev Koodli Subject: [Mip4] Re: [Mipshop] Proposed fast handover specification for Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit > I never heard of a rule that restricted discussion within a working > group to only those topics specified by ?operators? and ?vendors? > (Whatever happened to IETF being composed of individuals??) > Besides that, there's only been a few hours since I submitted my > e-mail to the working group. I didn't expect to generate any > noticeable support in that amount of time...?? > MIPSHOP was formed to take a specific set of fast handover drafts to experimental, then move them to MOBOPTS. The intent of forming MOBOPTS was that future questions of handover optimization for Mobile IP would be discussed there. The reason for doing this work in IRTF given at the time MOBOPTS was formed was because there was no interest in the vendor and operator community for deployment, because there were significant research questions about the technology. To my knowledge, I haven't seen any evidence that these questions have been answered to the extent that there's a protocol ready for standardization. Therefore, I believe MIP4 and MIPSHOP is the wrong venue for this draft. Besides, I don't see anything in the MIP4 charter about experimental work of this type. The charter is very explicit about being restricted to work that is relevent to deployment, with the exception of the existing LLMIPv4. To me, that means "vendor and operator interest", 'cause that is what drives deployment. For this draft to be discussed in MIP4, a charter revision would be required. For it to be discussed in MOBOPTS, similarly, the current charter would need to be expanded to include new drafts beyond the specific set explicitly listed in the charter, and I believe that would conflict with the original goal of forming MOBOPTS. Sorry to be so strict about this, but I've seen WGs get into trouble in the past by defocusing, ignoring their charter, and engaging in research work. jak -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 20 02:29:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27985 for ; Wed, 20 Oct 2004 02:29:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKAAp-0000Xf-VN for mip4-web-archive@ietf.org; Wed, 20 Oct 2004 02:42:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK8hh-0004TY-8M; Wed, 20 Oct 2004 01:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK5GQ-000283-I6 for mip4@megatron.ietf.org; Tue, 19 Oct 2004 21:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12784 for ; Tue, 19 Oct 2004 21:27:35 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5Se-0002K3-Sp for mip4@ietf.org; Tue, 19 Oct 2004 21:40:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2004 03:42:12 +0200 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9K1R1Sf004304; Wed, 20 Oct 2004 03:27:02 +0200 (MEST) Received: from cisco.com (dhcp-128-107-163-183.cisco.com [128.107.163.183]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYF27153; Tue, 19 Oct 2004 18:27:48 -0700 (PDT) Message-ID: <4175BEE0.3050204@cisco.com> Date: Tue, 19 Oct 2004 18:26:56 -0700 From: Alpesh Patel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org, Pete McCann , Henrik Levkowetz , Alpesh Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [Mip4] Question regarding 3012bis X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Hi - I have a basic concern regarding the use of HMAC_MD5 in 3012bis (I have had a few email exchanges with authors and WG chairs in this regards and am posting on WG chair suggestion) 3012bis defines GENAE (MN-AAA authenticator to be precise). The MN-AAA authenticator (MAAE) aids in AAA authentication by mapping the RRQ extensions to AAA attributes at FA or HA. With CHAP_SPI (value 2), the RRQ extensions are mapped to Radius chap attributes for chap authentication. The details are as follows: chap challenge = md5(RRQ data till the SPI field of MAAE) chap challenge = authenticator field from MAAE The authenticator calculation is specified in 3012bis and no issue with that in regards to MD5. This works and is widely deployed today. As a summary, the chap challenge above aids to compress the message. Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap challenge above is calculated using HMAC_MD5 and that the authenticator is calculated using HMAC_MD5. I have a concern with both these claims: 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is required between MN and FA/HA. One basic assumption is that in some domains/deployments this can be manually provisioned. One issue is how to decide on which :key: to use for challenge generation? No means to specify that. (one applicability of this draft is to leverage on a single MN/AAA secret and so, I cannot clearly see the reason for such a provisoned key). 2. second and primary concern is that there are no radius attributes (standard /VSAs), which can be used to authenticate a challenge response generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of that new attributes need to be defined and processing at Radius needs to be specified. In light of these two issues, I am wondering how HMAC_MD5 can be realistically used for authenticating MAAE today? Can someone demystify the usage of HMAC_MD5? Thanks Alpesh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 20 07:52:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25000 for ; Wed, 20 Oct 2004 07:52:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFDV-00070C-7J for mip4-web-archive@ietf.org; Wed, 20 Oct 2004 08:05:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDlO-00015p-1j; Wed, 20 Oct 2004 06:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKD6N-0007T3-RX for mip4@megatron.ietf.org; Wed, 20 Oct 2004 05:49:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15955 for ; Wed, 20 Oct 2004 05:49:43 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKDIf-0004J8-JI for mip4@ietf.org; Wed, 20 Oct 2004 06:02:34 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9K9nCIX000395; Wed, 20 Oct 2004 04:49:12 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i9K9n0X03690; Wed, 20 Oct 2004 04:49:01 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I5VN9K-0001X8-00; Wed, 20 Oct 2004 05:48:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16758.13447.53795.404726@gargle.gargle.HOWL> Date: Wed, 20 Oct 2004 04:48:55 -0500 From: Pete McCann To: Alpesh Patel Subject: [Mip4] Question regarding 3012bis In-Reply-To: <4175BEE0.3050204@cisco.com> References: <4175BEE0.3050204@cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Hi, Alpesh, I tend to agree that the usage of HMAC_CHAP_SPI is a bit under-specified. The usage of the "inner" MD5 for CHAP_SPI is as a compression function, to help solve the problem of limited space in RADIUS attributes. The problem is the text right now says: To compute the authenticator, apply MD5 [RFC1321] computed on the following data, in the order shown: High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge where the Type, Length, SPI, and possibly Subtype, are the fields of the authentication extension in use. For instance, all four of these fields would be in use when SPI == (CHAP_SPI or HMAC_CHAP_SPI) is used with the Generalized Authentication extension. The use of SPI number HMAC_CHAP_SPI indicates the use of HMAC_MD5 instead of MD5 in the above procedure. It seems to say that HMAC_MD5 replaces both the "inner" and "outer" occurences of MD5, but fails to specify the Key used for the "inner" HMAC_MD5. Because the purpose of this "inner" hash is to provide compression, not authentication, I think it is not reasonable to require a secret pre-shared key between the MN and FA. I think we have two realistic options at this point: 1) specify a fixed key for usage in the inner HMAC_MD5, or one that is derived from information in the RRQ; 2) revert back to MD5 for the inner hash for both CHAP_SPI and HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function Opinions? As for your second problem (RADIUS AVPs) I think that is not a problem that should be addressed with this document. If people want to support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs to carry an indication of the fact that HMAC_CHAP_SPI is being used. Also the home RADIUS server needs to be upgraded to support HMAC_MD5. It is not in the scope of 3012bis or the mip4 WG to do RADIUS extensions so I think we just have to understand that HMAC_CHAP_SPI cannot be supported by existing standard RADIUS servers until additional specification work has been done. -Pete Alpesh Patel writes: > Hi - > > I have a basic concern regarding the use of HMAC_MD5 in 3012bis > (I have had a few email exchanges with authors and WG chairs in > this regards and am posting on WG chair suggestion) > > 3012bis defines GENAE (MN-AAA authenticator to be precise). > The MN-AAA authenticator (MAAE) aids in AAA authentication by > mapping the RRQ extensions to AAA attributes at FA or HA. > > With CHAP_SPI (value 2), the RRQ extensions are mapped to > Radius chap attributes for chap authentication. The details are > as follows: > > chap challenge = md5(RRQ data till the SPI field of MAAE) > chap challenge = authenticator field from MAAE > > The authenticator calculation is specified in 3012bis and no issue > with that in regards to MD5. > > This works and is widely deployed today. > > As a summary, the chap challenge above aids to compress the message. > > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap > challenge above is calculated using HMAC_MD5 and that the authenticator > is calculated using HMAC_MD5. I have a concern with both these claims: > > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is > required between MN and FA/HA. One basic assumption is that in some > domains/deployments this can be manually provisioned. One issue is how > to decide on which :key: to use for challenge generation? No means to > specify that. (one applicability of this draft is to leverage on a > single MN/AAA secret and so, I cannot clearly see the reason for such a > provisoned key). > > 2. second and primary concern is that there are no radius attributes > (standard /VSAs), which can be used to authenticate a challenge response > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of > that new attributes need to be defined and processing at Radius needs to > be specified. > > In light of these two issues, I am wondering how HMAC_MD5 can be > realistically used for authenticating MAAE today? > > Can someone demystify the usage of HMAC_MD5? > > Thanks > Alpesh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 20 11:25:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14413 for ; Wed, 20 Oct 2004 11:25:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIXS-000307-NQ for mip4-web-archive@ietf.org; Wed, 20 Oct 2004 11:38:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHbX-0000HN-Q5; Wed, 20 Oct 2004 10:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGt0-0000OM-71 for mip4@megatron.ietf.org; Wed, 20 Oct 2004 09:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03778 for ; Wed, 20 Oct 2004 09:52:10 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKH5J-0000zW-7h for mip4@ietf.org; Wed, 20 Oct 2004 10:05:02 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2004 07:01:49 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9KDpXYJ025982; Wed, 20 Oct 2004 06:51:34 -0700 (PDT) Received: from cisco.com (sjc-vpn1-707.cisco.com [10.21.98.195]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYF58086; Wed, 20 Oct 2004 06:52:32 -0700 (PDT) Message-ID: <41766D67.2070207@cisco.com> Date: Wed, 20 Oct 2004 06:51:35 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Question regarding 3012bis References: <4175BEE0.3050204@cisco.com> <16758.13447.53795.404726@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Pete - regarding the first point, I have no strong preference. Either way is fine with me - use MD5 or HMAC_MD5 for compression to derive the challenge (don't see a benefit for the later from cryptographic point though). Regarding the 2nd point, my point is that it is really not usable - unless the attributes are available and there is some spec. which says how Radius should interpret it. I think we are doing a forward reference here. Atleast the text should clearly state this fact, IMO. -a Pete McCann wrote: >Hi, Alpesh, > >I tend to agree that the usage of HMAC_CHAP_SPI is a bit >under-specified. > >The usage of the "inner" MD5 for CHAP_SPI is as a compression >function, to help solve the problem of limited space in RADIUS >attributes. > >The problem is the text right now says: > > To compute the authenticator, apply MD5 [RFC1321] computed on the > following data, in the order shown: > > High-order byte from Challenge || Key || > MD5(Preceding Mobile IP data || > Type, Subtype (if present), Length, SPI) || > Least-order 237 bytes from Challenge > > where the Type, Length, SPI, and possibly Subtype, are the fields of > the authentication extension in use. For instance, all four of these > fields would be in use when SPI == (CHAP_SPI or HMAC_CHAP_SPI) is > used with the Generalized Authentication extension. The use of SPI > number HMAC_CHAP_SPI indicates the use of HMAC_MD5 instead of MD5 in > the above procedure. > >It seems to say that HMAC_MD5 replaces both the "inner" and "outer" >occurences of MD5, but fails to specify the Key used for the "inner" >HMAC_MD5. > >Because the purpose of this "inner" hash is to provide compression, >not authentication, I think it is not reasonable to require a secret >pre-shared key between the MN and FA. > >I think we have two realistic options at this point: > >1) specify a fixed key for usage in the inner HMAC_MD5, or one that > is derived from information in the RRQ; > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function > >Opinions? > >As for your second problem (RADIUS AVPs) I think that is not a problem >that should be addressed with this document. If people want to >support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs >to carry an indication of the fact that HMAC_CHAP_SPI is being used. >Also the home RADIUS server needs to be upgraded to support HMAC_MD5. >It is not in the scope of 3012bis or the mip4 WG to do RADIUS >extensions so I think we just have to understand that HMAC_CHAP_SPI >cannot be supported by existing standard RADIUS servers until >additional specification work has been done. > >-Pete > > >Alpesh Patel writes: > > Hi - > > > > I have a basic concern regarding the use of HMAC_MD5 in 3012bis > > (I have had a few email exchanges with authors and WG chairs in > > this regards and am posting on WG chair suggestion) > > > > 3012bis defines GENAE (MN-AAA authenticator to be precise). > > The MN-AAA authenticator (MAAE) aids in AAA authentication by > > mapping the RRQ extensions to AAA attributes at FA or HA. > > > > With CHAP_SPI (value 2), the RRQ extensions are mapped to > > Radius chap attributes for chap authentication. The details are > > as follows: > > > > chap challenge = md5(RRQ data till the SPI field of MAAE) > > chap challenge = authenticator field from MAAE > > > > The authenticator calculation is specified in 3012bis and no issue > > with that in regards to MD5. > > > > This works and is widely deployed today. > > > > As a summary, the chap challenge above aids to compress the message. > > > > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap > > challenge above is calculated using HMAC_MD5 and that the authenticator > > is calculated using HMAC_MD5. I have a concern with both these claims: > > > > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is > > required between MN and FA/HA. One basic assumption is that in some > > domains/deployments this can be manually provisioned. One issue is how > > to decide on which :key: to use for challenge generation? No means to > > specify that. (one applicability of this draft is to leverage on a > > single MN/AAA secret and so, I cannot clearly see the reason for such a > > provisoned key). > > > > 2. second and primary concern is that there are no radius attributes > > (standard /VSAs), which can be used to authenticate a challenge response > > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of > > that new attributes need to be defined and processing at Radius needs to > > be specified. > > > > In light of these two issues, I am wondering how HMAC_MD5 can be > > realistically used for authenticating MAAE today? > > > > Can someone demystify the usage of HMAC_MD5? > > > > Thanks > > Alpesh > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Oct 20 21:40:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05990 for ; Wed, 20 Oct 2004 21:40:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKS9B-0000NZ-7l for mip4-web-archive@ietf.org; Wed, 20 Oct 2004 21:53:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIQu-0007As-Dt; Wed, 20 Oct 2004 11:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHl4-0001ow-PA; Wed, 20 Oct 2004 10:48:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11316; Wed, 20 Oct 2004 10:48:08 -0400 (EDT) Message-Id: <200410201448.KAA11316@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:48:08 -0400 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-mip4-faerr-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Foreign Agent Error Extension for Mobile IPv4 Author(s) : C. Perkins Filename : draft-mip4-faerr-00.txt Pages : 5 Date : 2004-10-19 This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. The new extension option allows a foreign agent to supply an error code without disturbing the data supplied by the Home Agent within the Registration Reply message. In this way, the mobile node can verify that the Registration Reply message was generated by the Home Agent even in cases where the foreign agent is required by protocol to insert new status information into the Registration Reply message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mip4-faerr-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-faerr-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-mip4-faerr-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. --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: <2004-10-20105414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mip4-faerr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mip4-faerr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20105414.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Thu Oct 21 07:38:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05412 for ; Thu, 21 Oct 2004 07:38:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbU0-0005N4-4r for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 07:51:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUL9-0007jS-5J; Thu, 21 Oct 2004 00:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKK3y-0001Q7-RR for mip4@megatron.ietf.org; Wed, 20 Oct 2004 13:15:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28259 for ; Wed, 20 Oct 2004 13:15:42 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKGE-00064j-4N for mip4@ietf.org; Wed, 20 Oct 2004 13:28:38 -0400 Received: from archana70282 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I5W00L8V6STA7@mta0.huawei.com> for mip4@ietf.org; Thu, 21 Oct 2004 00:50:54 +0800 (CST) Date: Wed, 20 Oct 2004 22:23:03 +0530 From: Archana To: mip4@ietf.org Message-id: <003c01c4b6c5$44588140$4504120a@archana70282> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Subject: [Mip4] Query -- RFC 3344 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Hi RFC 3344 mentions that in a Registration Request both the 'M' and 'G' bits can be set by the requesting Mobile Node Section 3.6.1.2 "The mobile node MAY request alternative forms of encapsulation by setting the 'M' bit and/or the 'G' bit " We have the following queries regarding this case: During Registration: 1. Does the Mobility Agent accept such a registration and maintain the information in the binding entry / visitor entry as the case maybe ? During Forwarding: 1. If the agent gets a IP in IP packet though the registration indicates a Minimal IP/GRE , should the packet be processed by the Mobility agent 2.If the home agent receives a packet from the CN and the mobile node has registered with both Minimal IP and GRE , what type of encapsulation should be used to encapsulate the packet to be forwarded to the FA/MN. Thanks in advance Archana -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 07:47:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06843 for ; Thu, 21 Oct 2004 07:47:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbcK-0005lT-Ad for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 08:00:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKamD-0006Fo-Cv; Thu, 21 Oct 2004 07:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKL5I-0004vt-JM for mip4@megatron.ietf.org; Wed, 20 Oct 2004 14:21:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06132 for ; Wed, 20 Oct 2004 14:21:09 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLHf-0008Ng-14 for mip4@ietf.org; Wed, 20 Oct 2004 14:34:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9KHr9a27523; Wed, 20 Oct 2004 10:53:09 -0700 X-mProtect: <200410201753> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdddYXyS; Wed, 20 Oct 2004 10:53:08 PDT Message-ID: <4176ACCD.C06B199B@iprg.nokia.com> Date: Wed, 20 Oct 2004 11:22:05 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] Question regarding 3012bis References: <4175BEE0.3050204@cisco.com> <16758.13447.53795.404726@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Hello Pete, After looking over the document, I think I'm pretty much in line with your suggestions... Pete McCann wrote: > The usage of the "inner" MD5 for CHAP_SPI is as a compression > function, to help solve the problem of limited space in RADIUS > attributes. > > The problem is the text right ........ > > seems to say that HMAC_MD5 replaces both the "inner" and "outer" > occurences of MD5, but fails to specify the Key used for the "inner" > HMAC_MD5. I agree that this should be fixed, and probably to say that HMAC_MD5 only replaces the "enclosing" MD5, not the inner MD5 as in option (2) below. > Because the purpose of this "inner" hash is to provide compression, > not authentication, I think it is not reasonable to require a secret > pre-shared key between the MN and FA. A key is going to be needed by the outer HMAC_MD5, though. > I think we have two realistic options at this point: > > 1) specify a fixed key for usage in the inner HMAC_MD5, or one that > is derived from information in the RRQ; > > 2) revert back to MD5 for the inner hash for both CHAP_SPI and > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function > > Opinions? I'm in favor of (2). > As for your second problem (RADIUS AVPs) I think that is not a problem > that should be addressed with this document. If people want to > support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs > to carry an indication of the fact that HMAC_CHAP_SPI is being used. > Also the home RADIUS server needs to be upgraded to support HMAC_MD5. > It is not in the scope of 3012bis or the mip4 WG to do RADIUS > extensions so I think we just have to understand that HMAC_CHAP_SPI > cannot be supported by existing standard RADIUS servers until > additional specification work has been done. I agree with this also. I have some other concerns which I'll put into another e-mail. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 08:13:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12996 for ; Thu, 21 Oct 2004 08:13:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc1i-0007Nl-3Y for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 08:26:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKavT-0002Yq-JQ; Thu, 21 Oct 2004 07:16:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKOJo-0001jU-Bx for mip4@megatron.ietf.org; Wed, 20 Oct 2004 17:48:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01016 for ; Wed, 20 Oct 2004 17:48:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKOWD-00071N-Er for mip4@ietf.org; Wed, 20 Oct 2004 18:01:17 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2004 14:55:46 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9KLlvOE023490; Wed, 20 Oct 2004 14:47:58 -0700 (PDT) Received: from kleung-w2k01.cisco.com (sjc-vpn4-356.cisco.com [10.21.81.100]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYG07646; Wed, 20 Oct 2004 14:48:56 -0700 (PDT) Message-Id: <4.3.2.7.2.20041020142734.036b86f8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Oct 2004 14:47:53 -0700 To: Pete McCann From: Kent Leung Subject: Re: [Mip4] Question regarding 3012bis In-Reply-To: <16758.13447.53795.404726@gargle.gargle.HOWL> References: <4175BEE0.3050204@cisco.com> <4175BEE0.3050204@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: mip4@ietf.org, Henrik Levkowetz , Alpesh Patel X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: >It seems to say that HMAC_MD5 replaces both the "inner" and "outer" >occurences of MD5, but fails to specify the Key used for the "inner" >HMAC_MD5. > >Because the purpose of this "inner" hash is to provide compression, >not authentication, I think it is not reasonable to require a secret >pre-shared key between the MN and FA. > >I think we have two realistic options at this point: > >1) specify a fixed key for usage in the inner HMAC_MD5, or one that > is derived from information in the RRQ; Either fixed key or derivation of cleartext data seem to lose the security potency of HMAC_MD5. >2) revert back to MD5 for the inner hash for both CHAP_SPI and > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function Is this scheme stronger than just using MD5? I think the key question is how does not having a shared key affect the security strength? And is there value to use this method of authentication given it's not the designed HMAC_MD5 algorithm? >Opinions? Unless there's some worthwhile security gain using HMAC_MD5 in the suggested adapted method above, *and* some standardized way to even accomplish outer authentication function, wondering why should we proceed with this method? Maybe this is something we can add later when the details are worked out? Kent >As for your second problem (RADIUS AVPs) I think that is not a problem >that should be addressed with this document. If people want to >support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs >to carry an indication of the fact that HMAC_CHAP_SPI is being used. >Also the home RADIUS server needs to be upgraded to support HMAC_MD5. >It is not in the scope of 3012bis or the mip4 WG to do RADIUS >extensions so I think we just have to understand that HMAC_CHAP_SPI >cannot be supported by existing standard RADIUS servers until >additional specification work has been done. > >-Pete > > >Alpesh Patel writes: > > Hi - > > > > I have a basic concern regarding the use of HMAC_MD5 in 3012bis > > (I have had a few email exchanges with authors and WG chairs in > > this regards and am posting on WG chair suggestion) > > > > 3012bis defines GENAE (MN-AAA authenticator to be precise). > > The MN-AAA authenticator (MAAE) aids in AAA authentication by > > mapping the RRQ extensions to AAA attributes at FA or HA. > > > > With CHAP_SPI (value 2), the RRQ extensions are mapped to > > Radius chap attributes for chap authentication. The details are > > as follows: > > > > chap challenge = md5(RRQ data till the SPI field of MAAE) > > chap challenge = authenticator field from MAAE > > > > The authenticator calculation is specified in 3012bis and no issue > > with that in regards to MD5. > > > > This works and is widely deployed today. > > > > As a summary, the chap challenge above aids to compress the message. > > > > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap > > challenge above is calculated using HMAC_MD5 and that the authenticator > > is calculated using HMAC_MD5. I have a concern with both these claims: > > > > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is > > required between MN and FA/HA. One basic assumption is that in some > > domains/deployments this can be manually provisioned. One issue is how > > to decide on which :key: to use for challenge generation? No means to > > specify that. (one applicability of this draft is to leverage on a > > single MN/AAA secret and so, I cannot clearly see the reason for such a > > provisoned key). > > > > 2. second and primary concern is that there are no radius attributes > > (standard /VSAs), which can be used to authenticate a challenge response > > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of > > that new attributes need to be defined and processing at Radius needs to > > be specified. > > > > In light of these two issues, I am wondering how HMAC_MD5 can be > > realistically used for authenticating MAAE today? > > > > Can someone demystify the usage of HMAC_MD5? > > > > Thanks > > Alpesh > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 08:26:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14698 for ; Thu, 21 Oct 2004 08:26:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcDv-0007ng-K7 for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 08:39:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb1q-0001Sf-CE; Thu, 21 Oct 2004 07:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKQwB-0008Iy-6O for mip4@megatron.ietf.org; Wed, 20 Oct 2004 20:36:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26144 for ; Wed, 20 Oct 2004 20:36:08 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKR8a-0005b7-UL for mip4@ietf.org; Wed, 20 Oct 2004 20:49:06 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9L0ZZHt010861; Wed, 20 Oct 2004 19:35:35 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i9L0ZSO18609; Wed, 20 Oct 2004 19:35:29 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I5WSAV-0001MW-00; Wed, 20 Oct 2004 20:35:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16759.1094.258795.376355@gargle.gargle.HOWL> Date: Wed, 20 Oct 2004 19:35:18 -0500 From: Pete McCann To: Kent Leung Subject: Re: [Mip4] Question regarding 3012bis In-Reply-To: <4.3.2.7.2.20041020142734.036b86f8@mira-sjcm-2.cisco.com> References: <4175BEE0.3050204@cisco.com> <4.3.2.7.2.20041020142734.036b86f8@mira-sjcm-2.cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Henrik Levkowetz , Alpesh Patel X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Hi, Kent, Kent Leung writes: > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > > >It seems to say that HMAC_MD5 replaces both the "inner" and "outer" > >occurences of MD5, but fails to specify the Key used for the "inner" > >HMAC_MD5. > > > >Because the purpose of this "inner" hash is to provide compression, > >not authentication, I think it is not reasonable to require a secret > >pre-shared key between the MN and FA. > > > >I think we have two realistic options at this point: > > > >1) specify a fixed key for usage in the inner HMAC_MD5, or one that > > is derived from information in the RRQ; > > Either fixed key or derivation of cleartext data seem to lose the security > potency of HMAC_MD5. The inner hash is not for authentication, it is for compression. So, I am not so worried about "security potency." What you are saying is that it might be somewhat easier for someone to find a different RRQ that hashes to the same value; but, we still have the challenge value as input to the outer HMAC_MD5, which is still secured with a key. > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function > > Is this scheme stronger than just using MD5? I think the key question is > how does not having a shared key affect the security strength? And is there > value to use this method of authentication given it's not the designed > HMAC_MD5 algorithm? We probably don't have the expertise in this group to answer this question. I do not recall the input from the security review that led to the addition of HMAC_MD5. Did it ask for HMAC_MD5 to be added to both the main default algorithm and the RADIUS SPIs, or just the main default algorithm? Does anyone have a pointer to the original input? If there was no request from security folks to add HMAC_MD5 to the RADIUS SPIs I would not mind deleting it. > >Opinions? > > > Unless there's some worthwhile security gain using HMAC_MD5 in the > suggested adapted method above, *and* some standardized way to > even accomplish outer authentication function, wondering why should we > proceed with this method? I do not think there is a requirement to synchronize our draft with RADIUS extensions. > Maybe this is something we can add later when the details are worked > out? This is certainly one possible way to resolve the issue. -Pete > Kent > > > > >As for your second problem (RADIUS AVPs) I think that is not a problem > >that should be addressed with this document. If people want to > >support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs > >to carry an indication of the fact that HMAC_CHAP_SPI is being used. > >Also the home RADIUS server needs to be upgraded to support HMAC_MD5. > >It is not in the scope of 3012bis or the mip4 WG to do RADIUS > >extensions so I think we just have to understand that HMAC_CHAP_SPI > >cannot be supported by existing standard RADIUS servers until > >additional specification work has been done. > > > >-Pete > > > > > >Alpesh Patel writes: > > > Hi - > > > > > > I have a basic concern regarding the use of HMAC_MD5 in 3012bis > > > (I have had a few email exchanges with authors and WG chairs in > > > this regards and am posting on WG chair suggestion) > > > > > > 3012bis defines GENAE (MN-AAA authenticator to be precise). > > > The MN-AAA authenticator (MAAE) aids in AAA authentication by > > > mapping the RRQ extensions to AAA attributes at FA or HA. > > > > > > With CHAP_SPI (value 2), the RRQ extensions are mapped to > > > Radius chap attributes for chap authentication. The details are > > > as follows: > > > > > > chap challenge = md5(RRQ data till the SPI field of MAAE) > > > chap challenge = authenticator field from MAAE > > > > > > The authenticator calculation is specified in 3012bis and no issue > > > with that in regards to MD5. > > > > > > This works and is widely deployed today. > > > > > > As a summary, the chap challenge above aids to compress the message. > > > > > > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap > > > challenge above is calculated using HMAC_MD5 and that the authenticator > > > is calculated using HMAC_MD5. I have a concern with both these claims: > > > > > > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is > > > required between MN and FA/HA. One basic assumption is that in some > > > domains/deployments this can be manually provisioned. One issue is how > > > to decide on which :key: to use for challenge generation? No means to > > > specify that. (one applicability of this draft is to leverage on a > > > single MN/AAA secret and so, I cannot clearly see the reason for such a > > > provisoned key). > > > > > > 2. second and primary concern is that there are no radius attributes > > > (standard /VSAs), which can be used to authenticate a challenge response > > > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of > > > that new attributes need to be defined and processing at Radius needs to > > > be specified. > > > > > > In light of these two issues, I am wondering how HMAC_MD5 can be > > > realistically used for authenticating MAAE today? > > > > > > Can someone demystify the usage of HMAC_MD5? > > > > > > Thanks > > > Alpesh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 08:48:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19866 for ; Thu, 21 Oct 2004 08:48:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcZV-0000jD-GB for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 09:01:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbNX-0004cf-9s; Thu, 21 Oct 2004 07:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKXx7-0005GC-0f for mip4@megatron.ietf.org; Thu, 21 Oct 2004 04:05:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19992 for ; Thu, 21 Oct 2004 04:05:33 -0400 (EDT) Received: from av7-2-sn1.fre.skanova.net ([81.228.11.114]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKY9Y-0000o2-SJ for mip4@ietf.org; Thu, 21 Oct 2004 04:18:36 -0400 Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id E064037E77; Thu, 21 Oct 2004 10:05:00 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id D2CEE37E73 for ; Thu, 21 Oct 2004 10:05:00 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id C62F337E46 for ; Thu, 21 Oct 2004 10:05:00 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CKXwS-0004jS-FA for mip4@ietf.org; Thu, 21 Oct 2004 10:05:00 +0200 Message-ID: <41776DAE.7040107@levkowetz.com> Date: Thu, 21 Oct 2004 10:05:02 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 2.0 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Mip4] WG Last Call on draft-mip4-faerr-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit This message announces a WG last call on: "Foreign Agent Error Extension for Mobile IPv4" - draft-mip4-faerr-00.txt The last call will conclude at 24:00 UTC on Friday, 05 November 2004. draft-mip4-faerr-00.txt defines a new Mobile IP extension for carrying an error code from a foreign agent, which informs the mobile node of foreign-agent specific errors independently of the result code inserted by the home agent. A URL for this Internet-Draft is: Please respond to this WG last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like "I support the advancement of this document to the IESG with a request for publication as proposed standard." If you have comments, please use a line similar to the one above, and supplement this with your comments. * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your comments - "I don't support the advancement of this document to the IESG with a request for publication as proposed standard, for the following reasons:" ... Pete & Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 11:42:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14493 for ; Thu, 21 Oct 2004 11:42:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfHZ-0006JQ-Sb for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 11:55:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeyl-0002Ro-E1; Thu, 21 Oct 2004 11:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKerw-0007JA-Gk for mip4@megatron.ietf.org; Thu, 21 Oct 2004 11:28:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13133 for ; Thu, 21 Oct 2004 11:28:45 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKf4a-0005zU-AG for mip4@ietf.org; Thu, 21 Oct 2004 11:41:52 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9LFRa729710; Thu, 21 Oct 2004 11:27:36 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Oct 2004 11:27:37 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Pete McCann'" , "'Kent Leung'" Subject: RE: [Mip4] Question regarding 3012bis Date: Thu, 21 Oct 2004 11:27:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: "'mip4@ietf.org'" , "'Henrik Levkowetz'" , "'Alpesh Patel'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Hi Pete, Regarding your inquiry on the security review that led to the addition of HMAC-MD5, the following was the issue brought up by AD for RFC3012bis (mobile IP ver 3) document: Issue: "Section 8 (SPI for RADIUS AAA Servers) defines a method of computing the Generalized Mobile IP Authentication Extension's authenticator field using MD5 in a manner that is consistent with RADIUS [9]. The use of MD5 in the method described in Section 8 is less secure than HMAC-MD5 [6], and should be avoided whenever possible." Regards, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Pete McCann Sent: Wednesday, October 20, 2004 7:35 PM To: Kent Leung Cc: mip4@ietf.org; Henrik Levkowetz; Alpesh Patel Subject: Re: [Mip4] Question regarding 3012bis Hi, Kent, Kent Leung writes: > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > > >It seems to say that HMAC_MD5 replaces both the "inner" and "outer" > >occurences of MD5, but fails to specify the Key used for the "inner" > >HMAC_MD5. > > > >Because the purpose of this "inner" hash is to provide compression, > >not authentication, I think it is not reasonable to require a secret > >pre-shared key between the MN and FA. > > > >I think we have two realistic options at this point: > > > >1) specify a fixed key for usage in the inner HMAC_MD5, or one that > > is derived from information in the RRQ; > > Either fixed key or derivation of cleartext data seem to lose the security > potency of HMAC_MD5. The inner hash is not for authentication, it is for compression. So, I am not so worried about "security potency." What you are saying is that it might be somewhat easier for someone to find a different RRQ that hashes to the same value; but, we still have the challenge value as input to the outer HMAC_MD5, which is still secured with a key. > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function > > Is this scheme stronger than just using MD5? I think the key question is > how does not having a shared key affect the security strength? And is there > value to use this method of authentication given it's not the designed > HMAC_MD5 algorithm? We probably don't have the expertise in this group to answer this question. I do not recall the input from the security review that led to the addition of HMAC_MD5. Did it ask for HMAC_MD5 to be added to both the main default algorithm and the RADIUS SPIs, or just the main default algorithm? Does anyone have a pointer to the original input? If there was no request from security folks to add HMAC_MD5 to the RADIUS SPIs I would not mind deleting it. > >Opinions? > > > Unless there's some worthwhile security gain using HMAC_MD5 in the > suggested adapted method above, *and* some standardized way to > even accomplish outer authentication function, wondering why should we > proceed with this method? I do not think there is a requirement to synchronize our draft with RADIUS extensions. > Maybe this is something we can add later when the details are worked > out? This is certainly one possible way to resolve the issue. -Pete > Kent > > > > >As for your second problem (RADIUS AVPs) I think that is not a problem > >that should be addressed with this document. If people want to > >support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs > >to carry an indication of the fact that HMAC_CHAP_SPI is being used. > >Also the home RADIUS server needs to be upgraded to support HMAC_MD5. > >It is not in the scope of 3012bis or the mip4 WG to do RADIUS > >extensions so I think we just have to understand that HMAC_CHAP_SPI > >cannot be supported by existing standard RADIUS servers until > >additional specification work has been done. > > > >-Pete > > > > > >Alpesh Patel writes: > > > Hi - > > > > > > I have a basic concern regarding the use of HMAC_MD5 in 3012bis > > > (I have had a few email exchanges with authors and WG chairs in > > > this regards and am posting on WG chair suggestion) > > > > > > 3012bis defines GENAE (MN-AAA authenticator to be precise). > > > The MN-AAA authenticator (MAAE) aids in AAA authentication by > > > mapping the RRQ extensions to AAA attributes at FA or HA. > > > > > > With CHAP_SPI (value 2), the RRQ extensions are mapped to > > > Radius chap attributes for chap authentication. The details are > > > as follows: > > > > > > chap challenge = md5(RRQ data till the SPI field of MAAE) > > > chap challenge = authenticator field from MAAE > > > > > > The authenticator calculation is specified in 3012bis and no issue > > > with that in regards to MD5. > > > > > > This works and is widely deployed today. > > > > > > As a summary, the chap challenge above aids to compress the message. > > > > > > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap > > > challenge above is calculated using HMAC_MD5 and that the authenticator > > > is calculated using HMAC_MD5. I have a concern with both these claims: > > > > > > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is > > > required between MN and FA/HA. One basic assumption is that in some > > > domains/deployments this can be manually provisioned. One issue is how > > > to decide on which :key: to use for challenge generation? No means to > > > specify that. (one applicability of this draft is to leverage on a > > > single MN/AAA secret and so, I cannot clearly see the reason for such a > > > provisoned key). > > > > > > 2. second and primary concern is that there are no radius attributes > > > (standard /VSAs), which can be used to authenticate a challenge response > > > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of > > > that new attributes need to be defined and processing at Radius needs to > > > be specified. > > > > > > In light of these two issues, I am wondering how HMAC_MD5 can be > > > realistically used for authenticating MAAE today? > > > > > > Can someone demystify the usage of HMAC_MD5? > > > > > > Thanks > > > Alpesh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 21:50:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27569 for ; Thu, 21 Oct 2004 21:50:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKomQ-0001ro-0G for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 22:03:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoFR-0005q4-23; Thu, 21 Oct 2004 21:29:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmee-0001IE-M6 for mip4@megatron.ietf.org; Thu, 21 Oct 2004 19:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03393 for ; Thu, 21 Oct 2004 19:47:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKmrM-000353-BY for mip4@ietf.org; Thu, 21 Oct 2004 20:00:44 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 16:55:04 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9LNktk2009853; Thu, 21 Oct 2004 16:46:55 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-246.cisco.com [128.107.163.246]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYH14309; Thu, 21 Oct 2004 16:48:11 -0700 (PDT) Message-ID: <41784A75.5010809@cisco.com> Date: Thu, 21 Oct 2004 16:47:01 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kent Leung Subject: Re: [Mip4] Question regarding 3012bis References: <4175BEE0.3050204@cisco.com> <4175BEE0.3050204@cisco.com> <4.3.2.7.2.20041020142734.036b86f8@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: Pete McCann , mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Kent - In general HMAC based auth. provide better security than just MD5. Also, I agree with the group assessment that the inner algorithm can be just MD5 as it is just compressing the message. I would agree with Pete regarding point #2 and we can proceed from here. Would really like to see text which mentions that nce AAA attributes which use HMAC_MD5 are not defined today. That will help people avoid confusion. Beyond that, I think there is no other reason that this draft should be delayed any further. Rgds -a Kent Leung wrote: > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > >> It seems to say that HMAC_MD5 replaces both the "inner" and "outer" >> occurences of MD5, but fails to specify the Key used for the "inner" >> HMAC_MD5. >> >> Because the purpose of this "inner" hash is to provide compression, >> not authentication, I think it is not reasonable to require a secret >> pre-shared key between the MN and FA. >> >> I think we have two realistic options at this point: >> >> 1) specify a fixed key for usage in the inner HMAC_MD5, or one that >> is derived from information in the RRQ; > > > Either fixed key or derivation of cleartext data seem to lose the > security > potency of HMAC_MD5. > > > >> 2) revert back to MD5 for the inner hash for both CHAP_SPI and >> HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication >> function > > > Is this scheme stronger than just using MD5? I think the key question is > how does not having a shared key affect the security strength? And is > there > value to use this method of authentication given it's not the designed > HMAC_MD5 algorithm? > > >> Opinions? > > > > Unless there's some worthwhile security gain using HMAC_MD5 in the > suggested adapted method above, *and* some standardized way to > even accomplish outer authentication function, wondering why should we > proceed with this method? > > Maybe this is something we can add later when the details are worked > out? > > Kent > > > >> As for your second problem (RADIUS AVPs) I think that is not a problem >> that should be addressed with this document. If people want to >> support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs >> to carry an indication of the fact that HMAC_CHAP_SPI is being used. >> Also the home RADIUS server needs to be upgraded to support HMAC_MD5. >> It is not in the scope of 3012bis or the mip4 WG to do RADIUS >> extensions so I think we just have to understand that HMAC_CHAP_SPI >> cannot be supported by existing standard RADIUS servers until >> additional specification work has been done. >> >> -Pete >> >> >> Alpesh Patel writes: >> > Hi - >> > >> > I have a basic concern regarding the use of HMAC_MD5 in 3012bis >> > (I have had a few email exchanges with authors and WG chairs in >> > this regards and am posting on WG chair suggestion) >> > >> > 3012bis defines GENAE (MN-AAA authenticator to be precise). >> > The MN-AAA authenticator (MAAE) aids in AAA authentication by >> > mapping the RRQ extensions to AAA attributes at FA or HA. >> > >> > With CHAP_SPI (value 2), the RRQ extensions are mapped to >> > Radius chap attributes for chap authentication. The details are >> > as follows: >> > >> > chap challenge = md5(RRQ data till the SPI field of MAAE) >> > chap challenge = authenticator field from MAAE >> > >> > The authenticator calculation is specified in 3012bis and no issue >> > with that in regards to MD5. >> > >> > This works and is widely deployed today. >> > >> > As a summary, the chap challenge above aids to compress the message. >> > >> > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap >> > challenge above is calculated using HMAC_MD5 and that the >> authenticator >> > is calculated using HMAC_MD5. I have a concern with both these >> claims: >> > >> > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is >> > required between MN and FA/HA. One basic assumption is that in some >> > domains/deployments this can be manually provisioned. One issue is >> how >> > to decide on which :key: to use for challenge generation? No means to >> > specify that. (one applicability of this draft is to leverage on a >> > single MN/AAA secret and so, I cannot clearly see the reason for >> such a >> > provisoned key). >> > >> > 2. second and primary concern is that there are no radius attributes >> > (standard /VSAs), which can be used to authenticate a challenge >> response >> > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In >> light of >> > that new attributes need to be defined and processing at Radius >> needs to >> > be specified. >> > >> > In light of these two issues, I am wondering how HMAC_MD5 can be >> > realistically used for authenticating MAAE today? >> > >> > Can someone demystify the usage of HMAC_MD5? >> > >> > Thanks >> > Alpesh >> >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ > > > -- > | | Kent Leung > :|: :|: IP Mobility Development > :|||: :|||: IOS Technologies Division > :|||||||: :|||||||: Voice: 408.526.5030 > .:|||||||||:.:|||||||||:. Fax: 408.525.1653 > c i s c o S y s t e m s Email: kleung@cisco.com > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Oct 21 21:55:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28493 for ; Thu, 21 Oct 2004 21:55:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKora-00026T-Rd for mip4-web-archive@ietf.org; Thu, 21 Oct 2004 22:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoHb-00030G-4z; Thu, 21 Oct 2004 21:31:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKn6S-0003z7-3p for mip4@megatron.ietf.org; Thu, 21 Oct 2004 20:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09512 for ; Thu, 21 Oct 2004 20:16:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnJ9-0005CG-VW for mip4@ietf.org; Thu, 21 Oct 2004 20:29:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Oct 2004 17:15:55 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9M0Fj9b017286; Thu, 21 Oct 2004 17:15:46 -0700 (PDT) Received: from kleung-w2k01.cisco.com (dhcp-128-107-178-166.cisco.com [128.107.178.166]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYH16744; Thu, 21 Oct 2004 17:16:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20041021170304.039d69e0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 17:13:31 -0700 To: Alpesh From: Kent Leung Subject: Re: [Mip4] Question regarding 3012bis In-Reply-To: <41784A75.5010809@cisco.com> References: <4175BEE0.3050204@cisco.com> <4175BEE0.3050204@cisco.com> <4.3.2.7.2.20041020142734.036b86f8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Pete McCann , mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Option #2 seems reasonable to me then.. Kent At 04:47 PM 10/21/2004 -0700, Alpesh wrote: >Kent - > >In general HMAC based auth. provide better security than just MD5. > >Also, I agree with the group assessment that the inner algorithm can be >just MD5 as it is just compressing the message. > >I would agree with Pete regarding point #2 and we can proceed from here. > >Would really like to see text which mentions that nce AAA attributes which >use HMAC_MD5 are not defined today. That will help people avoid confusion. > >Beyond that, I think there is no other reason that this draft should be >delayed >any further. > >Rgds >-a > >Kent Leung wrote: > >> >>At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: >> >> >>>It seems to say that HMAC_MD5 replaces both the "inner" and "outer" >>>occurences of MD5, but fails to specify the Key used for the "inner" >>>HMAC_MD5. >>> >>>Because the purpose of this "inner" hash is to provide compression, >>>not authentication, I think it is not reasonable to require a secret >>>pre-shared key between the MN and FA. >>> >>>I think we have two realistic options at this point: >>> >>>1) specify a fixed key for usage in the inner HMAC_MD5, or one that >>> is derived from information in the RRQ; >> >> >>Either fixed key or derivation of cleartext data seem to lose the security >>potency of HMAC_MD5. >> >> >> >>>2) revert back to MD5 for the inner hash for both CHAP_SPI and >>> HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication function >> >> >>Is this scheme stronger than just using MD5? I think the key question is >>how does not having a shared key affect the security strength? And is there >>value to use this method of authentication given it's not the designed >>HMAC_MD5 algorithm? >> >> >>>Opinions? >> >> >> >>Unless there's some worthwhile security gain using HMAC_MD5 in the >>suggested adapted method above, *and* some standardized way to >>even accomplish outer authentication function, wondering why should we >>proceed with this method? >> >>Maybe this is something we can add later when the details are worked >>out? >> >>Kent >> >> >> >>>As for your second problem (RADIUS AVPs) I think that is not a problem >>>that should be addressed with this document. If people want to >>>support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs >>>to carry an indication of the fact that HMAC_CHAP_SPI is being used. >>>Also the home RADIUS server needs to be upgraded to support HMAC_MD5. >>>It is not in the scope of 3012bis or the mip4 WG to do RADIUS >>>extensions so I think we just have to understand that HMAC_CHAP_SPI >>>cannot be supported by existing standard RADIUS servers until >>>additional specification work has been done. >>> >>>-Pete >>> >>> >>>Alpesh Patel writes: >>> > Hi - >>> > >>> > I have a basic concern regarding the use of HMAC_MD5 in 3012bis >>> > (I have had a few email exchanges with authors and WG chairs in >>> > this regards and am posting on WG chair suggestion) >>> > >>> > 3012bis defines GENAE (MN-AAA authenticator to be precise). >>> > The MN-AAA authenticator (MAAE) aids in AAA authentication by >>> > mapping the RRQ extensions to AAA attributes at FA or HA. >>> > >>> > With CHAP_SPI (value 2), the RRQ extensions are mapped to >>> > Radius chap attributes for chap authentication. The details are >>> > as follows: >>> > >>> > chap challenge = md5(RRQ data till the SPI field of MAAE) >>> > chap challenge = authenticator field from MAAE >>> > >>> > The authenticator calculation is specified in 3012bis and no issue >>> > with that in regards to MD5. >>> > >>> > This works and is widely deployed today. >>> > >>> > As a summary, the chap challenge above aids to compress the message. >>> > >>> > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap >>> > challenge above is calculated using HMAC_MD5 and that the authenticator >>> > is calculated using HMAC_MD5. I have a concern with both these claims: >>> > >>> > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is >>> > required between MN and FA/HA. One basic assumption is that in some >>> > domains/deployments this can be manually provisioned. One issue is how >>> > to decide on which :key: to use for challenge generation? No means to >>> > specify that. (one applicability of this draft is to leverage on a >>> > single MN/AAA secret and so, I cannot clearly see the reason for such a >>> > provisoned key). >>> > >>> > 2. second and primary concern is that there are no radius attributes >>> > (standard /VSAs), which can be used to authenticate a challenge response >>> > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In light of >>> > that new attributes need to be defined and processing at Radius needs to >>> > be specified. >>> > >>> > In light of these two issues, I am wondering how HMAC_MD5 can be >>> > realistically used for authenticating MAAE today? >>> > >>> > Can someone demystify the usage of HMAC_MD5? >>> > >>> > Thanks >>> > Alpesh >>> >>> >>>-- >>>Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>Supplemental site: http://www.mip4.org/ >> >> >>-- >> | | Kent Leung >> :|: :|: IP Mobility Development >> :|||: :|||: IOS Technologies Division >> :|||||||: :|||||||: Voice: 408.526.5030 >>.:|||||||||:.:|||||||||:. Fax: 408.525.1653 >> c i s c o S y s t e m s Email: kleung@cisco.com >> > -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: IOS Technologies Division :|||||||: :|||||||: Voice: 408.526.5030 .:|||||||||:.:|||||||||:. Fax: 408.525.1653 c i s c o S y s t e m s Email: kleung@cisco.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 22 11:49:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15615 for ; Fri, 22 Oct 2004 11:49:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1sC-0000t1-Jm for mip4-web-archive@ietf.org; Fri, 22 Oct 2004 12:02:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1ZR-0004nv-Qw; Fri, 22 Oct 2004 11:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1TW-0002uu-HY for mip4@megatron.ietf.org; Fri, 22 Oct 2004 11:37:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14562 for ; Fri, 22 Oct 2004 11:37:02 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1gK-0000bB-Ks for mip4@ietf.org; Fri, 22 Oct 2004 11:50:21 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9MFZj307067; Fri, 22 Oct 2004 11:35:45 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Oct 2004 11:35:45 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Alpesh'" , "'Kent Leung'" Subject: RE: [Mip4] Question regarding 3012bis Date: Fri, 22 Oct 2004 11:35:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: "'Pete McCann'" , "'mip4@ietf.org'" , "'Henrik Levkowetz'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Alpesh, Can you suggest the exact text you like to see in RFC3012bis? Thanks, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Alpesh Sent: Thursday, October 21, 2004 6:47 PM To: Kent Leung Cc: Pete McCann; mip4@ietf.org; Henrik Levkowetz Subject: Re: [Mip4] Question regarding 3012bis Kent - In general HMAC based auth. provide better security than just MD5. Also, I agree with the group assessment that the inner algorithm can be just MD5 as it is just compressing the message. I would agree with Pete regarding point #2 and we can proceed from here. Would really like to see text which mentions that nce AAA attributes which use HMAC_MD5 are not defined today. That will help people avoid confusion. Beyond that, I think there is no other reason that this draft should be delayed any further. Rgds -a Kent Leung wrote: > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > >> It seems to say that HMAC_MD5 replaces both the "inner" and "outer" >> occurences of MD5, but fails to specify the Key used for the "inner" >> HMAC_MD5. >> >> Because the purpose of this "inner" hash is to provide compression, >> not authentication, I think it is not reasonable to require a secret >> pre-shared key between the MN and FA. >> >> I think we have two realistic options at this point: >> >> 1) specify a fixed key for usage in the inner HMAC_MD5, or one that >> is derived from information in the RRQ; > > > Either fixed key or derivation of cleartext data seem to lose the > security > potency of HMAC_MD5. > > > >> 2) revert back to MD5 for the inner hash for both CHAP_SPI and >> HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication >> function > > > Is this scheme stronger than just using MD5? I think the key question > is how does not having a shared key affect the security strength? And > is there value to use this method of authentication given it's not the > designed HMAC_MD5 algorithm? > > >> Opinions? > > > > Unless there's some worthwhile security gain using HMAC_MD5 in the > suggested adapted method above, *and* some standardized way to even > accomplish outer authentication function, wondering why should we > proceed with this method? > > Maybe this is something we can add later when the details are worked > out? > > Kent > > > >> As for your second problem (RADIUS AVPs) I think that is not a >> problem that should be addressed with this document. If people want >> to support the HMAC_CHAP_SPI then they need to construct the RADIUS >> AVPs to carry an indication of the fact that HMAC_CHAP_SPI is being >> used. Also the home RADIUS server needs to be upgraded to support >> HMAC_MD5. It is not in the scope of 3012bis or the mip4 WG to do >> RADIUS extensions so I think we just have to understand that >> HMAC_CHAP_SPI cannot be supported by existing standard RADIUS servers >> until additional specification work has been done. >> >> -Pete >> >> >> Alpesh Patel writes: >> > Hi - >> > >> > I have a basic concern regarding the use of HMAC_MD5 in 3012bis > >> (I have had a few email exchanges with authors and WG chairs in > >> this regards and am posting on WG chair suggestion) > >> > 3012bis defines GENAE (MN-AAA authenticator to be precise). >> > The MN-AAA authenticator (MAAE) aids in AAA authentication by >> > mapping the RRQ extensions to AAA attributes at FA or HA. >> > >> > With CHAP_SPI (value 2), the RRQ extensions are mapped to >> > Radius chap attributes for chap authentication. The details are >> > as follows: >> > >> > chap challenge = md5(RRQ data till the SPI field of MAAE) >> > chap challenge = authenticator field from MAAE >> > >> > The authenticator calculation is specified in 3012bis and no issue >> > with that in regards to MD5. >> > >> > This works and is widely deployed today. >> > >> > As a summary, the chap challenge above aids to compress the message. >> > >> > Now, when SPI in MAAE is HMAC_MD5, the draft mentions that the chap >> > challenge above is calculated using HMAC_MD5 and that the >> authenticator >> > is calculated using HMAC_MD5. I have a concern with both these >> claims: >> > >> > 1. Issue with chap challenge - for MHAC_MD6 to be used, a "key" is >> > required between MN and FA/HA. One basic assumption is that in some >> > domains/deployments this can be manually provisioned. One issue is >> how >> > to decide on which :key: to use for challenge generation? No means to >> > specify that. (one applicability of this draft is to leverage on a >> > single MN/AAA secret and so, I cannot clearly see the reason for >> such a >> > provisoned key). >> > >> > 2. second and primary concern is that there are no radius attributes >> > (standard /VSAs), which can be used to authenticate a challenge >> response >> > generated using HMAC_MD5. Basic radius CHAP uses plain MD5. In >> light of >> > that new attributes need to be defined and processing at Radius >> needs to >> > be specified. >> > >> > In light of these two issues, I am wondering how HMAC_MD5 can be >> > realistically used for authenticating MAAE today? >> > >> > Can someone demystify the usage of HMAC_MD5? >> > >> > Thanks >> > Alpesh >> >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ > > > -- > | | Kent Leung > :|: :|: IP Mobility Development > :|||: :|||: IOS Technologies Division > :|||||||: :|||||||: Voice: 408.526.5030 > .:|||||||||:.:|||||||||:. Fax: 408.525.1653 > c i s c o S y s t e m s Email: kleung@cisco.com > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 22 14:57:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29316 for ; Fri, 22 Oct 2004 14:57:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4nw-0004NR-BQ for mip4-web-archive@ietf.org; Fri, 22 Oct 2004 15:10:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4Y1-0006JG-3b; Fri, 22 Oct 2004 14:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4Ta-0004CS-B3 for mip4@megatron.ietf.org; Fri, 22 Oct 2004 14:49:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28671 for ; Fri, 22 Oct 2004 14:49:19 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4gO-0004DX-PU for mip4@ietf.org; Fri, 22 Oct 2004 15:02:38 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MILNM12481; Fri, 22 Oct 2004 11:21:23 -0700 X-mProtect: <200410221821> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfpFYic; Fri, 22 Oct 2004 11:21:21 PDT Message-ID: <41795672.4511CA07@iprg.nokia.com> Date: Fri, 22 Oct 2004 11:50:26 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv4 Mailing List , Henrik Levkowetz , Pete McCann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Mip4] New revision for rfc3344bis X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hello folks, I am ready to submit a revised version of rfc334bis today. I have re-checked on the issue tracker for open issues, and I think that in reality the only remaining open issue is issue #45, which is misnamed but deals with an unfortunate interaction between deregistration and the Foreign-Home Authentication extension. The part about fixing problems associated with NAT was, I think, rejected at the last IETF meeting. Fixing the deregistration problem was not, and some action has to be taken. My current intention is to take the "least" action I can do to get the draft published, consistent with existing discussion on the issue. I am not sure about issue #20. My fuzzy non-recollection is that it was rejected, but I cannot find documentation about this in the minutes or on the list. The issue log shows agreement that a normative reference for the Foreign Agent Error extension should be added to rfc3344bis, except for the typical delay associated with moving the extension specification to Draft Standard. If the extension cannot be progressed, then we could not meet our goal of progressing rfc3344bis to Draft Standard. My understanding of Draft Standard tells me that moving to Draft could happen only after significant deployment. Regarding the other issues, and pursuant to the discussion we had early in the year, I suggest that they should already have been marked as closed after the publication of version ...-00 of the draft. Perhaps discussion about this issue should be on the agenda for just a few minutes during the upcoming IETF. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 22 19:48:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14619 for ; Fri, 22 Oct 2004 19:48:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9MG-0000z2-Oj for mip4-web-archive@ietf.org; Fri, 22 Oct 2004 20:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL91F-0008Ed-Sq; Fri, 22 Oct 2004 19:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8wq-0005QQ-8C for mip4@megatron.ietf.org; Fri, 22 Oct 2004 19:35:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13809 for ; Fri, 22 Oct 2004 19:35:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL99l-0000iH-9f for mip4@ietf.org; Fri, 22 Oct 2004 19:49:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MN7wQ09519 for ; Fri, 22 Oct 2004 16:07:58 -0700 X-mProtect: <200410222307> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlOqiai; Fri, 22 Oct 2004 16:07:57 PDT Message-ID: <4179999E.C9C6F0C4@iprg.nokia.com> Date: Fri, 22 Oct 2004 16:37:02 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Mip4] An idea about issue #45 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hello folks, My last e-mail included some information about issue #45 that was not quite right. After sending that e-mail out, I began to review more e-mails about the subject, and found a note requesting me to change the specification so that the registration request would be dropped by the home agent if there is an offending Foreign-Home Authentication extension applied to a deregistration. Unfortunately, I am not able to complete that task in the limited time I have available today. However, I found another "minimal-text" solution to the problem, and I would like to propose it for now, include it in the release before next Monday, and make some discussion on the list and at the next meeting. Please accept my sincere regrets at (a) not tackling the task of issue #45 sooner, avoiding what has become a rush job, and (b) not having this idea sooner so that we could have a longer discussion before submission. I will make whatever changes are needed after our discussion at the upcoming IETF, immediately after it becomes possible to resubmit the document. The proposed solution is very simple: namely, that the Foreign-Home Authentication extension be modified to prohibit inclusion in a deregistration message, as follows: 3.5.4. Foreign-Home Authentication Extension This Extension MAY be included in Registration Requests and Replies in cases in which a mobility security association exists between the foreign agent and the home agent, as long as the Registration Request is not a deregistration (i.e., it is requesting a positive lifetime and the home address is different than the care-of address). The Foreign-Home Authentication extension MUST NOT be applied to deregistration messages. ... This makes sense, because the mobile node is clearly not using the deregistration message to ask for any service from the foreign agent. Furthermore, there is no danger from _malicious_ activity from the mobile node. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 22 19:59:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15090 for ; Fri, 22 Oct 2004 19:59:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9Wf-00018z-Kn for mip4-web-archive@ietf.org; Fri, 22 Oct 2004 20:12:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL99l-0005LX-DW; Fri, 22 Oct 2004 19:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL98L-00043o-7G for mip4@megatron.ietf.org; Fri, 22 Oct 2004 19:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14508 for ; Fri, 22 Oct 2004 19:47:43 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9LF-0000wg-C2 for mip4@ietf.org; Fri, 22 Oct 2004 20:01:06 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MNJoP24683 for ; Fri, 22 Oct 2004 16:19:50 -0700 X-mProtect: <200410222319> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNaanfC; Fri, 22 Oct 2004 16:19:48 PDT Message-ID: <41799C65.45477036@iprg.nokia.com> Date: Fri, 22 Oct 2004 16:48:53 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Mip4] rfc3344bis Internet Draft availability X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hello again folks, I should have mentioned in the last e-mail that I have posted the Internet Draft at the following URL: http://people.nokia.net/~charliep/txt/mobileip/rfc3344bis.txt There are some other minor changes that were needed between this draft and ...-00, but my last note shows the important point of difference. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 22 20:43:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18479 for ; Fri, 22 Oct 2004 20:43:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLAD6-0001wh-8M for mip4-web-archive@ietf.org; Fri, 22 Oct 2004 20:56:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9rA-00028W-NX; Fri, 22 Oct 2004 20:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9jG-0003vV-HJ for mip4@megatron.ietf.org; Fri, 22 Oct 2004 20:25:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16367 for ; Fri, 22 Oct 2004 20:25:54 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9wA-0001V6-Sf for mip4@ietf.org; Fri, 22 Oct 2004 20:39:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Oct 2004 17:33:32 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9N0PFk3025641; Fri, 22 Oct 2004 17:25:15 -0700 (PDT) Date: Fri, 22 Oct 2004 17:25:19 -0700 (PDT) From: Sri Gundavelli To: "Charles E.Perkins" Subject: Re: [Mip4] An idea about issue #45 In-Reply-To: <4179999E.C9C6F0C4@iprg.nokia.com> Message-ID: References: <4179999E.C9C6F0C4@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi Charlie, On the issue 45, we believe that the solution for that problem can be based on a FA Identity Extension and that can defined outside the 3344bis. We can discuss this further at the Washington IETF. Regards ! Sri/ On Fri, 22 Oct 2004, Charles E.Perkins wrote: > > Hello folks, > > My last e-mail included some information about issue #45 > that was not quite right. After sending that e-mail out, > I began to review more e-mails about the subject, and found > a note requesting me to change the specification so that > the registration request would be dropped by the home agent > if there is an offending Foreign-Home Authentication > extension applied to a deregistration. > > Unfortunately, I am not able to complete that task in > the limited time I have available today. However, I > found another "minimal-text" solution to the problem, and > I would like to propose it for now, include it in the > release before next Monday, and make some discussion on > the list and at the next meeting. Please accept my > sincere regrets at (a) not tackling the task of issue #45 > sooner, avoiding what has become a rush job, and (b) > not having this idea sooner so that we could have > a longer discussion before submission. I will make > whatever changes are needed after our discussion at > the upcoming IETF, immediately after it becomes > possible to resubmit the document. > > The proposed solution is very simple: namely, that the > Foreign-Home Authentication extension be modified to > prohibit inclusion in a deregistration message, as follows: > > 3.5.4. Foreign-Home Authentication Extension > > This Extension MAY be included in Registration Requests and Replies > in cases in which a mobility security association exists between > the foreign agent and the home agent, as long as the Registration > Request is not a deregistration (i.e., it is requesting a positive > lifetime and the home address is different than the care-of address). > The Foreign-Home Authentication extension MUST NOT be applied to > deregistration messages. ... > > > This makes sense, because the mobile node is clearly not using > the deregistration message to ask for any service from the foreign > agent. Furthermore, there is no danger from _malicious_ activity > from the mobile node. > > Regards, > Charlie P. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Oct 23 00:26:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10840 for ; Sat, 23 Oct 2004 00:26:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLDhQ-0005JH-1l for mip4-web-archive@ietf.org; Sat, 23 Oct 2004 00:40:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDPK-0001qk-Fe; Sat, 23 Oct 2004 00:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDMs-0000iV-KD for mip4@megatron.ietf.org; Sat, 23 Oct 2004 00:19:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10463 for ; Sat, 23 Oct 2004 00:19:00 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLDZo-0005As-Mo for mip4@ietf.org; Sat, 23 Oct 2004 00:32:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9N3ouq08585; Fri, 22 Oct 2004 20:50:56 -0700 X-mProtect: <200410230350> Nokia Silicon Valley Messaging Protection Received: from danira-pool049137.americas.nokia.com (10.241.49.137, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsQ8M1P; Fri, 22 Oct 2004 20:50:53 PDT Message-ID: <4179DB7C.3020403@iprg.nokia.com> Date: Fri, 22 Oct 2004 21:18:04 -0700 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [Mip4] An idea about issue #45 References: <4179999E.C9C6F0C4@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Hello Sri, The problem to be solved by having the identity extension is not the same as the problem about what to do if the mobile node authentication works fine, but the home agent encounters an error within the Foreign-Home authentication extension. This is a relatively small sub-issue that should have perhaps been separated out from issue #45. It is only this sub-issue that I was trying to solve by my proposed restriction. Regards, Charlie P. Sri Gundavelli wrote: >Hi Charlie, > On the issue 45, we believe that the >solution for that problem can be based on a FA >Identity Extension and that can defined outside >the 3344bis. We can discuss this further at the >Washington IETF. > >Regards ! >Sri/ > >On Fri, 22 Oct 2004, Charles E.Perkins wrote: > > > >>Hello folks, >> >>My last e-mail included some information about issue #45 >>that was not quite right. After sending that e-mail out, >>I began to review more e-mails about the subject, and found >>a note requesting me to change the specification so that >>the registration request would be dropped by the home agent >>if there is an offending Foreign-Home Authentication >>extension applied to a deregistration. >> >>Unfortunately, I am not able to complete that task in >>the limited time I have available today. However, I >>found another "minimal-text" solution to the problem, and >>I would like to propose it for now, include it in the >>release before next Monday, and make some discussion on >>the list and at the next meeting. Please accept my >>sincere regrets at (a) not tackling the task of issue #45 >>sooner, avoiding what has become a rush job, and (b) >>not having this idea sooner so that we could have >>a longer discussion before submission. I will make >>whatever changes are needed after our discussion at >>the upcoming IETF, immediately after it becomes >>possible to resubmit the document. >> >>The proposed solution is very simple: namely, that the >>Foreign-Home Authentication extension be modified to >>prohibit inclusion in a deregistration message, as follows: >> >>3.5.4. Foreign-Home Authentication Extension >> >> This Extension MAY be included in Registration Requests and Replies >> in cases in which a mobility security association exists between >> the foreign agent and the home agent, as long as the Registration >> Request is not a deregistration (i.e., it is requesting a positive >> lifetime and the home address is different than the care-of address). >> The Foreign-Home Authentication extension MUST NOT be applied to >> deregistration messages. ... >> >> >>This makes sense, because the mobile node is clearly not using >>the deregistration message to ask for any service from the foreign >>agent. Furthermore, there is no danger from _malicious_ activity >>from the mobile node. >> >>Regards, >>Charlie P. >> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> >> >> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Oct 24 17:42:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02190 for ; Sun, 24 Oct 2004 17:42:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLqLs-0005yZ-G7 for mip4-web-archive@ietf.org; Sun, 24 Oct 2004 17:56:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLq4Y-0004iz-U9; Sun, 24 Oct 2004 17:38:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLpy0-0004PM-EN for mip4@megatron.ietf.org; Sun, 24 Oct 2004 17:31:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01757 for ; Sun, 24 Oct 2004 17:31:53 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLqBG-0005q4-8n for mip4@ietf.org; Sun, 24 Oct 2004 17:45:42 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9OLVdPJ003408; Sun, 24 Oct 2004 16:31:45 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i9OLVXJ05649; Sun, 24 Oct 2004 16:31:33 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I5YO6W-0001QO-00; Thu, 21 Oct 2004 21:01:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16760.23542.368795.381371@gargle.gargle.HOWL> Date: Thu, 21 Oct 2004 20:01:42 -0500 From: Pete McCann To: "Jayshree Bharatia" Subject: RE: [Mip4] Question regarding 3012bis In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit Cc: "'Kent Leung'" , "'mip4@ietf.org'" , "'Henrik Levkowetz'" , "'Alpesh Patel'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Jayshree, Thanks very much. This text doesn't seem to explicitly ask for the HMAC_MD5 method to be added to Section 8. Maybe it is just a statement about Section 8 compared to the new default method. One way to go is to cut-and-paste this text into the security considerations and delete the HMAC_MD5 RADIUS method from Section 8. Opinions? -Pete Jayshree Bharatia writes: > Hi Pete, > > Regarding your inquiry on the security review that led to the addition of > HMAC-MD5, the following was the issue brought up by AD for RFC3012bis > (mobile IP ver 3) document: > > Issue: "Section 8 (SPI for RADIUS AAA Servers) defines a method of computing > the Generalized Mobile IP Authentication Extension's authenticator field > using MD5 in a manner that is consistent with RADIUS [9]. The use of MD5 in > the method described in Section 8 is less secure than HMAC-MD5 [6], and > should be avoided whenever possible." > > Regards, > Jayshree > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Pete > McCann > Sent: Wednesday, October 20, 2004 7:35 PM > To: Kent Leung > Cc: mip4@ietf.org; Henrik Levkowetz; Alpesh Patel > Subject: Re: [Mip4] Question regarding 3012bis > > > > Hi, Kent, > > Kent Leung writes: > > > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > > > > > >It seems to say that HMAC_MD5 replaces both the "inner" and "outer" > > >occurences of MD5, but fails to specify the Key used for the "inner" > > >HMAC_MD5. > > > >Because the purpose of this "inner" hash is to provide > compression, > >not authentication, I think it is not reasonable to require > a secret > >pre-shared key between the MN and FA. > > > >I think we have > two realistic options at this point: > > > >1) specify a fixed key for > usage in the inner HMAC_MD5, or one that > > > is derived from information in the RRQ; > > > > Either fixed key or derivation of cleartext data seem to lose the > security > potency of HMAC_MD5. > > The inner hash is not for authentication, it is for compression. So, I am > not so worried about "security potency." What you are saying is that it > might be somewhat easier for someone to find a different RRQ that hashes to > the same value; but, we still have the challenge value as input to the outer > HMAC_MD5, which is still secured with a key. > > > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > > > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication > function > > > > Is this scheme stronger than just using MD5? I think the key question is > > how does not having a shared key affect the security strength? And is > there > value to use this method of authentication given it's not the > designed > HMAC_MD5 algorithm? > > We probably don't have the expertise in this group to answer this question. > > I do not recall the input from the security review that led to the addition > of HMAC_MD5. Did it ask for HMAC_MD5 to be added to both the main default > algorithm and the RADIUS SPIs, or just the main default algorithm? Does > anyone have a pointer to the original input? > > If there was no request from security folks to add HMAC_MD5 to the RADIUS > SPIs I would not mind deleting it. > > > >Opinions? > > > > > > Unless there's some worthwhile security gain using HMAC_MD5 in the > > suggested adapted method above, *and* some standardized way to > even > accomplish outer authentication function, wondering why should we > proceed > with this method? > > I do not think there is a requirement to synchronize our draft with RADIUS > extensions. > > > Maybe this is something we can add later when the details are worked > > out? > > This is certainly one possible way to resolve the issue. > > -Pete > > > Kent > > > > > > > > >As for your second problem (RADIUS AVPs) I think that is not a problem > > >that should be addressed with this document. If people want to > > >support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs > > >to carry an indication of the fact that HMAC_CHAP_SPI is being used. > > >Also the home RADIUS server needs to be upgraded to support HMAC_MD5. > > >It is not in the scope of 3012bis or the mip4 WG to do RADIUS > > >extensions so I think we just have to understand that HMAC_CHAP_SPI > > >cannot be supported by existing standard RADIUS servers until > > >additional specification work has been done. > > > >-Pete > > > > > > >Alpesh Patel writes: > > > Hi - > > > > > > I have a basic concern > regarding the use of HMAC_MD5 in 3012bis > > > (I have had a few email > exchanges with authors and WG chairs in > > > this regards and am posting > on WG chair suggestion) > > > > > > 3012bis defines GENAE (MN-AAA > authenticator to be precise). > > > The MN-AAA authenticator (MAAE) aids > in AAA authentication by > > > mapping the RRQ extensions to AAA > attributes at FA or HA. > > > > > > With CHAP_SPI (value 2), the RRQ > extensions are mapped to > > > Radius chap attributes for chap > authentication. The details are > > > as follows: > > > > > > chap > challenge = md5(RRQ data till the SPI field of MAAE) > > > chap challenge > = authenticator field from MAAE > > > > > > The authenticator > calculation is specified in 3012bis and no issue > > > with that in > regards to MD5. > > > > > > This works and is widely deployed today. > > > > > > > As a summary, the chap challenge above aids to compress the > message. > > > > > > Now, when SPI in MAAE is HMAC_MD5, the draft > mentions that the chap > > > challenge above is calculated using HMAC_MD5 > and that the authenticator > > > is calculated using HMAC_MD5. I have a > concern with both these claims: > > > > > > 1. Issue with chap challenge > - for MHAC_MD6 to be used, a "key" is > > > required between MN and FA/HA. > One basic assumption is that in some > > > domains/deployments this can be > manually provisioned. One issue is how > > > to decide on which :key: to > use for challenge generation? No means to > > > specify that. (one > applicability of this draft is to leverage on a > > > single MN/AAA secret > and so, I cannot clearly see the reason for such a > > > provisoned key). > > > > > > > 2. second and primary concern is that there are no radius > attributes > > > (standard /VSAs), which can be used to authenticate a > challenge response > > > generated using HMAC_MD5. Basic radius CHAP uses > plain MD5. In light of > > > that new attributes need to be defined and > processing at Radius needs to > > > be specified. > > > > > > In light > of these two issues, I am wondering how HMAC_MD5 can be > > > > realistically used for authenticating MAAE today? > > > > > > Can > someone demystify the usage of HMAC_MD5? > > > > > > Thanks > > > > Alpesh > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 25 12:34:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12206 for ; Mon, 25 Oct 2004 12:34:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM81J-0002OQ-HD for mip4-web-archive@ietf.org; Mon, 25 Oct 2004 12:48:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7ed-0005hf-4w; Mon, 25 Oct 2004 12:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7ap-0004lM-V2 for mip4@megatron.ietf.org; Mon, 25 Oct 2004 12:21:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11139 for ; Mon, 25 Oct 2004 12:21:08 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7oJ-000256-8D for mip4@ietf.org; Mon, 25 Oct 2004 12:35:08 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9PGJYA12060; Mon, 25 Oct 2004 12:19:34 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Oct 2004 12:19:34 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Pete McCann'" Subject: RE: [Mip4] Question regarding 3012bis Date: Mon, 25 Oct 2004 12:19:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 Cc: "'Kent Leung'" , "'mip4@ietf.org'" , "'Henrik Levkowetz'" , "'Alpesh Patel'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1953011916==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1953011916== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BAAE.65969856" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4BAAE.65969856 Content-Type: text/plain Hi Pete, I am fine with your suggestions. If we don't receive any further comments on this topic by next Monday (Nov 1, 2004), I will update mip4-02 version to remove hooks for HMAC-MD5 and add risk statement as a part of security considerations. Thanks, Jayshree -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Thursday, October 21, 2004 8:02 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH] Cc: 'Kent Leung'; 'mip4@ietf.org'; 'Henrik Levkowetz'; 'Alpesh Patel' Subject: RE: [Mip4] Question regarding 3012bis Jayshree, Thanks very much. This text doesn't seem to explicitly ask for the HMAC_MD5 method to be added to Section 8. Maybe it is just a statement about Section 8 compared to the new default method. One way to go is to cut-and-paste this text into the security considerations and delete the HMAC_MD5 RADIUS method from Section 8. Opinions? -Pete Jayshree Bharatia writes: > Hi Pete, > > Regarding your inquiry on the security review that led to the addition of > HMAC-MD5, the following was the issue brought up by AD for RFC3012bis > (mobile IP ver 3) document: > > Issue: "Section 8 (SPI for RADIUS AAA Servers) defines a method of computing > the Generalized Mobile IP Authentication Extension's authenticator field > using MD5 in a manner that is consistent with RADIUS [9]. The use of MD5 in > the method described in Section 8 is less secure than HMAC-MD5 [6], and > should be avoided whenever possible." > > Regards, > Jayshree > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Pete > McCann > Sent: Wednesday, October 20, 2004 7:35 PM > To: Kent Leung > Cc: mip4@ietf.org; Henrik Levkowetz; Alpesh Patel > Subject: Re: [Mip4] Question regarding 3012bis > > > > Hi, Kent, > > Kent Leung writes: > > > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > > > > > >It seems to say that HMAC_MD5 replaces both the "inner" and "outer" > > >occurences of MD5, but fails to specify the Key used for the "inner" > > >HMAC_MD5. > > > >Because the purpose of this "inner" hash is to provide > compression, > >not authentication, I think it is not reasonable to require > a secret > >pre-shared key between the MN and FA. > > > >I think we have > two realistic options at this point: > > > >1) specify a fixed key for > usage in the inner HMAC_MD5, or one that > > > is derived from information in the RRQ; > > > > Either fixed key or derivation of cleartext data seem to lose the > security > potency of HMAC_MD5. > > The inner hash is not for authentication, it is for compression. So, I am > not so worried about "security potency." What you are saying is that it > might be somewhat easier for someone to find a different RRQ that hashes to > the same value; but, we still have the challenge value as input to the outer > HMAC_MD5, which is still secured with a key. > > > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > > > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication > function > > > > Is this scheme stronger than just using MD5? I think the key question is > > how does not having a shared key affect the security strength? And is > there > value to use this method of authentication given it's not the > designed > HMAC_MD5 algorithm? > > We probably don't have the expertise in this group to answer this question. > > I do not recall the input from the security review that led to the addition > of HMAC_MD5. Did it ask for HMAC_MD5 to be added to both the main default > algorithm and the RADIUS SPIs, or just the main default algorithm? Does > anyone have a pointer to the original input? > > If there was no request from security folks to add HMAC_MD5 to the RADIUS > SPIs I would not mind deleting it. > > > >Opinions? > > > > > > Unless there's some worthwhile security gain using HMAC_MD5 in the > > suggested adapted method above, *and* some standardized way to > even > accomplish outer authentication function, wondering why should we > proceed > with this method? > > I do not think there is a requirement to synchronize our draft with RADIUS > extensions. > > > Maybe this is something we can add later when the details are worked > > out? > > This is certainly one possible way to resolve the issue. > > -Pete > > > Kent > > > > > > > > >As for your second problem (RADIUS AVPs) I think that is not a problem > > >that should be addressed with this document. If people want to > > >support the HMAC_CHAP_SPI then they need to construct the RADIUS AVPs > > >to carry an indication of the fact that HMAC_CHAP_SPI is being used. > > >Also the home RADIUS server needs to be upgraded to support HMAC_MD5. > > >It is not in the scope of 3012bis or the mip4 WG to do RADIUS > > >extensions so I think we just have to understand that HMAC_CHAP_SPI > > >cannot be supported by existing standard RADIUS servers until > > >additional specification work has been done. > > > >-Pete > > > > > > >Alpesh Patel writes: > > > Hi - > > > > > > I have a basic concern > regarding the use of HMAC_MD5 in 3012bis > > > (I have had a few email > exchanges with authors and WG chairs in > > > this regards and am posting > on WG chair suggestion) > > > > > > 3012bis defines GENAE (MN-AAA > authenticator to be precise). > > > The MN-AAA authenticator (MAAE) aids > in AAA authentication by > > > mapping the RRQ extensions to AAA > attributes at FA or HA. > > > > > > With CHAP_SPI (value 2), the RRQ > extensions are mapped to > > > Radius chap attributes for chap > authentication. The details are > > > as follows: > > > > > > chap > challenge = md5(RRQ data till the SPI field of MAAE) > > > chap challenge > = authenticator field from MAAE > > > > > > The authenticator > calculation is specified in 3012bis and no issue > > > with that in > regards to MD5. > > > > > > This works and is widely deployed today. > > > > > > > As a summary, the chap challenge above aids to compress the > message. > > > > > > Now, when SPI in MAAE is HMAC_MD5, the draft > mentions that the chap > > > challenge above is calculated using HMAC_MD5 > and that the authenticator > > > is calculated using HMAC_MD5. I have a > concern with both these claims: > > > > > > 1. Issue with chap challenge > - for MHAC_MD6 to be used, a "key" is > > > required between MN and FA/HA. > One basic assumption is that in some > > > domains/deployments this can be > manually provisioned. One issue is how > > > to decide on which :key: to > use for challenge generation? No means to > > > specify that. (one > applicability of this draft is to leverage on a > > > single MN/AAA secret > and so, I cannot clearly see the reason for such a > > > provisoned key). > > > > > > > 2. second and primary concern is that there are no radius > attributes > > > (standard /VSAs), which can be used to authenticate a > challenge response > > > generated using HMAC_MD5. Basic radius CHAP uses > plain MD5. In light of > > > that new attributes need to be defined and > processing at Radius needs to > > > be specified. > > > > > > In light > of these two issues, I am wondering how HMAC_MD5 can be > > > > realistically used for authenticating MAAE today? > > > > > > Can > someone demystify the usage of HMAC_MD5? > > > > > > Thanks > > > > Alpesh > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ ------_=_NextPart_001_01C4BAAE.65969856 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Question regarding 3012bis

Hi Pete,

I am fine with your suggestions. If we don't receive = any further comments on this topic by next Monday (Nov 1, 2004), I will = update mip4-02 version to remove hooks for HMAC-MD5 and add risk = statement as a part of security considerations.

Thanks,
Jayshree

-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Thursday, October 21, 2004 8:02 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: 'Kent Leung'; 'mip4@ietf.org'; 'Henrik = Levkowetz'; 'Alpesh Patel'
Subject: RE: [Mip4] Question regarding = 3012bis



Jayshree,

Thanks very much.

This text doesn't seem to explicitly ask for the = HMAC_MD5 method to be added to Section 8.  Maybe it is just a = statement about Section 8 compared to the new default method.  One = way to go is to cut-and-paste this text into the security = considerations and delete the HMAC_MD5 RADIUS method from Section = 8.

Opinions?

-Pete


Jayshree Bharatia writes:
 > Hi Pete,
 >
 > Regarding your inquiry on the security = review that led to the addition of  > HMAC-MD5, the following = was the issue brought up by AD for RFC3012bis  > (mobile IP ver = 3) document:  >

 > Issue: "Section 8 (SPI for RADIUS AAA = Servers) defines a method of computing  > the Generalized = Mobile IP Authentication Extension's authenticator field  > = using MD5 in a manner that is consistent with RADIUS [9]. The use of = MD5 in  > the method described in Section 8 is less secure than = HMAC-MD5 [6], and  > should be avoided whenever = possible."  >

 > Regards,
 > Jayshree
 >
 > -----Original Message-----
 > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] = On Behalf Of Pete  > McCann  > Sent: Wednesday, October = 20, 2004 7:35 PM  > To: Kent Leung  > Cc: = mip4@ietf.org; Henrik Levkowetz; Alpesh Patel  > Subject: Re: = [Mip4] Question regarding 3012bis  >

 >
 >
 > Hi, Kent,
 >
 > Kent Leung writes:
 >  >
 >  > At 04:48 AM 10/20/2004 -0500, = Pete McCann wrote:
 >  >
 >  >
 >  > >It seems to say that = HMAC_MD5 replaces both the "inner" and = "outer"  >  > >occurences of MD5, but = fails to specify the Key used for the "inner"  = >  > >HMAC_MD5.  > >  > >Because = the purpose of this "inner" hash is to provide  > = compression,  > >not authentication, I think it is not = reasonable to require  > a secret  > >pre-shared key = between the MN and FA.  > >  > >I think we = have  > two realistic options at this point:  > = >  > >1) specify a fixed key for  > usage in the = inner HMAC_MD5, or one that

 >  > >    is = derived from information in the RRQ;
 >  >
 >  > Either fixed key or derivation = of cleartext data seem to lose the  > security  > = potency of HMAC_MD5.  >
 > The inner hash is not for authentication, = it is for compression.  So, I am  > not so worried about = "security potency."  What you are saying is that = it  > might be somewhat easier for someone to find a different = RRQ that hashes to  > the same value; but, we still have the = challenge value as input to the outer  > HMAC_MD5, which is = still secured with a key.  >

 >  > >2) revert back to MD5 for = the inner hash for both CHAP_SPI and
 >  > >    = HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication
 > function
 >  >
 >  > Is this scheme stronger than = just using MD5? I think the key question is  > > how does = not having a shared key affect the security strength? And is  > = there  > value to use this method of authentication given it's = not the  > designed  > HMAC_MD5 algorithm?  > =

 > We probably don't have the expertise in = this group to answer this question.  >
 > I do not recall the input from the = security review that led to the addition  > of HMAC_MD5.  = Did it ask for HMAC_MD5 to be added to both the main default  > = algorithm and the RADIUS SPIs, or just the main default = algorithm?  Does  > anyone have a pointer to the original = input?  >

 > If there was no request from security = folks to add HMAC_MD5 to the RADIUS  > SPIs I would not mind = deleting it.  >
 >  > >Opinions?
 >  >
 >  >
 >  > Unless there's some worthwhile = security gain using HMAC_MD5 in the  >  > suggested = adapted method above, *and* some standardized way to  > = even  > accomplish outer authentication function, wondering why = should we  > proceed  > with this method?  > =

 > I do not think there is a requirement to = synchronize our draft with RADIUS  > extensions.  > =
 >  > Maybe this is something we can = add later when the details are worked  >  > out?  = >
 > This is certainly one possible way to = resolve the issue.
 >
 > -Pete
 >
 >  > Kent
 >  >
 >  >
 >  >
 >  > >As for your second problem = (RADIUS AVPs) I think that is not a problem  > > >that = should be addressed with this document.  If people want to  = >  > >support the HMAC_CHAP_SPI then they need to = construct the RADIUS AVPs  >  > >to carry an = indication of the fact that HMAC_CHAP_SPI is being used.  = >  > >Also the home RADIUS server needs to be upgraded to = support HMAC_MD5.  >  > >It is not in the scope of = 3012bis or the mip4 WG to do RADIUS  >  > = >extensions so I think we just have to understand that = HMAC_CHAP_SPI  >  > >cannot be supported by existing = standard RADIUS servers until  >  > >additional = specification work has been done.  > >  > = >-Pete  > >  > >  >  > = >Alpesh Patel writes:  > >  > Hi -  > = >  >  > >  > I have a basic concern  = > regarding the use of HMAC_MD5 in 3012bis  > >  = > (I have had a few email  > exchanges with authors and WG = chairs in  > >  > this regards and am posting  = > on WG chair suggestion)  > >  >  > = >  > 3012bis defines GENAE (MN-AAA  > authenticator = to be precise).  > >  > The MN-AAA authenticator = (MAAE) aids  > in AAA authentication by  > >  = > mapping the RRQ extensions to AAA  > attributes at FA or = HA.  > >  >  > >  > With CHAP_SPI = (value  2), the RRQ  > extensions are mapped to  > = >  > Radius chap attributes for chap  > = authentication. The details are  > >  > as = follows:  > >  >  > >  > = chap  > challenge =3D md5(RRQ data till the SPI field of = MAAE)  > >  > chap challenge  > =3D = authenticator field from MAAE  > >  >  > = >  > The authenticator  > calculation is specified = in 3012bis and no issue  > >  > with that in  = > regards to MD5.  > >  >  > >  = > This works and is widely deployed today.  >  > = >  >  > >  > As a summary, the chap = challenge above aids to compress the  > message.  > = >  >  > >  > Now, when SPI in MAAE is = HMAC_MD5, the draft  > mentions that the chap  > = >  > challenge above is calculated using HMAC_MD5  > = and that the authenticator  > >  > is calculated = using HMAC_MD5. I have a  > concern with both these = claims:  > >  >  > >  > 1. Issue = with chap challenge  > - for MHAC_MD6 to be used, a = "key" is  > >  > required between MN and = FA/HA.  > One basic assumption is that in some  > = >  > domains/deployments this can be  > manually = provisioned. One issue is how  > >  > to decide on = which :key: to  > use for challenge generation? No means = to  > >  > specify that. (one  > = applicability of this draft is to leverage on a  > >  = > single MN/AAA secret  > and so, I cannot clearly see the = reason for such a  > >  > provisoned key).  = > > >  >  > >  > 2. second and = primary concern is that there are no radius  > attributes  = > >  > (standard /VSAs), which can be used to = authenticate a  > challenge response  > >  > = generated using HMAC_MD5. Basic radius CHAP uses  > plain MD5. = In light of  > >  > that new attributes need to be = defined and  > processing at Radius needs to  > = >  > be specified.  > >  >  > = >  > In light  > of these two issues, I am wondering = how HMAC_MD5 can be  > >  >  > realistically = used for authenticating MAAE today?  > >  >  = > >  > Can  > someone demystify the usage of = HMAC_MD5?  > >  >  > >  > = Thanks  > >  >  > Alpesh  > =

 >
 > --
 > Mip4 mailing list: Mip4@ietf.org
 >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4=
 >      Charter = page: http://www.ietf.org/html.charters/mip4-charter.html
 > Supplemental site: http://www.mip4.org/


------_=_NextPart_001_01C4BAAE.65969856-- --===============1953011916== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1953011916==-- From mip4-bounces@ietf.org Mon Oct 25 18:51:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06300 for ; Mon, 25 Oct 2004 18:51:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDuI-0000Mj-K0 for mip4-web-archive@ietf.org; Mon, 25 Oct 2004 19:05:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBTr-0003ho-Di; Mon, 25 Oct 2004 16:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB54-0006Q8-Ps; Mon, 25 Oct 2004 16:04:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29490; Mon, 25 Oct 2004 16:04:36 -0400 (EDT) Message-Id: <200410252004.QAA29490@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 25 Oct 2004 16:04:36 -0400 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc3344bis-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mip4-rfc3344bis-01.txt Pages : 100 Date : 2004-10-25 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc3344bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-rfc3344bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-rfc3344bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2004-10-25162144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-rfc3344bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-rfc3344bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162144.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon Oct 25 20:10:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22377 for ; Mon, 25 Oct 2004 20:10:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMF8H-0005Gl-2u for mip4-web-archive@ietf.org; Mon, 25 Oct 2004 20:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEZH-0006zW-6k; Mon, 25 Oct 2004 19:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CME3U-0006Jw-9e for mip4@megatron.ietf.org; Mon, 25 Oct 2004 19:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12011 for ; Mon, 25 Oct 2004 19:15:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEH1-00029F-Fo for mip4@ietf.org; Mon, 25 Oct 2004 19:29:12 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2004 16:23:45 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9PNEGYJ002512; Mon, 25 Oct 2004 16:14:16 -0700 (PDT) Received: from [128.107.163.246] (dhcp-128-107-163-246.cisco.com [128.107.163.246]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYJ46471; Mon, 25 Oct 2004 16:16:43 -0700 (PDT) Message-ID: <417D88EE.9050409@cisco.com> Date: Mon, 25 Oct 2004 16:14:54 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] Question regarding 3012bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: "'Pete McCann'" , "'mip4@ietf.org'" , "'Kent Leung'" , "'Henrik Levkowetz'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: 7bit Jayshree - I am fine with Pete's comment. Do you still need any text from me now? -a Jayshree Bharatia wrote: > Hi Pete, > > I am fine with your suggestions. If we don't receive any further > comments on this topic by next Monday (Nov 1, 2004), I will update > mip4-02 version to remove hooks for HMAC-MD5 and add risk statement as > a part of security considerations. > > Thanks, > Jayshree > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, October 21, 2004 8:02 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'Kent Leung'; 'mip4@ietf.org'; 'Henrik Levkowetz'; 'Alpesh Patel' > Subject: RE: [Mip4] Question regarding 3012bis > > > > Jayshree, > > Thanks very much. > > This text doesn't seem to explicitly ask for the HMAC_MD5 method to be > added to Section 8. Maybe it is just a statement about Section 8 > compared to the new default method. One way to go is to cut-and-paste > this text into the security considerations and delete the HMAC_MD5 > RADIUS method from Section 8. > > Opinions? > > -Pete > > > Jayshree Bharatia writes: > > Hi Pete, > > > > Regarding your inquiry on the security review that led to the > addition of > HMAC-MD5, the following was the issue brought up by AD > for RFC3012bis > (mobile IP ver 3) document: > > > > Issue: "Section 8 (SPI for RADIUS AAA Servers) defines a method of > computing > the Generalized Mobile IP Authentication Extension's > authenticator field > using MD5 in a manner that is consistent with > RADIUS [9]. The use of MD5 in > the method described in Section 8 is > less secure than HMAC-MD5 [6], and > should be avoided whenever > possible." > > > > Regards, > > Jayshree > > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Pete > McCann > Sent: Wednesday, October 20, 2004 7:35 PM > > To: Kent Leung > Cc: mip4@ietf.org; Henrik Levkowetz; Alpesh Patel > > Subject: Re: [Mip4] Question regarding 3012bis > > > > > > > > Hi, Kent, > > > > Kent Leung writes: > > > > > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > > > > > > > > >It seems to say that HMAC_MD5 replaces both the "inner" and > "outer" > > >occurences of MD5, but fails to specify the Key used > for the "inner" > > >HMAC_MD5. > > > >Because the purpose of this > "inner" hash is to provide > compression, > >not authentication, I > think it is not reasonable to require > a secret > >pre-shared key > between the MN and FA. > > > >I think we have > two realistic > options at this point: > > > >1) specify a fixed key for > usage in > the inner HMAC_MD5, or one that > > > > > is derived from information in the RRQ; > > > > > > Either fixed key or derivation of cleartext data seem to lose > the > security > potency of HMAC_MD5. > > > The inner hash is not for authentication, it is for compression. > So, I am > not so worried about "security potency." What you are > saying is that it > might be somewhat easier for someone to find a > different RRQ that hashes to > the same value; but, we still have the > challenge value as input to the outer > HMAC_MD5, which is still > secured with a key. > > > > > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > > > > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication > > function > > > > > > Is this scheme stronger than just using MD5? I think the key > question is > > how does not having a shared key affect the security > strength? And is > there > value to use this method of > authentication given it's not the > designed > HMAC_MD5 algorithm? > > > > We probably don't have the expertise in this group to answer this > question. > > > I do not recall the input from the security review that led to the > addition > of HMAC_MD5. Did it ask for HMAC_MD5 to be added to both > the main default > algorithm and the RADIUS SPIs, or just the main > default algorithm? Does > anyone have a pointer to the original > input? > > > > If there was no request from security folks to add HMAC_MD5 to the > RADIUS > SPIs I would not mind deleting it. > > > > >Opinions? > > > > > > > > > Unless there's some worthwhile security gain using HMAC_MD5 in > the > > suggested adapted method above, *and* some standardized way > to > even > accomplish outer authentication function, wondering why > should we > proceed > with this method? > > > > I do not think there is a requirement to synchronize our draft with > RADIUS > extensions. > > > > Maybe this is something we can add later when the details are > worked > > out? > > > This is certainly one possible way to resolve the issue. > > > > -Pete > > > > > Kent > > > > > > > > > > > > >As for your second problem (RADIUS AVPs) I think that is not a > problem > > >that should be addressed with this document. If people > want to > > >support the HMAC_CHAP_SPI then they need to construct > the RADIUS AVPs > > >to carry an indication of the fact that > HMAC_CHAP_SPI is being used. > > >Also the home RADIUS server needs > to be upgraded to support HMAC_MD5. > > >It is not in the scope of > 3012bis or the mip4 WG to do RADIUS > > >extensions so I think we > just have to understand that HMAC_CHAP_SPI > > >cannot be supported > by existing standard RADIUS servers until > > >additional > specification work has been done. > > > >-Pete > > > > > > > >Alpesh Patel writes: > > > Hi - > > > > > > I have a basic > concern > regarding the use of HMAC_MD5 in 3012bis > > > (I have > had a few email > exchanges with authors and WG chairs in > > > > this regards and am posting > on WG chair suggestion) > > > > > > > 3012bis defines GENAE (MN-AAA > authenticator to be precise). > > > > The MN-AAA authenticator (MAAE) aids > in AAA authentication by > > > > mapping the RRQ extensions to AAA > attributes at FA or HA. > > > > > > > With CHAP_SPI (value 2), the RRQ > extensions are mapped > to > > > Radius chap attributes for chap > authentication. The > details are > > > as follows: > > > > > > chap > challenge = > md5(RRQ data till the SPI field of MAAE) > > > chap challenge > = > authenticator field from MAAE > > > > > > The authenticator > > calculation is specified in 3012bis and no issue > > > with that in > > regards to MD5. > > > > > > This works and is widely deployed > today. > > > > > > > As a summary, the chap challenge above aids > to compress the > message. > > > > > > Now, when SPI in MAAE is > HMAC_MD5, the draft > mentions that the chap > > > challenge above > is calculated using HMAC_MD5 > and that the authenticator > > > is > calculated using HMAC_MD5. I have a > concern with both these > claims: > > > > > > 1. Issue with chap challenge > - for MHAC_MD6 > to be used, a "key" is > > > required between MN and FA/HA. > One > basic assumption is that in some > > > domains/deployments this can > be > manually provisioned. One issue is how > > > to decide on > which :key: to > use for challenge generation? No means to > > > > specify that. (one > applicability of this draft is to leverage on a > > > > single MN/AAA secret > and so, I cannot clearly see the reason > for such a > > > provisoned key). > > > > > > > 2. second and > primary concern is that there are no radius > attributes > > > > (standard /VSAs), which can be used to authenticate a > challenge > response > > > generated using HMAC_MD5. Basic radius CHAP uses > > plain MD5. In light of > > > that new attributes need to be defined > and > processing at Radius needs to > > > be specified. > > > > > > > In light > of these two issues, I am wondering how HMAC_MD5 can > be > > > > realistically used for authenticating MAAE today? > > > > > > > Can > someone demystify the usage of HMAC_MD5? > > > > > > > Thanks > > > > Alpesh > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Oct 25 20:11:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22687 for ; Mon, 25 Oct 2004 20:11:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMF9P-0005Kn-Pu for mip4-web-archive@ietf.org; Mon, 25 Oct 2004 20:25:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEZc-0007J6-MH; Mon, 25 Oct 2004 19:48:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CME8f-0007s2-30; Mon, 25 Oct 2004 19:20:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12843; Mon, 25 Oct 2004 19:20:29 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEM9-0002QA-LJ; Mon, 25 Oct 2004 19:34:32 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 19:19:58 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 19:19:58 -0400 Message-ID: Thread-Topic: MIP and transition issues Thread-Index: AcS66R10DpafzyueS8WJQO1BVKyGow== From: "Soliman, Hesham" To: , , , X-OriginalArrivalTime: 25 Oct 2004 23:19:58.0275 (UTC) FILETIME=[24EB1930:01C4BAE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Tsirtsis George Subject: [Mip4] MIP and transition issues X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Folks,=20 Sorry for the cross posting, but this issue is being discussed in all WG listed.=20 I submitted the following two drafts last night: draft-tsirtsis-dsmip-problem draft-soliman-v4v6-mipv6- The first deals with the problem statement and the=20 second is one of the solution for using MIPv6 only. There is another draft that proposes using MIPv4 only: draft-tsirtsis-v4v6-mipv4 I hope we can discuss the problem statement and scenarios=20 in the next meeting. While the problem statement is on the mip6 charter, it would be useful if we can have a slot allocated for=20 this in v6ops.=20 thx Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Oct 26 11:40:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16344 for ; Tue, 26 Oct 2004 11:40:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTeV-0005ow-MO for mip4-web-archive@ietf.org; Tue, 26 Oct 2004 11:54:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTLj-0003Je-Am; Tue, 26 Oct 2004 11:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMTEu-0001Pd-Ng for mip4@megatron.ietf.org; Tue, 26 Oct 2004 11:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14257 for ; Tue, 26 Oct 2004 11:27:58 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMTSa-0005Jz-2w for mip4@ietf.org; Tue, 26 Oct 2004 11:42:09 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9QFQI827909; Tue, 26 Oct 2004 11:26:18 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Oct 2004 11:26:17 -0400 Message-ID: From: "Jayshree Bharatia" To: "'Alpesh'" Subject: RE: [Mip4] Question regarding 3012bis Date: Tue, 26 Oct 2004 11:26:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 1.3 (+) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 Cc: "'Pete McCann'" , "'mip4@ietf.org'" , "'Kent Leung'" , "'Henrik Levkowetz'" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1711575519==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1711575519== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BB70.1D852161" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4BB70.1D852161 Content-Type: text/plain Alpesh, I don't think I will be needing any text unless you like to have any additional clarification. BTW, we already have suggested text in the security considerations section of RFC3012bis draft. Regards, Jayshree -----Original Message----- From: Alpesh [mailto:alpesh@cisco.com] Sent: Monday, October 25, 2004 6:15 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH] Cc: 'Pete McCann'; 'Kent Leung'; 'mip4@ietf.org'; 'Henrik Levkowetz' Subject: Re: [Mip4] Question regarding 3012bis Jayshree - I am fine with Pete's comment. Do you still need any text from me now? -a Jayshree Bharatia wrote: > Hi Pete, > > I am fine with your suggestions. If we don't receive any further > comments on this topic by next Monday (Nov 1, 2004), I will update > mip4-02 version to remove hooks for HMAC-MD5 and add risk statement as > a part of security considerations. > > Thanks, > Jayshree > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, October 21, 2004 8:02 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'Kent Leung'; 'mip4@ietf.org'; 'Henrik Levkowetz'; 'Alpesh Patel' > Subject: RE: [Mip4] Question regarding 3012bis > > > > Jayshree, > > Thanks very much. > > This text doesn't seem to explicitly ask for the HMAC_MD5 method to be > added to Section 8. Maybe it is just a statement about Section 8 > compared to the new default method. One way to go is to cut-and-paste > this text into the security considerations and delete the HMAC_MD5 > RADIUS method from Section 8. > > Opinions? > > -Pete > > > Jayshree Bharatia writes: > > Hi Pete, > > > > Regarding your inquiry on the security review that led to the > addition of > HMAC-MD5, the following was the issue brought up by AD > for RFC3012bis > (mobile IP ver 3) document: > > > > Issue: "Section 8 (SPI for RADIUS AAA Servers) defines a method of > computing > the Generalized Mobile IP Authentication Extension's > authenticator field > using MD5 in a manner that is consistent with > RADIUS [9]. The use of MD5 in > the method described in Section 8 is > less secure than HMAC-MD5 [6], and > should be avoided whenever > possible." > > > > Regards, > > Jayshree > > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Pete > McCann > Sent: Wednesday, October 20, 2004 7:35 PM > > To: Kent Leung > Cc: mip4@ietf.org; Henrik Levkowetz; Alpesh Patel > > Subject: Re: [Mip4] Question regarding 3012bis > > > > > > > > Hi, Kent, > > > > Kent Leung writes: > > > > > > At 04:48 AM 10/20/2004 -0500, Pete McCann wrote: > > > > > > > > > >It seems to say that HMAC_MD5 replaces both the "inner" and > "outer" > > >occurences of MD5, but fails to specify the Key used > for the "inner" > > >HMAC_MD5. > > > >Because the purpose of this > "inner" hash is to provide > compression, > >not authentication, I > think it is not reasonable to require > a secret > >pre-shared key > between the MN and FA. > > > >I think we have > two realistic > options at this point: > > > >1) specify a fixed key for > usage in > the inner HMAC_MD5, or one that > > > > > is derived from information in the RRQ; > > > > > > Either fixed key or derivation of cleartext data seem to lose > the > security > potency of HMAC_MD5. > > > The inner hash is not for authentication, it is for compression. > So, I am > not so worried about "security potency." What you are > saying is that it > might be somewhat easier for someone to find a > different RRQ that hashes to > the same value; but, we still have the > challenge value as input to the outer > HMAC_MD5, which is still > secured with a key. > > > > > >2) revert back to MD5 for the inner hash for both CHAP_SPI and > > > > HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication > > function > > > > > > Is this scheme stronger than just using MD5? I think the key > question is > > how does not having a shared key affect the security > strength? And is > there > value to use this method of > authentication given it's not the > designed > HMAC_MD5 algorithm? > > > > We probably don't have the expertise in this group to answer this > question. > > > I do not recall the input from the security review that led to the > addition > of HMAC_MD5. Did it ask for HMAC_MD5 to be added to both > the main default > algorithm and the RADIUS SPIs, or just the main > default algorithm? Does > anyone have a pointer to the original > input? > > > > If there was no request from security folks to add HMAC_MD5 to the > RADIUS > SPIs I would not mind deleting it. > > > > >Opinions? > > > > > > > > > Unless there's some worthwhile security gain using HMAC_MD5 in > the > > suggested adapted method above, *and* some standardized way > to > even > accomplish outer authentication function, wondering why > should we > proceed > with this method? > > > > I do not think there is a requirement to synchronize our draft with > RADIUS > extensions. > > > > Maybe this is something we can add later when the details are > worked > > out? > > > This is certainly one possible way to resolve the issue. > > > > -Pete > > > > > Kent > > > > > > > > > > > > >As for your second problem (RADIUS AVPs) I think that is not a > problem > > >that should be addressed with this document. If people > want to > > >support the HMAC_CHAP_SPI then they need to construct > the RADIUS AVPs > > >to carry an indication of the fact that > HMAC_CHAP_SPI is being used. > > >Also the home RADIUS server needs > to be upgraded to support HMAC_MD5. > > >It is not in the scope of > 3012bis or the mip4 WG to do RADIUS > > >extensions so I think we > just have to understand that HMAC_CHAP_SPI > > >cannot be supported > by existing standard RADIUS servers until > > >additional > specification work has been done. > > > >-Pete > > > > > > > >Alpesh Patel writes: > > > Hi - > > > > > > I have a basic > concern > regarding the use of HMAC_MD5 in 3012bis > > > (I have > had a few email > exchanges with authors and WG chairs in > > > > this regards and am posting > on WG chair suggestion) > > > > > > > 3012bis defines GENAE (MN-AAA > authenticator to be precise). > > > > The MN-AAA authenticator (MAAE) aids > in AAA authentication by > > > > mapping the RRQ extensions to AAA > attributes at FA or HA. > > > > > > > With CHAP_SPI (value 2), the RRQ > extensions are mapped > to > > > Radius chap attributes for chap > authentication. The > details are > > > as follows: > > > > > > chap > challenge = > md5(RRQ data till the SPI field of MAAE) > > > chap challenge > = > authenticator field from MAAE > > > > > > The authenticator > > calculation is specified in 3012bis and no issue > > > with that in > > regards to MD5. > > > > > > This works and is widely deployed > today. > > > > > > > As a summary, the chap challenge above aids > to compress the > message. > > > > > > Now, when SPI in MAAE is > HMAC_MD5, the draft > mentions that the chap > > > challenge above > is calculated using HMAC_MD5 > and that the authenticator > > > is > calculated using HMAC_MD5. I have a > concern with both these > claims: > > > > > > 1. Issue with chap challenge > - for MHAC_MD6 > to be used, a "key" is > > > required between MN and FA/HA. > One > basic assumption is that in some > > > domains/deployments this can > be > manually provisioned. One issue is how > > > to decide on > which :key: to > use for challenge generation? No means to > > > > specify that. (one > applicability of this draft is to leverage on a > > > > single MN/AAA secret > and so, I cannot clearly see the reason > for such a > > > provisoned key). > > > > > > > 2. second and > primary concern is that there are no radius > attributes > > > > (standard /VSAs), which can be used to authenticate a > challenge > response > > > generated using HMAC_MD5. Basic radius CHAP uses > > plain MD5. In light of > > > that new attributes need to be defined > and > processing at Radius needs to > > > be specified. > > > > > > > In light > of these two issues, I am wondering how HMAC_MD5 can > be > > > > realistically used for authenticating MAAE today? > > > > > > > Can > someone demystify the usage of HMAC_MD5? > > > > > > > Thanks > > > > Alpesh > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > ------_=_NextPart_001_01C4BB70.1D852161 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Question regarding 3012bis

Alpesh,

I don't think I will be needing any text unless you = like to have any additional clarification. BTW, we already have = suggested text in the security considerations section of RFC3012bis = draft.

Regards,
Jayshree

-----Original Message-----
From: Alpesh [mailto:alpesh@cisco.com]
Sent: Monday, October 25, 2004 6:15 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: 'Pete McCann'; 'Kent Leung'; 'mip4@ietf.org'; = 'Henrik Levkowetz'
Subject: Re: [Mip4] Question regarding = 3012bis


Jayshree -

I am fine with Pete's comment. Do you still need any = text from me now?

-a

Jayshree Bharatia wrote:

> Hi Pete,
>
> I am fine with your suggestions. If we don't = receive any further
> comments on this topic by next Monday (Nov 1, = 2004), I will update
> mip4-02 version to remove hooks for HMAC-MD5 = and add risk statement as
> a part of security considerations.
>
> Thanks,
> Jayshree
>
> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Thursday, October 21, 2004 8:02 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'Kent Leung'; 'mip4@ietf.org'; 'Henrik = Levkowetz'; 'Alpesh Patel'
> Subject: RE: [Mip4] Question regarding = 3012bis
>
>
>
> Jayshree,
>
> Thanks very much.
>
> This text doesn't seem to explicitly ask for = the HMAC_MD5 method to be
> added to Section 8.  Maybe it is just a = statement about Section 8
> compared to the new default method.  One = way to go is to cut-and-paste
> this text into the security considerations and = delete the HMAC_MD5
> RADIUS method from Section 8.
>
> Opinions?
>
> -Pete
>
>
> Jayshree Bharatia writes:
>  > Hi Pete,
>  >
>  > Regarding your inquiry on the = security review that led to the
> addition of  > HMAC-MD5, the following = was the issue brought up by AD
> for RFC3012bis  > (mobile IP ver 3) = document:  >
>
>  > Issue: "Section 8 (SPI for = RADIUS AAA Servers) defines a method of
> computing  > the Generalized Mobile IP = Authentication Extension's
> authenticator field  > using MD5 in a = manner that is consistent with
> RADIUS [9]. The use of MD5 in  > the = method described in Section 8 is
> less secure than HMAC-MD5 [6], and  > = should be avoided whenever
> possible."  >
>
>  > Regards,
>  > Jayshree
>  >
>  > -----Original Message-----
>  > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] = On
> Behalf Of Pete  > McCann  > = Sent: Wednesday, October 20, 2004 7:35 PM 
> > To: Kent Leung  > Cc: = mip4@ietf.org; Henrik Levkowetz; Alpesh Patel
> > Subject: Re: [Mip4] Question regarding = 3012bis  >
>
>  >
>  >
>  > Hi, Kent,
>  >
>  > Kent Leung writes:
>  >  >
>  >  > At 04:48 AM 10/20/2004 = -0500, Pete McCann wrote:
>  >  >
>  >  >
>  >  > >It seems to say that = HMAC_MD5 replaces both the "inner" and
> "outer"  >  > = >occurences of MD5, but fails to specify the Key used
> for the "inner"  >  > = >HMAC_MD5.  > >  > >Because the purpose of = this
> "inner" hash is to provide  > = compression,  > >not authentication, I
> think it is not reasonable to require  = > a secret  > >pre-shared key
> between the MN and FA.  > >  = > >I think we have  > two realistic
> options at this point:  > >  = > >1) specify a fixed key for  > usage in
> the inner HMAC_MD5, or one that
>
>  >  > >    is = derived from information in the RRQ;
>  >  >
>  >  > Either fixed key or = derivation of cleartext data seem to lose
> the  > security  > potency of = HMAC_MD5.  >
>  > The inner hash is not for = authentication, it is for compression. 
> So, I am  > not so worried about = "security potency."  What you are
> saying is that it  > might be somewhat = easier for someone to find a
> different RRQ that hashes to  > the = same value; but, we still have the
> challenge value as input to the outer  = > HMAC_MD5, which is still
> secured with a key.  >
>
>  >  > >2) revert back to MD5 = for the inner hash for both CHAP_SPI and
>  >  > >    = HMAC_CHAP_SPI, but keep HMAC_MD5 for the outer authentication
>  > function
>  >  >
>  >  > Is this scheme stronger = than just using MD5? I think the key
> question is  > > how does not having = a shared key affect the security
> strength? And is  > there  > = value to use this method of
> authentication given it's not the  > = designed  > HMAC_MD5 algorithm?  >
>
>  > We probably don't have the expertise = in this group to answer this
> question.  >
>  > I do not recall the input from the = security review that led to the
> addition  > of HMAC_MD5.  Did it = ask for HMAC_MD5 to be added to both
> the main default  > algorithm and the = RADIUS SPIs, or just the main
> default algorithm?  Does  > anyone = have a pointer to the original
> input?  >
>
>  > If there was no request from = security folks to add HMAC_MD5 to the
> RADIUS  > SPIs I would not mind = deleting it.  >
>  >  > >Opinions?
>  >  >
>  >  >
>  >  > Unless there's some = worthwhile security gain using HMAC_MD5 in
> the  >  > suggested adapted = method above, *and* some standardized way
> to  > even  > accomplish outer = authentication function, wondering why
> should we  > proceed  > with = this method?  >
>
>  > I do not think there is a = requirement to synchronize our draft with
> RADIUS  > extensions.  >
>  >  > Maybe this is something = we can add later when the details are
> worked  >  > out?  = >
>  > This is certainly one possible way = to resolve the issue.
>  >
>  > -Pete
>  >
>  >  > Kent
>  >  >
>  >  >
>  >  >
>  >  > >As for your second = problem (RADIUS AVPs) I think that is not a
> problem  > > >that should be = addressed with this document.  If people
> want to  >  > >support the = HMAC_CHAP_SPI then they need to construct
> the RADIUS AVPs  >  > >to = carry an indication of the fact that
> HMAC_CHAP_SPI is being used.  >  = > >Also the home RADIUS server needs
> to be upgraded to support HMAC_MD5.  = >  > >It is not in the scope of
> 3012bis or the mip4 WG to do RADIUS  = >  > >extensions so I think we
> just have to understand that = HMAC_CHAP_SPI  >  > >cannot be supported
> by existing standard RADIUS servers until  = >  > >additional
> specification work has been done.  > = >  > >-Pete  > >  > >  = >  >
> >Alpesh Patel writes:  > >  = > Hi -  > >  >  > >  > I have = a basic
> concern  > regarding the use of = HMAC_MD5 in 3012bis  > >  > (I have
> had a few email  > exchanges with = authors and WG chairs in  > >  >
> this regards and am posting  > on WG = chair suggestion)  > >  >  > >  > =
> 3012bis defines GENAE (MN-AAA  > = authenticator to be precise).  > >  >
> The MN-AAA authenticator (MAAE) aids  > = in AAA authentication by  > > 
> > mapping the RRQ extensions to AAA  = > attributes at FA or HA.  > >
> >  > >  > With CHAP_SPI = (value  2), the RRQ  > extensions are mapped
> to  > >  > Radius chap = attributes for chap  > authentication. The
> details are  > >  > as = follows:  > >  >  > >  > = chap  > challenge =3D
> md5(RRQ data till the SPI field of MAAE)  = > >  > chap challenge  > =3D
> authenticator field from MAAE  > = >  >  > >  > The authenticator  > =
> calculation is specified in 3012bis and no = issue  > >  > with that in 
> > regards to MD5.  > >  = >  > >  > This works and is widely = deployed
> today.  >  > >  = >  > >  > As a summary, the chap challenge above = aids
> to compress the  > message.  > = >  >  > >  > Now, when SPI in MAAE is =
> HMAC_MD5, the draft  > mentions that = the chap  > >  > challenge above
> is calculated using HMAC_MD5  > and = that the authenticator  > >  > is
> calculated using HMAC_MD5. I have a  > = concern with both these
> claims:  > >  >  > = >  > 1. Issue with chap challenge  > - for MHAC_MD6 =
> to be used, a "key" is  > = >  > required between MN and FA/HA.  > One
> basic assumption is that in some  > = >  > domains/deployments this can
> be  > manually provisioned. One issue = is how  > >  > to decide on
> which :key: to  > use for challenge = generation? No means to  > >  >
> specify that. (one  > applicability of = this draft is to leverage on a 
> > >  > single MN/AAA secret  = > and so, I cannot clearly see the reason
> for such a  > >  > = provisoned key).  > > >  >  > >  = > 2. second and
> primary concern is that there are no = radius  > attributes  > >  >
> (standard /VSAs), which can be used to = authenticate a  > challenge
> response  > >  > generated = using HMAC_MD5. Basic radius CHAP uses  >
> plain MD5. In light of  > >  = > that new attributes need to be defined
> and  > processing at Radius needs = to  > >  > be specified.  > >  = >  >
> >  > In light  > of these = two issues, I am wondering how HMAC_MD5 can
> be  > >  >  > = realistically used for authenticating MAAE today?  > = >
> >  > >  > Can  > = someone demystify the usage of HMAC_MD5?  > >  = >  >
> >  > Thanks  > >  = >  > Alpesh  >
>
>  >
>  > --
>  > Mip4 mailing list: = Mip4@ietf.org
>  >     Web = interface: https://www1.ietf.org/mailman/listinfo/mip4=
>  >      = Charter page: http://www.ietf.org/html.charters/mip4-charter.html
>  > Supplemental site: http://www.mip4.org/
>
>

------_=_NextPart_001_01C4BB70.1D852161-- --===============1711575519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1711575519==-- From mip4-bounces@ietf.org Wed Oct 27 19:14:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26457 for ; Wed, 27 Oct 2004 19:14:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxDa-0001rW-I5 for mip4-web-archive@ietf.org; Wed, 27 Oct 2004 19:28:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwxF-0003XV-Ob; Wed, 27 Oct 2004 19:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwwF-0003Ip-9Y for mip4@megatron.ietf.org; Wed, 27 Oct 2004 19:10:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26231 for ; Wed, 27 Oct 2004 19:10:39 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxAB-0001mk-CJ for mip4@ietf.org; Wed, 27 Oct 2004 19:25:08 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2004 16:19:19 -0700 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9RNA3k4015136; Wed, 27 Oct 2004 16:10:05 -0700 (PDT) Received: from cisco.com (dhcp-128-107-176-47.cisco.com [128.107.176.47]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id AYF12079; Wed, 27 Oct 2004 16:11:39 -0700 (PDT) Message-ID: <41802AC8.1070108@cisco.com> Date: Wed, 27 Oct 2004 16:10:00 -0700 From: Naveen PaulKandasamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip4] WG Last Call on draft-mip4-faerr-00.txt References: <41776DAE.7040107@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, Charlie P X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit "I support the advancement of this document to the IESG with a request for publication as proposed standard." and i have the following comments abt the draft... - Length field is mentioned as 4. think it should be 2, excluding type/length fields as per rfc 3344 ? - in the case of a MN using collocated CoA without R bit set, can the MN ignore the FA error extn (in case if some malicious node added this extn,) since this extn does not seem to relate to this scenario ? also, since this extension is unprotected, wondering if we should mention abt the FA behavior when a (malicious) node between FA and HA appends this extn to the RRP ? is the FA supposed to drop the RRP considering it a parse error ? am not sure if this is a generic problem for all extns and has been addressed elsewhere ? thanks, naveen. Henrik Levkowetz wrote: > > This message announces a WG last call on: > > "Foreign Agent Error Extension for Mobile IPv4" > - draft-mip4-faerr-00.txt > > The last call will conclude at 24:00 UTC on Friday, 05 November 2004. > > draft-mip4-faerr-00.txt defines a new Mobile IP extension for carrying > an error code from a foreign agent, which informs the mobile node of > foreign-agent specific errors independently of the result code > inserted by the home agent. > > A URL for this Internet-Draft is: > > > > Please respond to this WG last call: > > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like > > "I support the advancement of this document to the IESG with a > request for publication as proposed standard." > > If you have comments, please use a line similar to the one above, and > supplement this with your comments. > > > * If you *don't* support its advancement, respond with a line containing > something like the following, supplemented by your comments - > > "I don't support the advancement of this document to the IESG with > a request for publication as proposed standard, for the following > reasons:" > ... > > > Pete & Henrik > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 29 11:04:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07354 for ; Fri, 29 Oct 2004 11:04:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNYWz-0000vS-EE for mip4-web-archive@ietf.org; Fri, 29 Oct 2004 11:19:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNXwn-0004dq-Kw; Fri, 29 Oct 2004 10:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDtp-0005An-PD; Thu, 28 Oct 2004 13:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23413; Thu, 28 Oct 2004 13:17:19 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNE7v-0005CE-RC; Thu, 28 Oct 2004 13:31:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9SHGbt20090; Thu, 28 Oct 2004 20:16:37 +0300 Date: Thu, 28 Oct 2004 20:16:37 +0300 (EEST) From: Pekka Savola To: "Soliman, Hesham" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Fri, 29 Oct 2004 10:41:44 -0400 Cc: nemo@ietf.org, mip6@ietf.org, mip4@ietf.org, miptrans@ops.ietf.org, v6ops@ops.ietf.org, Tsirtsis George Subject: [Mip4] Re: MIP and transition issues X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi, I've created a new mailing list to discuss Mobile IP transition issues. There is no single good mailing list to do that, and crossposting to upto 4 WGs is not a good idea. Address: miptrans@ops.ietf.org To subscribe: 'subscribe miptrans' in the body to majordomo@psg.com Web archives: http://ops.ietf.org/lists/miptrans/ **** DO NOT POST ANY FURTHER MESSAGES ON V6OPS LIST! **** (if you respond, please remove the other lists from Cc:) FWIW, I also noticed there is another related draft: Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks draft-larsson-v6ops-mip-scenarios-00.txt (Larsson, Gustafsson, Levkowetz) As there have been various presentations on v6ops two times already, with no clear resolution, it would seem to be useful to have various people working on different documents bang their heads together on miptrans or offlist on which document(s) describing the problems and scenarios is the most appropriate as a basis for discussion. On Mon, 25 Oct 2004, Soliman, Hesham wrote: > Sorry for the cross posting, but this issue is being > discussed in all WG listed. > > I submitted the following two drafts last night: > draft-tsirtsis-dsmip-problem > draft-soliman-v4v6-mipv6- > > The first deals with the problem statement and the > second is one of the solution for using MIPv6 only. > There is another draft that proposes using MIPv4 > only: draft-tsirtsis-v4v6-mipv4 > > I hope we can discuss the problem statement and scenarios > in the next meeting. While the problem statement is on the mip6 > charter, it would be useful if we can have a slot allocated for > this in v6ops. > > thx > Hesham > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Oct 29 11:27:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09081 for ; Fri, 29 Oct 2004 11:27:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNYtp-0001RD-HB for mip4-web-archive@ietf.org; Fri, 29 Oct 2004 11:42:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNYNL-0004VX-U0; Fri, 29 Oct 2004 11:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNYDD-0003Mc-FK for mip4@megatron.ietf.org; Fri, 29 Oct 2004 10:58:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06983 for ; Fri, 29 Oct 2004 10:58:41 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNYRU-0000ob-Qr for mip4@ietf.org; Fri, 29 Oct 2004 11:13:30 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9TEw80T009125; Fri, 29 Oct 2004 09:58:09 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i9TEw8Q24723; Fri, 29 Oct 2004 09:58:08 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id I6CPKV-0001TW-00; Fri, 29 Oct 2004 10:58:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16770.23165.724750.338652@gargle.gargle.HOWL> Date: Fri, 29 Oct 2004 09:58:05 -0500 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: henrik@levkowetz.com Subject: [Mip4] Agenda for MIP4 at IETF61 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hello, Below is a proposed agenda for the MIP4 working group meeting at IETF61. Please send any comments or requests for additional slots to the chairs and the mip4@ietf.org mailing list. -Pete & Henrik MIP4 (Mobility for IPv4 WG) Agenda ---------------------------------------- 1300-1500 Afternoon Sessions I THURSDAY, November 11, 2004 CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs (slides: http://mip4.org/ietf61/item-1.ppt) - Minutes - Agenda bashing - WG status web page update ( http://www.mip4.org/ ) 2. Document Status 10 min Chairs draft-ietf-mip4-aaa-nai-03 RFC Published draft-ietf-mip4-aaa-key-06 RFC Ed Queue draft-ietf-mobileip-lowlatency-handoffs-v4-09 AD Evaluation draft-ietf-mip4-vpn-problem-statement-03 IESG Evaluation draft-ietf-mip4-rfc3012bis-02 Almost ready to be sent to IESG draft-ietf-mobileip-reg-tunnel-09 Draft with new boilerplate, then IESG draft-ietf-mip4-dynamic-assignment-03 Publication Requested draft-ietf-mip4-experimental-messages-02 IESG Evaluation draft-ietf-mip4-rfc2006bis-01 Review needed draft-ietf-mobileip-vpn-problem-solution-03 Editing needed draft-ietf-mip4-rfc3344bis-01 ID exists draft-mip4-faerr-00.txt In WG last call 3. 3012bis - summary of recent issues, 5 min Jayshree Bharatia status and next steps. - draft-ietf-mip4-rfc3012bis-02.txt 4. Co-editor for draft: 5 min Chairs - draft-ietf-mobileip-vpn-problem-solution-03.txt 5. Resolving outstanding issues for 3344bis, 15 min Charlie Perkins and next steps 6. Faerr document - last call status 5 min Chairs 7. Take up route optimization for MIPv4? 5 min ?? ------ Total 60 min -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/