Subject: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

From: Sebastien Decugis <[email-masked]>
Date: Fri, 05 Nov 2010 18:33:59 +0900

Hello,

I just noticed that RFC 5296 uses "SHOULD" several times in section 5.2
(2nd, 3rd paragraph) but uses "MAY" in section 5.3.1.1 about if the
authenticator MAY/SHOULD send a EAP-Initiate/Re-Auth-Start message when
a new peer appears.

I think this should be easily fixed in rfc5296bis by changing the text
in 5.3.1.1 to "SHOULD".

Best regards,
Sebastien.

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

---

From: Tina TSOU <[email-masked]>
Date: Fri, 05 Nov 2010 17:59:13 +0800

Support.

B. R.
Tina
http://tinatsou.weebly.com

On Nov 5, 2010, at 5:33 PM, Sebastien Decugis wrote:

> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

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

Hi,
To me, I don't think there is fundmental difference between using "SHOULD" and using "MAY".
Because you can not guarantee that the new  peer can receive EAP-Initiate-Auth-Start message from any authenticator.
How the authenticator know a new peer appears is another issue. You may still rely on some lower layer mechanism to help authenticator to percieve the new peer appears.
Therefore RFC5296 describes many ways to get local domain name for the peer, e.g., via lower layer mechanism,
using EAP-Initiate-auth-Start and using Explicit ER bootstapping.
That's why using  EAP-Initiate-Auth-Start message in the ERP exchange is just a optional choice in the figure 4 of RFC5296.

Regards!
-Qin

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 18 Nov 2010 10:42:17 +0900

Well, because this message is not a MUST, we have this issue of the peer
maybe not knowing the local domain name, which complicates everything. I
would personally be in favor of requesting ("MUST") the authenticator to
send a EAP-Initiate-Auth-Start -- or even better, a new TLV attribute
inside the Identity Request that contains the ERP domain name, so that
we don't delay the normal full authentication.
Anyway I guess that if this design choice was made initially there were
good reasons to do so, even though I don't understand them.

What I was highlighting is a mere contradiction in the text that must be
fixed.

Best regards,
Sebastien.

---

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

Hi,
I think it is possible if we assume that the authenticator can perceive there is new peer attaching to the network,
then the authenticator can send EAP-Initiate-Auth-Start to inform the peer the local domain name.

Even the peer  can not learn local domain name from EAP-Initiate-Auth-Start, the peer can learn from
other ways like other  lower layer mechanism.

If we allow bootstapping happens within the local domain with the peer and local ER server involved,  we can use 
EAP-Finish message through Explicit ERP exchange to carry the local domain name to the peer. In this case, the local
ER server needs to terminate EAP-Initiate message and just send AAA message with DSRK request to the home EAP server.
It will simplify the bootstapping. But I am not sure we may agree upon with this.

In the current RFC5296, if  the home ER server is involved in ER explicit boostrapping, also the local ER server get involved, the home ER server can inform the peer that the local domain name
provided by local ER server through EAP-Finish message. It complicates the bootstapping with two ER server involved.

As for using EAP-identity request containing local domain name, It could be. But I am not sure the peer can treat
 EAP-identity-request as a message to provide local domain name. 

Regards!
-Qin

---

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

Hi again,

> then the authenticator can send EAP-Initiate-Auth-Start to inform the peer the local domain name.
In normal EAP (without ERP) the first message is sent by the
authenticator to the peer.
It is certainly not an issue to do the same in ERP.

> other ways like other  lower layer mechanism.
Unfortunately not all lower layers provide this information. Moreover,
requesting an ERP-specific information to be configured in another layer
is a good way to ensure that ERP will never be deployed correctly.
Especially when we could do all we need inside ERP itself.

> If we allow bootstapping happens within the local domain with the peer and local ER server involved, 
Bootstrapping must involve the home EAP server and the local ER server,
at least.
My proposal is to remove the peer from it.

>  we can use 
> EAP-Finish message through Explicit ERP exchange to carry the local domain name to the peer.
Yes. This is already specified in rfc5296.

>  In this case, the local
We cannot, because the peer does not use the proper DS-rIK to protect
the message in this case. Therefore the local ER server cannot verify
the message is valid. To make it work, please see my slides presented in
Beijing where I explained the required changes.

>  EAP-identity-request as a message to provide local domain name.
Why not? It seems possible to piggy-tail information at the end of the
Identity message (like "\0ERPDomain=some.domain.net"). If the peer
supports ERP it interprets this and sends an ERP-Initiate, otherwise it
simply ignores the extension and replies with its identity.

Regards.
Sebastien.

---

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

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 18, 2010 12:42 PM
Subject: Re: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

> It is certainly not an issue to do the same in ERP.

[Qin]:Okay, It is reaonable to me.

> Especially when we could do all we need inside ERP itself.

[Qin]: Right.

> My proposal is to remove the peer from it.

