Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2

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

Hi Yaron,

On Mon, November 30, 2009 10:47 pm, Yaron Sheffer wrote:
> Hello Dan,
>
> [WG co-chair hat off]
>
> EAP-only authentication is a small IKE extension that does not change the
> existing IKE architecture; neither does it change many of the extant
> implementations. Given the right EAP methods, it would provide us exactly
> what EAP was supposed to provide from day one: mutual non-PKI
> authentication.

  I don't know where you came up with the idea that EAP was supposed to
provide us with mutual non-PKI authentication from day one. It was
designed for PPP and the trust model for which it was designed is
DRAMATICALLY DIFFERENT than the trust model used for IKE.

> And the solution is generic: any suitable EAP method can be deployed, so
> implementors can make their own security/interoperability/IPR/simplicity
> tradeoffs, instead of having one specific authentication method mandated.

  Please do not overstate your proposal. The only type of EAP method that
is suitable is one in which a password, and only a password, is the
authentication credential, and each side possesses that credential. Any
other EAP method can quite happily be handled in IKEv2 today, no need
for new EAP-only authentication proposals.

> To address your specific concerns:
>
> - The case of client-to-gateway authentication happens to be one of the
> top use cases of IKE/IPsec. Certainly not a "small use case". I'm not
> saying that EAP-only auth is limited to this use case, but it certainly
> solves it well.

  I don't want to get in a case of dueling marketing departments but let's
just say we disagree. Site-to-site IKE/IPsec is large, transport-only
IKE/IPsec is less so, and the <poof> that became the UMA market put a
serious dent in client-to-gateway IKEv2. But I will agree with you that
client-to-gateway IKE/IPsec using IKEv1 and insecure proprietary hacks is
also quite large today. And hopefully you will agree that it would be good
to provide a _secure_ solution to that market.

  I will take issue with your statement about limited use of EAP-only
auth. It really is limited. What you are proposing is for one, and only
one, use case of IKEv2. And what you are proposing is more complicated
than just solving it directly in IKE. You have failed to justify the
increased complexity and decreased utility.

> - It would depend very much on the specific product/scenario whether "both
> client and server state machines" need to be implemented. Specifically
> this is incorrect for client-to-gateway.
>
> - EAP as you well know is a 3-party protocol, it is not necessarily
> terminated on the IKE peer. So it is incorrect to say that "both sides
> MUST possess the shared secret" - exactly the right parties will need to:
> the client and the authentication server.

  Actually EAP is a 2-party protocol that, for optimization reasons, has
become viewed as a 3-party protocol. And therein lies the problem.

  Both sides will need to possess the shared secret for this proposal to
be applicable to all use cases of IKEv2. Note that a simpler proposal that
solves the exact problem you're trying to solve is applicable to all use
cases of IKEv2. You have to decide whether your proposal has limited
applicability or whether it requires unnecessary implementation of EAP
state machines, you can't have both.

  I'm sure you will agree that encapsulating messages in EAP buys nothing
and doubling the number of messages also buys nothing. But they both
cost something. Again, we have cost with no gain with your proposal but
less cost and more gain with mine.

  And now the security problem: an IKEv2 gateway can claim ANY identity
during EAP-only authentication. That has serious implications with the
security claims of IKE. If password-based authentication is provided as
part of IKE this security problem goes away.

> - EAP-only auth can also be applied to scenarios where no Auth Server is
> deployed. However in these cases both peers would indeed need a full EAP
> implementation.
>
> - The EAP community is (very slowly) coming to terms with EAP channel
> bindings. While this is not provided by your EAP-PWD (and I hope this is
> fixed before publication), EAP-EKE has been extended to add this
> capability.

  Very slowly being the operative words. And this disclaimer also nullifies
your previous statement of this being a "generic solution". It really
only applies to EAP methods that are password-only and have some extra
capability above-and-beyond EAP. On the other hand, we could have all this
with less complexity by going with draft-harkins-ipsecme-spsk-auth.

  It's a choice of more complexity, less utility, and less security OR
