Re: [Dime] DiME ERP: new Application ID or not ? (non-roaming case)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [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 at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of
> Julien Bournelle
> Sent: Tuesday, March 10, 2009 3:14 AM
> To: Hannes Tschofenig
> Cc: dime at 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 at 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.txt
> 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 at gmail.com]
> >>Sent: 04 March, 2009 12:03
> >>To: Hannes Tschofenig
> >>Cc: dime at 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 at 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 at ietf.org [mailto:dime-bounces at ietf.org] On
> Behalf
> >>>>Of Julien Bournelle
> >>>>Sent: 04 March, 2009 09:05
> >>>>To: dime at 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 at ietf.org
> >>>>https://www.ietf.org/mailman/listinfo/dime
> >>>>
> >>>
> >>>
> >>
> >
> >
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.