[Dime] RE: RFC 4004 Diameter MIP issues
"McCann Peter-A001034" <pete.mccann@motorola.com> Fri, 28 September 2007 19:34 UTC
Return-path: <dime-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLbv-0007OQ-Na; Fri, 28 Sep 2007 15:34:51 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbLbu-0007Js-K2 for dime@ietf.org; Fri, 28 Sep 2007 15:34:50 -0400
Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbLbt-00024W-VS for dime@ietf.org; Fri, 28 Sep 2007 15:34:50 -0400
X-VirusChecked: Checked
X-Env-Sender: pete.mccann@motorola.com
X-Msg-Ref: server-2.tower-119.messagelabs.com!1191008085!20944626!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 9281 invoked from network); 28 Sep 2007 19:34:45 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 28 Sep 2007 19:34:45 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8SJYjUv013571 for <dime@ietf.org>; Fri, 28 Sep 2007 12:34:45 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8SJYi8q027632 for <dime@ietf.org>; Fri, 28 Sep 2007 14:34:45 -0500 (CDT)
Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8SJYicF027622 for <dime@ietf.org>; Fri, 28 Sep 2007 14:34:44 -0500 (CDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Sep 2007 15:34:43 -0400
Message-ID: <BE4B07D4197BF34EB3B753DD34EBCD1301E53593@de01exm67.ds.mot.com>
In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D09F@SEHAN021MB.tcad.telia.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RFC 4004 Diameter MIP issues
Thread-Index: Acf//VAzwhid8e60R2ucOGnB3Ro1HQBQqU9w
References: <59D7431DE2527D4CB0F1EFEDA5683ED30222D09F@SEHAN021MB.tcad.telia.se>
From: McCann Peter-A001034 <pete.mccann@motorola.com>
To: jouni.korhonen@teliasonera.com, dime@ietf.org
X-CFilter-Loop: Reflected
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc:
Subject: [Dime] RE: RFC 4004 Diameter MIP issues
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org
jouni.korhonen@teliasonera.com wrote: > Hi, > > I was reading RFC 4004 (again). Both MIP-HA-to-MN-SPI and > MIP-MN-to-HA-SPI are listed in respective command ABNFs as mandatory > AVPs & in AVP occurrence tables; see sections 9.4., 9.6., and 11.1. > However, no code values have been allocated and no types has been > defined. Any particular reason for this or am I missing something? > > Cheers, > Jouni Hi, Jouni, As this is the 3rd time this question has come up on the list, I went back and closely re-read the spec regarding key distribution. I think I've found a number of errors that need to be corrected. I hope we can develop an errata in the near future that addresses these things. 1. We left out the AAA-SPI needed for RFC 3957. In Section 8.2: The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce. Should be: The hashing algorithm used by the mobile node to construct the session key has to be the same as that used by the AAAH in the session key generation procedure. The AAAH therefore indicates the algorithm used along with the nonce by including a AAA SPI. In Section 9: Need to add a new AVP to the table called "MIP-AAA-SPI" of type "Unsigned32". In Section 9.5. MIP-MN-to-FA-MSA AVP Need to include "{MIP-AAA-SPI}" right before the "{MIP-Nonce}" In Section 9.6 MIP-MN-to-HA-MSA AVP Need to include "{MIP-AAA-SPI}" right before the "{MIP-Nonce}" Create new section 9.15 describing the AAA-SPI: 9.15. MIP-AAA-SPI AVP The MIP-AAA-SPI AVP (AVP Code TBD) is of type Unsigned32 and contains the Security Parameter Index the AAA and MN use to indicate the algorithm used to generate a Mobile IP Session Key from a Mobile IP Nonce. It appears in registration replies according to [RFC3957]. 2. The MN-FA SPI is created by the FA but is currently not being transferred in the AMR. This is needed by the HA to construct the Registration Reply that contains the Generalized MN-FA Key Generation Nonce Reply Extension. Section 5.1 AA-Mobile-Node-Request Need to include "[ MIP-MN-to-FA-SPI "] right after "[ MIP-HA-to-FA-SPI ]" in the grammar for AMR. Section 8.4 Distributing the Mobile-Foreign Session Key The HA also includes the SPIs proposed by the mobile node and foreign agent in the "Generalized MN-FA Key Generation Nonce Request" extension. Should be: The HA also includes the SPI proposed by the FA in the "Generalized MN-FA Key Generation Nonce Reply" extension. Note that the MIP-MN-to-FA-SPI is correctly included in the MIP-MN-to-FA-MSA that is carried in the HAR and defined in Section 9.5. This attribute, however, needs to be added to the table in Section 9: Insert "MIP-MN-to-FA-SPI" right after "MIP-HA-to-FA-SPI" in this table. Need to add a new Section 9.16: 9.16. MIP-MN-to-FA-SPI AVP The MIP-MN-to-FA-SPI AVP (AVP Code TBD) is of type Unsigned32 and contains the Security Parameter Index the MN and FA use to refer to the MN-FA mobility security association. The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP]. 3. MN-HA SPI is not needed in the MN-HA MSA AVP. This AVP is sent to the HA, and the HA is the one that must choose the SPI. Therefore the SPI is not even available to send from the AAAH to the HA. Also, the text incorrectly states that the MN-HA-MSA AVP is carried in an AMR, when it should be AMA: In Section 9.6: This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension using the session key and algorithm, and the HA verifies that extension using the same session key and algorithm. Should be: This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMA for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-HA session key using the nonce and an algorithm indexed by the AAA SPI. Delete the line { MIP-MN-HA-SPI } from the ABNF. 4. The HA-MN SPI is not needed in the HA-MN MSA AVP. This is because the HA-MN SPI (chosen by the MN) is already present in the Registration Request that gets sent to the HA. Delete the line { MIP-HA-to-MN-SPI } from the ABNF in Section 9.4. 5. For consistency, we should change the text in Section 9.5 to match what I proposed above for Section 9.6: The MN creates the MN-FA authentication extension by using the session key and algorithm, and the FA verifies that extension using the same key and algorithm. Should be: The MN creates the MN-FA session key by using the nonce and an algorithm indexed by the AAA SPI. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime
- [Dime] RFC 4004 Diameter MIP issues jouni.korhonen
- [Dime] RE: RFC 4004 Diameter MIP issues McCann Peter-A001034
- [Dime] RE: RFC 4004 Diameter MIP issues jouni.korhonen