Nico Williams writes:
> On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:
> > 3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the
> > extra payloads in them depend on the SPAM algorithm used, and the
> > SPAM algorithm used also affects the AUTH payload generation. The
> >
On Tue, Apr 12, 2011 at 7:17 AM, Tero Kivinen wrote:
> 3) The IKE_SA_INIT and IKE_AUTH are used as exchange types, but the
> extra payloads in them depend on the SPAM algorithm used, and the
> SPAM algorithm used also affects the AUTH payload generation. The
> exchange will similar to EAP, i
Nico Williams writes:
> I believe you are wrong about that. Evidence: SCRAM (RFC5802).
>
> If you look at SCRAM you'll see that it's exceedingly simple -- it's a
> pre-shared password type mechanism, loosely resembling DIGEST-MD5.
I have not yet read the SCRAM, but based on the discussion on the
On Wed, Apr 13, 2011 at 5:53 AM, Tero Kivinen wrote:
> Nico Williams writes:
>> b) there are reserved numbers for using the GSS-API in IKEv1, and we
>> could make it usable in IKEv2,
>
> If I remember right GSS-API is also asymmetric meaning only there is
> clear separation of client and server si
Hi Tero,
To clarify (once again): I am NOT moving forward with HUSH. I think it's
a nice contribution and I'm not aware of any major problems with it, but
I'd rather concentrate on one PAKE method. I decided to go with PACE for
the sole reason that it comes with a security proof.
Thanks,
Yaron Sheffer writes:
> So I don't think we need a whole framework. We just need a way for the
> two peers to negotiate which method(s) they support early enough, i.e.
> in IKE_SA_INIT. In PACE we use a notification, and I strongly urge the
> two other documents' authors to do the same. But I'm
Nico Williams writes:
> 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 be quickly approximating EAP re-invention.
I
Dan Harkins writes:
> 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 > 1, to solve a single problem wit
Nico Williams writes:
> Reading into what you write above you seem to think that it's not
> possible to abstract authentication sufficiently well (for IKEv2's
> purposes, in this case). I disagree. I'll grant only that there's
We do have abstract authentication method already in the IKEv2, i.e.
Nico Williams writes:
> 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
Nico Williams writes:
> We already have three generic authentication frameworks: SASL,
> GSS-API, and EAP. Must we add a fourth one? (We also have a number
> of less generic ones, such as the ones in SSHv2, TLS, ...).
I do not consider this to be generic authentication framework. I
consider this
Yoav Nir writes:
> 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 methods, and no guide to implementers as
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
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;
-
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
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: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
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
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 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
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 >
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.
>>>
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 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 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 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
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 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 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
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
30 matches
Mail list logo
