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

From: Julien Bournelle <[email-masked]>
Date: Wed, 4 Mar 2009 08:05:03 +0100

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 4 Mar 2009 10:14:25 +0200

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? 

The non-HOKEY expert
Hannes

PS: I never said that this is specific document is going to be trivial :-) 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Julien Bournelle
>Sent: 04 March, 2009 09:05
>To: [email-masked]
>Subject: [Dime] DiME ERP: new Application ID or not ? 
>(non-roaming case)
>
>Hi all,
>
> 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.
>
> Then, for reauthentication using ERP, we have two messages 
>(Request/Response)  between NAS and the AAA/ERP server 
>carrying EAP packets
>
> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 4 Mar 2009 11:03:25 +0100

hi hannes,

 see inline,

>   Peer               Authenticator                      Server

 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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 5 Mar 2009 08:26:52 +0200

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:
>>
>>
>> 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.
>>
> 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.

You are pointing to some of the challenges we had during the Diameter extensibility discussions. 

With Diameter Mobile IPv6 you are referring to the HA<->AAA server interaction. If you want to cover that case as well and you would like to ensure that messages are correctly understood and correctly routed then you need to define an application that does all these different things. If you are OK with optional parts then you can just define your application and allow other AVPs, namely those from the Diameter Mobility stuff to get included. 

Ciao
Hannes

>> PS: I never said that this is specific document is going to 
>be trivial 
>> :-)
>>
>>>From: [email-masked] [mailto:[email-masked]] On Behalf 
>>>Of Julien Bournelle
>>>basically defines two new EAP codes and uses keying material derived 
>>>from a first EAP authentication.
>>>
>>>(Request/Response)  between NAS and the AAA/ERP server carrying EAP 
>>>packets
>>>
>>> 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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 7 Mar 2009 13:36:17 +0200

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. 

There is also the question how much you want to say about Mobile IPv6
bootstrapping in the ERP document.

Ciao
Hannes

>From: Julien Bournelle [mailto:[email-masked]] 
>Sent: 04 March, 2009 12:03
>To: Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [Dime] DiME ERP: new Application ID or not ? 
>(non-roaming case)
>
>hi hannes,
>
> see inline,
>

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 10 Mar 2009 11:14:14 +0100

Hi hannes,

> 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 ?
> bootstrapping in the ERP document.

 Yes, Diameter ERP could be used along with Diameter EAP or Diameter
Mobile IPv6.

 Regards,

 Julien

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 17:07:37 +0200

Hi Julien 

>> 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 ?

When you register a new Diameter Application ID then you need to decide 
* what Command Codes are needed
* what AVPs are carried inside these Command Codes. 

Many past Diameter application designs have answered that question in way
that they said: I re-use an existing application and extend it. 

This is essentially what I am suggesting here. You could build your new
application on top of Diameter Mobile IPv6 IKE (which is Diameter EAP +
Mobility AVPs) + your own ERP AVPs. 

> Yes, Diameter ERP could be used along with Diameter EAP or 
>Diameter Mobile IPv6.

Ciao
Hannes

>>>would say NASREQ-EAP) AND soon another app-id for Diameter
>make sense 
>>>to not reuse the same App-ID for ERP if we want to use ERP for the 
>>>mip6 case.
>>>
>>>>> In non-roaming, we have first an EAP authentication using 
>Diameter 
>>>>>EAP.
>carrying EAP

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 09:38:26 -0700

