Subject: [IPsec] Mandatory Public Key based authentication with EAP

From: Rahul Vaidya <[email-masked]>
Date: Thu, 11 Sep 2014 09:26:28 +0530

Dear IPsec Experts,

In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-rfc5996bis, there
is a statement:

"An implementation using EAP MUST also use a public-key-based
authentication of the server to the client before the EAP exchange begins,
even if the EAP method offers mutual authentication."

RFC 5998 which updates 5996 says:
"This document specifies how EAP methods that provide mutual authentication
and key agreement can be used to provide extensible responder
authentication for IKEv2 based on methods other than public key signatures."

The 2 statements are contradictory, given the 'MUST' requirement for public
-key based authentication in RFC 5996.

I request a view from the IPsec community on whether public key based
authentication can be avoided without impacting the security of the
connection/network.

Regards,
Rahul Vaidya

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Sep 2014 08:35:02 +0300

Hi Rahul,

This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply 
here. Note that it only applies in specific cases, and for specific EAP 
methods.

Yes, we should have updated the text in RFC 5996 to refer to 5998, but 
we forgot. Sigh.

Thanks,
	Yaron

On 09/11/2014 06:56 AM, Rahul Vaidya wrote:
> Dear IPsec Experts,
>
> In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-rfc5996bis,
> there is a statement:
>
> authentication of the server to the client before the EAP exchange
> begins, even if the EAP method offers mutual authentication."
>
> "This document specifies how EAP methods that provide mutual
> authentication and key agreement can be used to provide extensible
> responder authentication for IKEv2 based on methods other than public
> key signatures."
>
> The 2 statements are contradictory, given the 'MUST' requirement for
> public -key based authentication in RFC 5996.
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Rahul Vaidya <[email-masked]>
Date: Thu, 11 Sep 2014 11:14:12 +0530

Thanks for the quick reply, Yaron,

So does it mean that if an EAP method provides mutual authentication (e.g.,
EAP-AKA), then this particular text from 5996 does not apply? Or are their
further conditions which are not mentioned in 5998 where still the public
key based authentication is required?

Regards,
Rahul

On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <[email-masked]>
wrote:

> Yes, we should have updated the text in RFC 5996 to refer to 5998, but we
> forgot. Sigh.
>
> Thanks,
>         Yaron
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Sep 2014 08:59:04 +0300

Hi Rahul,

I am not aware of any additional conditions.

EAP-AKA is actually listed in the table in RFC 5998, Sec. 4.

Thanks,
	Yaron

On 09/11/2014 08:44 AM, Rahul Vaidya wrote:
> So does it mean that if an EAP method provides mutual authentication
> (e.g., EAP-AKA), then this particular text from 5996 does not apply? Or
> are their further conditions which are not mentioned in 5998 where still
> the public key based authentication is required?
>
> Regards,
> Rahul
>
> On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Rahul,
>
>     This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does
>     apply here. Note that it only applies in specific cases, and for
>     specific EAP methods.
>
>     Yes, we should have updated the text in RFC 5996 to refer to 5998,
>     but we forgot. Sigh.
>
>     Thanks,
>              Yaron
>
>
>         In RFC 4306, 5996 as well as
>         draft-kivinen-ipsecme-ikev2-__rfc5996bis,
>         there is a statement:
>
>         _________________________________________________
>         IPsec mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/ipsec
>         <https://www.ietf.org/mailman/listinfo/ipsec>
>
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 11 Sep 2014 10:15:26 +0400

Hi Rahul, Yaron,

> I am not aware of any additional conditions.

Sorry to pop up, but doesn't text from RFC5998 apply only
to EAP-only authentication? Isn't it an additional condition?

I mean, that if you perform EAP authentication, as described
in RFC5996, i.e. when responder does send AUTH payload
in its first reply to IKE_AUTH, then even if you use
EAP method with mutual authentiaction, the responder
must use public signature to compute this AUTH payload.

So, from my reading, RFC5998 updates RFC5996 in the sense,
that responder is not needed to send this AUTH payload
(and therefore, to use PK signature to compute it)
if (and only if) it receives EAP_ONLY_AUTHENTICATION and honors it.

Regards,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Sep 2014 09:19:15 +0300

Hi Valery,

Thanks for popping up :-)

You are right of course. The EAP_ONLY_AUTHENTICATION notification is 
mandatory in this case. I just didn't think of it as an additional 
condition.

Best,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Sep 2014 14:02:33 +0300

> Yes, we should have updated the text in RFC 5996 to refer to 5998, but 

Hmm.. I hope this does not mean we should update
draft-kivinen-ikev2-rfc5996bis (now in AUTH48) to say something about
this?

The RFC 5998 is standard track protocol that extends IKEv2 by
including new notifications to negotiate the mutual EAP
authentication, and also changes the payloads sent in the exchanges.

The current text in the draft is not incorrect, as if you follow the
protocol described in this draft, then the in draft is correct:

   An implementation using EAP MUST also use a public-key-based
   authentication of the server to the client before the EAP
   authentication begins, even if the EAP method offers mutual
   authentication.  This avoids having additional IKEv2 protocol
   variations and protects the EAP data from active attackers.

What we could do, is to add reference to the RFC5998 there, but I
think it might not be needed, as RFC5998 is clearly an extension to
the IKEv2, and we do not need to list all extensions to IKEv2 in the
specification.

What do others think? If we would earlier in the publication process,
I would say go for it, but adding this kind of text in AUTH48 is not
something I would like to be doing... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Sep 2014 14:59:46 +0300

> draft-kivinen-ikev2-rfc5996bis (now in AUTH48) to say something about

As there has not been any support in the list to add anything like
this to the draft-kivinen-ikev2-rfc5996bis, I assume we do not then
need to change it. 

-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 22 Sep 2014 17:30:17 +0300

So for the record, I do think we should add to RFC 5996, at the end of 
the paragraph that starts with "An implementation using EAP MUST also 
use a public-key-based" something like:

As an exception to this rule, public key authentication of the server is 
not required when using the extension defined in [RFC5998].

Thanks,
	Yaron