less complexity, more utility and more security. I don't understand why
you want to go with the former.

  Dan.

---

From: Martin Willi <[email-masked]>
Date: Tue, 01 Dec 2009 10:27:12 +0100

Hi Dan,

> And in that case EAP encapsulation of the underlying key exchange would
> be completely pointless and extraneous, would double the number of
> messages required to complete the exchange, and would increase the amount
> of security-critical code.

EAP authentication was not primarily included in IKEv2 to implement some
kind of password authentication on top if IKEv2, but to reuse existing
EAP methods and infrastructure.

The most demanding user of IKEv2 currently is the mobile/telco industry;
There are several specs in 3GPP and 3GPP2 using it. Many of them have
chosen IKEv2 because they can use their existing EAP-AKA/SIM
infrastructure for authentication.

>   It seems to me that EAP-only authentication in IKEv2:
>      1. does not solve a general problem;

It does. It allows to omit public key authentication in cases where
mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2
spec that already uses EAP-AKA/TLS only authentication, but does not
follow this draft. I really see a need for this WG item.

>      2. solves the specific problem it is aimed at poorly-- doubling of
>         the number of messages, requiring writing and testing of new
>         state EAP state machines that are, otherwise, unnecessary

If you're just talking about password authentication, yes. But this
allows IKEv2 to work in existing infrastructures (EAP over
RADIUS/DIAMETER). We currently see a strong demand for such solutions.

> To provide the benefits of EAP-only authentication [...] it would be
> much better to support the inclusion of "Secure PSK authentication" as
> a work item.

Implementing password authentication on top of EAP may be one reason for
this draft, but there are several others. And the separated EAP layer
allows you to forward authentication to an existing AAA server.
Further, many vendors already have generic EAP support. Implementing PSK
authentication on top of it is probably simpler and more flexible than
integrating it in IKEv2 directly.

Best regards
Martin

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Dec 2009 02:16:11 -0800 (PST)

Hi Martin,

> EAP methods and infrastructure.

  I understand. I'm not talking about EAP authentication in IKEv2 today.

  Please, don't misunderstand me. I'm not proposing to do away with EAP
authentication in IKEv2, I'm proposing a more efficient, more secure,
and simpler way of doing password-only authentication in IKEv2.

> follow this draft. I really see a need for this WG item.

  I guess I was just saying that certificate-less, password-based
authentication is not general. It's specific to the problem of
authenticating with only a password and no certificate.

  If 3GPP2 has a need for authentication with only a password and no
certificate please take a look at EAP-pwd! That will, apparently,
solve your problem. If it doesn't then the singular use of EAP-only IKEv2
authentication will not either.

  Furthermore, doing pointless encapsulations and doubling of messages
does not really seem to solve _any_ problem.

  Keep in mind that IKE/IPsec is, fundamentally, a peer-to-peer protocol.
While your client-server application is a very valid use case, it is
not the only one and it is important to solve problems generally, with
utility to all use cases, if possible.

> RADIUS/DIAMETER). We currently see a strong demand for such solutions.

  IKEv2 already works in such infrastructure. Yes, I'm talking about
password authentication. That's the only use for EAP-only authentication
in IKEv2. Any other EAP authentication can already be handled in IKEv2
today.

  I'm glad you have a strong desire for using existing EAP authentication
of IKEv2. But please understand that that is not what the topic under
discussion is.

> integrating it in IKEv2 directly.

  Please tell me what other reasons there are for this draft. This draft
solves one problem only-- using only a password to authenticate, with both
sides requiring plaintext access to the password-- and that problem can
be solved more simply and more securely than EAP-only, and in a way that
is applicable to all use cases of IKE.

  Note that the EAP methods being used to justify EAP-only authentication
in IKEv2 (the ones mentioned by the Yaron) DO NOT allow for forwarding of
authentication to a AAA server. Other EAP methods might but, as I stated
earlier, those are already handled today in IKEv2. The benefit you want to
apply to this proposal is not valid and what you seem to be requiring is
already provided for.

  Dan.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 2 Dec 2009 00:00:17 +0200

