Re: [Dime] [HOKEY] DiME ERP: new Application ID or not ?(non-roaming case)

Julien Bournelle <julien.bournelle@gmail.com> Thu, 12 March 2009 09:06 UTC

Return-Path: <julien.bournelle@gmail.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00B93A6877; Thu, 12 Mar 2009 02:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmsigrZ46QMJ; Thu, 12 Mar 2009 02:06:10 -0700 (PDT)
Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 390873A67CC; Thu, 12 Mar 2009 02:06:10 -0700 (PDT)
Received: by yw-out-2324.google.com with SMTP id 5so1165612ywh.49 for <multiple recipients>; Thu, 12 Mar 2009 02:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WbTVU5j7hNN0OJdfWOeVUw5K2XSXhE3SoTb/4GKnsHg=; b=ct+g1X82jV37rDpiuB3QwUA0f3L8HSf4yDdJLWG4jEpuvUnHRekb+QNNNGfMDTACNG MC3N/oQy0TssMui9QLLwavXP3SAB0KdVZZ8jbTjDdmGcP3ZdzHhfKHRY4E79rgyN6bzI Y0B1NBXpLEfpGpBpSjOvdRjWktmF+kutGmc60=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GUowrsJlL9p2LKIqU6BqeOeUEdKb3RUB+tLlr/tyMRvfyeVxyRchd/05cE6EmqzKu0 +rUcHe/VIsjOc6PymnWq1d3+sFmy+Zf8y9rncdF8JOo53E5gBSu4s8Y/d+rJlL7RO7NQ rgRONR5QxwXqyicUXaXTp0E8aLTv9KyCK7Mco=
MIME-Version: 1.0
Received: by 10.220.45.212 with SMTP id g20mr3782999vcf.43.1236848806963; Thu, 12 Mar 2009 02:06:46 -0700 (PDT)
In-Reply-To: <024d01c9a2e7$6708e0f0$1b0ca40a@china.huawei.com>
References: <5e2406980903032305k48ad83b7r1015e61c6ed983ae@mail.gmail.com> <020e01c99ca1$3b704150$2fb4b70a@nsnintra.net> <5e2406980903040203i26ab161bs3f221dc4ac03ed7@mail.gmail.com> <021601c99f18$ee622250$0201a8c0@nsnintra.net> <5e2406980903100314ycaf2a26mebff07d6e8ad395a@mail.gmail.com> <006b01c9a19e$aa68cf30$ff3a6d90$@net> <07ce01c9a1a1$5a8daa50$0201a8c0@nsnintra.net> <024d01c9a2e7$6708e0f0$1b0ca40a@china.huawei.com>
Date: Thu, 12 Mar 2009 10:06:46 +0100
Message-ID: <5e2406980903120206h5d80503bw46edbc3388105516@mail.gmail.com>
From: Julien Bournelle <julien.bournelle@gmail.com>
To: Qin Wu <sunseawq@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dime@ietf.org, hokey@ietf.org
Subject: Re: [Dime] [HOKEY] DiME ERP: new Application ID or not ?(non-roaming case)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 09:06:12 -0000

Hi Qin,

 let me try to give you my understanding concerning your (good) question.

On Thu, Mar 12, 2009 at 8:51 AM, Qin Wu <sunseawq@huawei.com> wrote:
> Hi:
> I am glad to see the further work associated with RFC5296 has been developed well in the Diameter working group.
> As regarding whether to define a new Diameter application for ERP,  I would like to ask a question first:
> As we know, the normal authentication is quite different from Re-authentication. Re-authentication is usually applicable for the inter-authenticator handover scenarios. However, leave the inter-authenticator handover scenarios aside, when the existing keying materials are expired on the serving authenticator associated with the peer, which authentication mechanisms will be used to renew the lifetime of existing keying materials, normal authentication or Re-authentication?

 That's indeed a good question..
 In my understanding, the MSK lifetime is tied to the Diameter EAP session
 i.e. the AAA/EAP server provides a lifetime associated with this session and
keying material. When the lifetime expires, we have two options:

 1/ re-uses full EAP authentication with Diameter EAP

 2/ perform a reauthentication using ERP.


 If we use 1/, I don't see any problem.

 If we use 2/, and we have a new Diameter ERP app-id, a distinct AAA
server may be reached. And this AAA server is able to perform the
re-authentication
for this EAP client. How this is perform is out-of scope of our document but
we certainly need something to synchronize between the two AAA servers (the one
used for normal authentication and the other for reauthentication). This
new AAA server will now be in charged of the session.

