From mip4-bounces@ietf.org Thu Dec 01 09:13:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBp-0007CK-Tk; Thu, 01 Dec 2005 09:13:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhpBn-00078v-LP for mip4@megatron.ietf.org; Thu, 01 Dec 2005 09:13:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25001 for ; Thu, 1 Dec 2005 09:12:48 -0500 (EST) Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpWH-0006z8-RK for mip4@ietf.org; Thu, 01 Dec 2005 09:34:46 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp5.clb.oleane.net with ESMTP id jB1EDEA7007612 for ; Thu, 1 Dec 2005 15:13:25 +0100 Message-Id: <200512011413.jB1EDEA7007612@smtp5.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 1 Dec 2005 15:12:52 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX2gVD+Lsssj0tsT46qK5ClTfD15Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Mip4] Wireless/WiFi Convergence Conference - Call for Papers 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="===============1463274433==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1463274433== Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01C5F689.B3081150" This is a multi-part message in MIME format. ------=_NextPart_000_013D_01C5F689.B3081150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Wireless/WiFi Convergence Conference will be held in Paris on May 16 to May 19, 2006 http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006cfp.htm It is still time to submit proposals. Organizers are looking for UMA papers. ------=_NextPart_000_013D_01C5F689.B3081150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Wireless/WiFi Convergence = Conference will be held in Paris on May 16 to May 19, 2006

http://www.upperside.fr/wirelessconvergence2006/wwconvergence200= 6cfp.htm

It is still time to submit proposals. = Organizers are looking for UMA papers.