Can we include the hokey WG in this discussion, please?

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Julien Bournelle
> Sent: Tuesday, March 10, 2009 3:14 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Dime] DiME ERP: new Application ID or not ? (non-roaming
> case)
> 
> Hi hannes,
> 
> which
> then

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 18:57:52 +0200

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

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Glen Zorn
>Sent: 10 March, 2009 18:38
>To: 'Julien Bournelle'; 'Hannes Tschofenig'
>Cc: [email-masked]; [email-masked]
>Subject: Re: [HOKEY] [Dime] DiME ERP: new Application ID or 
>not ?(non-roaming case)
>
>(non-roaming
>> > There is also the question how much you want to say about Mobile 
>> > IPv6 bootstrapping in the ERP document.
>> 
>> >>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.
>> >>
>> >>>>Diameter EAP.
>> >>>>(Request/Response)  between NAS and the AAA/ERP server carrying 
>> >>>>EAP packets
>> >>>>
>HOKEY mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/hokey
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 15:51:49 +0800

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?
If the answer is both, how to distinguish between them?
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" <[email-masked]>
To: "'Glen Zorn'" <[email-masked]>; "'Julien Bournelle'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 11, 2009 12:57 AM
Subject: Re: [HOKEY] [Dime] DiME ERP: new Application ID or not ?(non-roaming case)

Ciao
Hannes

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 12 Mar 2009 10:06:46 +0100

Hi Qin,

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

> 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-aut…

 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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 11:13:37 +0200

> If we use 2/, and we have a new Diameter ERP app-id, a 
>distinct AAA server may be reached. 

If I understood Glen correctly from previous conversations then the Diameter
ERP re-authentication does not happen with a AAA server but with a HOKEY
server. Hence, I am not sure that there is an issue. 

Ciao
Hannes

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 17:30:40 +0800

Hi:
If my understanding is correct, the ERP re-authentication with a AAA server through a Hokey server will happen in the intial EAP exchange or in  the bootstrapping phase.
e.g., when the peer firstly enter into one visited AAA domain away from the home AAA server, intial EAP exchange between the peer and home AAA server is required. However when the peer move between two adjacent authenticator within the same AAA domain,  the ERP re-authentication does not happen with a AAA server but with a local hokey server which is a optimized approach to reduce handoff latency.

Best Regards!
-Qin

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 12 Mar 2009 10:45:47 +0100

Hi all,

 I have to correct myself. Sorry about that.

>  2/ perform a reauthentication using ERP.

 Basically I don't think we can use ERP here because if the MSK, EMSK
lifetime expires, the
whole keying material for ERP also expires. So, correct me if I'm
wrong, but when the existing keying
materials (derived at initial EAP authentication) expires, a normal
authentication should occur.

 Regards,

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 12 Mar 2009 10:49:56 +0100

Hi hannes,

> server. Hence, I am not sure that there is an issue.

 yes, you're right. But for me a HOKEY server is like an EAP server. It may be
collocated or not with a AAA server but the NAS uses Diameter protocol so
the message is a AAA message which is going to reach a AAA server (colocated
or not with an HOKEY server).

 Not that I was not pointing this as an issue.

 Regards,

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 12 Mar 2009 10:53:16 +0100

Hi Qin,

> e.g., when the peer firstly enter into one visited AAA domain away from the home AAA server, intial EAP exchange between the peer and home AAA server is required. However when the peer move between…

 hmm, same comment as for hannes. The local hokey server has a AAA
part (colocated or not). We are using a AAA protocol between the NAS
and the HOKEY server, so by extension, the HOKEY server as a AAA part
(colocated or not).

 Regards,

 Julien

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 17:54:31 +0800

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

Hi Qin,

[Qin] Yes, I agree.

[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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 12:07:00 +0200

Hi Qin, 

>Hi:
>If my understanding is correct, the ERP re-authentication with 
>a AAA server through a Hokey server will happen in the intial 
>EAP exchange or in  the bootstrapping phase.

If I understood Glen correctly so far then this is not the model. 
The Diameter (or RADIUS signaling for that matter) messages are not routed
through the HOKEY server but the AAA entities interact with the HOKEY
server(s) using some other protocol mechanism. To me that sounded like a
reasonable approach. 

>e.g., when the peer firstly enter into one visited AAA domain 
>away from the home AAA server, intial EAP exchange between the 
>peer and home AAA server is required.

Are you talking now about the regular Diameter EAP exchange. 

>  However when the peer 
>move between two adjacent authenticator within the same AAA 
>domain,  the ERP re-authentication does not happen with a AAA 
>server but with a local hokey server which is a optimized 
>approach to reduce handoff latency.
Currently, this is the HOKEY re-authentication exchange. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 12:10:09 +0200

Hi Julien, 

>>>server may be reached.
>> If I understood Glen correctly from previous conversations then the 
>> Diameter ERP re-authentication does not happen with a AAA server but 
>> with a HOKEY server. Hence, I am not sure that there is an issue.
>
> yes, you're right. But for me a HOKEY server is like an EAP 
>server. It may be collocated or not with a AAA server but the 
>NAS uses Diameter protocol so the message is a AAA message 
>which is going to reach a AAA server (colocated or not with an 
>HOKEY server).
Maybe that's just a terminology issue but it causes confusion regarding the
way how the messages are routed. 
In DIME we had this discussion regarding the routing of messages and Glen
clarified these aspects. 

I would also think it is extremely important to put a sort of architecture
picture in the Diameter ERP document that illustrates how the messages are
routed and how the entities relate to each other so that we aren't always
talking past each other. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 12:39:51 +0200

The figures in http://www.ietf.org/rfc/rfc5296.txt are pretty confusing. 

For example, Figure 2 talks about a 'server' rather than saying that this is
the ERP server. 

Figure 3 is even more confusing as it shows a standard EAP exchange but then
has a ER server in there. 

  Peer        EAP Authenticator     Local ER Server     Home EAP Server
   ====        =================     ===============     ===============

   <-- EAP-Request/ --
        Identity

   -- EAP Response/-->
        Identity      --AAA(EAP Response/-->
                            Identity)       --AAA(EAP Response/ -->
                                                      Identity,
                                                [DSRK Request,
                                              domain name])

   <------------------------ EAP Method exchange------------------>

                                            <---AAA(MSK, DSRK, ----
                                                   EMSKname,
                                                 EAP-Success)

                       <---  AAA(MSK,  -----
                            EAP-Success)

   <---EAP-Success-----

            Figure 3: Local ERP Exchange, Initial EAP Exchange 

I think that the figures have to look like: 

============================================================================
=======

   EAP Peer           Diameter EAP Client               EAP Server
   ========           =================                 ==========

    <--- EAP-Request/ ------
            Identity

    ----- EAP Response/ --->
            Identity          ---AAA(EAP Response/Identity)-->

    <--- EAP Method ------->  <------ AAA(EAP Method -------->
           exchange                    exchange)

                              <----AAA(MSK, EAP-Success)------

    <---EAP-Success---------

                       Figure 1: EAP Authentication

[This figure does not have any ERP stuff in there. That does not seem to be
right or at least not relevant then.]

   Peer               Diameter ERP Client                ERP Server
   ====               =============                      ======

    [<-- EAP-Initiate/ -----
        Re-auth-Start]
    [<-- EAP-Request/ ------
        Identity]

                          Figure 2: ERP Exchange

[New Diameter ERP application in action.]

 Peer        Diameter ERP/EAP      Local EAP Proxy/    Home EAP/ERP
 ====        =====Client======     ===ERP server==     ====Server=====

 <-- EAP-Request/ --
      Identity

 -- EAP Response/-->
      Identity      --AAA(EAP Response/-->
                          Identity)       --AAA(EAP Response/ -->
                                                    Identity,
                                              [DSRK Request,
                                            domain name])

 <------------------------ EAP Method exchange------------------>

                                          <---AAA(MSK, [DSRK, ----
                                                 EMSKname],
                                               EAP-Success)

                     <---  AAA(MSK,  -----
                          EAP-Success)

 <---EAP-Success-----

            Figure 3: Local ERP Exchange, Initial EAP Exchange

[Here we assume that there is some communication going on between the
Diameter EAP proxy and the ERP server in the local network. 
For editorial reasons we do not show the two entities separately but maybe
we should. The same is true for the Diameter EAP server and the ERP server.

Graphically, this could be shown as: 

  Diameter EAP +-------------+   Diameter EAP   +-------------+
               |             |                  |             |
 <------------>| Local       |<---------------->| Home        |
               | Diameter    |                  | Diameter    |
               | EAP Proxy   |                  | EAP Server  |
               |             |                  |             |
               +-------------+                  +-------------+
                      ^                                ^
                   (a)| proprietary        proprietary |(b)
                      v                                v
               +-------------+                  +-------------+
  Diameter ERP |             |    Diameter ERP  |             |
               | Local       |                  |  Home       |
 <------------>| Diameter    |<---------------->|  Diameter   |
               | ERP Server  |                  |  ERP Server |
               |             |                  |             |
               +-------------+                  +-------------+

It might be useful to say what information is exchanged at (a) and (b) and
when in the protocol exchange.

]

   Peer                ER Authenticator            Local ER Server
   ====                ================            ===============

   [<-- EAP-Initiate/ --------
        Re-auth-Start]
   [<-- EAP-Request/ ---------
        Identity]

    ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
          Re-auth                        Re-auth)

    <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
          Re-auth                        Re-auth)

                       Figure 4: Local ERP Exchange