> If the answer is both, how to distinguish between them?

 My impression is that both are possible. But what do you mean by
"how to distinguish" ? at which level ?


 Regards,

 -Julien

> If the answer is normal authentication, I would like to support defining new Diameter application for ERP.
>
> Best Regards!
>
> -Qin
> ----- Original Message -----
> From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
> To: "'Glen Zorn'" <glenzorn@comcast.net>; "'Julien Bournelle'" <julien.bournelle@gmail.com>
> Cc: <dime@ietf.org>; <hokey@ietf.org>
> Sent: Wednesday, March 11, 2009 12:57 AM
> Subject: Re: [HOKEY] [Dime] DiME ERP: new Application ID or not ?(non-roaming case)
>
>
> To quickly summarize for HOKEY WG members:
>
> We are currently trying to make the main design assumptions for the Diameter
> ERP work and we are currently leaning towards defining a new Diameter
> application for ERP that builds on top of Diameter EAP and makes use of the
> MIPv6 bootstrapping AVPs we have defined in
> draft-ietf-dime-mip6-split-16.txt.
>
> If you have an opinion about the Diameter ERP design please let us know
> ASAP. We would like to cast these things in stone pretty quickly.
> If you are planning to write code then drop us a note.
>
> Ciao
> Hannes
>
>>-----Original Message-----
>>From: hokey-bounces@ietf.org [mailto:hokey-bounces@ietf.org]
>>On Behalf Of Glen Zorn
>>Sent: 10 March, 2009 18:38
>>To: 'Julien Bournelle'; 'Hannes Tschofenig'
>>Cc: dime@ietf.org; hokey@ietf.org
>>Subject: Re: [HOKEY] [Dime] DiME ERP: new Application ID or
>>not ?(non-roaming case)
>>
>>Can we include the hokey WG in this discussion, please?
>>
>>> -----Original Message-----
>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf
>>> Of Julien Bournelle
>>> Sent: Tuesday, March 10, 2009 3:14 AM
>>> To: Hannes Tschofenig
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] DiME ERP: new Application ID or not ?
>>(non-roaming
>>> case)
>>>
>>> Hi hannes,
>>>
>>> On Sat, Mar 7, 2009 at 12:36 PM, Hannes Tschofenig
>>> <Hannes.Tschofenig@gmx.net> wrote:
>>> > I also have to add ...
>>> >
>>> > If you define a new Diameter Application ID then you have to decide
>>> which
>>> > application to use as a baseline. If you look at Section 5.1 of
>>> >
>>http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-16.tx
>>> > t
>>> then
>>> > you see that the Mobile IPv6 specific AVPs are optional in the
>>> Command Code
>>> > ABNF. Hence, building on EAP is probably not such a bad idea.
>>>
>>>  Not sure to understand your comment. If we define a new App-Id we
>>> won't build the application on Diameter EAP. It will be orthogonal.
>>> What do you mean ?
>>> >
>>> > There is also the question how much you want to say about Mobile
>>> > IPv6 bootstrapping in the ERP document.
>>>
>>>  Yes, Diameter ERP could be used along with Diameter EAP or Diameter
>>> Mobile IPv6.
>>>
>>>  Regards,
>>>
>>>  Julien
>>>
>>>
>>>
>>> >
>>> > Ciao
>>> > Hannes
>>> >
>>> >>-----Original Message-----
>>> >>From: Julien Bournelle [mailto:julien.bournelle@gmail.com]
>>> >>Sent: 04 March, 2009 12:03
>>> >>To: Hannes Tschofenig
>>> >>Cc: dime@ietf.org
>>> >>Subject: Re: [Dime] DiME ERP: new Application ID or not ?
>>> >>(non-roaming case)
>>> >>
>>> >>hi hannes,
>>> >>
>>> >> see inline,
>>> >>
>>> >>On Wed, Mar 4, 2009 at 9:14 AM, Hannes Tschofenig
>>> >><Hannes.Tschofenig@gmx.net> wrote:
>>> >>> Hi Julien,
>>> >>>
>>> >>> When we discussed this at the phone conference call (and the
>>> >>> discussion is also captured in the meeting minutes) then
>>I thought
>>> >>> that the conclusion was to define a new Diameter application
>>> >>for this exchange:
>>> >>>
>>> >>>
>>> >>> Peer Authenticator Server
>>> >>> ==== ============= ======
>>> >>>
>>> >>> [<-- EAP-Initiate/ -----
>>> >>> Re-auth-Start]
>>> >>> [<-- EAP-Request/ ------
>>> >>> Identity]
>>> >>>
>>> >>>
>>> >>> ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
>>> >>> Re-auth/ Re-auth/
>>> >>> [Bootstrap] [Bootstrap])
>>> >>>
>>> >>> <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
>>> >>> Re-auth/ Re-auth/
>>> >>> [Bootstrap] [Bootstrap])
>>> >>>
>>> >>> Note: [] brackets indicate optionality.
>>> >>>
>>> >>> Figure 2: ERP Exchange
>>> >>>
>>> >>> (The server in the figure above is the HOKEY server, a dedicated
>>> >>> entity.)
>>> >>>
>>> >>>
>>> >>> The initial EAP authentication is left untouched and, as Glen
>>> >>> explained us, there is the assumption that the AAA entities work
>>> >>> together with the HOKEY servers in a non-standardized way.
>>> >>To me that sounded like a good plan.
>>> >>>
>>> >>> Does this make any sense?
>>> >>
>>> >> Taking into accounts that we have one app-id for Diameter EAP (I
>>> >>would say NASREQ-EAP) AND soon another app-id for Diameter
>>> >>MIP6 (which also use EAP for authentication). It certainly make
>>> >>sense to not reuse the same App-ID for ERP if we want to
>>use ERP for
>>> >>the mip6 case.
>>> >>
>>> >> Let's see if others have opinion.
>>> >>
>>> >> Regards,
>>> >>
>>> >> Julien
>>> >>
>>> >>>
>>> >>>
>>> >>> The non-HOKEY expert
>>> >>> Hannes
>>> >>>
>>> >>> PS: I never said that this is specific document is going to
>>> >>be trivial
>>> >>> :-)
>>> >>>
>>> >>>>-----Original Message-----
>>> >>>>From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
>>> Behalf
>>> >>>>Of Julien Bournelle
>>> >>>>Sent: 04 March, 2009 09:05
>>> >>>>To: dime@ietf.org
>>> >>>>Subject: [Dime] DiME ERP: new Application ID or not ?
>>> >>>>(non-roaming case)
>>> >>>>
>>> >>>>Hi all,
>>> >>>>
>>> >>>> we try to solve the issue concerning the need for a new
>>> >>App-Id or not.
>>> >>>>
>>> >>>> The ERP protocol (RFC 5296) is to be used along with EAP. It
>>> >>>>basically defines two new EAP codes and uses keying material
>>> derived
>>> >>>>from a first EAP authentication.
>>> >>>>
>>> >>>> To start the discussion, let's take the non-roaming case.
>>> >>>>
>>> >>>> In non-roaming, we have first an EAP authentication using
>>> >>>>Diameter EAP.
>>> >>>> Then, for reauthentication using ERP, we have two messages
>>> >>>>(Request/Response) between NAS and the AAA/ERP server carrying
>>> >>>>EAP packets
>>> >>>>
>>> >>>> See (http://tools.ietf.org/html/rfc5296#page-6)
>>> >>>>
>>> >>>> So, either we reuse the Diameter EAP Application
>>(DER/DEA) or we
>>> >>>>define a new Diameter Application.
>>> >>>>
>>> >>>> If we use a new Diameter Application, a new Diameter
>>> >>session will be
>>> >>>>created and eventually a new Diameter server will be
>>reached. What
>>> >>>>bothers me in this case is that we basically perform a
>>> >>>>reauthentication for the same session which is primarly
>>> >>handled at the
>>> >>>>AAA/EAP server. So, i'm wondering what happens concerning
>>> >>>>Authorization Lifetime session etc..
>>> >>>>
>>> >>>> Note that I still don't have strong opinion and I'll be
>>> >>glad to hear
>>> >>>>opinions from others.
>>> >>>>
>>> >>>> Regards,
>>> >>>>
>>> >>>> Julien
>>> >>>>_______________________________________________
>>> >>>>DiME mailing list
>>> >>>>DiME@ietf.org
>>> >>>>https://www.ietf.org/mailman/listinfo/dime
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>
>>_______________________________________________
>>HOKEY mailing list
>>HOKEY@ietf.org
>>https://www.ietf.org/mailman/listinfo/hokey
>>
>
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
>