------=_NextPart_000_013D_01C5F689.B3081150-- --===============1463274433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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/ --===============1463274433==-- From mip4-bounces@ietf.org Thu Dec 01 15:50:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvOK-0000cw-C8; Thu, 01 Dec 2005 15:50:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNW-00009F-UC; Thu, 01 Dec 2005 15:50:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25918; Thu, 1 Dec 2005 15:49:18 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehvi1-00084V-35; Thu, 01 Dec 2005 16:11:18 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNR-0006cE-V5; Thu, 01 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-reg-tunnel-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 --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 Regional Registration Author(s) : E. Gustafsson, et al. Filename : draft-ietf-mip4-reg-tunnel-01.txt Pages : 34 Date : 2005-12-1 Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e. registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-reg-tunnel-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-reg-tunnel-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-reg-tunnel-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: <2005-12-1121333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-reg-tunnel-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-reg-tunnel-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1121333.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 Dec 01 17:46:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxCL-00044b-Ko; Thu, 01 Dec 2005 17:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxCK-000442-HW for mip4@megatron.ietf.org; Thu, 01 Dec 2005 17:46:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27157 for ; Thu, 1 Dec 2005 17:45:53 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhxWs-0001Xn-GD for mip4@ietf.org; Thu, 01 Dec 2005 18:07:55 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB1MkGL15651; Thu, 1 Dec 2005 17:46:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 1 Dec 2005 16:46:15 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX2E25CxbifUvQcTzq/9N9k1ghurwAsvp7Q From: "Jayshree Bharatia" To: "Charles E. Perkins" , "Kent Leung \(kleung\)" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: mccap@lucent.com, mip4@ietf.org, henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 Hi all, I am not sure how to proceed toward supporting co-located CoA mode in RFC3012bis. RFC3012 doesn't have any details on this and it was a working assumption that this draft is not applicable for co-located CoA mode. Later in the process of updating RFC3012bis, there was a discussion that we shouldn't be limiting use of MN-AAA extension for co-located CoA mode. Anyway, we need to come up with some agreement now. The following is the summary of the discussion: - Kent and Madjid think that having clarification that there is no challenge included in the MN-AAA extension for co-located CoA mode is good. Although, there is no need of indicating what type of value is used for replay protection. Although, Vijay likes to see this to be clarified. - Charlie suggest removing support of co-located CoA mode. Hence, I have three options: 1. Remove the paragraph which discusses co-located CoA support (last paragraph of section 3.1) 2. Make changes to indicate that there is no challenge included in the MN-CoA extension for co-located CoA mode. 3. Include changes proposed by Vijay in earlier email. Please send me reply suggesting which option you prefer. Regards, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Charles E. Perkins Sent: Wednesday, November 30, 2005 7:05 PM To: Kent Leung (kleung) Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hello folks, I do not believe the document should support co-located CoA mode. The point is to enable some mechanism for use by the foreign agent. There is no need for a mobile node to use the challenge. No additional replay protection is afforded. I would prefer for the use of the extension to be prohibited whenever the 'D' bit is set. Even when a foreign agent is sending 'R' bit advertisements, there isn't any significant functionality gained. Perhaps it's technically feasible to have the challenge in such situations, but (i) it is wasteful and (ii) I would not like to see it become considered a mandatory part of any mobile node implementation where co-located care-of addresses are used, for whatever reason. Regards, Charlie P. PS. Please excuse if I have overlooked some e-mail about this. Kent Leung (kleung) wrote: >On this particular topic, I don't understand what is missing in the=20 >details to support the CCoA mode? Since the draft covers MN-AAA=20 >authentication with NAS in between, I would like to see both FA (CoA)=20 >and HA (CCoA) modes supported. Where else would we be able to cover=20 >just the CCoA for MN-AAA authentication if not in this draft? > >Kent > > > =20 > >>not at this late stage. its fine as it is. however, I have >>one comment on the support for co-located CoA mode. the draft=20 >>claims it supports it but there really isnt enough detail.=20 >>IMO, it should be clarified that only FA mode is described in=20 >>the draft. >> >> =20 >> > > =20 > --=20 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 Dec 01 18:04:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxTX-0006ZD-6c; Thu, 01 Dec 2005 18:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhxTV-0006TL-Rm for mip4@megatron.ietf.org; Thu, 01 Dec 2005 18:04:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28958 for ; Thu, 1 Dec 2005 18:03:39 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehxo4-0002Dd-1d for mip4@ietf.org; Thu, 01 Dec 2005 18:25:41 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2005 15:04:16 -0800 X-IronPort-AV: i="3.99,203,1131350400"; d="scan'208"; a="372925462:sNHT48086050" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB1N49eU001713; Thu, 1 Dec 2005 15:04:12 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 15:04:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 1 Dec 2005 15:04:04 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX2E25CxbifUvQcTzq/9N9k1ghurwAsvp7QAADXKbA= From: "Kent Leung \(kleung\)" To: "Jayshree Bharatia" , "Charles E. Perkins" , , X-OriginalArrivalTime: 01 Dec 2005 23:04:05.0300 (UTC) FILETIME=[86F62740:01C5F6CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: mccap@lucent.com, mip4@ietf.org, henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 I vote for #2. The reason is that that RFC 3012 is addressing two functions, as stated in previous emails (initiated by Gabe's review and comment to split this draft). 1) FA challenge/authentication and MN-FA replay protection. =20 2) Generalized authentication (e.g. MN-AAA), which is independent if the NAS is FA or HA. I would like to keep this in one draft, which means both functions should be covered fully (i.e. including CCoA mode). I believe that Vijay was OK with this except he wanted to explicitly state that replay protection is using nonce/timestamp. But I don't see a need since this is fundamental function of Mobile IP itself. Kent > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 > Sent: Thursday, December 01, 2005 2:46 PM > To: Charles E. Perkins; Kent Leung (kleung);=20 > Madjid.Nakhjiri@motorola.com; vijayd@iprg.nokia.com > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com; mccap@lucent.com;=20 > henrik@levkowetz.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Hi all, >=20 > I am not sure how to proceed toward supporting co-located CoA=20 > mode in RFC3012bis. RFC3012 doesn't have any details on this=20 > and it was a working assumption that this draft is not=20 > applicable for co-located CoA mode. >=20 > Later in the process of updating RFC3012bis, there was a=20 > discussion that we shouldn't be limiting use of MN-AAA=20 > extension for co-located CoA mode. Anyway, we need to come up=20 > with some agreement now. The following is the summary of the=20 > discussion: > - Kent and Madjid think that having clarification that there=20 > is no challenge included in the MN-AAA extension for=20 > co-located CoA mode is good. Although, there is no need of=20 > indicating what type of value is used for replay protection.=20 > Although, Vijay likes to see this to be clarified. > - Charlie suggest removing support of co-located CoA mode. >=20 > Hence, I have three options: > 1. Remove the paragraph which discusses co-located CoA=20 > support (last paragraph of section 3.1) 2. Make changes to=20 > indicate that there is no challenge included in the MN-CoA=20 > extension for co-located CoA mode. > 3. Include changes proposed by Vijay in earlier email. >=20 > Please send me reply suggesting which option you prefer. >=20 > Regards, > Jayshree >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Charles E. Perkins > Sent: Wednesday, November 30, 2005 7:05 PM > To: Kent Leung (kleung) > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 >=20 > Hello folks, >=20 > I do not believe the document should support co-located CoA=20 > mode. The point is to enable some mechanism for use by the=20 > foreign agent. There is no need for a mobile node to use the=20 > challenge. No additional replay protection is afforded. >=20 > I would prefer for the use of the extension to be prohibited=20 > whenever the 'D' bit is set. >=20 > Even when a foreign agent is sending 'R' bit advertisements,=20 > there isn't any significant functionality gained. >=20 > Perhaps it's technically feasible to have the challenge in=20 > such situations, but (i) it is wasteful and (ii) I would not=20 > like to see it become considered a mandatory part of any=20 > mobile node implementation where co-located care-of addresses=20 > are used, for whatever reason. >=20 > Regards, > Charlie P. >=20 > PS. Please excuse if I have overlooked some e-mail about this. >=20 >=20 > Kent Leung (kleung) wrote: >=20 > >On this particular topic, I don't understand what is missing in the=20 > >details to support the CCoA mode? Since the draft covers MN-AAA=20 > >authentication with NAS in between, I would like to see both=20 > FA (CoA)=20 > >and HA (CCoA) modes supported. Where else would we be able to cover=20 > >just the CCoA for MN-AAA authentication if not in this draft? > > > >Kent > > > > > > =20 > > > >>not at this late stage. its fine as it is. however, I have=20 > one comment=20 > >>on the support for co-located CoA mode. the draft claims it=20 > supports=20 > >>it but there really isnt enough detail. > >>IMO, it should be clarified that only FA mode is described in the=20 > >>draft. > >> > >> =20 > >> > > > > =20 > > >=20 >=20 >=20 > -- > 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/ >=20 -- 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 Dec 01 20:55:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei08n-0004Ne-30; Thu, 01 Dec 2005 20:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei08l-0004NT-J1 for mip4@megatron.ietf.org; Thu, 01 Dec 2005 20:55:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17341 for ; Thu, 1 Dec 2005 20:54:24 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0TL-0000Of-HA for mip4@ietf.org; Thu, 01 Dec 2005 21:16:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB21KO616269; Thu, 1 Dec 2005 17:20:24 -0800 X-mProtect: <200512020120> Nokia Silicon Valley Messaging Protection Received: from es-nira-26-125.europe.nokia.com (10.162.26.125, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdEbAMmg; Thu, 01 Dec 2005 17:20:21 PST Message-ID: <438FA95E.5000906@iprg.nokia.com> Date: Thu, 01 Dec 2005 17:54:38 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Jayshree Bharatia , 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 Hello Kent, What if the draft allows the Generalized Authentication extension for mobile nodes with CCoA, but does not allow the challenge extension? I don't see what's wrong with this, since the draft is "about" a foreign agent protocol. Then, enabling the Generalized Authentication extension for co-located CoA just amounts to reasonable practice, not refocussing the document on colocated CoA. Regards, Charlie P. Kent Leung (kleung) wrote: >I vote for #2. The reason is that that RFC 3012 is addressing two >functions, as stated in previous emails (initiated by Gabe's review and >comment to split this draft). > >1) FA challenge/authentication and MN-FA replay protection. > >2) Generalized authentication (e.g. MN-AAA), which is independent if the >NAS is FA or HA. > >I would like to keep this in one draft, which means both functions >should be covered fully (i.e. including CCoA mode). I believe that >Vijay was OK with this except he wanted to explicitly state that replay >protection is using nonce/timestamp. But I don't see a need since this >is fundamental function of Mobile IP itself. > >Kent > > -- 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 Dec 01 20:55:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei09B-0004i4-J1; Thu, 01 Dec 2005 20:55:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei09A-0004hL-2H for mip4@megatron.ietf.org; Thu, 01 Dec 2005 20:55:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17362 for ; Thu, 1 Dec 2005 20:54:48 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0Tj-0000P7-O2 for mip4@ietf.org; Thu, 01 Dec 2005 21:16:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB1NgID12986; Thu, 1 Dec 2005 15:42:18 -0800 X-mProtect: <200512012342> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdOpcg6F; Thu, 01 Dec 2005 15:11:13 PST Message-ID: <438F8A43.4030002@iprg.nokia.com> Date: Thu, 01 Dec 2005 15:41:55 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Madjid.Nakhjiri@motorola.com, mccap@lucent.com, Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" , henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 Kent Leung (kleung) wrote: > I vote for #2. The reason is that that RFC 3012 is addressing two > functions, as stated in previous emails (initiated by Gabe's review and > comment to split this draft). > > 1) FA challenge/authentication and MN-FA replay protection. > > 2) Generalized authentication (e.g. MN-AAA), which is independent if the > NAS is FA or HA. > > I would like to keep this in one draft, which means both functions > should be covered fully (i.e. including CCoA mode). okay until this far. > I believe that > Vijay was OK with this except he wanted to explicitly state that replay > protection is using nonce/timestamp. But I don't see a need since this > is fundamental function of Mobile IP itself. it is needed because 3012 leaves things incomplete without this. if you notice in my changes I did reference RFC 3344 when I spoke about replay protection in the co-located CoA mode. I didnt propose a new mechanism. Vijay -- 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 Dec 01 20:57:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0Ap-0006A8-Q5; Thu, 01 Dec 2005 20:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0Ao-0006A3-IS for mip4@megatron.ietf.org; Thu, 01 Dec 2005 20:57:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17509 for ; Thu, 1 Dec 2005 20:56:30 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0VO-0000TD-5I for mip4@ietf.org; Thu, 01 Dec 2005 21:18:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB1NdLg11583; Thu, 1 Dec 2005 15:39:21 -0800 X-mProtect: <200512012339> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdsCDcVT; Thu, 01 Dec 2005 15:08:47 PST Message-ID: <438F89AF.4030609@iprg.nokia.com> Date: Thu, 01 Dec 2005 15:39:27 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Madjid.Nakhjiri@motorola.com, mccap@lucent.com, mip4@ietf.org, "Charles E. Perkins" , "Kent Leung \(kleung\)" , henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 Jayshree Bharatia wrote: > Hi all, > > I am not sure how to proceed toward supporting co-located CoA mode in > RFC3012bis. RFC3012 doesn't have any details on this and it was a > working assumption that this draft is not applicable for co-located CoA > mode. > > Later in the process of updating RFC3012bis, there was a discussion that > we shouldn't be limiting use of MN-AAA extension for co-located CoA > mode. Anyway, we need to come up with some agreement now. The following > is the summary of the discussion: > - Kent and Madjid think that having clarification that there is no > challenge included in the MN-AAA extension for co-located CoA mode is > good. Although, there is no need of indicating what type of value is > used for replay protection. Although, Vijay likes to see this to be > clarified. > - Charlie suggest removing support of co-located CoA mode. > > Hence, I have three options: > 1. Remove the paragraph which discusses co-located CoA support (last > paragraph of section 3.1) > 2. Make changes to indicate that there is no challenge included in the > MN-CoA extension for co-located CoA mode. > 3. Include changes proposed by Vijay in earlier email. the changes I proposed include 2. the changes I suggested do the following - clarify that the MN MUST NOT include the challenge extension - clarify that in the absence of the FA, there is no challenge generated by the network. - clarify that in the absence of a challenge, replay protection is provided by the identification field. Vijay -- 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 Dec 01 21:13:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0QL-0002oT-Rg; Thu, 01 Dec 2005 21:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0QK-0002oL-NC for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:13:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18790 for ; Thu, 1 Dec 2005 21:12:32 -0500 (EST) 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.43) id 1Ei0ku-0000v3-83 for mip4@ietf.org; Thu, 01 Dec 2005 21:34:37 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 18:13:09 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB22CWe0019693; Thu, 1 Dec 2005 18:13:04 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 18:13:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 1 Dec 2005 18:13:01 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014B20@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX2423Zt3knx2nZTTGVko45elB9PgAAZJVQ From: "Kent Leung \(kleung\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 02 Dec 2005 02:13:02.0812 (UTC) FILETIME=[ECA531C0:01C5F6E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: Jayshree Bharatia , 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 Hi Charlie. Comments below. >=20 > What if the draft allows the Generalized Authentication=20 > extension for mobile nodes with CCoA, but does not allow the=20 > challenge extension? I don't see what's wrong with this,=20 > since the draft is "about" a foreign agent protocol. >=20 But that means the Generalized Authentication is split into 2 separate drafts (this one for FA CoA mode and a new draft for CCoA mode). BTW, I think this was proposed in the thread but not warmly received. > Then, enabling the Generalized Authentication extension for=20 > co-located CoA just amounts to reasonable practice, not=20 > refocussing the document on colocated CoA. >=20 I don't think adding a couple of sentences to specify that MFCE is not needed in CCoA mode is refocussing this draft. Kent -- 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 Dec 01 21:18:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0V2-0004X5-BE; Thu, 01 Dec 2005 21:18:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0V1-0004X0-99 for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:18:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20025 for ; Thu, 1 Dec 2005 21:17:23 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei0pc-0001Lz-0f for mip4@ietf.org; Thu, 01 Dec 2005 21:39:28 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB21hOU30300; Thu, 1 Dec 2005 17:43:24 -0800 X-mProtect: <200512020143> Nokia Silicon Valley Messaging Protection Received: from es-nira-26-125.europe.nokia.com (10.162.26.125, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdac1Ala; Thu, 01 Dec 2005 17:43:23 PST Message-ID: <438FAEC3.4040306@iprg.nokia.com> Date: Thu, 01 Dec 2005 18:17:39 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC5201014B20@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014B20@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Jayshree Bharatia , 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 Kent Leung (kleung) wrote: >>What if the draft allows the Generalized Authentication >>extension for mobile nodes with CCoA, but does not allow the >>challenge extension? I don't see what's wrong with this, >>since the draft is "about" a foreign agent protocol. >> >> >> > >But that means the Generalized Authentication is split into 2 separate >drafts (this one for FA CoA mode and a new draft for CCoA mode). BTW, I >think this was proposed in the thread but not warmly received. > > No, I think it's fine if the same draft mentions that the extension is legitimate for use by mobile nodes with co-located CoA. >I don't think adding a couple of sentences to specify that MFCE is not >needed in CCoA mode is refocussing this draft. > > This is fine with me. I guess you inferred that I am against mentioning co-located CoA in this draft. I am not against that, and I did not mean to imply that. I am only against specifying a way to use the challenge extension with co-located CoA. 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 Dec 01 21:29:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0gL-0001KL-DG; Thu, 01 Dec 2005 21:29:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0gJ-0001Ih-1h for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:29:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23500 for ; Thu, 1 Dec 2005 21:29:03 -0500 (EST) 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.43) id 1Ei10s-0002bn-8m for mip4@ietf.org; Thu, 01 Dec 2005 21:51:08 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 01 Dec 2005 18:29:38 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB22SnwF011651; Thu, 1 Dec 2005 18:29:29 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 18:28:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 1 Dec 2005 18:28:45 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2A@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX2474EawJ9IaZRSZaNRHzQ4GLcowAAlIwg From: "Kent Leung \(kleung\)" To: "Vijay Devarapalli" , "Jayshree Bharatia" X-OriginalArrivalTime: 02 Dec 2005 02:28:46.0955 (UTC) FILETIME=[1F65FBB0:01C5F6E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: Madjid.Nakhjiri@motorola.com, mccap@lucent.com, mip4@ietf.org, "Charles E. Perkins" , henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 Hi Vijay. =20 > the changes I proposed include 2. the changes I suggested do=20 > the following >=20 > - clarify that the MN MUST NOT include the challenge extension > - clarify that in the absence of the FA, there is no=20 > challenge generated by the network. Also, MN sets the challenge value to zero in the MN-AAA authenticator computation. =20 > - clarify that in the absence of a challenge, replay=20 > protection is provided by the identification field. >=20 I don't think this is necessary, but doesn't matter too much to me either. Kent -- 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 Dec 01 21:30:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0h5-0001kH-4F; Thu, 01 Dec 2005 21:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei0h4-0001kC-1d for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:30:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23738 for ; Thu, 1 Dec 2005 21:29:50 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei11d-0002h3-2c for mip4@ietf.org; Thu, 01 Dec 2005 21:51:55 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2005 18:30:26 -0800 X-IronPort-AV: i="3.99,203,1131350400"; d="scan'208"; a="236357549:sNHT27951236" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jB22TTcZ011404; Thu, 1 Dec 2005 18:30:24 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 18:30:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 1 Dec 2005 18:30:00 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2B@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX25qy8aHzGeaU3SUKaOwOk7hLK7AAAXtMg From: "Kent Leung \(kleung\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 02 Dec 2005 02:30:01.0271 (UTC) FILETIME=[4BB1B470:01C5F6E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Jayshree Bharatia , 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 Oh, OK then. :) We're in agreement that MFCE is not needed in CCoA mode. Kent > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]=20 > Sent: Thursday, December 01, 2005 6:18 PM > To: Kent Leung (kleung) > Cc: Jayshree Bharatia; mip4@ietf.org > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Kent Leung (kleung) wrote: >=20 > >>What if the draft allows the Generalized Authentication=20 > extension for=20 > >>mobile nodes with CCoA, but does not allow the challenge=20 > extension? I=20 > >>don't see what's wrong with this, since the draft is=20 > "about" a foreign=20 > >>agent protocol. > >> > >> =20 > >> > > > >But that means the Generalized Authentication is split into=20 > 2 separate=20 > >drafts (this one for FA CoA mode and a new draft for CCoA=20 > mode). BTW,=20 > >I think this was proposed in the thread but not warmly received. > > =20 > > > No, I think it's fine if the same draft mentions that the=20 > extension is legitimate for use by mobile nodes with co-located CoA. >=20 > >I don't think adding a couple of sentences to specify that=20 > MFCE is not=20 > >needed in CCoA mode is refocussing this draft. > > =20 > > > This is fine with me. I guess you inferred that I am against=20 > mentioning co-located CoA in this draft. I am not against=20 > that, and I did not mean > to imply that. I am only against specifying a way to use=20 > the challenge > extension with co-located CoA. >=20 > Regards, > Charlie P. >=20 -- 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 Dec 01 21:58:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei17z-0001Uq-6F; Thu, 01 Dec 2005 21:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei17w-0001Qv-P9 for mip4@megatron.ietf.org; Thu, 01 Dec 2005 21:58:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28461 for ; Thu, 1 Dec 2005 21:57:36 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei1SW-0004NO-Nu for mip4@ietf.org; Thu, 01 Dec 2005 22:19:42 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB22NaM21711; Thu, 1 Dec 2005 18:23:36 -0800 X-mProtect: <200512020223> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdYoEaOh; Thu, 01 Dec 2005 18:23:34 PST Message-ID: <438FB834.5030102@iprg.nokia.com> Date: Thu, 01 Dec 2005 18:57:56 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2A@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014B2A@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" 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 Kent Leung (kleung) wrote: > Hi Vijay. > > >>the changes I proposed include 2. the changes I suggested do >>the following >> >>- clarify that the MN MUST NOT include the challenge extension >>- clarify that in the absence of the FA, there is no >>challenge generated by the network. > > > Also, MN sets the challenge value to zero in the MN-AAA authenticator > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay >>protection is provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 02 01:18:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4FM-0006wu-Rv; Fri, 02 Dec 2005 01:18:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4FL-0006wp-7W for mip4@megatron.ietf.org; Fri, 02 Dec 2005 01:18:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11899 for ; Fri, 2 Dec 2005 01:17:28 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei4Zx-0001E1-Il for mip4@ietf.org; Fri, 02 Dec 2005 01:39:34 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2005 22:18:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB26Hv77020799; Thu, 1 Dec 2005 22:18:02 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 22:18:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 1 Dec 2005 22:17:59 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201014BBB@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27EIopXqetqffRXqfU5TQdgBLXwAElxIg From: "Kent Leung \(kleung\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 02 Dec 2005 06:18:01.0148 (UTC) FILETIME=[258947C0:01C5F708] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" 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 The MN and RADIUS client (HA) needs to follow the rules for CHAP authentication. Section 3.1: If the SPI value is chosen as CHAP_SPI (see Section 9), then the mobile node specifies CHAP-style authentication [RFC1994] using MD5 [RFC1321]. Section 8: 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=20 When there is no MFCE, then HA needs to set the "Challenge" to 0 with length of 1 (minimally) to populate the RADIUS CHAP-Password attribute properly. The CHAP ID is expected to be one byte for authenticator computation. So there is no need for MFCE because MN-FA replay protect is unnecessary in CCoA mode, but the challenge value (i.e. zero) is still required to properly perform CHAP authentication. Did I miss your pt? Kent > >=20 > > Also, MN sets the challenge value to zero in the MN-AAA=20 > authenticator=20 > > computation. >=20 > hmm.. how about the MN does not use any challenge value=20 > (whether 0 or anything else)? it calculates the MN-AAA=20 > authenticator without any challenge field. one the basic=20 > clarifications that is needed is that there is no challenge=20 > to use when there is no FA. >=20 -- 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 Dec 02 11:02:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDMM-00076L-Hp; Fri, 02 Dec 2005 11:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiDMK-00075Y-LK for mip4@megatron.ietf.org; Fri, 02 Dec 2005 11:02:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10531 for ; Fri, 2 Dec 2005 11:01:15 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiDh2-0004EY-Jz for mip4@ietf.org; Fri, 02 Dec 2005 11:23:28 -0500 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 jB2G1nD4006503; Fri, 2 Dec 2005 10:01:49 -0600 (CST) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jB2G1mx21247; Fri, 2 Dec 2005 10:01:48 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17296.28651.260505.760532@gargle.gargle.HOWL> Date: Fri, 2 Dec 2005 10:01:47 -0600 From: Pete McCann To: "Kent Leung \(kleung\)" Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> References: <2979E38DD6FC6544B789C8DAD7BAFC5201014A5D@xmb-sjc-235.amer.cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: Madjid.Nakhjiri@motorola.com, Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" , vijayd@iprg.nokia.com, henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 Chair hat off, I think there is clearly value in using MN-AAA authenticator even in co-located mode, especially if one is trying to bootstrap an HA for which no security association exists yet. I support Kent's and Vijay's suggested changes. -Pete Kent Leung \(kleung\) writes: > I vote for #2. The reason is that that RFC 3012 is addressing two > functions, as stated in previous emails (initiated by Gabe's review and > comment to split this draft). > > 1) FA challenge/authentication and MN-FA replay protection. > > 2) Generalized authentication (e.g. MN-AAA), which is independent if the > NAS is FA or HA. > > I would like to keep this in one draft, which means both functions > should be covered fully (i.e. including CCoA mode). I believe that > Vijay was OK with this except he wanted to explicitly state that replay > protection is using nonce/timestamp. But I don't see a need since this > is fundamental function of Mobile IP itself. > > Kent > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortel.com] > > Sent: Thursday, December 01, 2005 2:46 PM > > To: Charles E. Perkins; Kent Leung (kleung); > > Madjid.Nakhjiri@motorola.com; vijayd@iprg.nokia.com > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com; mccap@lucent.com; > > henrik@levkowetz.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > Hi all, > > > > I am not sure how to proceed toward supporting co-located CoA > > mode in RFC3012bis. RFC3012 doesn't have any details on this > > and it was a working assumption that this draft is not > > applicable for co-located CoA mode. > > > > Later in the process of updating RFC3012bis, there was a > > discussion that we shouldn't be limiting use of MN-AAA > > extension for co-located CoA mode. Anyway, we need to come up > > with some agreement now. The following is the summary of the > > discussion: > > - Kent and Madjid think that having clarification that there > > is no challenge included in the MN-AAA extension for > > co-located CoA mode is good. Although, there is no need of > > indicating what type of value is used for replay protection. > > Although, Vijay likes to see this to be clarified. > > - Charlie suggest removing support of co-located CoA mode. > > > > Hence, I have three options: > > 1. Remove the paragraph which discusses co-located CoA > > support (last paragraph of section 3.1) 2. Make changes to > > indicate that there is no challenge included in the MN-CoA > > extension for co-located CoA mode. > > 3. Include changes proposed by Vijay in earlier email. > > > > Please send me reply suggesting which option you prefer. > > > > Regards, > > Jayshree > > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > Behalf Of Charles E. Perkins > > Sent: Wednesday, November 30, 2005 7:05 PM > > To: Kent Leung (kleung) > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > > > Hello folks, > > > > I do not believe the document should support co-located CoA > > mode. The point is to enable some mechanism for use by the > > foreign agent. There is no need for a mobile node to use the > > challenge. No additional replay protection is afforded. > > > > I would prefer for the use of the extension to be prohibited > > whenever the 'D' bit is set. > > > > Even when a foreign agent is sending 'R' bit advertisements, > > there isn't any significant functionality gained. > > > > Perhaps it's technically feasible to have the challenge in > > such situations, but (i) it is wasteful and (ii) I would not > > like to see it become considered a mandatory part of any > > mobile node implementation where co-located care-of addresses > > are used, for whatever reason. > > > > Regards, > > Charlie P. > > > > PS. Please excuse if I have overlooked some e-mail about this. > > > > > > Kent Leung (kleung) wrote: > > > > >On this particular topic, I don't understand what is missing in the > > >details to support the CCoA mode? Since the draft covers MN-AAA > > >authentication with NAS in between, I would like to see both > > FA (CoA) > > >and HA (CCoA) modes supported. Where else would we be able to cover > > >just the CCoA for MN-AAA authentication if not in this draft? > > > > > >Kent > > > > > > > > > > > > > > >>not at this late stage. its fine as it is. however, I have > > one comment > > >>on the support for co-located CoA mode. the draft claims it > > supports > > >>it but there really isnt enough detail. > > >>IMO, it should be clarified that only FA mode is described in the > > >>draft. > > >> > > >> > > >> > > > > > > > > > > > > > > > > > -- > > 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 Dec 02 12:18:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiET6-0006WA-P8; Fri, 02 Dec 2005 12:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiET4-0006UH-NP for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:13:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18788 for ; Fri, 2 Dec 2005 12:12:19 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEnl-0006ml-SZ for mip4@ietf.org; Fri, 02 Dec 2005 12:34:30 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB2HPl3J022285 for ; Fri, 2 Dec 2005 10:25:47 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB2HOQRK004961 for ; Fri, 2 Dec 2005 11:24:26 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 2 Dec 2005 12:12:33 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX3Wd17JcalLaBUSSS/qozi3JhIVAACXqxQ From: "Nakhjiri Madjid-MNAKHJI1" To: "Pete McCann" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" , vijayd@iprg.nokia.com, henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 Yes, I agree. Otherwise not sure how we can do 3957 and 4004? Given that the fix we proposed (replace the challenge value with 0 in the authenticator calculation for direct RRQ), I think this RFC will get a much bigger applicability with a small change. Madjid=20 -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com]=20 Sent: Friday, December 02, 2005 10:02 AM To: Kent Leung (kleung) Cc: Jayshree Bharatia; Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1; vijayd@iprg.nokia.com; mip4@ietf.org; itijibox-mip4@yahoo.com; henrik@levkowetz.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Chair hat off, I think there is clearly value in using MN-AAA authenticator even in co-located mode, especially if one is trying to bootstrap an HA for which no security association exists yet. I support Kent's and Vijay's suggested changes. -Pete Kent Leung \(kleung\) writes: > I vote for #2. The reason is that that RFC 3012 is addressing two > functions, as stated in previous emails (initiated by Gabe's review and > comment to split this draft). > > 1) FA challenge/authentication and MN-FA replay protection. =20 > > 2) Generalized authentication (e.g. MN-AAA), which is independent if the > NAS is FA or HA. > > I would like to keep this in one draft, which means both functions > should be covered fully (i.e. including CCoA mode). I believe that > Vijay was OK with this except he wanted to explicitly state that replay > protection is using nonce/timestamp. But I don't see a need since this > is fundamental function of Mobile IP itself. > > Kent > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortel.com] > > Sent: Thursday, December 01, 2005 2:46 PM > > To: Charles E. Perkins; Kent Leung (kleung); > > Madjid.Nakhjiri@motorola.com; vijayd@iprg.nokia.com > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com; mccap@lucent.com; > > henrik@levkowetz.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > Hi all, > > > > I am not sure how to proceed toward supporting co-located CoA > > mode in RFC3012bis. RFC3012 doesn't have any details on this > > and it was a working assumption that this draft is not > > applicable for co-located CoA mode. > > > > Later in the process of updating RFC3012bis, there was a > > discussion that we shouldn't be limiting use of MN-AAA > > extension for co-located CoA mode. Anyway, we need to come up > > with some agreement now. The following is the summary of the > > discussion: > > - Kent and Madjid think that having clarification that there > > is no challenge included in the MN-AAA extension for > > co-located CoA mode is good. Although, there is no need of > > indicating what type of value is used for replay protection.=20 > > Although, Vijay likes to see this to be clarified. > > - Charlie suggest removing support of co-located CoA mode. > > > > Hence, I have three options: > > 1. Remove the paragraph which discusses co-located CoA > > support (last paragraph of section 3.1) 2. Make changes to > > indicate that there is no challenge included in the MN-CoA > > extension for co-located CoA mode. > > 3. Include changes proposed by Vijay in earlier email. > > > > Please send me reply suggesting which option you prefer. > > > > Regards, > > Jayshree > > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > Behalf Of Charles E. Perkins > > Sent: Wednesday, November 30, 2005 7:05 PM > > To: Kent Leung (kleung) > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > > > Hello folks, > > > > I do not believe the document should support co-located CoA > > mode. The point is to enable some mechanism for use by the > > foreign agent. There is no need for a mobile node to use the > > challenge. No additional replay protection is afforded. > > > > I would prefer for the use of the extension to be prohibited > > whenever the 'D' bit is set. > > > > Even when a foreign agent is sending 'R' bit advertisements, > > there isn't any significant functionality gained. > > > > Perhaps it's technically feasible to have the challenge in > > such situations, but (i) it is wasteful and (ii) I would not > > like to see it become considered a mandatory part of any > > mobile node implementation where co-located care-of addresses > > are used, for whatever reason. > > > > Regards, > > Charlie P. > > > > PS. Please excuse if I have overlooked some e-mail about this. > > > > > > Kent Leung (kleung) wrote: > > > > >On this particular topic, I don't understand what is missing in the > > >details to support the CCoA mode? Since the draft covers MN-AAA > > >authentication with NAS in between, I would like to see both > > FA (CoA) > > >and HA (CCoA) modes supported. Where else would we be able to cover > > >just the CCoA for MN-AAA authentication if not in this draft? > > > > > >Kent > > > > > > > > > > > > > > >>not at this late stage. its fine as it is. however, I have > > one comment > > >>on the support for co-located CoA mode. the draft claims it > > supports > > >>it but there really isnt enough detail. > > >>IMO, it should be clarified that only FA mode is described in the > > >>draft. > > >> > > >> =20 > > >> > > > > > > > > > > > > > > > > > -- > > 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/ > >=20 -- 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 Dec 02 12:20:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEae-000192-7b; Fri, 02 Dec 2005 12:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEac-00018T-KI for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:20:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20481 for ; Fri, 2 Dec 2005 12:20:07 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEvJ-0007PI-1e for mip4@ietf.org; Fri, 02 Dec 2005 12:42:19 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB2HXjkH023638 for ; Fri, 2 Dec 2005 10:33:45 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jB2HUgI9017855 for ; Fri, 2 Dec 2005 11:30:42 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 2 Dec 2005 12:20:31 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX2471MnExlPyePROW74Ap5pNY4EAAgI/cQ From: "Nakhjiri Madjid-MNAKHJI1" To: "Vijay Devarapalli" , "Jayshree Bharatia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: mccap@lucent.com, mip4@ietf.org, "Charles E. Perkins" , "Kent Leung \(kleung\)" , henrik@levkowetz.com, itijibox-mip4@yahoo.com 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 I think the first 2 changes are pretty harmless. Even the third probably, as long as we clarify that the challenge is only provided to protect the foreign network, so in direct RRQ, you do not need the challenge, not that ID field and challenge are two alternative replay protections. ID protects HA, challenge protects FA.. Also the other change needed is the clarification of use of MN-AAA AE in case of direct RRQ (challenge is absent). Madjid the changes I proposed include 2. the changes I suggested do the following - clarify that the MN MUST NOT include the challenge extension - clarify that in the absence of the FA, there is no challenge generated by the network. - clarify that in the absence of a challenge, replay protection is provided by the identification field. Vijay -- 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 Dec 02 12:24:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEe3-0003gO-Py; Fri, 02 Dec 2005 12:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEe1-0003bh-En for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:24:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21203 for ; Fri, 2 Dec 2005 12:23:37 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiEyi-0007Zd-9D for mip4@ietf.org; Fri, 02 Dec 2005 12:45:49 -0500 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jB2Hn5tB001822 for ; Fri, 2 Dec 2005 10:49:06 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id jB2HckQa019164 for ; Fri, 2 Dec 2005 11:38:47 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 2 Dec 2005 12:24:00 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX25PfkkxdQ4p9iRn6yF1P8v7I46wAf+mSg From: "Nakhjiri Madjid-MNAKHJI1" To: "Charles E. Perkins" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: Jayshree Bharatia , 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 The point really is that a generalized extension is defined only for one case, leaving treatment of CCOA underspecified. And yes, whether the challenge extension is not allowed, or it includes 0s (pretty useless) or whatever else needs to be specified somewhere. Madjid -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Charles E. Perkins Sent: Thursday, December 01, 2005 7:55 PM To: Kent Leung (kleung) Cc: Jayshree Bharatia; mip4@ietf.org Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hello Kent, What if the draft allows the Generalized Authentication extension for mobile nodes with CCoA, but does not allow the challenge extension? I don't see what's wrong with this, since the draft is "about" a foreign agent protocol. Then, enabling the Generalized Authentication extension for co-located CoA just amounts to reasonable practice, not refocussing the document on colocated CoA. Regards, Charlie P. Kent Leung (kleung) wrote: >I vote for #2. The reason is that that RFC 3012 is addressing two=20 >functions, as stated in previous emails (initiated by Gabe's review and >comment to split this draft). > >1) FA challenge/authentication and MN-FA replay protection. =20 > >2) Generalized authentication (e.g. MN-AAA), which is independent if=20 >the NAS is FA or HA. > >I would like to keep this in one draft, which means both functions=20 >should be covered fully (i.e. including CCoA mode). I believe that=20 >Vijay was OK with this except he wanted to explicitly state that replay >protection is using nonce/timestamp. But I don't see a need since this >is fundamental function of Mobile IP itself. > >Kent > =20 > -- 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 Dec 02 12:31:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEkb-0003gF-3M; Fri, 02 Dec 2005 12:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiEkY-0003bV-Th for mip4@megatron.ietf.org; Fri, 02 Dec 2005 12:31:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22078 for ; Fri, 2 Dec 2005 12:30:23 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiF5C-0007p5-AS for mip4@ietf.org; Fri, 02 Dec 2005 12:52:35 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jB2Hm8lh020603 for ; Fri, 2 Dec 2005 10:48:08 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jB2HdfS9014223 for ; Fri, 2 Dec 2005 11:39:41 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 2 Dec 2005 12:30:40 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8g From: "Nakhjiri Madjid-MNAKHJI1" To: "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" 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 Vijay, However we want to do it, needs to be specified. Motorola development folks share Nokia's confusion:) I think only a handful of people in the industry know exactly how 3344, 3012, 3957, 4004 all work together and that is why the key bootstrapping is not getting any traction in the implementations. We have endless internal "educative" sessions on this too :) I believe 4004 for Diameter missed the problem with MN-AAA AE for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't think that is the right place for it. We suggested zero based on Charlie's initial suggestion to make implementation of CoA and CCoA less complex, you have the same field, you just enter zero when no value is available. Madjid > Also, MN sets the challenge value to zero in the MN-AAA authenticator=20 > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay protection is=20 >>provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me=20 > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 05 13:58:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLXw-00081r-KE; Mon, 05 Dec 2005 13:58:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLXu-00081l-Jv for mip4@megatron.ietf.org; Mon, 05 Dec 2005 13:58:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27073 for ; Mon, 5 Dec 2005 13:57:51 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjLtE-0004u6-UA for mip4@ietf.org; Mon, 05 Dec 2005 14:20:45 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jB5It6w19027 for ; Mon, 5 Dec 2005 13:55:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 12:58:19 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcW+f6H/b15Nd7TURcGqSZis+o4t5Q7QAmeA From: "Jayshree Bharatia" To: X-Spam-Score: 2.0 (++) X-Scan-Signature: edafdfdf1a7c40feead31b1909b66c9e Content-Transfer-Encoding: quoted-printable 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 Hi Gabriel, My apology for not responding you earlier. I thought I took care of your comments. Anyway, I have updated document with many of your comments. Although, I have some clarification questions for few which are included inline. Thanks, Jayshree=20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of gabriel montenegro Sent: Wednesday, September 21, 2005 2:36 AM To: mip4@ietf.org Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt I reviewed this document. I feel it is not quite RFC quality, being a bit confusing and verbose/repetitive in sections. A big issue=20 I have is that it is really two different things bunched together: =09 - Challenge/Response extention - Generalized Authentication Extension They really should be two documents, specially cuz this is a revision, the proper=20 opportunity to make such changes. [JB] Based on earlier email from Henrik, I would think that WG decision is not to split this draft at this time. So I haven't addressed this comment. I'm also wondering about the use of MD5 throughout. Given recent developments, some folks (not unanimously, though) are already calling for the deprecation of SHA-1, and here we are recommending MD5 for a proposed standard? If this is what's being used today, then this could be published as a historical or informational RFC,=20 If the intent is to fix a few bugs in rfc 3012, perhaps the errata page is enough. But the use of MD5 should be reviewed by the security ADs. CHAP should also be avoided, due to its vulnerability to dictionary attacks. For example, EAP advices against its usage (see rfc3748 section 7.6). Even more explicitly, the EAP requirements for wireless usage call for mandatory resistance to dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html, section 2.2. This comment applies to 3344bis as well. [JB] I am fine with having a review with security Ads on this topic.=20 Nit: saw "processing for" in several places. Shouldn't it be "processing of"?=20 [JB] Done Other comments interspersed below. >=20 >=20 >=20 > Network Working Group Charles E. Perkins > Internet-Draft Nokia Research Center > Expires: December 19, 2005 Pat R. Calhoun > Black Storm Networks > Jayshree. Bharatia > Nortel Networks > June 17, > 2005 Please update the author contact information now, instead of waiting for AUTH48. ... > Abstract >=20 ... > Furthermore, this document updates RFC3344 by including new > authentication extension called the Mobile-AAA Authentication > extension. This new extension is provided so that a mobile node can > supply credentials for authorization using commonly available AAA > infrastructure elements. This Authorization-enabling extension MAY > co-exist in the same Registration Request with Authentication > extensions defined for Mobile IP Registration by RFC3344. This > document obsoletes RFC3012. This should be a separate document. =20 [JB] Should be covered by my earlier comment on WG decision of not splitting the document.=20 ... > 1. Introduction >=20 > Mobile IP defines the Mobile-Foreign Authentication extension to > allow a mobile node to authenticate itself to a foreign agent. > Such It can provide *mutual* authentication, right? Suggest making it explicit here precisely because this extension differs in that it is unilateral. It does not aid the MN in establishing legitimacy of the FA; only the opposite is true.=20 [JB] MN-FA Authentication extension is defined by RFC3344 so I am not sure adding clarification on that extension is necessary here. I would think that purpose of having MN-AAA is clearly defined. If you have any specific text change, please let me know and I will update the document. > authentication mechanisms are mostly external to the principal > operation of Mobile IP, since the foreign agent can easily route > packets to and from a mobile node whether or not the mobile node is > reporting a legitimately owned home address to the foreign agent. > Unfortunately, that extension does not provide the foreign agent any > direct guarantee that the protocol is protected from replays, and > does not allow for the use of CHAP [RFC1994] for authenticating See above comments on CHAP. Shouldn't be a motivation for a new PS document.=20 [JB] As indicated in my earlier comment, I am ok with further review by security ADs. ... > 2. Mobile IP Agent Advertisement Challenge Extension The organization of this section (describing a format), followed by the next section on operation, followed by other sections (4 and 5) on packet formats is very confusing. Suggest having all the packet formats bunched together, following each other.=20 Also suggest preceding them by some section on overview of operation (perhaps section 3 itself. ... [JB] I would rather not do restructuring at this stage, unless others are having same issue and see value in doing so. >=20 > The Challenge extension, illustrated in Figure 1, is inserted in the > Agent Advertisements by the foreign agent, in order to communicate a > previously unused challenge value that can be used by the mobile node > to compute an authentication for its next registration request > message. The challenge is selected by the foreign agent to provide > local assurance that the mobile node is not replaying any earlier > registration request. Eastlake, et al. [RFC1750] provides more > information on generating pseudo-random numbers suitable for use as > values for the challenge. Perhaps clarify that the transport of these is unicast. [JB]Can you clarify your comment further? As mentioned in the draft, Agent Advertisement can be multicast or unicast.=20 > 2.1 Handling of Solicited Agent Advertisements ... > advertised Challenges. It must instead re-use the most recent of the > CHALLENGE_WINDOW Advertisement Challenge values. This is the first time this is mentioned, and it is not explained. It is mentioned several times afterwards, but is never really explained until the appendices. Explanation or at least a reference to the proper section should accompany the first reference.=20 [JB] Done (provided reference of section 9) > 3. Operation >=20 > This section describes modifications to the Mobile IP registration > process [RFC3344] which may occur after the foreign agent issues a > Mobile IP Agent Advertisement containing the Challenge on its local Given that Agent Advertisements can be multicast, I'd clarify here that these are unicast. ... [JB] This is true that Agent Advertisements can be multicast or unicast. In section 2, we have explicit description on handling challenges in case of multicast and unicast. So I am not sure why we need to mention here that Agent Advertisement is going to be unicast only. > 3.2 Foreign Agent Processing for Registration Requests Perhaps s/for/of/ =20 E.g., 3344 uses "processing of" but never "processing for" [JB] Done >=20 > Upon receipt of the Registration Request, if the foreign agent has > issued a Challenge as part of its Agent Advertisements, and it does s/and it/and if it/ [JB] Done ... > unless the Registration Reply has already been > received from the home agent. In this case the foreign agent MUST > preserve the value of the Code field set by the home agent and MUST > put its own rejection code only in the Status field of the FA Error > extension (defined in [FAERR]). The above does not belong here, but in the next section (3.3) on handling Registration Replies. [JB] Done s/code only in/code in/ [JB] Done ... > with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication > Extension is present in the Registration Request, the foreign agent > MUST NOT remove the Mobile-AAA Authentication Extension and the > Mobile-Foreign Challenge Extension from the Registration Request. s/Request./Request, before forwarding to the Home Agent./ [JB] Done > Appendix C provides an example of an action that could be taken by a > foreign agent. >=20 > In the event that the Challenge extension is authenticated through > the Mobile-Foreign Authentication extension and the Mobile-AAA > Authentication extension is not present, the foreign agent MAY remove > the Challenge Extension from the Registration Request without > disturbing the authentication value computed by the mobile node for > use by the AAA or the home agent. Sometimes "Challenge extension" and sometimes "Challenge Extension" Please double-check throughout to make sure capitalization is consistent.=20 [JB] Done (changed to "Challenge extension"] "use by the AAA" is confusing as it was just said that this case has no=20 AAA, so perhaps clarifying text could be added: s/home agent./home agent, the former because it is not present, the latter because its calculation does not include the Challenge Extension. Or one could reword, of course... [JB] I have reworded the above paragraph as: "In the event that the Challenge extension is authenticated through the Mobile-Foreign Authentication extension and the Mobile-AAA Authentication extension is not present, the foreign agent MAY remove the Challenge extension from the Registration Request without disturbing the authentication value used for the computation." ... > If the foreign agent does not remove the Challenge extension, then > the foreign agent SHOULD store the Challenge value as part of the notice the should here. But what if it's not stored? See below. > pending registration request list [RFC3344]. Also, if the > Registration Reply coming from the home agent does not include the > Challenge Extension, the foreign agent SHOULD NOT reject the > Registration Request message. If the Challenge Extension is present > in the Registration Reply, it MUST be the same Challenge value that > was included in the Registration Request. If the Challenge value > differs in the Registration Reply received from the home agent, the > foreign agent MUST insert an FA Error extension with Status value > HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node > (see Section 10). The above section does not belong here but in the next section on Registration Replies. Mixing section contents like this makes things very confusing.=20 [JB] Done Above, notice the MUST be the same Challenge value. But if the value was not stored (as allowed by the SHOULD above), then what happens? The error recovery and error status value above does not take that into account. [JB] I am ok with your suggestion but I haven't made this change yet. I need input from others with respect to backward compatibility if "should" changes to "must". =20 > If the foreign agent does remove the Challenge extension and > applicable authentication from the Registration Request message, then > it SHOULD insert the Identification field from the Registration s/insert/store/ [JB] Done > Request message along with its record-keeping information about the s/along with/as part of/ [JB] Done > particular mobile node in order to protect against replays. >=20 > 3.3 Foreign Agent Processing for Registration Replies s/for/of/ [JB] Done ... > If the foreign agent receives a Registration Reply with the Code > value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. Presumably, regardless of code value, the Reg Reply must be relayed, yes? If so, why is this here? Suggest deleting the above as it is=20 redundant. In general, there seems to be a lot of repetition. One reads them carefully expecting there to be an exception to a rule, but there is none, so it's just tiring. [JB] I have reworded as below to reflect that the error received in the Registration Reply from the HA is relayed to the MN in the Registration Reply. "If the foreign agent receives a Registration Reply with the Code value HA_BAD_AAA_AUTH, the Registration Reply with this Code value MUST be relayed to the mobile node." > 3.4 Home Agent Processing for the Challenge Extensions ... > The home agent MAY receive a Registration Request with the > Mobile-AAA s/MAY/may/ JB] Done Does not seem prescriptive but merely describing an eventuality, so I don't think we need rfc 2026 language here. > 3.5 Mobile Node Processing for Registration Replies ... > UNKNOWN_CHALLENGE: This error code is received by the mobile node in > the case where the mobile node has moved to a new foreign agent > that s/in the case where the mobile node/if it/ [JB] As a part of Jari's comments, this text is removed. > MISSING_CHALLENGE: A mobile node that does not include a Challenge > when the Mobile-Foreign Authentication extension is present may > receive a MISSING_CHALLENGE error. In this case, the mobile node > SHOULD send a Challenge extension containing an unused challenge in > the next Registration Request. >=20 > BAD_AUTHENTICATION: This error is sent by the foreign agent if the > Registration Request contains a Mobile-Foreign Authentication > extension with an incorrect authenticator that fails verification. A > mobile node that receives a BAD_AUTHENTICATION Code value SHOULD > include the Mobile-AAA Authentication Extension in the next > Registration Request. This will make it possible for the Foreign > Agent to use its AAA infrastructure in order to authenticate the > mobile node. In this case, the mobile node MUST use a new Challenge > value in any new registration, obtained either from an Agent > Advertisement, or from a Challenge extension to the Registration > Reply containing the error. >=20 > FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the > Registration Request contains a Mobile-AAA Authentication extension > with an incorrect authenticator that fails verification. A mobile > node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value > in any new registration, obtained either from an Agent Advertisement, > or from a Challenge extension to the Registration Reply containing > the error. >=20 > HA_BAD_AAA_AUTH: This error is sent by the home agent if the > Registration Request contains a Mobile-AAA Authentication extension > with an incorrect authenticator that fails verification. A mobile s/incorrect// [JB] As a part of Jari's comments, this text is removed. > node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value > in any new registration, obtained either from an Agent Advertisement, > or from a Challenge extension to the Registration Reply containing > the error. >=20 > STALE_CHALLENGE: If the foreign agent receives a Registration Request > with a Challenge extension containing a Challenge value previously > used by that mobile node, the mobile node MAY receive a > Registration s/MAY/may/ [JB] As a part of Jari's comments, this text is removed. > Reply to the mobile node containing the Code value STALE_CHALLENGE. > In such instances, the mobile node MUST use a new Challenge value in > next Registration Request, obtained either from an Agent > Advertisement, or from a Challenge extension to the Registration > Reply containing the error. >=20 > HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the > Registration Reply from the home agent contains a different Challenge > value from the one included in the Registration Request. s/the one/that/ Repetitiveness in the challenge rules was already taken care of by Jari's comments, I believe.=20 [JB] Yes. As a part of Jari's comments, this text is removed. ... > 4. Mobile-Foreign Challenge Extension >=20 > This section specifies a new Mobile IP Registration extension that is > used to satisfy a Challenge in an Agent Advertisement. The Challenge > extension to the Registration Request message is used to indicate the > challenge that the mobile node is attempting to satisfy. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Challenge ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2: The Mobile-Foreign Challenge Extension >=20 > Type: >=20 > 132 (skippable) (see [RFC3344]) >=20 > Length: >=20 > Length of the Challenge value >=20 > Challenge: >=20 > The Challenge field is copied from the Challenge field found in > the Agent Advertisement Challenge extension (see section 2). s/Agent Advertisement/received/ Cuz Agent Advertisements are not the only way to learn a Challenge.=20 [JB] Done > 5. Generalized Mobile IP Authentication Extension This really should be a separate document. > Several new authentication extensions have been designed for various > control messages proposed for extensions to Mobile IP. A new > authentication extension is required for a mobile node to present its > credentials to any other entity other than the ones already defined; > the only entities defined in the base Mobile IP specification > [RFC3344] are the home agent and the foreign agent. It is the s/It is/The/ [JB] Done > purpose of the generalized authentication extension defined here to s/here to/here is to/ [JB] Done ... > 6. Mobile-AAA Authentication subtype >=20 > The Generalized Authentication extension with subtype 1 will be > referred to as a Mobile-AAA Authentication extension. The mobile > node MAY include a Mobile-AAA Authentication extension in any > Registration Request. This extension MAY co-exist in the same > Registration Request with Authentication extensions defined for > Mobile IP Registration by [RFC3344]. If the mobile node does not s/by// [JB] Done > include a Mobile-Foreign Authentication [RFC3344] extension, then > it s/[RFC3344]// [JB] Done > MUST include the Mobile-AAA Authentication extension whenever the > Challenge extension is present. If both are present, the Mobile-AAA > Authentication extension MUST precede the Mobile-Foreign > Authentication extension. >=20 > If the Mobile-AAA Authentication extension is present, then the > Registration Message sent by the mobile node MUST contain the Mobile- > Home Authentication extension [RFC3344] if it shares a security notice this "if" > association with the home agent. If both are present, the Mobile- and this "if" as well. This means that MN-HA Authentication is no longer a MUST, and that it may be absent. I believe this is a departure from rfc 3344, and if so, it should be flagged by explicitly saying so.=20 [JB] Agree. I have reworded the paragraph as below: From: If the Mobile-AAA Authentication extension is present, then the Registration Message sent by the mobile node MUST contain the Mobile-Home Authentication extension [RFC3344] if it shares a security association with the home agent. If both are present, the Mobile-Home Authentication Extension MUST appear prior to the Mobile-AAA Authentication extension. The corresponding response MUST include the Mobile-Home Authentication Extension, and MUST NOT include the Mobile-AAA Authentication Extension. To: If the Mobile-AAA Authentication extension is present, the Mobile-Home Authentication Extension MUST appear prior to the Mobile-AAA Authentication extension. The corresponding response MUST include the Mobile-Home Authentication Extension, and MUST NOT include the Mobile-AAA Authentication Extension. ... > 8. SPIs for RADIUS AAA Servers >=20 > Some AAA servers only admit a single security association, and thus > do not use the SPI numbers for Mobile IP authentication extensions > for use when determining the security association that would be > necessary for verifying the authentication information included with > the Authentication extension. >=20 > SPI number CHAP_SPI (see Section 9) is reserved for indicating the > following procedure for computing authentication data (called the > "authenticator"), which is used by many RADIUS servers [RFC2138] > today. >=20 > To compute the authenticator, apply MD5 [RFC1321] computed on the > following data, in the order shown: >=20 > High-order byte from Challenge || Key || >=20 > MD5(Preceding Mobile IP data || >=20 > Type, Subtype (if present), Length, SPI) || >=20 > Least-order 237 bytes from Challenge >=20 > 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 =3D=3D CHAP_SPI is used with the > Generalized Authentication extension. Since the RADIUS protocol > cannot carry attributes of length greater than 253, the preceding > Mobile IP data, type, subtype (if present), length and SPI are hashed > using MD5. Finally, the least significant 237 bytes of the challenge > are concatenated. If the challenge has fewer than 238 bytes, this > algorithm includes the high-order byte in the computation twice, but > ensures that the challenge is used exactly as is. Additional padding > is never used to increase the length of the challenge; the input data > is allowed to be shorter than 237 bytes long. This draft starts by trying to help the FA, not the MN. so it should at least do no harm to the MN.=20 But this is something that can end up screwing the MN. Any device within RF coverage of both can see everything above (including the challenge), except the password used in CHAP. Given the weakness to dictionary attacks, an exchange like the above effectively blasts the user's password to anybody who cares to listen. This shouldn't be recommended. Or am I missing something? ... [JB] We can reflect what security AD may be proposing for this issue. > 9. Configurable Parameters >=20 > Every Mobile IP agent supporting the extensions defined in this > document SHOULD be able to configure each parameter in the following > table. Each table entry contains the name of the parameter, the > default value, and the section of the document in which the parameter > first appears. >=20 > +------------------+---------------+---------------------+ > | Parameter Name | Default Value | Section of Document | > +------------------+---------------+---------------------+ > | CHALLENGE_WINDOW | 2 | 3.2 | This has never been explained! And the first time it's mentioned is section 2.1. [JB] I have given reference to this section (section 9) in section 2.1 > | | | | > | CHAP_SPI | 2 | 8 | First time it's mentioned is section 3.1. [JB] We already have reference to section 9 for CHAP_SPI. ... > 10. Error Values >=20 > Each entry in the following table contains the name of the Code > [RFC3344] to be returned in a Registration Reply, the value for the > Code, and the section in which the error is first mentioned in this > specification. Why is the first time it's mentioned that important? What should be referenced is the section in which it is properly explained (which=20 could be forward referenced from wherever it's mentioned for the=20 first time). [JB] Done (removed "first" from the statement) >=20 > +--------------------+-------+--------------------------+ > | Error Name | Value | Section of Document | > +--------------------+-------+--------------------------+ > | UNKNOWN_CHALLENGE | 104 | 3.2 | > | | | | > | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | > | | | | > | MISSING_CHALLENGE | 105 | 3.1, 3.2 | > | | | | > | STALE_CHALLENGE | 106 | 3.2 | > | | | | > | FA_BAD_AAA_AUTH | TBD | 3.2 | > | | | | > | HA_BAD_AAA_AUTH | TBD | 3.4 | > | | | | > | HA_WRONG_CHALLENGE | TBD | 3.2 | > +--------------------+-------+--------------------------+ >=20 > Table 2: Error Values >=20 Given the errors seen in the previous table, please double-check all the above. ... [JB] Done > 12. Security Considerations >=20 > In the event that a malicious mobile node attempts to replay the > authenticator for an old Mobile-Foreign Challenge, the foreign agent > would detect it since the agent always checks whether it has recently > advertised the Challenge (see Section 3.2). Allowing mobile nodes > with different IP addresses or NAIs to use the same Challenge value > does not represent a security vulnerability, because the > authentication data provided by the mobile node will be computed over > data that is different (at least by the bytes of the mobile nodes' IP > addresses). OLD: at least by the bytes of the mobile nodes' IP addresses NEW: at least the mobile node's IP address will vary [JB] Done ... > 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 [RFC2138]. > The use of MD5 in the method described in Section 8 is less secure > than HMAC-MD5 [RFC2104], and should be avoided whenever possible. s/should/MUST/ But really, this MUST be avoided always, unless there's other (e.g., link-layer mechanisms) that can help prevent the dictionary attacks. I guess the latter applies throughout to the other methods as well.=20 [JB] Done. I would think that "whenever possible" term will take care of backward compatibility issue. > Note that an active attacker may try to prevent successful > registrations by sending a large number of Agent Solicitations or > bogus Registration Requests, each of which could cause the foreign > agent to respond with a fresh challenge, invalidating the challenge > that the MN is currently trying to use. To prevent such attacks, the > foreign agent MUST NOT invalidate previously unused challenges when > responding to unauthenticated Registration Requests or Agent > Solicitations. In addition, the foreign agent MUST NOT allocate new > storage when responding to such messages, because this would also > create the possibility of denial of service. Should say that it does not seek to provide any assurance to the MN, only to the FA and infrastructure. [JB] I though it is implicit. Not sure we really need specific text saying that. I am ok clarifying further if others have issue following the intent. ... > 14. Normative References >=20 > [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile > IPv4", draft-perkins-mip4-faerr-00.txt (work in progress), > January 2004. Update this reference to the latest version. [JB] Done ... > Authors' Addresses ... > Pat R. Calhoun > Black Storm Networks > 110 Nortech Parkway > San Jose, CA 95134 >=20 > Fax: +1 720-293-7501 > Email: pcalhoun@diameter.org Update this info. [JB] Done > Appendix A. Change History I like Jari's suggestion to detail the changes with respect to 3012. [JB] Done ... > Appendix B. Verification Infrastructure ... > In order to verify the credentials of the mobile node, we imagine s/imagine/assume/ [JB] Done ... > Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA > Extension ... > 1. The foreign agent disseminates a Challenge Value in an Agent s/disseminates/includes/=20 [JB] Done s/an Agent/a unicast Agent/ [JB] Done ... > Appendix E. Foreign Agent Algorithm for Tracking Used Challenges This section is normative, and is where we finally see the explanation of how to use CHALLENGE_WINDOW. This should be in the body of the document and must not remain in an appendix. The appendix should only have the pseudo-code example. [JB] I am waiting for further feedback from the WG on this comment and hence haven't included it in the document. --=20 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 Dec 05 15:30:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMyk-0001zS-PE; Mon, 05 Dec 2005 15:30:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMyk-0001zA-17 for mip4@megatron.ietf.org; Mon, 05 Dec 2005 15:30:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07048 for ; Mon, 5 Dec 2005 15:29:38 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjNK4-00087Q-6S for mip4@ietf.org; Mon, 05 Dec 2005 15:52:34 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB5KU5m07586; Mon, 5 Dec 2005 15:30:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 14:29:39 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEA= From: "Jayshree Bharatia" To: "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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 Hi all, Thanks for all your comments. In summary, I see that we have now general agreement that co-located CoA support for MN-AAA extension will be part of this draft. In that respect, I am considering text proposed by Vijay for section 3.1 and 3.5.=20 Currently we have text saying that the mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document. Based on the input from Kent and Madjid, the following is the proposal (modified Vijay's proposal for section 3.5): From: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. To: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. In this case, the Challenge value 0 is recommended for the authenticator calculation mentioned in section 8. Please note that I haven't included Vijay's proposed text for a new section (5) and also for Security Considerations since they are already part of RFC3344. Regards, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 Sent: Friday, December 02, 2005 11:31 AM To: Vijay Devarapalli; Kent Leung (kleung) Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Vijay, However we want to do it, needs to be specified. Motorola development folks share Nokia's confusion:) I think only a handful of people in the industry know exactly how 3344, 3012, 3957, 4004 all work together and that is why the key bootstrapping is not getting any traction in the implementations. We have endless internal "educative" sessions on this too :) I believe 4004 for Diameter missed the problem with MN-AAA AE for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't think that is the right place for it. We suggested zero based on Charlie's initial suggestion to make implementation of CoA and CCoA less complex, you have the same field, you just enter zero when no value is available. Madjid > Also, MN sets the challenge value to zero in the MN-AAA authenticator > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay protection is >>provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 05 16:22:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNmb-0006V5-C3; Mon, 05 Dec 2005 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNmZ-0006SK-Id for mip4@megatron.ietf.org; Mon, 05 Dec 2005 16:21:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12368 for ; Mon, 5 Dec 2005 16:21:09 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjO7w-0001Q6-A6 for mip4@ietf.org; Mon, 05 Dec 2005 16:44:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5Kl1e22086; Mon, 5 Dec 2005 12:47:01 -0800 X-mProtect: <200512052047> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdjWc5QX; Mon, 05 Dec 2005 12:46:58 PST Message-ID: <4394AF58.8030300@iprg.nokia.com> Date: Mon, 05 Dec 2005 13:21:28 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt 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: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Nakhjiri Madjid-MNAKHJI1 , "Kent Leung \(kleung\)" , mip4@ietf.org, "Charles E. Perkins" 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 Jayshree Bharatia wrote: > > Please note that I haven't included Vijay's proposed text for a new > section (5) and also for Security Considerations since they are already > part of RFC3344. Jayshree, we need this text for completeness. if you notice, the text I proposed does not specify anything new. it points to RFC 3344. for example, when one reads 3012bis, they read that replay protection is provided by the challenge. but for the CCoA mode, one gets the impression that the replay protection is not adequate. so we need to point out that the replay protection is provided by the Identification field and just refer to RFC 3344. not trying to be difficult, but this improves 3012bis readability. Vijay > > Regards, > Jayshree > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, December 02, 2005 11:31 AM > To: Vijay Devarapalli; Kent Leung (kleung) > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. > Perkins > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > Vijay, > > However we want to do it, needs to be specified. Motorola development > folks share Nokia's confusion:) I think only a handful of people in the > industry know exactly how 3344, 3012, 3957, 4004 all work together and > that is why the key bootstrapping is not getting any traction in the > implementations. We have endless internal "educative" sessions on this > too :) I believe 4004 for Diameter missed the problem with MN-AAA AE > for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't > think that is the right place for it. We suggested zero based on > Charlie's initial suggestion to make implementation of CoA and CCoA less > complex, you have the same field, you just enter zero when no value is > available. > > Madjid > > > > >>Also, MN sets the challenge value to zero in the MN-AAA authenticator >>computation. > > > hmm.. how about the MN does not use any challenge value (whether 0 or > anything else)? it calculates the MN-AAA authenticator without any > challenge field. one the basic clarifications that is needed is that > there is no challenge to use when there is no FA. > > >>>- clarify that in the absence of a challenge, replay protection is >>>provided by the identification field. >>> >> >>I don't think this is necessary, but doesn't matter too much to me >>either. > > > well, folks inside Nokia who implement mobile nodes were very confused > by RFC 3012. it would be good to make this explicit. > > Vijay > > > -- > 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 Dec 05 16:27:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNsD-0008G2-Ak; Mon, 05 Dec 2005 16:27:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNsB-0008Fu-P6 for mip4@megatron.ietf.org; Mon, 05 Dec 2005 16:27:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12851 for ; Mon, 5 Dec 2005 16:26:58 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjODX-0001ce-NH for mip4@ietf.org; Mon, 05 Dec 2005 16:49:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5Kqiu24473; Mon, 5 Dec 2005 12:52:44 -0800 X-mProtect: <200512052052> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdvit56h; Mon, 05 Dec 2005 12:52:43 PST Message-ID: <4394B0B1.3000700@iprg.nokia.com> Date: Mon, 05 Dec 2005 13:27:13 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" 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 Nakhjiri Madjid-MNAKHJI1 wrote: > Vijay, > > However we want to do it, needs to be specified. Motorola development > folks share Nokia's confusion:) I think only a handful of people in the > industry know exactly how 3344, 3012, 3957, 4004 all work together and > that is why the key bootstrapping is not getting any traction in the > implementations. We have endless internal "educative" sessions on this > too :) > I believe 4004 for Diameter missed the problem with MN-AAA AE for > direct RRQs. > We tried to cover it in RADIUS-MIP draft, but I don't think that is the > right place for it. We suggested zero based on Charlie's initial > suggestion to make implementation of CoA and CCoA less complex, you have > the same field, you just enter zero when no value is available. then we need one more clarification. if the SPI is set to CHAP_SPI and the mobile node is using co-located CoA mode, it sets the challenge to 0. if the SPI is something else, the mobile node leaves out the challenge while calculating the authenticator field. agreed? please excuse me if this sounds obvious to you. :) Vijay -- 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 Dec 05 16:28:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNsq-0008TN-PX; Mon, 05 Dec 2005 16:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjNsp-0008TH-FO for mip4@megatron.ietf.org; Mon, 05 Dec 2005 16:28:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12929 for ; Mon, 5 Dec 2005 16:27:37 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjOEB-0001eO-81 for mip4@ietf.org; Mon, 05 Dec 2005 16:50:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5KrUg25361; Mon, 5 Dec 2005 12:53:30 -0800 X-mProtect: <200512052053> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdQpI2Qw; Mon, 05 Dec 2005 12:53:28 PST Message-ID: <4394B0DE.6000309@iprg.nokia.com> Date: Mon, 05 Dec 2005 13:27:58 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC5201014BBB@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201014BBB@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" 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 agreed. if the SPI is set to CHAP_SPI then we need to use a challenge set to 0. Vijay Kent Leung (kleung) wrote: > The MN and RADIUS client (HA) needs to follow the rules for CHAP > authentication. > > Section 3.1: > > If the SPI value is > chosen as CHAP_SPI (see Section 9), then the mobile node specifies > CHAP-style authentication [RFC1994] using MD5 [RFC1321]. > > > Section 8: > > 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 > > When there is no MFCE, then HA needs to set the "Challenge" to 0 with > length of 1 (minimally) to populate the RADIUS CHAP-Password attribute > properly. The CHAP ID is expected to be one byte for authenticator > computation. > > So there is no need for MFCE because MN-FA replay protect is unnecessary > in CCoA mode, but the challenge value (i.e. zero) is still required to > properly perform CHAP authentication. > > Did I miss your pt? > > Kent > > > >>>Also, MN sets the challenge value to zero in the MN-AAA >> >>authenticator >> >>>computation. >> >>hmm.. how about the MN does not use any challenge value >>(whether 0 or anything else)? it calculates the MN-AAA >>authenticator without any challenge field. one the basic >>clarifications that is needed is that there is no challenge >>to use when there is no FA. >> -- 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 Dec 05 18:17:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPa9-0004LQ-BP; Mon, 05 Dec 2005 18:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPa8-0004LI-Ae for mip4@megatron.ietf.org; Mon, 05 Dec 2005 18:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29315 for ; Mon, 5 Dec 2005 18:16:26 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjPvU-0006te-5g for mip4@ietf.org; Mon, 05 Dec 2005 18:39:22 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB5NU851027539 for ; Mon, 5 Dec 2005 16:30:08 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB5NSoxH009570 for ; Mon, 5 Dec 2005 17:28:50 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 18:16:41 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX54rPwOOS1qmX1Tfeu8REcniPSMQADqS2Q From: "Nakhjiri Madjid-MNAKHJI1" To: "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , Jayshree Bharatia , mip4@ietf.org, "Charles E. Perkins" 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 Hi Vijay, Agreed, however remember that SPI=3DCHAP-SPI and the authenticator using the challenge value is defined under section "8: SPIs for RADIUS AAA Servers" So your addition should go there. Not sure what the document recommends for Diameter, probably nothing. For Diameter, 4004 uses MIP-MN-AAA-SPI AVP which is different from CHAP SPI, not sure how they handle it. Madjid -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 Sent: Monday, December 05, 2005 3:27 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: Kent Leung (kleung); Jayshree Bharatia; mip4@ietf.org; Charles E. Perkins Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Nakhjiri Madjid-MNAKHJI1 wrote: > Vijay, >=20 > However we want to do it, needs to be specified. Motorola development=20 > folks share Nokia's confusion:) I think only a handful of people in=20 > the industry know exactly how 3344, 3012, 3957, 4004 all work together > and that is why the key bootstrapping is not getting any traction in=20 > the implementations. We have endless internal "educative" sessions on=20 > this too :) I believe 4004 for Diameter missed the problem with=20 > MN-AAA AE for direct RRQs. > We tried to cover it in RADIUS-MIP draft, but I don't think that is=20 > the right place for it. We suggested zero based on Charlie's initial=20 > suggestion to make implementation of CoA and CCoA less complex, you=20 > have the same field, you just enter zero when no value is available. then we need one more clarification. if the SPI is set to CHAP_SPI and the mobile node is using co-located CoA mode, it sets the challenge to 0. if the SPI is something else, the mobile node leaves out the challenge while calculating the authenticator field. agreed? please excuse me if this sounds obvious to you. :) Vijay -- 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 Dec 05 18:42:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPyM-0003UO-1Y; Mon, 05 Dec 2005 18:42:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPyK-0003UH-JS for mip4@megatron.ietf.org; Mon, 05 Dec 2005 18:42:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01669 for ; Mon, 5 Dec 2005 18:41:26 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQJh-0007eS-KA for mip4@ietf.org; Mon, 05 Dec 2005 19:04:23 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB5NtExO000575 for ; Mon, 5 Dec 2005 16:55:14 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id jB5Nri66011857 for ; Mon, 5 Dec 2005 17:53:44 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 18:41:47 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Jayshree Bharatia" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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 Jayshree,=20 Appreciate for the effort on gaining consensus. I don't have a strong position either way, the text is now complete. I sort of agree with Vijay that you might want to add that "In CCoA, replay protection is provided through methods specified in 3344 (Identification field in RRQ)", this is just to keep people from wondering... I am fine with either way consensus goes on this one. Madjid -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Monday, December 05, 2005 2:30 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi all, Thanks for all your comments. In summary, I see that we have now general agreement that co-located CoA support for MN-AAA extension will be part of this draft. In that respect, I am considering text proposed by Vijay for section 3.1 and 3.5.=20 Currently we have text saying that the mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document. Based on the input from Kent and Madjid, the following is the proposal (modified Vijay's proposal for section 3.5): From: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. To: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. In this case, the Challenge value 0 is recommended for the authenticator calculation mentioned in section 8. Please note that I haven't included Vijay's proposed text for a new section (5) and also for Security Considerations since they are already part of RFC3344. Regards, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Friday, December 02, 2005 11:31 AM To: Vijay Devarapalli; Kent Leung (kleung) Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Vijay, However we want to do it, needs to be specified. Motorola development folks share Nokia's confusion:) I think only a handful of people in the industry know exactly how 3344, 3012, 3957, 4004 all work together and that is why the key bootstrapping is not getting any traction in the implementations. We have endless internal "educative" sessions on this too :) I believe 4004 for Diameter missed the problem with MN-AAA AE for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't think that is the right place for it. We suggested zero based on Charlie's initial suggestion to make implementation of CoA and CCoA less complex, you have the same field, you just enter zero when no value is available. Madjid > Also, MN sets the challenge value to zero in the MN-AAA authenticator > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay protection is >>provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 05 18:56:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQCU-0007Za-BG; Mon, 05 Dec 2005 18:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQCS-0007ZH-Qr for mip4@megatron.ietf.org; Mon, 05 Dec 2005 18:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02970 for ; Mon, 5 Dec 2005 18:56:02 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQXp-00082g-QH for mip4@ietf.org; Mon, 05 Dec 2005 19:18:59 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jB5NrHw23828; Mon, 5 Dec 2005 18:53:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 17:56:30 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPg From: "Jayshree Bharatia" To: "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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 Hi Madjid, OK. In this case, I will include his text in section 3.1 (Mobile Node processing of Registration Requests) rather than having a new section as he suggested. I will also include his proposed text for "Security Considerations" section. Thanks, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 Sent: Monday, December 05, 2005 5:42 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Jayshree,=20 Appreciate for the effort on gaining consensus. I don't have a strong position either way, the text is now complete. I sort of agree with Vijay that you might want to add that "In CCoA, replay protection is provided through methods specified in 3344 (Identification field in RRQ)", this is just to keep people from wondering... I am fine with either way consensus goes on this one. Madjid -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Monday, December 05, 2005 2:30 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi all, Thanks for all your comments. In summary, I see that we have now general agreement that co-located CoA support for MN-AAA extension will be part of this draft. In that respect, I am considering text proposed by Vijay for section 3.1 and 3.5.=20 Currently we have text saying that the mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document. Based on the input from Kent and Madjid, the following is the proposal (modified Vijay's proposal for section 3.5): From: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. To: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. In this case, the Challenge value 0 is recommended for the authenticator calculation mentioned in section 8. Please note that I haven't included Vijay's proposed text for a new section (5) and also for Security Considerations since they are already part of RFC3344. Regards, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Friday, December 02, 2005 11:31 AM To: Vijay Devarapalli; Kent Leung (kleung) Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Vijay, However we want to do it, needs to be specified. Motorola development folks share Nokia's confusion:) I think only a handful of people in the industry know exactly how 3344, 3012, 3957, 4004 all work together and that is why the key bootstrapping is not getting any traction in the implementations. We have endless internal "educative" sessions on this too :) I believe 4004 for Diameter missed the problem with MN-AAA AE for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't think that is the right place for it. We suggested zero based on Charlie's initial suggestion to make implementation of CoA and CCoA less complex, you have the same field, you just enter zero when no value is available. Madjid > Also, MN sets the challenge value to zero in the MN-AAA authenticator=20 > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay protection is=20 >>provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me=20 > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 05 19:04:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQJN-0001MV-6M; Mon, 05 Dec 2005 19:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQJL-0001MG-9Q for mip4@megatron.ietf.org; Mon, 05 Dec 2005 19:04:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03726 for ; Mon, 5 Dec 2005 19:03:08 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQei-0008JK-I2 for mip4@ietf.org; Mon, 05 Dec 2005 19:26:06 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jB60GuBj003737 for ; Mon, 5 Dec 2005 17:16:56 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB60FclA024674 for ; Mon, 5 Dec 2005 18:15:38 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 19:03:29 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPgAACiwEA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Jayshree Bharatia" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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 Hi Jayshree, Please note that this also impacts section 8 on use of CHAP SPI for RADIUS server, as I mentioned in a previous email. Regards, Madjid=20 -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Monday, December 05, 2005 5:57 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi Madjid, OK. In this case, I will include his text in section 3.1 (Mobile Node processing of Registration Requests) rather than having a new section as he suggested. I will also include his proposed text for "Security Considerations" section. Thanks, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, December 05, 2005 5:42 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Jayshree,=20 Appreciate for the effort on gaining consensus. I don't have a strong position either way, the text is now complete. I sort of agree with Vijay that you might want to add that "In CCoA, replay protection is provided through methods specified in 3344 (Identification field in RRQ)", this is just to keep people from wondering... I am fine with either way consensus goes on this one. Madjid -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Monday, December 05, 2005 2:30 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi all, Thanks for all your comments. In summary, I see that we have now general agreement that co-located CoA support for MN-AAA extension will be part of this draft. In that respect, I am considering text proposed by Vijay for section 3.1 and 3.5.=20 Currently we have text saying that the mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document. Based on the input from Kent and Madjid, the following is the proposal (modified Vijay's proposal for section 3.5): From: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. To: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. In this case, the Challenge value 0 is recommended for the authenticator calculation mentioned in section 8. Please note that I haven't included Vijay's proposed text for a new section (5) and also for Security Considerations since they are already part of RFC3344. Regards, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Friday, December 02, 2005 11:31 AM To: Vijay Devarapalli; Kent Leung (kleung) Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Vijay, However we want to do it, needs to be specified. Motorola development folks share Nokia's confusion:) I think only a handful of people in the industry know exactly how 3344, 3012, 3957, 4004 all work together and that is why the key bootstrapping is not getting any traction in the implementations. We have endless internal "educative" sessions on this too :) I believe 4004 for Diameter missed the problem with MN-AAA AE for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't think that is the right place for it. We suggested zero based on Charlie's initial suggestion to make implementation of CoA and CCoA less complex, you have the same field, you just enter zero when no value is available. Madjid > Also, MN sets the challenge value to zero in the MN-AAA authenticator=20 > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay protection is=20 >>provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me=20 > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 05 19:07:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQMk-0002LT-K4; Mon, 05 Dec 2005 19:07:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQMj-0002LJ-48 for mip4@megatron.ietf.org; Mon, 05 Dec 2005 19:07:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04020 for ; Mon, 5 Dec 2005 19:06:38 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQi6-0008Sa-Bw for mip4@ietf.org; Mon, 05 Dec 2005 19:29:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB5NWVb15074; Mon, 5 Dec 2005 15:32:31 -0800 X-mProtect: <200512052332> Nokia Silicon Valley Messaging Protection Received: from danira-pool05389.americas.nokia.com (10.241.53.89, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdINgzYf; Mon, 05 Dec 2005 15:32:30 PST Message-ID: <4394D61A.5000303@iprg.nokia.com> Date: Mon, 05 Dec 2005 16:06:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt 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: a1852b4f554b02e7e4548cc7928acc1f 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 thanks. Vijay Jayshree Bharatia wrote: > Hi Madjid, > > OK. In this case, I will include his text in section 3.1 (Mobile Node > processing of Registration Requests) rather than having a new section as > he suggested. I will also include his proposed text for "Security > Considerations" section. > > Thanks, > Jayshree > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, December 05, 2005 5:42 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung > (kleung) > Cc: mip4@ietf.org; Charles E. Perkins > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > Jayshree, > > Appreciate for the effort on gaining consensus. > I don't have a strong position either way, the text is now complete. I > sort of agree with Vijay that you might want to add that "In CCoA, > replay protection is provided through methods specified in 3344 > (Identification field in RRQ)", this is just to keep people from > wondering... I am fine with either way consensus goes on this one. > > Madjid > > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortel.com] > Sent: Monday, December 05, 2005 2:30 PM > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) > Cc: mip4@ietf.org; Charles E. Perkins > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > Hi all, > > Thanks for all your comments. In summary, I see that we have now general > agreement that co-located CoA support for MN-AAA extension will be part > of this draft. In that respect, I am considering text proposed by Vijay > for section 3.1 and 3.5. > > Currently we have text saying that the mechanism used by the mobile node > to obtain the Challenge value in this case is outside the scope of this > document. Based on the input from Kent and Madjid, the following is the > proposal (modified Vijay's proposal for section 3.5): > > From: > In the co-located CoA mode, the mobile node will receive a Registration > Reply without the Challenge Extension and processes the Registration > Reply as specified in [RFC3344]. > > To: > In the co-located CoA mode, the mobile node will receive a Registration > Reply without the Challenge Extension and processes the Registration > Reply as specified in [RFC3344]. In this case, the Challenge value 0 is > recommended for the authenticator calculation mentioned in section 8. > > Please note that I haven't included Vijay's proposed text for a new > section (5) and also for Security Considerations since they are already > part of RFC3344. > > Regards, > Jayshree > > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Friday, December 02, 2005 11:31 AM > To: Vijay Devarapalli; Kent Leung (kleung) > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. > Perkins > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > Vijay, > > However we want to do it, needs to be specified. Motorola development > folks share Nokia's confusion:) I think only a handful of people in the > industry know exactly how 3344, 3012, 3957, 4004 all work together and > that is why the key bootstrapping is not getting any traction in the > implementations. We have endless internal "educative" sessions on this > too :) I believe 4004 for Diameter missed the problem with MN-AAA AE > for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't > think that is the right place for it. We suggested zero based on > Charlie's initial suggestion to make implementation of CoA and CCoA less > complex, you have the same field, you just enter zero when no value is > available. > > Madjid > > > > >>Also, MN sets the challenge value to zero in the MN-AAA authenticator >>computation. > > > hmm.. how about the MN does not use any challenge value (whether 0 or > anything else)? it calculates the MN-AAA authenticator without any > challenge field. one the basic clarifications that is needed is that > there is no challenge to use when there is no FA. > > >>>- clarify that in the absence of a challenge, replay protection is >>>provided by the identification field. >>> >> >>I don't think this is necessary, but doesn't matter too much to me >>either. > > > well, folks inside Nokia who implement mobile nodes were very confused > by RFC 3012. it would be good to make this explicit. > > Vijay > > > -- > 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 Dec 05 19:11:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQQC-0003mR-F2; Mon, 05 Dec 2005 19:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQQB-0003mM-At for mip4@megatron.ietf.org; Mon, 05 Dec 2005 19:11:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04496 for ; Mon, 5 Dec 2005 19:10:12 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQlZ-0000Ak-5S for mip4@ietf.org; Mon, 05 Dec 2005 19:33:09 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jB60AeZ21419; Mon, 5 Dec 2005 19:10:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 5 Dec 2005 18:10:20 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPgAACiwEAAAAXbEA== From: "Jayshree Bharatia" To: "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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 Hi Madjid, I have covered this part in the modified text for section 3.4 I sent earlier today. Please check that and see if you like to add or modify.=20 In short, most of Vijay's proposal is going in. But I have slightly modified text for section 3.5 to include value of challenge for authenticator computation in section 8. Also, instead of new section, I will include his proposed text to section 3.1.=20 Regards, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 Sent: Monday, December 05, 2005 6:03 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi Jayshree, Please note that this also impacts section 8 on use of CHAP SPI for RADIUS server, as I mentioned in a previous email. Regards, Madjid=20 -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Monday, December 05, 2005 5:57 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi Madjid, OK. In this case, I will include his text in section 3.1 (Mobile Node processing of Registration Requests) rather than having a new section as he suggested. I will also include his proposed text for "Security Considerations" section. Thanks, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, December 05, 2005 5:42 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH]; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Jayshree,=20 Appreciate for the effort on gaining consensus. I don't have a strong position either way, the text is now complete. I sort of agree with Vijay that you might want to add that "In CCoA, replay protection is provided through methods specified in 3344 (Identification field in RRQ)", this is just to keep people from wondering... I am fine with either way consensus goes on this one. Madjid -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Monday, December 05, 2005 2:30 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapalli; Kent Leung (kleung) Cc: mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi all, Thanks for all your comments. In summary, I see that we have now general agreement that co-located CoA support for MN-AAA extension will be part of this draft. In that respect, I am considering text proposed by Vijay for section 3.1 and 3.5.=20 Currently we have text saying that the mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document. Based on the input from Kent and Madjid, the following is the proposal (modified Vijay's proposal for section 3.5): From: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. To: In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. In this case, the Challenge value 0 is recommended for the authenticator calculation mentioned in section 8. Please note that I haven't included Vijay's proposed text for a new section (5) and also for Security Considerations since they are already part of RFC3344. Regards, Jayshree -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Friday, December 02, 2005 11:31 AM To: Vijay Devarapalli; Kent Leung (kleung) Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; mip4@ietf.org; Charles E. Perkins Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Vijay, However we want to do it, needs to be specified. Motorola development folks share Nokia's confusion:) I think only a handful of people in the industry know exactly how 3344, 3012, 3957, 4004 all work together and that is why the key bootstrapping is not getting any traction in the implementations. We have endless internal "educative" sessions on this too :) I believe 4004 for Diameter missed the problem with MN-AAA AE for direct RRQs. We tried to cover it in RADIUS-MIP draft, but I don't think that is the right place for it. We suggested zero based on Charlie's initial suggestion to make implementation of CoA and CCoA less complex, you have the same field, you just enter zero when no value is available. Madjid > Also, MN sets the challenge value to zero in the MN-AAA authenticator > computation. hmm.. how about the MN does not use any challenge value (whether 0 or anything else)? it calculates the MN-AAA authenticator without any challenge field. one the basic clarifications that is needed is that there is no challenge to use when there is no FA. >>- clarify that in the absence of a challenge, replay protection is >>provided by the identification field. >> > I don't think this is necessary, but doesn't matter too much to me > either. well, folks inside Nokia who implement mobile nodes were very confused by RFC 3012. it would be good to make this explicit. Vijay -- 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 Dec 08 15:57:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSpt-0008VM-1T; Thu, 08 Dec 2005 15:57:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSpr-0008V8-Kl for mip4@megatron.ietf.org; Thu, 08 Dec 2005 15:57:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10164 for ; Thu, 8 Dec 2005 15:56:53 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSpp-00014t-QC for mip4@ietf.org; Thu, 08 Dec 2005 15:57:50 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id jB8LErTV022863 for ; Thu, 8 Dec 2005 14:14:53 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id jB8L8bof022907 for ; Thu, 8 Dec 2005 15:08:37 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Thu, 8 Dec 2005 15:57:00 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcX27Je3mwcw6WCkQnSqUtrCftucugAeLN8gAJudFEAACEVxcAAAPlPgAACiwEAAAAXbEACQWv7w From: "Nakhjiri Madjid-MNAKHJI1" To: "Jayshree Bharatia" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, "Charles E. Perkins" 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: ,