[Is this figure from a Diameter ERP routing the same as Figure 2?]

So, I suggest to get the high level messaing right before starting with the
details

Ciao
Hannes

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 19:02:20 +0800

Hi, Hannes:
Thank for your reply. please see inline.
-Qin
----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "'Qin Wu'" <[email-masked]>; "'Julien Bournelle'" <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 12, 2009 6:07 PM
Subject: RE: [HOKEY] [Dime] DiME ERP: new Application ID or not ?(non-roaming case)

> server(s) using some other protocol mechanism. To me that sounded like a

[Qin]  I agree it is a good way to make AAA entities interact with Hokey server using existing mechanism.
As regarding whether hokey server can be viewed as proxy AAA or an independent ER server, I am not sure. Maybe this is what DiME ERP 
needs to find out or define.

> Are you talking now about the regular Diameter EAP exchange. 

[Qin]  It is not regualr Diameter EAP exchange but ERP for intial EAP exchange.
As regarding ERP for intial EAP exchange, please refer to the figure 3 of RFC5296.

> Currently, this is the HOKEY re-authentication exchange. 

[Qin] You understanding is correct.

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 19:15:38 +0800

I agree, to my knowledge, the hokey server plays the AAA part. In the RFC 5296, it should be ER server for ERP if my understanding is correct.
----- Original Message ----- 
From: "Julien Bournelle" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Hannes Tschofenig" <[email-masked]>; "Glen Zorn" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 12, 2009 5:53 PM
Subject: Re: [HOKEY] [Dime] DiME ERP: new Application ID or not ?(non-roamingcase)

