The challenge I have in understanding the motivation for this work is
impacted by ...
1) EAP is not only meant to be used with backend infrastructure.
2) EAP is an authentication framework and EAP methods exist that support
strong-password based authentication.
3) EAP is implemented by folks i
Hi Pasi,
Thanks for your comments. Some of them are pretty major and we would like to
request some time to properly address them. We will respond by next Monday with
our proposed resolutions.
Thanks
Suresh
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.
At 7:22 PM +0200 3/2/10, Hannes Tschofenig wrote:
>The challenge I have in understanding the motivation for this work is impacted
>by ...
>
>1) EAP is not only meant to be used with backend infrastructure.
>2) EAP is an authentication framework and EAP methods exist that support
>strong-password
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Using Advanced Encryption Standard (AES) Counter Mode
with IKEv2
Author(s) :
On Tue, 2 Mar 2010 13:03:40 -0500
"Blumenthal, Uri - 0662 - MITLL" wrote:
> I see value in adding a simpler-than-EAP method, and support this
> effort. But overall it's an extremely difficult task because of IPR.
>
> I personally would hate to see a patent-encumbered solution - and
> that would
Whether or not the EKE patent is broad enough, if you search the IPR repository
for RFC 2945 (SRP), you will find out that more than one company is happy to
post an IPR warning related to SRP. This of course does not prove anything -
they're just saying that their patents "might apply". BTW, I a
Hello,
There are other criteria that should be evaluated in making a
decision, such as how well does the solution fits into IKE(v2) and
does it support "crypto agility".
RFC 2409 supported negotiation of various parameters, like the group
used for the Diffie-Hellman key exchange. That was
Hi Dan,
EAP-EKE supports negotiation of various algorithms, a.k.a. crypto-agility. One
of the negotiated algorithms is in fact the group being used. EAP-EKE does
require MODP groups that fulfill certain conditions, and as a result, the
document defines one such group (additional ones can be eas
At 12:12 PM -0800 3/2/10, Dan Harkins wrote:
> There are other criteria that should be evaluated in making a
>decision, such as how well does the solution fits into IKE(v2) and
>does it support "crypto agility".
...and what we mean by "agility". To some, that means "in-protocol negotiation
of pa
Even as of draft-08, section 2.9:
When an RFC4301-compliant IPsec subsystem receives an IP packet that
matches a "protect" selector in its Security Policy Database (SPD),
the subsystem protects that packet with IPsec. When no SA exists
yet, it is the task of IKE to create it. Mainten
Hi Yaron,
The discussion is on the secure password-only authentication work item
in which a password authenticated key exchange is being added directly
to IKE(v2). It doesn't matter what EAP-EKE does or does not do because
EAP is not being used for this work item.
Now we can add some sort
Hi Paul,
On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote:
[snip]
>> RFC 2409 supported negotiation of various parameters, like the group
>>used for the Diffie-Hellman key exchange. That was removed in RFC 4306.
>>All of the candidate exchanges listed in draft-sheffer-ipsecme-pake-
>>criteria
Dan,
> >> For instance, I do not believe EKE is suitable for any of the
> >>groups currently in the IANA registry of groups that can be used with
> >>IKE(v2).
There was an analogous experience with SRP for iSCSI - completely different
groups were used up to 2048 bits and beyond there, the modul
On Tue, 2 Mar 2010 12:12:19 -0800 (PST)
"Dan Harkins" wrote:
>
> Hello,
>
> There are other criteria that should be evaluated in making a
> decision, such as how well does the solution fits into IKE(v2) and
> does it support "crypto agility".
>
There are certainly many things that need to
Hi David,
On Tue, March 2, 2010 3:49 pm, black_da...@emc.com wrote:
[snip]
>
> OTOH, I think you've oversimplified here ...
>
>> The candidate exchanges all rely on the "hard problem" of doing a
>> discrete logarithm in one of the defined groups. It's the same "hard
>> problem" that makes th
On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
"Dan Harkins" wrote:
>
> Hi David,
>
>
> On Tue, March 2, 2010 3:49 pm, black_da...@emc.com wrote:
> [snip]
> >
> > OTOH, I think you've oversimplified here ...
> >
> >> The candidate exchanges all rely on the "hard problem" of doing a
> >> discrete
> > >> The candidate exchanges all rely on the "hard problem" of doing
a
> > >> discrete logarithm in one of the defined groups. It's the same
> > >> "hard problem" that makes the Diffie-Hellman portion of IKE
> > >> secure. If the group negotiated or demanded in IKE allows for an
> > >> "easier
Hi Dan,
I consider reuse of DH groups a minor issue at best. But yes, it's a valid
criterion.
Thanks,
Yaron
> -Original Message-
> From: Dan Harkins [mailto:dhark...@lounge.org]
> Sent: Wednesday, March 03, 2010 0:26
> To: Yaron Sheffer
> Cc: Dan Harkins; Paul Hoffman; IPsecme W
18 matches
Mail list logo
