Subject: Re: [Mobike] Proposal for revised charter

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Apr 2006 17:46:07 -0800

So far, only one person on the list has spoken up in favor of 
revising the charter to include work for a transport-mode protocol. 
Is there interest from others?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Apr 2006 21:25:03 +0200

In your previous mail you wrote:

=> I am in favor of applying *current* mechanisms to transport mode
when it is possible, this includes updating transport mode SAs in some
special cases but explicitely doesn't require to change the charter.

Regards

[email-masked]

PS: I'll try to update my old I-D about mobike & transport mode to
include these special cases. If someone is interesting to participate
just send a message to me. Of course as it won't specify new mechanism
or protocol the goal is to publish it as an informational document.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 Apr 2006 08:54:14 -0700

There seems to be not enough interest in the WG to revise the 
charter: only two people spoke up. I assume that the people at the 
face-to-face meeting who wanted to see the charter revised wanted to 
see the work done, but didn't intend to help do it, which is 
understandable.

<cue the forlorn violin music>

Russ: please start the process to shut down the MOBIKE WG. I assume 
that Steve Bellovin, our mailing list host, will keep the list open 
indefinitely. If not, we can move it to VPNC.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Yaron Sheffer" <[email-masked]>
Date: Mon, 10 Apr 2006 16:04:29 +0300

I realize that I'm a bit late, but still...

I would like to propose two work items that I believe fall within MOBIKE's
charter.

1. "Secure beacon": a secure way for a mobile client to determine whether it
is inside or outside of the trusted network. In many cases, depending on
network topology and local security policy, you might want to suspend IPsec
once "inside the network". There are now similar solutions being discussed
in the Mobile-IP+IPsec context, but a solution that's independent of Mobile
IP would be preferable.

2. Short-term credentials assigned by one gateway, to allow a client to
connect to another gateway without performing full EAP-based authentication
(and entering a password). Although the need to connect to multiple IPsec
gateways is not limited to the mobility case, it is amplified by mobility.
For example, some of the gateways may not be accessible through different
access methods, e.g. cellular/GPRS.

I (and Check Point) obviously commit to work on these items if there is
interest.

Paul and Russ, I'd like to request a week to allow the group to support
these proposals (or shoot them, anything is better than silence). Following
that, we can reconsider group shut down.

Thanks,
	Yaron

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Friday, April 7, 2006 18:54
To: [email-masked]
Cc: Russ Housley
Subject: Re: [Mobike] Proposal for revised charter

--Paul Hoffman, Director
--VPN Consortium

---

From: Julien Laganier <[email-masked]>
Date: Mon, 10 Apr 2006 23:22:13 +0200

Hi Yaron,

I have few questions on your rechartering proposal.

On Monday 10 April 2006 15:04, Yaron Sheffer wrote:
> I would like to propose two work items that I believe fall within
> MOBIKE's charter.

<snip>

> 2. Short-term credentials assigned by one gateway, to allow a
> client to connect to another gateway without performing full
> EAP-based authentication (and entering a password). Although the
> need to connect to multiple IPsec gateways is not limited to the
> mobility case, it is amplified by mobility. For example, some of
> the gateways may not be accessible through different access
> methods, e.g. cellular/GPRS.

What kind of short term credentials do you have in mind? Pre-shared 
key? Or certificates? 

Also, IIUC that would means that the keying material required to 
validate those credentials would need to be distributed amongst the 
multiple gateways. Would you like to include such a work item in 
MOBIKE charter?

Finally, I guess the goal of your proposal is to reduce the delay of 
establishment of secure access upon inter-technology handover, right? 
Don't you think this goal could be achieved more simply via 
pre-authentication to the next gateway while still attached to the 
old gateway?

Thanks. Best regards,

--julien 

> face-to-face meeting who wanted to see the charter revised wanted
> to see the work done, but didn't intend to help do it, which is
> understandable.
>

---

From: "Ariel Shaqed (Scolnicov)" <[email-masked]>
Date: Tue, 11 Apr 2006 09:45:20 +0300

> pre-authentication to the next gateway while still attached to the

Key exchange and authentication are distinct in remote access, even though 
they may occur in the same process.  During roaming, you may need to 
exchange keys even if there is no need to re-authenticate.

In many remote access scenarios, there is more to the handover than just 
delay.  Some popular authentication technologies require user intervention 
to succeed.  It would be desirable to provide an alternative to users 
having to re-enter credentials, e.g. from some token.  Pre-authentication 
actually makes this worse, as the user's work is potentially wasted.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Apr 2006 13:53:13 -0700

After more discussion last week, there still seems to be very little 
interest in rechartering the MOBIKE Working Group. However, it looks 
like you should expect some individual submissions over time.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Apr 2006 13:28:08 +0300

>access methods, e.g. cellular/GPRS.
MOBIKE was designed to handle the case where communication
is between the same peers, but the peers' addresses change.
When one of the peers change the problem becomes somewhat
different.

In IETF-65 there was a BoF, HOKEY, on handover keying, mainly
focused on EAP-based access authentication. If you have needs
for efficient handover from one SGW to another, it might be
useful to work on your problem in the HOKEY space to ensure
that IKEv2 EAP mode is one of the "accesses" where efficient
handover works.

--Jari