Hi Qin,

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 12 Mar 2009 20:44:42 +0900

Hi,

>                | EAP Proxy   |                  | EAP Server  |
I agree with this figure -- I mean, it reflects my current understanding
of the architecture.
In my understanding of Glen's explanation during Interim Meeting, there
would be a "HOKEY server" as a separate entity, and both the local
Diameter EAP Proxy and ERP proxy talk to this HOKEY server using this
proprietary protocol (a).

Note that the proprietary exchange (a) with EAP proxy is necessary only
for implicit bootstrapping, which as you know I believe should be avoided.

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 12 Mar 2009 20:49:00 +0900

Hi,

Julien Bournelle a écrit :
> lifetime expires, 

I have a couple of questions related to this, I could not find the
answer yet:

- Do MSK and EMSK have the same lifetime?
- Do the peer and the server agree on the lifetime(s) of these keys
during EAP exchange?

Sorry if these are trivial questions... I believe anyway they are
important to help understanding the issue raised here.

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 20:27:43 +0800

Hi, Hannes:
Let me try to answer the question you rasised.
-Qin
----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "'Qin Wu'" <[email-masked]>; "'Julien Bournelle'" <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 12, 2009 6:39 PM
Subject: DiME ERP - Getting the message flows right

> For example, Figure 2 talks about a 'server' rather than saying that this is
[Qin] Figure 2 is a high level model for ERP, so the server is a generic server, 
in the initial EAP exchange for ERP as described in figure 3, the sever can divided into two part, one is local ER server, the other is home EAP server.
in the local ERP exchange as described in figure 4, the server can be viewed as local ER server.
> has a ER server in there. 