Hi Martin,

If you (or anybody else) support EAP-only auth (or any of the other 6 drafts), please commit to review it assuming it becomes a WG document. *This* was the main point of this discussion thread: we cannot make progress without committed editors and reviewers.

Thanks, and apologies for picking on you :-)

	Yaron

> -----Original Message-----
> From: Martin Willi [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 11:27
> To: Dan Harkins
> Cc: Yaron Sheffer; [email-masked]
> Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
> 
> Hi Dan,
> 
> Scanned by Check Point Total Security Gateway.

---

From: Martin Willi <[email-masked]>
Date: Wed, 02 Dec 2009 10:47:16 +0100

Hi Yaron,

> - 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?

I'm willing to review and contribute text to the EAP-only work item. We
probably start on implementing the draft soon, so I'll have some
feedback from the front...

Regards
Martin

---

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

Dan Harkins wrote:
>         state EAP state machines that are, otherwise, unnecessary; and,

Does it double, or does it really just "n+1", which is doubling if the
rest of the protocol has "n=1"?  I also wonder if this is really a
sufficiently compelling reason to have two sets of code.

>      3. is insecure (unless something used nowhere today is employed: EAP
>         channel bindings).

We can, and must solve this.

---

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

Yaron Sheffer wrote:
> This draft proposes an IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for one of the peers to present a certificate. This applies to a small number of key-generating EAP methods that allow mutual authentication.
>  
> Proposed starting point: http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt.
>  
> Please reply to the list:

I believe that this item is a lower priority than SPSK.
I would like to find a way to find a compromise, but recent discussion
suggests to me that it isn't possible.  Those who want an EAP method can
do that work in EMU.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 4 Dec 2009 08:32:51 +0200

To clarify: we don't want "an EAP method". We would like to slightly extend IKEv2 to use existing, and future, EAP methods that fit the bill.

Thanks,
	Yaron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: Friday, December 04, 2009 5:20
> To: [email-masked]
> > This draft proposes an IKEv2 extension to allow mutual EAP-based
> authentication in IKEv2, eliminating the need for one of the peers to
> present a certificate. This applies to a small number of key-generating
> EAP methods that allow mutual authentication.
> >
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 4 Dec 2009 12:43:55 -0800 (PST)

Hi Michael,

> sufficiently compelling reason to have two sets of code.

  For the proposed EAP methods, EAP-EKE and EAP-PWD, it really is
double. I don't think it's possible to do the kind of exchange that's
required-- mutual authentication, key generation-- in n=1 messages.

  If you look at the SPSK draft, it is doing essentially the same
exchange as EAP-PWD and doing it in 6 messages total. If you do EAP-only
plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't matter) it's 12 messages
total.

> We can, and must solve this.

  We can and we must. That's the easy part :-) The hard part is coming
up with a way to do it.

  One of the big problems with EAP is that it is a completely
underspecified shim. That's why every EAP method needs to roll-its-own
identity exchange (the identity obtained by EAP is not suitable for
authentication purposes) and roll-its-own fragmentation/reassembly code.
So the obvious, and in my opinion wrong, solution for channel bindings
is to just have each EAP method roll-its-own security capabilities
negotiation plus definition of TLV message exchange and a cryptographic
protection of that TLV message exchange as a way to solve channel
bindings. Another option is to have it done generally as some sort of
extension to EAP that every EAP method can "inherit". But mention that
and people who wear hats start saying what can and cannot be done and
what's in a charter and blah blah blah.

  Keep in mind, though, that however channel bindings gets solved, it
is only going to further increase the number of messages necessary to
get what you can get in SPSK in 6, and only 6, messages :-)

  Dan.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Dec 2009 07:34:34 -0500

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:
    >>> 2. solves the specific problem it is aimed at poorly-- doubling
    >>> of the number of messages, requiring writing and testing of new
    >> Does it double, or does it really just "n+1", which is doubling
    >> if the rest of the protocol has "n=1"?  I also wonder if this is
    >> really a sufficiently compelling reason to have two sets of code.

    Dan>   For the proposed EAP methods, EAP-EKE and EAP-PWD, it really
    Dan> is double. I don't think it's possible to do the kind of
    Dan> exchange that's required-- mutual authentication, key
    Dan> generation-- in n=1 messages.

    Dan>   If you look at the SPSK draft, it is doing essentially the
    Dan> same exchange as EAP-PWD and doing it in 6 messages total. If
    Dan> you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't
    Dan> matter) it's 12 messages total.

