Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

[Yaron Sheffer <[e-mail]>]

Hi Dan,

I actually think the patent situation plays against SPSK, rather than in its favor. But I will say no more. Patent *discussions* are a drag. My personal opinion is that patents should have the lowest priority in this decision.

As you know, it is trivial to generate MODP groups that will work well with EKE, and whether you use the existing registry or not is a minor detail. For ECC groups, admittedly we don't have a solution yet.

I'm glad to hear that SPSK is being reviewed by cryptographers, and would be happy to read an analysis. Publishing it at a more crypto-oriented venue would also help in soliciting more and better reviews.

Thanks,
	Yaron

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Wednesday, December 02, 2009 21:12
> To: Yaron Sheffer
> Cc: [e-mail]
> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication
> (SPSK) - NO
> 
> 
>   Hi Yaron,
> 
>   The technology underlying SPSK is not patented, EKE, SRP and PAK
> are all patented. Patents are a drag.
> 
>   In addition, EKE has the additional problem that it requires
> specialized MODP groups-- it can't use the ones in the IKE registry--
> and I don't believe it can be used with elliptic curve groups at all.
> SPSK can use any MODP or ECP group in the registry, just like IKE.
> SPSK is a natural fit.
> 
>   The technology underlying SPSK was published outside the IETF.
> Check out the references in the draft. It is being reviewed in the
> academic community right now. I'm sorry you don't don't feel that
> the IETF/IRTF has the expertise to do crypto but, once again, I
> disagree.
> 
>   Dan.
> 
> On Wed, December 2, 2009 12:31 am, Yaron Sheffer wrote:
> > Hi Dan,
> >
> > Responding to your last point:
> >
> > The alternatives for EAP-PWD (a.k.a. SPSK), namely EKE, SRP and PAK,
> have
> > all been published outside the IETF and peer-reviewed by the relevant
> > community: cryptographers, mainly of the academic kind. I highly
> > appreciate the expertise we have at the IPsecME WG and at the CFRG. But
> if
> > we're adding a new security mechanism to a major IETF security protocol,
> > this level of expertise is insufficient. Anything we do will STILL need
> to
> > be reviewed by CFRG - both EAP-EKE and EAP-PWD have had holes punched
> into
> > them by these people. But it would be irresponsible to ONLY have this
> > limited level of review.
> >
> > Regarding the process at the EMU side of the house, I share your
> > frustration...
> >
> > Thanks,
> > 	Yaron
> >
> >> -----Original Message-----
> >> From: Dan Harkins [mailto:[e-mail]]
> >> Sent: Tuesday, December 01, 2009 10:19
> >> To: Yaron Sheffer
> >> Cc: Dan Harkins; [e-mail]
> >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication
> >> (SPSK) - NO
> >>
> >>
> >>   Yaron,
> >>
> >>   It is important for you to state what problem you're trying to solve.
> >> That problem is, simply, password-only authentication. To bring up the
> >> motivation for adding EAP to IKEv2 is quite irrelevant since EAP in
> >> IKEv2
> >> today involves server-side authentication using a certificate.
> >>
> >>   You want to do password authentication in IKE. Period. Full stop. And
> >> to
> >> do that you want to add a pointless encapsulation. And you want to do
> it
> >> with twice as many messages. And you want to require each side to
> >> implement
> >> both the client- and server-side state machines for this "solution" to
> >> be useful in the use cases defined in IKEv2.
> >>
> >>   It seems to me that you need to justify why such EXTRA work is
> >> necessary
> >> when a simpler way of solving your problem is available. Don't just say
> >> "it doesn't make sense", justify why you are proposing more, extraneous
> >> work.
> >>
> >>   Furthermore, I would be very interested in why you feel that a WG in
> >> the Security Area of the IETF is not the place to define cryptographic
> >> protocols and that it would be more appropriate for a WG in the
> Security
> >> Area to just use a protocol from the Network Area with protocols
> defined
> >> as individual submissions.
> >>
> >>   Dan.
> >>
> >> On Mon, November 30, 2009 10:46 pm, Yaron Sheffer wrote:
> >> > Hi everyone,
> >> >
> >> > [WG co-chair hat off]
> >> >
> >> > I believe this effort is misguided, and would be a waste of the WG
> >> time.
> >> >
> >> > EAP was added to IKEv2 to provide "legacy" (a.k.a. password)
> >> > authentication. In the past it did not do it very well, but this is
> >> > changing. We should improve the use of EAP in IKEv2, rather than
> >> replacing
> >> > it by a homebrew solution.
> >> >
> >> > Specifically, the following EAP methods can be used today (or in the
> >> near
> >> > future) for mutual password-based auth:
> >> >
> >> > - Dan's own EAP-PWD,
> >> > http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12
> >> > - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03
> >> > - The long expired EAP-SRP,
> >> > http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03
> >> > - A rumored EAP method based on the PAK protocol
> >> > (http://tools.ietf.org/html/draft-brusilovsky-pak-10)
> >> >
> >> > Embedding one of these methods as the single way to do mutual auth in
> >> IKE
> >> > simply doesn't make sense.
> >> >
> >> > In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto
> >> > protocol. It has had by far the least crypto review than the other
> >> three
> >> > protocols. IMHO, this working group should NOT be developing new
> >> > cryptographic protocols. This is not where our expertise lies.
> >> >
> >> > Lastly, one of the major criticisms with IKEv1 was the number of
> >> protocol
> >> > modes. And here we are, with a proposal to add another mode to IKEv2.
> >> > Doesn't seem like a good idea to me.
> >> >
> >> > Thanks,
> >> > 	Yaron
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: Dan Harkins [mailto:[e-mail]]
> >> >> Sent: Tuesday, December 01, 2009 1:35
> >> >> To: Yaron Sheffer
> >> >> Cc: [e-mail]
> >> >> Subject: Re: [IPsec] Proposed work item: IKEv2 password
> >> authentication
> >> >> (SPSK)
> >> >>
> >> >>
> >> >>   Hello,
> >> >>
> >> >>   As can be inferred by my previous posting on EAP-only
> >> authentication,
> >> >> I favor this particular method for mutual authentication.
> >> >>
> >> >>   I believe this is a general purpose exchange, useful for more than
> >> the
> >> >> narrow focus of EAP-only, does not require extraneous encapsulations
> >> or
> >> >> unnecessary code (ala EAP-only), and is secure regardless of its use
> >> >> (unlike EAP-only).
> >> >>
> >> >>   I am committed to working on this as a WG work item. I agree to
> >> >> continue
> >> >> contributing to the text and (co-)authoring the text. I solicit
> help,
> >> >> and
> >> >> support, from those who are interested in this task.
> >> >>
> >> >>   regards,
> >> >>
> >> >>   Dan.
> >> >>
> >> >> On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote:
> >> >> > This draft proposes a particular method for mutual authentication
> >> of
> >> >> IKEv2
> >> >> > peers using a short, low quality shared secret (a.k.a.
> "password").
> >> >> The
> >> >> > proposal is to embed this method in the IKE exchange, rather than
> >> use
> >> >> EAP.
> >> >> >
> >> >> > Proposed starting point:
> >> >> > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt.
> >> >> >
> >> >> > Please reply to the list:
> >> >> >
> >> >> > - If this proposal is accepted as a WG work item, are you
> >> committing
> >> >> to
> >> >> > review multiple versions of the draft?
> >> >> > - Are you willing to contribute text to the draft?
> >> >> > - Would you like to co-author it?
> >> >> >
> >> >> > Please also reply to the list if:
> >> >> >
> >> >> > - You believe this is NOT a reasonable activity for the WG to
> spend
> >> >> time
> >> >> > on.
> >> >> >
> >> >> > If this is the case, please explain your position. Do not explore
> >> the
> >> >> fine
> >> >> > technical details (which will change anyway, once the WG gets hold
> >> of
> >> >> the
> >> >> > draft); instead explain why this is uninteresting for the WG or
> for
> >> >> the
> >> >> > industry at large. Also, please mark the title clearly (e.g.
> >> "DES40-
> >> >> export
> >> >> > in IPsec - NO!").
> >> >> > _______________________________________________
> >> >> > IPsec mailing list
> >> >> > [e-mail]
> >> >> > https://www.ietf.org/mailman/listinfo/ipsec
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> Scanned by Check Point Total Security Gateway.
> >> > _______________________________________________
> >> > IPsec mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ipsec
> >> >
> >>
> >>
> >>
> >> Scanned by Check Point Total Security Gateway.
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> 
> 
> Scanned by Check Point Total Security Gateway.