[Qin] I agree it is a little ambiguity. I would like to call the figure 3 as "ERP for initial EAP exchange". It is quite similar to the regular EAP authentication,
what's the difference with regular EAP authentication is that the figure 3 is applicable for some certain use cases where the peer moves across the different visited AAA domain and it is first time for the peer to enter into one new AAA domain. In this scenarios, the keying materials between the peer and the authenticator to which the peer firstly attached in this new AAA domain needs to be re-generated.

>  Peer        EAP Authenticator     Local ER Server     Home EAP Server

[Qin] Figure 1 is the full EAP authentication as described in the section 3. It is not ERP.

>   Peer               Diameter ERP Client                ERP Server
[Qin] I agree, Bootstrapping is one scenario to explain why we need ERP?  However I wonder for the regular EAP authentication,
We also need to consider bootrapping case, is that right?

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 16:40:06 +0200

Hi Sebastien, 

>> It might be useful to say what information is exchanged at 
>(a) and (b) 
>> and when in the protocol exchange.
>>   
>I agree with this figure -- I mean, it reflects my current 
>understanding of the architecture.
>In my understanding of Glen's explanation during Interim 
>Meeting, there would be a "HOKEY server" as a separate entity,

Separate logical entity. 
 
>and both the local Diameter EAP Proxy and ERP proxy talk to 
>this HOKEY server using this proprietary protocol (a).
>
>Note that the proprietary exchange (a) with EAP proxy is 
>necessary only for implicit bootstrapping, which as you know I 
>believe should be avoided.
Good that you mention this. I believe that this aspect should be described
as well. It could be covered in a description that illustrates the different
stages of the ERP messaging and the variations that exist together with the
information that actually needs to be made available to the ERP server. 

What is also important with respect to the message routing, which is not yet
covered in the current figures is that the Diameter EAP exchange is routed
based on that specific application ID and Diameter ERP would be routed on
this newly defined application ID. This is quite important to capture in
this discussion and the figure above captures this aspect in some fashion. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Mar 2009 16:47:41 +0200

Hi Qin, 

>the section 3. It is not ERP.

Not sure how relevant a pure EAP method exchange is. 

>[Qin] I agree, Bootstrapping is one scenario to explain why we 
>need ERP?  However I wonder for the regular EAP authentication,

We need to cover all the ERP scenarios. 

In the DIME document we don't have to explain why ERP is useful and why it
is needed. 
That info should be contained in the HOKEY documents. 

Ciao
Hannes

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Mar 2009 14:58:59 +0800

Hi,Sebastien:
The MSK and EMSK both result from EAP authentiction and are used to derive other keys.
Also both MSK and EMSK are shared between the peer and the AAA server. So MSK has the same lifetime as EMSK, what's more, the derived keys also has the same lifetime as MSK or EMSK.

As regarding the second question, since the keying materials is established through the EAP exchange between the peer and the server and shared between the corresponding two entities. I am sure the peer and the AAA server should agree on the lifetime of these keys firstly. With respect to how much is the lifetime of keys, it mostly depends on the specific implementation.

-Qin
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Julien Bournelle" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 12, 2009 7:49 PM
Subject: Re: [Dime] [HOKEY] DiME ERP: new Application ID or not ?(non-roaming case)

Hi,

Best regards,
Sebastien.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 Mar 2009 16:22:06 -0700 (PDT)

Hi Hannes,
  Fig. 1 in RFC 5296 is included to introduce full EAP authentication to the reader so that EAP Re-authentication Protocol can be presented.

  I agree with you that in Fig. 2 should have indicated ER Server not just Server, but I think this has been clarified in the text.

  Shouldn't it be ER Server but not ERP Server? ER Server is defined in the terminology section of RFC 5296.

Regards,

Behcet

