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

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Dec 2009 00:19:27 -0800 (PST)

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:[email-masked]]
>> Sent: Tuesday, December 01, 2009 1:35
>> To: Yaron Sheffer
>> Cc: [email-masked]
>> 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
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/ipsec
>> >
>>
>>
>>
>> Scanned by Check Point Total Security Gateway.
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Dec 2009 01:00:45 -0800 (PST)

Hi Matthew,

  Please take a look at both proposals. There is no proposal to simply
offer guidelines. Both of them are "new solutions" and modify the IKE
exchange. One uses NOTIFY messages to indicate the new exchange and the
other uses the critical bit to indicate the new exchange. I would be
interested in your opinion as a developer which is better-- NOTIFY or
critical bit-- and why.

  As a developer, I do not believe it is better to double the number
of messages needed to do a key exchange, and do not believe it is better
to require pointless encapsulations of a key exchange. If you disagree I
would also be interested in knowing why.

  Dan.

On Mon, November 30, 2009 11:10 pm, Matthew Cini Sarreo wrote:
> From a developer point of view, I share the same opinion as Yaron about
> this
> issue. Instead of creating new solutions, I personally think that it would
> be better to offer guidlines on how to implement current solutions (i.e
> EAP)
> and provide documents targeting implementers. This would create less
> confusion and keep IKEv2 a clean, easy to understand and use protocol.
>
> Regards,
> Matthew
>
> 2009/12/1 Yaron Sheffer <[email-masked]>
>
>> Hi everyone,
>>
>> [WG co-chair hat off]
>>
>> - A rumored EAP method based on the PAK protocol (
>> http://tools.ietf.org/html/draft-brusilovsky-pak-10)
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 1 Dec 2009 13:38:25 +0200

Hi Dan,

I'm sorry, but you are misstating the difference between the proposals. One is adding a notification and eliminating one existing (certificate) check; the other is adding an IKE mode, and changing the protocol state machine in the process.

Regardless of all the other pros and cons, the proposals are clearly not comparable as far as changing the protocol.

Thanks,
	Yaron

> Sent: Tuesday, December 01, 2009 11:01
> To: Matthew Cini Sarreo
> Cc: Yaron Sheffer; [email-masked]
> (SPSK) - NO

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2009 13:52:51 +0200

Yaron Sheffer writes:
> changing. We should improve the use of EAP in IKEv2, rather than
> replacing it by a homebrew solution. 

EAP can really only be used in the client / server situation. Using
EAP to protect site to site, or host to host traffic is very hard,
because of the assymetric properties of the EAP.

Because if this I do think there is use for having secure password
protocol in the IKEv2 without using EAP.

As an additional note, I also think there is use for EAP methods you
list below, as those can be used when there is clear client / server
distinction just like in the remote access case.

Btw, this same applies to the EAP only authentication, i.e. it has
uses when there is clear client / server distinction, i.e. it is not
competing with this one, but it provides similar properties for those
cases where we really have client and server, and where we do have
existing infrastructure (for example using EAP-SIM or EAP-AKA in the
GSM or 3GPP environments). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2009 14:29:40 +0200

Matthew Cini Sarreo writes:
> From a developer point of view, I share the same opinion as Yaron about this
> be better to offer guidlines on how to implement current solutions (i.e EAP)

I think it would be much more complicated to try to turn EAP from
client / server protocol to symmetric protocol, than to add new
exchange to IKEv2.

Note, that I do not comment anything about how the current SPKS draft
is done, as I have not really read it, but I think we should add
secure password protocol to the IKEv2 and not use EAP for that when
using symmetric site to site, or host to host scenarios.

If we had that clean secure password protocol, then we could leave out
EAP in some environments, which would make protocol implementation
much easier.

Looking at the state machine of IKE_AUTH in our own implementation,
EAP causes most of the complexity (mostly because EAP is open ended).

On the other hand if we add multiple authentication support to the
state machine pictures, then that is even more complex than EAP...

Good thing with SPSK is that it is alternative for all other
authentication modes, i.e. adds one to the shared key-shared key,
shared key-public key, public key-shared key, and EAP-public key list.
I.e. it does not multiply the test cases but just adds one to the list
of current authentication modes, raising it from 4 to 5. EAP only
authentication mode raises it by one more.

Multiple authentication support raises it to power of n (depending how
many different authentication rounds you support)...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2009 15:03:34 +0200

Yaron Sheffer writes:
> I'm sorry, but you are misstating the difference between the
> proposals. One is adding a notification and eliminating one existing
> (certificate) check; the other is adding an IKE mode, and changing
> the protocol state machine in the process.

Not true.

Both are adding new IKEv2 authentication mode.

In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also
makes it so that server DOES NOT need to have certificate and public
key, meaning it does not send it s first AUTH payload in message 4.

The main benefit from this is that the server DOES NOT need to have
private key.

(at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt)

We currently already have 4 authentication modes.

     Client				Server
1)   Shared key				Shared key
2)   Public key				Shared key
3)   Shared key				Public key
4)   EAP				Public key

EAP only will add one more:

5)   mutual-EAP				mutual-EAP

and SPSK will add one more:

6)   Password				Password