Is this 6 messages, times 2 directions?
Or just 6 messages. I can not quite see why the EAP encapsulation
*doubles* the number of round trips.  I can see how it might increase it
by 1, due to need to do some EAP thing.

    Dan>   One of the big problems with EAP is that it is a completely
    Dan> underspecified shim. That's why every EAP method needs to
    Dan> roll-its-own identity exchange (the identity obtained by EAP is
    Dan> not suitable for authentication purposes) and roll-its-own

Yes, I completed understand this problem.
I'm suggesting that if we care for channel bindings for EAP, that we
(security people who care) need to solve this once and for all.

    Dan>   Keep in mind, though, that however channel bindings gets
    Dan> solved, it is only going to further increase the number of
    Dan> messages necessary to get what you can get in SPSK in 6, and
    Dan> only 6, messages :-)

Again, I do not know why it has to double the number of round trips.
I see one extra round trip caused by the EAP-ID process, and then it's
the same number both ways.

Perhaps you can draw a time-sequence diagram for this to convince me?

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 7 Dec 2009 12:01:21 -0800 (PST)

Hi Michael,

  Here's some figures from I-Ds to illustrate what I'm talking about.
Some of the overhead is because both of these are technically client-
server protocols but IKEv2 is initiated by the initiator/client and
EAP is initiated by the responder/server (due to fact that it's design
was for PPP and authentication begins after "link up" notification to
the server-- a call is received at a modem bank, an 802.11 association
completed, etc). Both of these end with a message from the responder/
server so to fit these things together it requires some overhead beyond
a simple +1 message.

  Here's the IKEv2 message exchange for EAP-only from the I-D:

   Initiator                   Responder
     -----------                 -----------
      HDR, SAi1, KEi, Ni,
           [N(NAT_DETECTION_SOURCE_IP),
            N(NAT_DETECTION_DESTINATION_IP)]  -->

                            <--   HDR, SAr1, KEr, Nr, [CERTREQ],
                                       [N(NAT_DETECTION_SOURCE_IP),
                                        N(NAT_DETECTION_DESTINATION_IP)]

      HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
                N(EAP_ONLY_AUTHENTICATION),
                [CP(CFG_REQUEST)] }  -->

                            <--   HDR, SK { IDr, EAP(Request) }

      HDR, SK { EAP(Response) }  -->

                            <--   HDR, SK { EAP(Request) }

      HDR, SK { EAP(Response) }  -->

                            <--   HDR, SK { EAP(Success) }

      HDR, SK { AUTH }  -->

                            <--   HDR, SK { AUTH, SAr2, TSi, TSr,
                                            [CP(CFG_REPLY] }

Notice there are 3 messages for IKEv2 handling before the EAP stuff
and then 2 more messages after the EAP stuff. So it's 5 plus whatever
the EAP method adds. What the EAP method adds is indeterminate and depends
on the particular EAP method used (it shows 5 but that's just an example).
So let's plug in an EAP method that has been proposed for use in EAP-only,
EAP-pwd (EAP-EKE has also been proposed but it is exactly the same). This
is figure 2 from the EAP-pwd I-D (soon to be an RFC!):

           +--------+                                     +--------+
           |        |                  EAP-pwd-ID/Request |        |
           |  EAP   |<------------------------------------|  EAP   |
           |  peer  |                                     | server |
           |        | EAP-pwd-ID/Response                 |        |
           |        |------------------------------------>|        |
           |        |                                     |        |
           |        |              EAP-pwd-Commit/Request |        |
           |        |<------------------------------------|        |
           |        |                                     |        |
           |        | EAP-pwd-Commit/Response             |        |
           |        |------------------------------------>|        |
           |        |                                     |        |
           |        |             EAP-pwd-Confirm/Request |        |
           |        |<------------------------------------|        |
           |        |                                     |        |
           |        | EAP-pwd-Confirm/Response            |        |
           |        |------------------------------------>|        |
           |        |                                     |        |
           |        |          EAP-Success                |        |
           |        |<------------------------------------|        |
           +--------+                                     +--------+

So you see this EAP method does 3 request-response exchanges then a
success. That's 7 messages and 7 + 5 = 12 messages to do this exchange
using the EAP-only technique.

  Here's the same underlying key exchange done in SPSK, figure 4 from
the I-D:

     Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni       -->
                                <--    HDR, SAr1, KEr, Nr, [CERTREQ]
       HDR, SK {IDi, Commit, [IDr,]
                SAi2, TSi, TSr} -->
                                <--    HDR, SK {IDr, Commit, Confirm}
       HDR, SK {Confirm, AUTH}  -->
                                <--    HDR, SK {AUTH, SAr2, TSi, TSr}

That's 6 messages.

  So we have 6 messages for SPSK and 12 for EAP-only plus EAP method.
A more uncharitable, but arguably accurate, way of looking at this is
to note that the IKEv2 exchange, by itself, is 4 messages so SPSK only
adds 2 while EAP-only plus an EAP method adds 8. So really EAP-only plus
an EAP method is _4 times the number of messages_ of SPSK, not double.
And any channel bindings solution necessary for EAP-only will just
increase the number of messages.

  Dan.

On Mon, December 7, 2009 4:34 am, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>    Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBSxz2WICLcPvd0N1lAQInLQgAiLf0gKq8aHRAKq4r7oaAUXGYYqt9q3Kk
> g+KQYGjBrTmfXCEOYziSNonIN7XrjX4ePn7LHWk9AsWWh22y/esYF3Y5n4fkhktV
> an2SY9AE9CYz2PsXACZut2oRAM/YtHSeSnvvPbTzQ6i5bYoVeJqwthM4XIhpoFL1
> 6J9wY2owu1JzPI5KZeDDefbZscNjI7JVvHvI5deR8qtdykn2W2oOaxhaEEEpPY7p
> gIwkBIhFsnwSslF2sWUPmosDI/CTmo+KKFCa0QbXOP/D93raAgnNmKdDno9AwGjU
> FgAXkh/Z7102hkytkc64D6Lg7wU0fhxo+T+m5OkKV3RlfszjSQe9YA==
> =nC7X
> -----END PGP SIGNATURE-----

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 8 Dec 2009 20:07:45 -0600

> We can, and must solve this.

It's not just EAP channel binding that you need, but EAP cryptographic
binding.  Remember: what EAP calls "channel binding" is very different
from the meaning of "channel binding" used elsewhere (RFC5056 describes
the difference in terminology); EAP cryptographic binding is closer to
the more generic (IMO) meaning of channel binding.  (Just trying to
avoid confusion!)

Nico
--

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 9 Dec 2009 08:12:25 +0200

Hi Nico,

If I understand you correctly, EAP crypto binding is what IKEv2 provides by default, by including the EAP MSK into the IKE AUTH payload (RFC 4306, sec. 2.16 and 2.15). I believe what Dan is discussing is enabling secure transmission of ID parameters over the EAP channel (sorry...), which is exactly what RFC 5056 refers to as "EAP channel binding". Is there anything more that's needed?

Thanks,
	Yaron

> Nicolas Williams
> Sent: Wednesday, December 09, 2009 4:08
> To: Michael Richardson
> Cc: [email-masked]