[Qin]: No, it is the peer who first initiated bootstapping by sending EAP-Initiate message with bootstapping flag on.
As described in RFC5296:
"
 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.  The bootstrap message is always
      sent to the home AAA server, and the keyname-NAI attribute in the
      bootstrap message is constructed as follows: the username portion
      of the NAI contains the EMSKname, and the realm portion contains
      the home domain name.
.....
When the peer receives an EAP-Finish/Re-auth message with the
      bootstrap flag set, if a local domain name is present, it MUST use
      that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-
      NAI, and initialize the replay counter for the DS-rIK.  If not,
      the peer SHOULD derive the domain-specific keys using the domain
      name it learned via the lower layer or from the EAP-Initiate/
      Re-auth-Start message.  If the peer does not know the domain name,
      it must assume that there is no local ER server available.

"

> Yes. This is already specified in rfc5296.

[Qin] Right.
 
> Beijing where I explained the required changes.

 [Qin]: Thank for explaining this again. However I still don't get it.
First, If the home ER server exist in the home domain or collocated with home EAP server, 
I think the peer can use home domain name to calculate the home DS-rIK to protect the ERP message between
the peer and the home ER server. 
Second, If the local ER server situated in the path, I think the local ER server does not need to verify this message. 
what he is doing is just to insert DSRK request in the AAA message and send this AAA message to the home 
EAP Server and get DSRK back.

You can see this from the description of RFC5296 as follows:
"
   o  If a local ER server is present, the local ER server MUST include
      the DSRK request and its domain name in the AAA message
      encapsulating the EAP-Initiate/Re-auth message sent by the peer.

"
But you are right, the local ER server can not interpretate the ERP message sent to the home domain. 
And the local ER server just insert the DSRK request in  the AAA message containing ERP message nested.

> simply ignores the extension and replies with its identity.

[Qin]: Okay. Sounds a good idea to me.

---

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

Hi again,

I removed the things we agreed on. Other comments are bellow...

> [Qin]: No, it is the peer who first initiated bootstapping by sending EAP-Initiate message with bootstapping flag on.
OK it seems that this is the source of our communication problem. Let me
clarify bellow.

[bootstrapping] is the process by which the local ER server receives the
DS-rRK key corresponding to an EMSK from the home EAP server. There are
2 ways to perform this [bootstrapping] defined in RFC5296, the [implicit
bootstrapping] and the [explicit bootstrapping]. In the mail exchange, I
am refering to the [bootstrapping] process while you refer to the ERP
message used to support the [explicit bootstrapping]. They are two
different concepts.

As I wrote, I believe the peer should not have an active role in the
[boostrapping] process. It is already the case when [implicit
bootstrapping] occurs, but the peer is involved in the [explicit
bootstrapping] exchange. My proposal is therefore to change the protocol
in rfc5296bis to remove the [explicit bootstrapping] message initiated
by the peer, and let the [bootstrapping] process happen when needed
(initiated by the local ER server, not the peer). Put otherwise, I am
proposing to create a new different [implicit bootstrapping] that does
not happen during the full EAP authentication, but during the first ERP
message.

> EAP Server and get DSRK back.
I don't understand what you originally meant with your "the local ER
server needs to terminate EAP-Initiate message" then. Can you rephrase
your proposal?

Sebastien.

---

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

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 18, 2010 3:45 PM
Subject: Re: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

> not happen during the full EAP authentication, but during the first ERP

[Qin]: Based on my understanding to RFC5296, bootstapping also is the process by which
the peer learn the local domain name and derive DSRK, DS-rRK, DS-rIK, and keyName-NAI.

Unfortunetely, there is no definition of bootstapping in the RFC5296.

If the local ER server sits between the peer and home EAP server, the local ER server can 
request the DSRK from the home EAP server in any case. That is what Implicit bootstapping is 
as described in RFC5296. Becos you don't need the peer to send message with bootstapping flag
to trigger such procedure.

As for your two proposals, personally, I am suspecting you distort the original meaning of bootstapping,:-).
 
> server needs to terminate EAP-Initiate message" then. Can you rephrase

[Qin]: The original proposal is to ask local ER server process  ERP message
during the bootstapping, the presumption is the peer know local domain name
through EAP-Initiated Reauth-Start message. In this case, upon receiving the EAP-Initiated 
message protected by DS-rIK from the peer, the local ER server should first request DSRK
 from home EAP server , calculate the right DS-rIK 
and then using this DS-rIK to verify the ERP message.

Does it make sense, Is this your proposal?

---

From: Tom Taylor <[email-masked]>
Date: Thu, 18 Nov 2010 08:34:41 -0500

I think your discussion would go more smoothly if you discarded the term 
"bootstrapping" and just discussed the specific actions that have to 
occur and information that has to be passed.

On 18/11/2010 3:36 AM, Qin Wu wrote:
> From: "Sebastien Decugis"<[email-masked]>
> To: "Qin Wu"<[email-masked]>
> Cc:<[email-masked]>

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 19 Nov 2010 10:33:46 +0900

