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

[Qin Wu <[e-mail]>]

Hi, Julien:
Thank for your quick answer. please see inline.
-Qin
----- Original Message ----- 
From: "Julien Bournelle" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Hannes Tschofenig" <[e-mail]>; "Glen Zorn" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Thursday, March 12, 2009 5:06 PM
Subject: Re: [HOKEY] [Dime] DiME ERP: new Application ID or not ?(non-roamingcase)


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 <[e-mail]> 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.

[Qin] Yes, I agree.

 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 ?

[Qin] What I conern here is if both  possible, how to make the AAA server choose between 1/ and 2/, why not use 1/, i.e., re-use full EAP authentication with Diameter EAP. Is it neccessary for both full EAP authenticatioin and ERP to do the same thing, i.e., renew the lifetime of keying materials.
As regarding "how to distinguish", what i mean is how to make the AAA server distinguish between 1/ and 2/, upon receiving AAA request with EAP request as payload from the authenticator. It should be in the AAA level. Is it necssary for the AAA to distinguish between 1/ and 2.

On the other hand, I think ERP is designed to establish the keying materials for inter-authenticator handover scenario which is a optimized approach in contrast with the full EAP authentication, So in this sense, it is a good idea to define new Diameter application for ERP to make difference.
Thanks!


 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" <[e-mail]>
> To: "'Glen Zorn'" <[e-mail]>; "'Julien Bournelle'" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]]
>>On Behalf Of Glen Zorn
>>Sent: 10 March, 2009 18:38
>>To: 'Julien Bournelle'; 'Hannes Tschofenig'
>>Cc: [e-mail]; [e-mail]
>>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: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of Julien Bournelle
>>> Sent: Tuesday, March 10, 2009 3:14 AM
>>> To: Hannes Tschofenig
>>> Cc: [e-mail]
>>> 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
>>> <[e-mail]> 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:[e-mail]]
>>> >>Sent: 04 March, 2009 12:03
>>> >>To: Hannes Tschofenig
>>> >>Cc: [e-mail]
>>> >>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
>>> >><[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf
>>> >>>>Of Julien Bournelle
>>> >>>>Sent: 04 March, 2009 09:05
>>> >>>>To: [e-mail]
>>> >>>>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
>>> >>>>[e-mail]
>>> >>>>https://www.ietf.org/mailman/listinfo/dime
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> _______________________________________________
>>> DiME mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dime
>>
>>_______________________________________________
>>HOKEY mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/hokey
>>
>
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hokey
>