> Regardless of all the other pros and cons, the proposals are clearly
> not comparable as far as changing the protocol.

The changes required for EAP only might be smaller, but testing effort
for both of them is same, except EAP only really requires you to test
with all supported mutual key generating EAP methods (and also test
with others and make sure they are not accepted).

One thing I think most of you are missing is that their usage
scenarios are COMPLETELY different.

EAP-only can be used when there is clear client-server setup, existing
EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there
is no certificates or shared keys in use at all. This setup is
asymmetric, one party (the user) always initiates the connection. SPSK
cannot be used in such setup, as there is no password it can find.

SPSK can be used when there is requirement for host to host (or site
to site) connection, where either end can initiate traffic and
exchanges and where entities still want to use passwords instead of
public keys to authenticate. Shared keys could be used there, but in
most setups the shared keys used in those scenarios are not strong
enough to be resistant against dictionary attacks. EAP-only cannot be
used there as this is not client-server setup. In these setup the
authentication needs to be symmetric.

For this reason I do not think we need to decide to take on or the
other, we can take both as I do see use for both of them.

If I would need to select one, I would select SPSK, as that is
something which cannot be done by IKEv2 now.

EAP-only is an optimization (both in protocol level, and especially in
adminstrative level) for the existing EAP-Public key authentication.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 1 Dec 2009 15:17:46 +0200

Hi Tero,

I think you are too quick to dismiss the option of using EAP-only for site-to-site and transport deployments, where the EAP state machine is embedded into the IKE endpoint. For people who already have client-side EAP, this is not adding a lot. It's not as efficient as tailor-made password authentication in IKE, but OTOH it is much more generic.

Thanks,
	Yaron

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 15:04
> To: Yaron Sheffer
> Cc: Dan Harkins; Matthew Cini Sarreo; [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Dec 2009 12:04:14 -0800 (PST)

Hi Yaron,

  EAP is a client/server protocol. If either side can initiate the
exchange (necessary for site-to-site and transport) then each side
will be required to implement BOTH the EAP client and EAP server
state machines. "[P]eople who already have client-side EAP" will
need to add server-side EAP to their IPsec client implementation
and people who have server-side EAP today will need to add client-
side EAP to their gateway implementation. You say it's "not adding a
lot"; I disagree. Having written an EAP implementation (as well as
802.1x and several EAP methods) I can tell you it's a good sized
chunk of code that needs testing and debugging.

  Doing what you propose means:

     1. no AAA server for off-load is possible since both sides need
        to possess the shared secret and there is no AAA server in
        the world that can _initiate_ EAP.
     2. the EAP encapsulation serves no purpose since the conversation
        is just between the two peers.
     3. it takes twice as many messages.
     4. it involves a pointless exchange of identities which brings up
        further complexity in the case when the identity in the EAP
        exchange differs from the one in the IKE exchange. You'll need
        to check, what do you do and why?

  All this added complexity to a security product for what gain? Nothing.
For the other use case-- true client/server-- the EAP-only proposal
also has a security issue since the server can claim any identity it
chooses and the AAA server terminating EAP will "authenticate" it.

  So for 2 uses cases it's pointless complexity and for the other use
case it's got a security problem. Why is this a good idea? Because
"this is not adding a lot"? That's like saying that dirt doesn't taste
that bad without explaining why someone would want to eat dirt in the
first place.

  Dan.

On Tue, December 1, 2009 5:17 am, Yaron Sheffer wrote:
> Hi Tero,
>
> I think you are too quick to dismiss the option of using EAP-only for
> site-to-site and transport deployments, where the EAP state machine is
> embedded into the IKE endpoint. For people who already have client-side
> EAP, this is not adding a lot. It's not as efficient as tailor-made
> password authentication in IKE, but OTOH it is much more generic.
>
> Thanks,
> 	Yaron
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 1 Dec 2009 23:29:10 +0200

Hi Dan,

I will not argue about the implementation complexity. Such arguments are useless in general, and I certainly cannot argue with your first-hand experience.

But EAP does solve, perfectly, the client-to-server use case. The password can be offloaded to AAA or not, depending on security and performance considerations. And multiple choices are available for the authentication method, depending on various criteria like performance, IPR, security strength and others.

To repeat what I'd already said, the "lying NAS" problem can be easily solved with channel bindings, and will (eventually) be solved. Adding a few protected fields to any particular EAP method is not a big deal.

Thanks,
	Yaron

> Sent: Tuesday, December 01, 2009 22:04
> To: Yaron Sheffer
> Cc: Tero Kivinen; [email-masked]; Matthew Cini Sarreo

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 2 Dec 2009 10:31:19 +0200

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

> Sent: Tuesday, December 01, 2009 10:19
> To: Yaron Sheffer
> Cc: Dan Harkins; [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 2 Dec 2009 11:12:09 -0800 (PST)

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:
> 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.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 2 Dec 2009 21:42:51 +0200

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

> Sent: Wednesday, December 02, 2009 21:12
> To: Yaron Sheffer
> Cc: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Dec 2009 22:19:05 -0500

> adminstrative level) for the existing EAP-Public key authentication.

I concur with Tero's analysis and I agree that I would prefer to solve
the problem that SPSK solves.