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

From: Sebastien Decugis <[email-masked]>
Date: Wed, 20 Oct 2010 14:08:51 +0900

Hello,

I would like to propose two changes for rfc5296bis which would result in
a simplification of the protocol, if accepted.
I will send each proposed change in a separate mail so that they can be
discussed separately.

My first proposal would be to change the protocol so that:
1) If the local ER server already received the keying material for the
peer, it must be able to respond directly without forwarding the ERP
message to the home domain, even if this message contains the 'B'
(bootstrapping) flag.
2) If the local ER server does not have the keying material
corresponding to the peer, it must be able to forward the message to the
home domain, resulting in effect in a bootstrapping exchange and
allowing the ERP exchange to succeed, even when the ERP message does not
contain the 'B' flag.

I think these changes require minimal modifications to the ERP protocol :
 - deprecate the 'B' flag, since it becomes useless
 - always include the name of the home domain in ERP requests, so that
(local) ER server can bootstrap when needed
 - always include the local domain name known by the peer, if any, in
the request. 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. This "new" domain name is included in the answer so that the peer
will use this new domain name in later exchanges.

I can think of only one possible security issue. It should be possible
for a rogue domain to trick the peer into thinking it is located in a
different domain, and then acquire the DSRK for that domain from the
server. The same risk exist with the current mechanism, and the same
security precautions should be taken.

I can help wording this proposal in the document, should the group deem
it useful.

Best regards,
Sebastien.

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

---

From: Qin Wu <[email-masked]>
Date: Wed, 27 Oct 2010 16:56:32 +0800

Hi,
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 20, 2010 1:08 PM
Subject: [HOKEY] Changes proposals for rfc5296bis - 1: simplify bootstrapping

> allowing the ERP exchange to succeed, even when the ERP message does not

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

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

> (local) ER server can bootstrap when needed

[Qin]: The home domain is part of keyName-NAI. So you need not worry about this.

> the request. 

[Qin]: The peer may not know the local domain name, but authenticator or local ER server may know.

This local domain name is either acquired by a different
> name.

[Qin]: RFC5296 hasn't specified such behavior. We need to discuss this in the upcoming Beijing meeting.

 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.

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

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 28 Oct 2010 10:58:07 +0900

Hi Qin,

Thank you for your comments. As usual, please find my answers inline.

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

> '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]: 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]: 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]: RFC5296 hasn't specified such behavior. 
True, hence the *Changes proposal* title of this mail ;-)

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

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

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.

---

From: Qin Wu <[email-masked]>
Date: Thu, 28 Oct 2010 14:13:36 +0800

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

> changes that are needed to achieve this goal. There are probably other

[Qin]: Yes.

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

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

> to guess what the peer has used...

[Qin]: This is new behavior unspecifed in the RFC5296, we may need to look at it.

> True, hence the *Changes proposal* title of this mail ;-)

[Qin]: Okay. I got it.

> during Beijing meeting. But if nobody cares for improving ERP, why

[Qin]: Okay, that's great.

> updated after an ERP exchange, as I described.

[Qin]: Good point.