Thanks Tero.
Can i know why is the DHCP allocated IP scenario not considered in IKEv2 RFC
or any separate RFC(like RFC3456 for IKEv1)?
Is it only because of CONFIG_PAYLOAD is capable of providing IP to IRAC
during IKEv2 negotiation itself.
What happens when some corporate network providing vpn se
Balaji J writes:
> Can i know why is the DHCP allocated IP scenario not considered in
> IKEv2 RFC or any separate RFC(like RFC3456 for IKEv1)?
It was considered, but working group decided that it is too
complicated and decided to include built in support for address
allocation using configuration
As we all know we (as a wg) did fail to pick one secure password
authentication method, and the latest count seems to be that we are
going to have 4 of them.
All of them seem to be mostly same from the IKEv2 protocol point of
view, but each of them are implemented differently. All of the
proposals
On Apr 12, 2011, at 3:17 PM, Tero Kivinen wrote:
> This kind of framework would allow using any of the secure password
> authentication methods in a way where they can co-exist in the same
> implementation. If the implementation is done properly, then it might
> be even possible to make it so that
On Tue, Apr 12, 2011 at 8:29 AM, Yoav Nir wrote:
> I have mixed feelings about this. It's better than all four of those drafts
> advancing separately. OTOH this plug-innable architecture is pretty much
> admitting defeat. It sets us up to have a situation like EAP, with lots of
> different meth
On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:
> As we all know we (as a wg) did fail to pick one secure password
> authentication method, and the latest count seems to be that we are
> going to have 4 of them.
>
> All of them seem to be mostly same from the IKEv2 protocol point of
> view, b
On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:
> 1) Add new notification to the IKE_SA_INIT telling which SPAM
> algorithms are supported. This will notification will include tuple
> of 8-bit integers containing the 8-bit SPAM algorith number and
> 8-bit password preprosessing techniqu
Hi Nico,
On Tue, April 12, 2011 7:38 am, Nico Williams wrote:
> I don't get the hostility to pluggable authentication architectures.
> Why on Earth should any of us dictate to users what kinds of
> authentication infrastructures they must have?
We do that when we ship support for some authen
On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins wrote:
> On Tue, April 12, 2011 7:38 am, Nico Williams wrote:
>> I don't get the hostility to pluggable authentication architectures.
>> Why on Earth should any of us dictate to users what kinds of
>> authentication infrastructures they must have?
>
>
Hi Nico,
On Tue, April 12, 2011 11:53 am, Nico Williams wrote:
> On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins wrote:
>> On Tue, April 12, 2011 7:38 am, Nico Williams wrote:
>>> I don't get the hostility to pluggable authentication architectures.
>>> Why on Earth should any of us dictate to use
On Tue, Apr 12, 2011 at 2:39 PM, Dan Harkins wrote:
> On Tue, April 12, 2011 11:53 am, Nico Williams wrote:
>> On Tue, Apr 12, 2011 at 1:01 PM, Dan Harkins wrote:
>>> On Tue, April 12, 2011 7:38 am, Nico Williams wrote:
I don't get the hostility to pluggable authentication architectures.
>>>
On Tue, Apr 12, 2011 at 2:39 PM, Dan Harkins wrote:
> I'm a bit undecided on Tero's proposal. I tend to get in trouble when
> I ascribe motivation to things people do so I won't do that, but as
> someone who actually implements the protocols we design here I think
> having n protocols, where n >
Hi Nico,
On Tue, April 12, 2011 12:45 pm, Nico Williams wrote:
> "If you want to use certs then use certs... if you want to use
> passwords then use passwords ..." implies an authentication framework
> with at least two authentication mechanisms (and negotiation!).
>
> So you're for at least on
Hi,
I'd like to skip through the architectural bits in a hurry, and then
come back to Tero's proposal. All while rapidly flipping hats :-)
In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC
5998) could get us all we need for password authentication, and
eliminate the use o
Hi Nico,
On Tue, April 12, 2011 1:00 pm, Nico Williams wrote:
> I fail to see how Tero's proposal makes any headway. Customers who
> have and want to use AAA will not be able to use it, near as I can
> tell, and if you undertake to make it possible to use AAA in Tero's
> proposal then you'll b
On Tue, Apr 12, 2011 at 3:03 PM, Dan Harkins wrote:
> On Tue, April 12, 2011 12:45 pm, Nico Williams wrote:
>> So you're for at least one authentication framework. Only you weren't
>> aware of it. Or what did I miss this time? :)
>
> No I don't think you missed it. The "framework" is just IKE a
On Tue, Apr 12, 2011 at 3:18 PM, Dan Harkins wrote:
> On Tue, April 12, 2011 1:00 pm, Nico Williams wrote:
>> I fail to see how Tero's proposal makes any headway. Customers who
>> have and want to use AAA will not be able to use it, near as I can
>> tell, and if you undertake to make it possible
On Tue, Apr 12, 2011 at 3:13 PM, Yaron Sheffer wrote:
> I'd like to skip through the architectural bits in a hurry, and then come
> back to Tero's proposal. All while rapidly flipping hats :-)
:)
> In the past I was of the opinion that IKEv2+EAP (with Mutual EAP, RFC 5998)
> [EAP pain elided -Ni
And if the mechanism does strong KE then you don't lose a round-trip nor do
channel binding as in my previous example.
The differences between Tero's and my proposal, then are pretty simple:
- the way mechanisms are named;
- names are sent in each mech's messages, not in separate IKE payloads;
-
Hi Dan,
as you say below, PACE uses a notification for the initiator to indicate
its support of the protocol. In fact, both sides get a chance to
indicate their support.
SPSK uses the Critical (a.k.a. Mandatory) bit for the initiator to
indicate this support, and relies on an error indicatio
20 matches
Mail list logo
