RE: [Mip6] Comments on jee-mip6-bootstrap-pana

Tschofenig Hannes <hannes.tschofenig@siemens.com> Thu, 04 November 2004 14:50 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26150 for <mip6-web-archive@ietf.org>; Thu, 4 Nov 2004 09:50:17 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjBv-00060n-0R for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 10:06:23 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPioK-0006fo-O5; Thu, 04 Nov 2004 09:42:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPidK-0004dE-QJ for mip6@megatron.ietf.org; Thu, 04 Nov 2004 09:30:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24696 for <mip6@ietf.org>; Thu, 4 Nov 2004 09:30:37 -0500 (EST)
Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPiss-0005Wx-7i for mip6@ietf.org; Thu, 04 Nov 2004 09:46:42 -0500
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iA4EUYP6015151; Thu, 4 Nov 2004 15:30:34 +0100
Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iA4EUXBO011736; Thu, 4 Nov 2004 15:30:33 +0100
Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR0R3W>; Thu, 4 Nov 2004 15:30:33 +0100
Message-ID: <2A8DB02E3018D411901B009027FD3A3F05319FD7@mchp905a.mch.sbs.de>
From: Tschofenig Hannes <hannes.tschofenig@siemens.com>
To: Junghoon Jee <jhjee@etri.re.kr>, Alper Yegin <alper.yegin@samsung.com>, mip6@ietf.org
Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana
Date: Thu, 04 Nov 2004 15:30:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d

hi junghoon,  

> Hannes,
> 
> > 
> > when i read the draft i came accross the same questions. 
> > 
> > i like your pull (instead of the push approach). this might 
> also work 
> > nicely with <draft-ietf-mip6-auth-protocol-00.txt>.
> 
> Can you explain this point more concretely ?
you can bootstrap a number of security associations using the same approach.
hence, you might be able to bootstrap a security association which can be
used for protecting mip6 binding updates as described in
<draft-ietf-mip6-auth-protocol-00.txt> (instead of an ike/ipsec sa). 

i can draw a message flow if you want. 

> 
> > i wasn't sure how and when the MIPv6-AAA-Key is computed as well. 
> 
> I answered that question through my previous mail.
> For clarity,
> The AAA server and the MN maintains the key mapping table, 
> MIPv6-AAA-Key-Id vs. MIPv6-AAA-Key.
> When EAP authentication is succeeded, the MIPv6-AAA-Key and 
> its id. are stored to the key mapping table.
> The MIPv6-AAA-Key can be an AAA-Key or concatenation of the 
> AAA-Key' with AAA-Key'' if multiple session keys are derived 
> by the EAP authentication process. 
> The choice of which key to use to derive MIPv6 IKE PSK is 
> determined by the AAA home server. 
> The AAA home server notifies the MN which key to use by 
> sending the MIPv6-AAA-Key-Id.

i see. 

> 
> > a minor correction to your mail: the diameter application ships the 
> > parameters to the PAA (and not to the mobile node). this is 
> the reason 
> > why a pana protocol is required which carries the 
> parameters finally 
> > to the end host. this is probably the most important 
> difference with 
> > regard to the <draft-giaretta-mip6-authorization-eap> draft.
> 
> Right, I agree with you.
> 
> >   
> > ps: it might be good to reference an old draft 
> > <draft-le-aaa-diameter-mobileipv6-02.txt> which proposed 
> the same approach.
> > i also remember that julien published a draft with a 
> similar idea some 
> > time ago.
> 
> The previous draft-le-aaa-diameter-mobileipv6-03.txt is a 
> good reference for our work.
> In that draft, BU message is processed during the AAA auth. & 
> authorization phase.
> The BU message can be piggybacked to the AAA auth request 
> message or it can be produced on the AAA server. 
> In the draft-jee-mip6-bootstrap-aaa-00, BU is processed after 
> the AAA auth & authorization phase.
> This is because the BU MUST be protected by the IPsec SA 
> according to the RFC 3775.
> If the  draft-ietf-mip6-auth-protocol-00.txt is used, BU may 
> be piggybacked during the AAA auth& authorization phase if 
> the MN's CoA is configured.
> 
there are certainly differences but the main idea goes in the same
direction. 

ciao
hannes


> 
> Junghoon
> 
> 
> 
> > > -----Original Message-----
> > > From: Alper Yegin [mailto:alper.yegin@samsung.com]
> > > Sent: Dienstag, 02. November 2004 02:23
> > > To: mip6@ietf.org
> > > Subject: [Mip6] Comments on jee-mip6-bootstrap-pana
> > > 
> > > Hello,
> > > 
> > > Here are some comments and questions on the 
> > > draft-jee-mip6-bootstrap-pana-00.txt.
> > > 
> > > - I see the new Diameter application has two functionalities. 
> > > Regarding the delivery of the bootstrapping information 
> to the MN, I 
> > > was wondering if we could get away with not defining new 
> commands, 
> > > but instead piggybacking on existing NAS application? The 
> > > bootstrapping information could be delivered to the NAS 
> as part of 
> > > the mobile's profile.
> > > 
> > > - The other functionality is the push of bootstrapping 
> information 
> > > from AAAh to HA. This is carried in serial with the (in 
> fact, in the 
> > > middle
> > > of) network access AAA. I think it could be done in parallel, or 
> > > even after the network access AAA. If you use a pull 
> model instead 
> > > of the push, this part gets aligned with the yegin-mip6-aaa-fwk.
> > > 
> > > - I didn't quite understand how the MN obtains/computes the 
> > > MIPv6-AAA-Key. It is only provided with the MIPv6-AAA-Key-Id, and 
> > > that's not sufficient to derive the key.
> > > 
> > > Thanks in advance.
> > > 
> > > Alper
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Mip6 mailing list
> > > Mip6@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> > > 
> > 
> > _______________________________________________
> > Mip6 mailing list
> > Mip6@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> 

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6