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
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
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:
> 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.
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:
> 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
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
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,
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
Hello Scott,
Thank you for your time. To give you a background, I am implementing a
conformance tool which exercises GCM/GMAC using ESP/AH for IKev1, running
against Strongswan. Based on your inputs, I have been able to successfully
negotiate ikev1 & send ESP/GCM packets using IKEv1 to Strongsw
10 matches
Mail list logo
