Subject: Re: [HOKEY] Changes proposals for rfc5296bis - 1: simplify bootstrapping

From: Qin Wu <[email-masked]>
Date: Thu, 18 Nov 2010 10:17:01 +0800

Hi,
Summarize what we discuss here, several things we need to agree upon:
1. Do you think the user(i.e., the peer) always know the home domain name whereever the user moves around?
2. Do you think the user usually will not change the home domain name, even the user could change the home domain name, the user should be notified about it?
3. Do you think the user know when to do bootstrapping and when not?
4. Do you think the bootstrapping means that the user should go back to the home domain?

As described in the section 4.3 of RFC5296, it said:
"
   In case of ERP with the
   home ER server, the peer uses the realm from its original NAI; in
   case of a local ER server, the peer uses the domain name received at
   the lower layer or through an ERP bootstrapping exchange.

"  

Also as described in the RFC5296, it said:
"
The following steps describe the ERP explicit bootstrapping process:

   o  The peer sends the EAP-Initiate/Re-auth message with the
       bootstrapping flag turned on.  
"
>From the description above, it seems to me the user or peer know when to do bootstrapping.,e.g, starup of the mobile device or inter-domain handover.
 Also the user know when he move within the home domain and when not.

As for bootstrapping means that the user should go back to the home domain, my answer is Yes. becos it is the peer who initiate bootstrapping process by adding bootstapping flag to  the EAP-Initiate message,
this 'B' flag not only can trigger the local ER server to request DSRK from the home EAP server, but also trigger the home EAP server return the local domain name provided by local ER server to the peer. The peer can derive
appropriate DSRK, DS-rRK, DS-rIK, and keyName- NAI. So in my understanding the 'B' flag means a lot to the peer and does has its value.

Also I think it is both the peer and the ER server who needs bootstrapping. that is why the peer needs to go back to home EAP server to complete bootstapping.

What do you think of it?

Regards!
-Qin
----- Original Message ----- 
From: "Qin Wu" <[email-masked]>
To: "Sebastien Decugis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 28, 2010 2:13 PM
Subject: Re: [HOKEY] Changes proposals for rfc5296bis - 1: simplify bootstrapping

> Hi,
> ----- Original Message ----- 
> From: "Sebastien Decugis" <[email-masked]>
> To: "Qin Wu" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, October 28, 2010 9:58 AM
> Subject: Re: [HOKEY] Changes proposals for rfc5296bis - 1: simplify bootstrapping
> 
> 
>> Hi Qin,
>> 
>> Thank you for your comments. As usual, please find my answers inline.
>> 
>>> [Qin]: I am okay with  your proposal in two folds mentioned above.
>>> for the case when local ER server doesn't have keying material, I think it will make ERP more simple to let the local ER server
>>>  send DSRK request to home EAP server instead of home ER server. becos if you let home ER server get invovlve in
>>> this bootstapping, the home ER server also need to request DSRK from Home EAP server. Therefore
>>> allow ERP with only one ER server would be more desirable.
>> 
>> I am glad we agree on the goal. The remaining is a proposal of the
>> changes that are needed to achieve this goal. There are probably other
>> ways of doing it also.
> 
> [Qin]: Yes.
> 
>>>> I think these changes require minimal modifications to the ERP protocol :
>>>> - deprecate the 'B' flag, since it becomes useless
>>> [Qin]: I am not sure deprecating 'B' flag  is a good idea.
>>> 'B'flag has its value when peer needs to startup device or handover to different visited domain.
>> Well, I don't see what value it has, if the (local) ER server in the new
>> domain is able to ask the DSRK in any case, 'B' flag or not.
>> Maybe I am missing another use for this flag?
> 
> [Qin]: 'B' flag has two purpose:
> (a). Trigger local ER server to Request DSRK from the home EAP server
> (b). Trigger the peer to Request the local domain name by sending EAP-Initiate, 
> and then the peer can derive the appropriate DSRK, DS-rRK, DS-rIK based on this local domain name presented in EAP-Finish message
> 
> The case you are missing is when there is no local ER server in the new domain, the peer only can perform EAP exchange with the home
> ER Server.
> 
> Therefore the 'B' has its value.
> 
>>>> - always include the name of the home domain in ERP requests, so that
>>>> (local) ER server can bootstrap when needed
>>> [Qin]: The home domain is part of keyName-NAI. So you need not worry about this.
>> That is not true. The keyName-NAI is of the form EMSKname@ERrealm where
>> ERrealm is the domain of the ER server. In case this ER server is in the
>> visited domain ("local" ER server) then the ERrealm is the local domain,
>> and there is no information about what the home domain is.
> 
> [Qin]: So keyName-NAI needs to be recalculated based on the local domain name instead of home domain name.
> I agree with this.
> 
>>>> - always include the local domain name known by the peer, if any, in
>>>> the request. 
>>> [Qin]: The peer may not know the local domain name, but authenticator or local ER server may know.
>> 
>> That is true. However, since this local domain name is used by the peer
>> to compute the DSRK and then the rIK that protects the message, it is
>> important that the peer includes the information about what domain it
>> used for this derivation. The authenticator and ER server are not able
>> to guess what the peer has used...
> 
> [Qin]: This is new behavior unspecifed in the RFC5296, we may need to look at it.
> 
>>> This local domain name is either acquired by a different
>>>> mean (such as L2 mechanism) or reused from the previous authentication,
>>>> even if the new attachment point might be in a different domain. This
>>>> local domain name is used to derive the rIK and rRK, so it is important
>>>> to provide it (if none is included, home domain name is used). The ER
>>>> server that receives this request compares to its own domain name. If
>>>> there is a match, it can complete the ERP exchange locally (provided
>>>> that it already have received the DSRK). Otherwise, it adds its own
>>>> domain name (if different) in the request and forwards to the home
>>>> domain. The home server can complete the ERP exchange and authenticate
>>>> the peer using the peer's provided domain name, and also derive the DSRK
>>>> for the ER server (bootstrapping) using the ER server's provided domain
>>>> name.
>>> [Qin]: RFC5296 hasn't specified such behavior. 
>> True, hence the *Changes proposal* title of this mail ;-)
> 
> [Qin]: Okay. I got it.
> 
>>> We need to discuss this in the upcoming Beijing meeting.
>> Agreed. I wanted to see if there is any feedback on the mailing-list. If
>> some people show interest, I can give a presentation on these changes
>> during Beijing meeting. But if nobody cares for improving ERP, why
>> should I do it ?
> 
> [Qin]: Okay, that's great.
> 
>>>  This "new" domain name is included in the answer so that the peer
>>>> will use this new domain name in later exchanges.
>>>
>>> [Qin]: In my opinion, No matter how the new doamin name is changed, the home domain name will not be changed and replaced
>>> by other "new" domain name.
>> It is not what I meant. All peer-issued messages should always contain:
>> - the home domain (which does not change for the peer)
>> - the local domain to the best knowledge of the peer. This one may be
>> updated after an ERP exchange, as I described.
> 
> [Qin]: Good point.
> 
>> 
>> I know this is quite a change compared to current mechanism, but it is
>> also more robust and much simpler to understand.
>> Since rfc5296 is being revised, I believe this would be a good time to
>> make such useful changes...
>>
>> Best regards,
>> Sebastien.
>> 
>> 
>> -- 
>> Sebastien Decugis
>> Research fellow
>> Network Architecture Group
>> NICT (nict.go.jp)
>>
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 18 Nov 2010 13:27:43 +0900