________________________________
From: Hannes Tschofenig <[email-masked]>
To: Qin Wu <[email-masked]>; Julien Bournelle <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Thursday, March 12, 2009 5:39:51 AM
Subject: [Dime] DiME ERP - Getting the message flows right

  <-- EAP-Request/ --
        Identity

  -- EAP Response/-->

                                            <---AAA(MSK, DSRK, ----
                                                  EMSKname,
                                                EAP-Success)

                      <---  AAA(MSK,  -----
                            EAP-Success)

  <---EAP-Success-----

    <--- EAP-Request/ ------
            Identity

    ----- EAP Response/ --->

    <---EAP-Success---------

    [<-- EAP-Initiate/ -----
        Re-auth-Start]
    [<-- EAP-Request/ ------
        Identity]

                          Figure 2: ERP Exchange

<-- EAP-Request/ --
      Identity

-- EAP Response/-->

                                          <---AAA(MSK, [DSRK, ----
                                                EMSKname],
                                              EAP-Success)

                    <---  AAA(MSK,  -----
                          EAP-Success)

<---EAP-Success-----

]

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 14 Mar 2009 11:00:16 +0200

Hi Behcet, 

	Hi Hannes,
	  Fig. 1 in RFC 5296 is included to introduce full EAP
authentication to the reader so that EAP Re-authentication Protocol can be
presented.
	 
[hannes] OK. Makes sense in RFC 5296 but not in the Diameter document, I
believe. 

	  I agree with you that in Fig. 2 should have indicated ER Server
not just Server, but I think this has been clarified in the text.
	 
[hannes] Maybe it is but still there is still a lot of confusion on how the
message routing works and these details make it even more difficult to
understand. 
	 
	  Shouldn't it be ER Server but not ERP Server? ER Server is defined
in the terminology section of RFC 5296. 

[hannes]	Correct. 
	 
Ciao
Hannes

	Regards,
	 
	Behcet

	From: Hannes Tschofenig <[email-masked]>
	To: Qin Wu <[email-masked]>; Julien Bournelle
<[email-masked]>
	Cc: [email-masked]; [email-masked]
	Sent: Thursday, March 12, 2009 5:39:51 AM
	Subject: [Dime] DiME ERP - Getting the message flows right
	
	The figures in http://www.ietf.org/rfc/rfc5296.txt are pretty
confusing. 
	
	For example, Figure 2 talks about a 'server' rather than saying that
this is
	the ERP server. 
	
	Figure 3 is even more confusing as it shows a standard EAP exchange
but then
	has a ER server in there. 
	
	  Peer        EAP Authenticator    Local ER Server    Home EAP
Server
	  ====        =================    ===============
===============
	
	  <-- EAP-Request/ --
	        Identity
	
	  -- EAP Response/-->

	                                            <---AAA(MSK, DSRK, ----
	                                                  EMSKname,
	                                                EAP-Success)
	
	                      <---  AAA(MSK,  -----
	                            EAP-Success)
	
	  <---EAP-Success-----

	
	
	    <--- EAP-Request/ ------
	            Identity
	
	    ----- EAP Response/ --->

	
	    <---EAP-Success---------

	[This figure does not have any ERP stuff in there. That does not
seem to be
	right or at least not relevant then.]

	    [<-- EAP-Initiate/ -----
	        Re-auth-Start]
	    [<-- EAP-Request/ ------
	        Identity]

	
	
	                          Figure 2: ERP Exchange

	
	<-- EAP-Request/ --
	      Identity
	
	-- EAP Response/-->

	                                          <---AAA(MSK, [DSRK, ----
	                                                EMSKname],
	                                              EAP-Success)
	
	                    <---  AAA(MSK,  -----
	                          EAP-Success)
	
	<---EAP-Success-----

	
	
	[Here we assume that there is some communication going on between
the
	Diameter EAP proxy and the ERP server in the local network. 
	For editorial reasons we do not show the two entities separately but
maybe
	we should. The same is true for the Diameter EAP server and the ERP
server.

	
	
	It might be useful to say what information is exchanged at (a) and
(b) and
	when in the protocol exchange.
	
	]

	

	

	So, I suggest to get the high level messaing right before starting
with the
	details
	
	Ciao
	Hannes

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 17 Mar 2009 15:05:17 +0900

Hi,

Thank you for yor answer, and sorry for replying so late myself.