Hi,

> I think your discussion would go more smoothly if you discarded the
> term "bootstrapping" and just discussed the specific actions that have
> to occur and information that has to be passed.
I think you are right :) However, it is important to ensure we are
talking about the same thing, whatever we call it.

>> As for your two proposals, personally, I am suspecting you distort
>> the original meaning of bootstapping,:-).
Well, let me just point that with implicit bootstrapping the peer is not
involved, and it is still called "bootstrapping", which leads me to
think that I am not the one distorting the intent of RFC5296 ;)

>> Does it make sense, Is this your proposal?
Yes, I agree with this. It is simpler to request that the peer always
learn the local ERP domain name from the EAP-Initiated Reauth-Start
message (or extension to EAP-Identity, FFS).

In order for what you describe to work, the peer must also always
include its home domain name in the message, because otherwise the local
ER server does not know where to ask for this DS-rRK.

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Nov 2010 15:38:38 +0800

Hi,
Sorry for late reply.
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Tom Taylor" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Friday, November 19, 2010 9:33 AM
Subject: Re: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

> talking about the same thing, whatever we call it.

[Qin]: Yes, we are on the same page. I am okay to replace MAY with SHOULD.

> think that I am not the one distorting the intent of RFC5296 ;)

[Qin]: Yes, the peer is not involved in the implicit bootstapping. That's why it is called implicit Bootstapping. That is to say, in my understanding,
in the implicit Bootstapping, only local ER server should get involved.
While in the Explicit Bootstapping, both the peer and Local ER server should get involved.

> message (or extension to EAP-Identity, FFS).

[Qin]: Okay.

> ER server does not know where to ask for this DS-rRK.

[Qin]: Another issue is 
In which way the home domain name is carried in the message?
If we use TLV with type '4'  to carry home domain name, how does the authenticator or local ER server know if such TLV is used to carry home domain name rather than other domain name?
If we use both home  domain name and local domain name  to construct keyname-NAI by the peer? How does the authenticator or local ER server know such keyname-NAI use home domain name
as realm part?

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 24 Nov 2010 10:34:24 +0900

Hi Qin, all,

>> The peer must also always
Yes, this is an issue that we have to solve.
I see two possibilities, feedback is appreciated:
 (1) use a decorated NAI, such as: [homeDN]%[EMSKname]@[localDN]
or
 (2) use a TLV to carry the [homeDN]. If no existing type is
appropriate, we might request a new one assigned for this (I did not
check the details of the type '4' yet).

Any opinion?

Best regards,
Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Nov 2010 09:48:52 +0800

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Tom Taylor" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 24, 2010 9:34 AM
Subject: Re: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

> check the details of the type '4' yet).

[Qin]: My proposal is
the peer must not include both home domain name and local domain name in the same message, 
 the home domain name can be in any form, e.g., Keyname-NAI.

in this way, the authenticator or local ER server can check if the domain name in the message match 
the local domain it has already known. If match, the authenticator or local ER server know the domain
name in the message is local domain name. If not, the authenticator or local Er server know
the domain name in the message is home domain name. 

Do it make sense?

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 24 Nov 2010 10:54:13 +0900

Hi,

> the domain name in the message is home domain name. 
I am sorry I don't understand your proposal, what would the peer send
exactly (if we consider the peer knows both its home domain name and the
local domain name) ?

Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Nov 2010 10:00:45 +0800

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 24, 2010 9:54 AM
Subject: Re: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

> exactly (if we consider the peer knows both its home domain name and the

[Qin]: Just for clarification:
I think Peer should know whether he need to go back to home domain or not.
If the peer need to go back to home domain, the peer choose home domain name
as the realm part of KeyName-NAI.
If not, the peer choose local domain name.

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 24 Nov 2010 11:02:58 +0900

> If not, the peer choose local domain name.
My proposal was to remove this need from the peer... Because how does
the peer know if it must go to home domain or not? It really depends on
the internal state of local ER server, which the peer knows nothing about...

Sebastien.

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Nov 2010 10:24:14 +0800

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 24, 2010 10:02 AM
Subject: Re: [HOKEY] rfc5296bis: MAY vs. SHOULD in RFC 5296

> the internal state of local ER server, which the peer knows nothing about...

[Qin]: 
In my understanding,
The Peer always know the home domain name. Also the peer can learn local domain name in many different ways.
If the peer fails to perform ER exchange with the local ER server, the peer can fall back to normal full EAP authentication
or Explicit Bootstapping, which means the peer needs to go back to the home domain.
I know this is not smart way, but I think it works. Right?

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 24 Nov 2010 11:31:07 +0900

Hi,

> I know this is not smart way, but I think it works. Right?

Yes, that's right, but it seems a bad design to me to require the first
exchange to fail in order to learn the state of the ER server, when it
is very easy to design things differently so that it will work on the
first attempt in all cases.

It's only my personal opinion of course.

Best regards,
Sebastien.