Hi,

Thank you for this summary. My comments are inline.

> 1. Do you think the user(i.e., the peer) always know the home domain name whereever the user moves around?
Yes, the HOME domain name is always known.

> 2. Do you think the user usually will not change the home domain name, even the user could change the home domain name, the user should be notified about it?
Yes, the HOME domain is constant for a user (at least with regards to
ERP). Users with registration in several domains are outside the scope
of ERP.

> 3. Do you think the user know when to do bootstrapping and when not?
I think with current mechanism this is an issue, because the user
*cannot* know when to do bootstrapping or not. The change I proposed
during the Beijing meeting is aimed at removing this issue, by making
the bootstrapping transparent to the user.

> 4. Do you think the bootstrapping means that the user should go back to the home domain?
No, the bootstrapping should not involve the user in my opinion.

> From the description above, it seems to me the user or peer know when to do bootstrapping.,e.g, starup of the mobile device or inter-domain handover.
I disagree. The text roughly says that the peer should initiate an
explicit bootstrapping message when the local domain ER server is not
bootstrapped already. It does not say how the peer is supposed to know
if it is the case.

>  Also the user know when he move within the home domain and when not.
Here you assume that the peer always know the domain name of the access
point it is attaching to. There is no such assumption in RFC5296.

> Also I think it is both the peer and the ER server who needs bootstrapping. that is why the peer needs to go back to home EAP server to complete bootstapping.
I disagree. The peer only needs to know the local domain name, and if an
ER server is available in this domain. This information should be
provided *before* the ERP message is sent. It is not the case currently,
and this is why I am proposing some changes.

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Nov 2010 14:03:21 +0800

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 18, 2010 12:27 PM
Subject: Re: [HOKEY] Changes proposals for rfc5296bis - 1: simplify bootstrapping

> the bootstrapping transparent to the user.

[Qin]: I don't think there is anything break here.  There are many ways for the user to know when to do bootstapping, 
e.g., as you mentioned, the user can rely on EAP-Initiate-Reauth-Start to get the local domain name.
Even this ways fails, the user can rely on Explicit ERP bootstrapping or subsequent ERP exchange or 
DHCP based Local domain name discovery to learn the local domain name.
As we discussed before, the user can try the domain name he knows, if fails, the user can use home domain name and fall back to
the normal full EAP authentication or Explicit ERP bootstrapping.
 
> No, the bootstrapping should not involve the user in my opinion.

[Qin]: This is our main difference on this question.
As described in RFC5296, The user should send EAP-Initiate Message with Bootstapping flag on, 
it means the peer know when to bootstrapping, e.g., using EAP-Initiate Re-Auth Start message as you mentioned.
the user I mentioned here is the peer.

> bootstrapped already. It does not say how the peer is supposed to know

[Qin]: See above.

> and this is why I am proposing some changes.

[Qin]: I get your point, but in the current RFC5296, the user can try the domain name he know.
In case of failure, the user can fall back to full EAP authentication or Explicit ER bootstapping using the home domain name.
After the full EAP authentication, the subsequent ERP exchange or DHCP based mechanism can tell the peer the local domain 
name.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 18 Nov 2010 15:16:41 +0900

> the user I mentioned here is the peer.
I think you don't understand where the problem is. Please read again my
Beijing presentation, hopefully the explanation will be clear (I cannot
do better by repeating the same thing again and again on the list...)

Regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Nov 2010 15:16:02 +0800

Okay. But I know your concept.
As I pointed out, our difference is how to understand bootstapping, who really need bootstapping.
In your opinion, you think only local ER server ror ER proxy needs bootstapping.
In my opinion, both the peer and the local ER server needs bootstapping.
Bootstrapping concept is very popular in the mobility scenario.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 18 Nov 2010 16:47:05 +0900

> Bootstrapping concept is very popular in the mobility scenario.
Yes. But the bootstrapping in mobility refers to something completely
different from the bootstrapping of ERP (as defined in RFC5296).

Sebastien.