> As regarding the second question, since the keying materials is established through the EAP exchange between the peer and the server and shared between the corresponding two entities. I am sure the…

Since ERP would use material derived from the EMSK, I guess that when
the MSK is expiring then an ERP exchange cannot occur, and therefore we
don't really have a choice here, but to use full EAP.

This brings the following conclusion (please correct me if I am wrong):
ERP is only used when the peer attaches to a new authenticator while
having a valid authentication material (EMSK).

I am not sure anyway how this is related to the {EAP or new} application
ID problem.

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 17 Mar 2009 15:28:05 +0900

Hi again,

After trying to capture the new mechanism (based on a new application
id) in a document, I have encountered an issue and I am not sure what is
the proper way to solve it.

When the local ER server (aka HOKEY server in the visited domain) needs
to retrieve the rDSRK material (i.e. it was not bootstrapped already)
this material can not be provided directly by the Home ER server,
because of the key hierarchy:

EMSK (in Home EAP server)
|
+- rRK (in Home ERP server)
|
+- DSRK (in Home EAP server or a local server)
    |
   +- rDSRK (in local ERP server)

There are two ways to get this material:
- through the home ERP server (in this case the home ER server receives
visited domain specific keying material, which may not be good)
- directly with an exchange between local ERP server and home EAP server.

This second option would be shown as follow ( exchange (c) ):

>                |             |            ----->|             |
>                +-------------+           /      +-------------+
>                       ^                 /              ^
>                    (a)| proprietary   (c)  proprietary |(b)
>                       v               /                v
>                +-------------+ <-----/          +-------------+
>   Diameter ERP |             |                  |             |
>                | Local       |    Diameter ERP  |  Home       |

Note that the exchange (b) is needed anyway for the case when the peer
is in its home domain.

Does anybody have some comments on this?

Thank you,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 17 Mar 2009 16:45:18 +0900

(Sorry for replying on myself)

I think a lot of confusion comes actually from the name "Home AAA
server" in RFC5296, section 5.1 (ERP bootstrapping). Does this refer to
EAP or ERP server? Or does this assume these server are the same logical
entity?

Thank you,
Sebastien.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Mar 2009 10:37:21 +0200

Hmmm. Interesting. 

>From your description I would go for a direct exchange between local ERP
server and home EAP server. 

>Behalf Of ext Sebastien Decugis
>Sent: 17 March, 2009 08:28
>To: Hannes Tschofenig
>Subject: Re: [Dime] DiME ERP - Getting the message flows right
>
>Hi again,
>
>id) in a document, I have encountered an issue and I am not 
>sure what is the proper way to solve it.
>
>When the local ER server (aka HOKEY server in the visited 
>domain) needs to retrieve the rDSRK material (i.e. it was not 
>bootstrapped already) this material can not be provided 
>directly by the Home ER server, because of the key hierarchy:
>
>- through the home ERP server (in this case the home ER server 
>receives visited domain specific keying material, which may 
>not be good)
>Note that the exchange (b) is needed anyway for the case when 
>the peer is in its home domain.
>
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Mar 2009 21:05:26 +0800

Hi,
Sorry for the late reply.
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Julien Bournelle" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 17, 2009 2:05 PM
Subject: Re: [Dime] [HOKEY] DiME ERP: new Application ID or not ?(non-roaming case)

> having a valid authentication material (EMSK).
[Qin]: 
According to the RFC 5296, ERP is also used when ERP bootstrapping happens, 
Here ERP bootstapping is quite different from MIPv6 bootstrapping. What ERP bootstrapping means the how the DSRK is generated and distributed to the peer via EAP basic four message (i.e., EAP request/response, EAP success/failure)

On the other hand, ERP is also used in the inter-authenticator handover scenarios in  which EAP Initiate/Finish is used to complete Re-authentiation.

> I am not sure anyway how this is related to the {EAP or new} application

[Qin]: 
As regarding to how this is related to the application, I think ERP mechanism is quite different from regular EAP authentication mechanism. ER server can be 
indpendent AAA server which can be proprietary.